This morning brings talk of Pareto, Ruby (Tuesday) on Rails, and Risk to my RSS reader and our blog.

“SECURE” VS. ACCEPTABLE RISK

First, I thought we might have fun discussing the nature of security, risk and compliance. Lots of praise for Marcus Ranum when he says,

Will the future be more secure? It’ll be just as insecure as it possibly can, while still continuing to function. Just like it is today.

This sounds like a very well thought out means to explain to people that the goal of “100% secure” will always be tempered by the risk tolerance of those with the resources. I made a little graph (primarily because I’ve been trying to get better at using OmniGraffle to create ad hoc graphs).

So it’s not the best piece of work. The curve is kind of goofy on the ends, I know. But I hope you get the idea.

Within the context of Ranum’s comments: The balance between investment and risk reduction is not perfectly “market efficient”. I’m don’t mean to nitpick or say that his wisdom is inaccurate, just that there are inefficiencies we should note. What are the nature of these inefficiencies?

Firsk, future events are uncertain. We can be perfectly at ease with our risk tolerance and still suffer loss. Risk is a probability issue. We cannot foretell the future with certainty, only measure our certainty concerning the future. So as we determine current state, we can have an accurate probability statement, but that’s not going to tell you that “X will happen” with 100% certainty at a point in time. This is akin to us knowing that there’s a 1 in 36 chance that I’ll roll double sixes using two six sided dice. We’re both precise and accurate in the knowledge of our odds - the probabilities involved. However, we don’t know if we’ll roll double sixes with the next roll, or even in the next 100 rolls. In the same way, we can be efficient in addressing risk and risk tolerance, but still have incidents (more on this as it relates to vulnerability for Shrdlu in a post later this week).

Second, there are tons of biases that our decision makers will use in determining their risk tolerance. The decision maker may easily over or under estimate their need for risk reduction. Cybercops and risk analysts can disagree over whether overestimation is beneficial or inefficient - but the point is that plenty of folks operate in a more secure manner than they need to in order to keep “continuing to function”.

Third, we have a “risk tolerance floor” (think price floor for a market) established by the various mandates for compliance some industries face. HIPAA, PCI, NERC, (insert your pain here) take the power of determining risk tolerance out of the hands of the decision makers and put it in the hands of someone else. Some are so completely prescriptive that they involve maybe too much spending or (maybe not enough - see below). Which is a nice segway into a discussion of Ken Belva’s most recent post.

COMPLIANCE, SECURITY, AND RISK (ARE WE SICK OF IT YET?)

I’m not! There’s so much to be discovered! Folks, I really believe that over the next few years we’re about to make things better not only for our stakeholders, but for us as well. This isn’t optimism about our ability to resist the forces that threats apply to us (the source of much apathy and pessimism) as much as it is an optimism that we’ll be able to do a much better job at organizational information risk management.

One of the things that’s going to make a significant difference is going to be changes in our understanding of risk, security and compliance. Ken Belva claims that there’s a false distinction between security and compliance. Well, yes and no.

First, it’s important to differentiate between “state of compliance” and “results of compliance efforts”. State of compliance is something that we account for as a factor that contributes to the probable magnitude of loss as we determine risk. Results of compliance efforts are either positive or negative effects on our capability to manage risk (i.e. our ability to create a secure environment). These are two different things.

So in terms of “being compliant”, that is, our state of compliance, it has little to do with “security” - and everything to do with the amount of probable losses in the instance of incident. In FAIR, we talk about compliance being part of the Fines/Judgments category for probable and worst case losses. Remember how I called compliance a “risk tolerance floor” above? That’s because many times FAIR analysts see scenarios in which the severity of risk increase dramatically just because of fines/judgments added by external stakeholders (governments, credit card companies, etc…).

Achieving some “State of Compliance” does create some results that we can quantify in terms of our capability to manage risk, what I referred to as the “results of our compliance efforts”, above. But unlike the title of Ken’s blog post suggests, I think this can just as easily be a negative as it can be a positive in its impact on our security posture.

For example, let’s say that the CISO knows what he needs to do in order to increase his capability to manage risk. Maybe that’s better process or project management, maybe that’s the establishment of a good S, C, &A process, spend more resources on log management, whatever. If those things aren’t either prescribed by the compliance program, or those who are in charge of applying this external risk tolerance are too unsophisticated to properly value the worth of those efforts in the context of their “checklist”- there may be a negative impact on the organizational capability to manage risk.

My favorite example of this is an audit I did as a consultant for a small F.I. service firm. Their upstream provider insisted that they comply with BITS AUP. Now the engine that drove this F.I.’s business was a dozen web sites. Nowhere did BITS AUP ask for review of any measures that would give us direct indication of web application security. As a consultant, understanding the current situation, I couldn’t in good conscience not address the issue. Sure enough, 2 minutes into an interview with the developers, they admitted the whole portfolio of sites was, in their words, “a giant XSS farm”. BITS AUP seemed it would rather have me chasing earthquake sensors and floor to roof walls for their server closet than address what would I thought would be a more frequent source of loss events.

Another thing to note is that the results of our compliance efforts may give our decision makers an inaccurate understanding of their risk. Mark Curphey writes about that subject today - The Ticking Time Bomb - PCI Application Security. We may be deemed, PCI (or whatever) compliant - but still have significant probability of loss event. Yet this is not easily distinguished by the non-technical decision maker. Worse yet, it can put the CISO in a “who do you trust more, me or them” situation.

So when Ken says that best practices are attempts to lower risk, he’s correct. But that has nothing to do with my use of the word “transfer” in that quote. I’m not quite sure Ken understands what I’m saying there. Just to clarify, my assertion is that individuals will be doing risk analysis, whether they like to say they are or not. The only question is with what rigor. Some people (Donn and maybe Richard) are uncomfortable with their understanding of probabilities. So rather than be wrong in making a belief statement about probabilities, they transfer the risk of being wrong to a checklist. This transfer of risk is a completely independent “risk issue” than their capability to lower the risk to their stakeholders. It is a personal risk analysis they’re doing about risk analysis.

Posted on September 25