« Dangers of Mixed Incentives | Main | Twitter-enabled Information Disclosure in Sports »




I'll bite. In terms of data and network security, can you talk about what makes a resilient enterprise and what how we might measure resiliency?

Jon Passki

We can figuratively move away from wood, but the steel and concrete buildings still burn because of what's in them, not because of their structure. Earthquakes and strong storm threats, though are mitigated.

This sounds like someone (client, maybe?) triggered your response. What brought on this topic? I have never encountered someone saying we shouldn't do security because it's too hard, explicitly. I've seen it not done because of budgeting priorities, mismanagement, etc., but not ever called out.


@Jon: latest mjr there have been many others tho

@Alex:as far as networks, last time i checked networks are supposed to a) dumb and b) untrustworthy. seems like expecting more than that is a bad assumption.

for data, how about encyrpted data v cleartext?

Rob Lewis


Another approach using your example:

Why not develop technology that makes wood inert and fireproof? It might take a decade or more to rebuild the city, or perhaps only new construction would be steel and concrete. What about legacy structures?

However, it might only take a year, or months to spray on a fire retardent barrier.

Adrian Lane

Sorry Gunnar, but I think that is a dubious distinction. I will posit that most thieves do not want to steal, but as no one is willing to hand them what they want, they steal because it gets them what they want. It is the direct path to achieving their goals and the items they gain outweights the percieved risks associated with the theft.

I meet young developers who want to write insecure code on a periodic basis. As the primary goal(s) of writing new code are focused on project completion, impressing the boss, or to look like they are actually doing something, I claim there is no practical differentiation between that and intentionally writing insecure code. The results are less subtle, but the code is insecure. Pure desire to write insecure code may be lacking, but as writing secure code is orthogonal to the primary goals, secure code is accidental. Is expending just enough effort to get the code checked in and past the nightly build materially different?



In many respects, secure software is a software project management issue.

I wonder how many of these 'security thought leaders' have read Fred Brooks' "Mythical Man Month", or Tom DeMarco's "Why Does Software Cost So Much"?

The important themes concerning the construction of complex software systems haven't changed much over the years.

The comments to this entry are closed.