For those of it who don’t have a subscription to IEEE’s Security & Privacy newsletter, we can still get a PDF of Dan Geer & Dave Conway’s new essay/column/article, “Security is a subset of Reliability.”

Reliability measures the deviation between the system and the specification. Security involves a sub-space of reliability—only particular deviations—thus, security must be easier than reliability. Thumbs up. Hastening over the delicate premise that the specification is always accurate and up-to-date, we can roughly align security with the subset of reliability where the cost of deviation per unit time is very high. Thumbs down. This makes us wonder about measuring how risk tolerance scales and consequently where to point our thumbs.

Similarly, since I’ve been talking to lots of engineering types about security issues of late, I’ve been using the argument that “security issues are a subset of defects, especially post-release defects, which tend to have a higher-than-average severity.” This gets their attention since PRD’s are something they worry about, even if they consider it somehow “unfair” that they’re a category of defect that they aren’t very good at.

I’ll definitely be passing this article along to a few people I know.

I find that the problem with engineering risk management to zero defect spec (goodness knows, I believe that rooting out the strategic cause of variance is the real definition of risk management) is that it assumes that weaknesses in information systems are prime cause of incidents. One simply cannot engineer five nines worth of human behavior or physical security.

True, Alex, but it provides a useful framework to quantify the impact of failures, even in processes/workflows (algorithms for people). That framework, in turn, provides us with a mechanism for understanding the risk of a particular process, which then allows us to determine whether or not additional controls are needed to get the risk down to an acceptable level.

Another area where there is still significant room for improvement is in configuration. It’s frequently a fairly manual process which produces a lot of risk if done poorly. Again, the post-release defect model provides a familiar framework to explain to people why security issues matter.

Oh, I’m not denying that, or trying to denigrate the work there.

I’m just saying that if you *really* want to know your “risk” (i.e. do risk management) you’re still gonna have to layer sixsigma or lean or something on top of that framework, and on fairly subjective things like “visibility” into more landscapes than just controls and assets.

OK…I see where you’re going now. You’re trying to actually get to the risk. I’m just trying to get them to agree that there’s some point in talking to me.

Unfortunately, the reality of corporate culture is the chicken-and-egg problem that very few people want to know their risk until they can explain how it’s been or is being managed to an acceptable level.