Monday, September 21, 2009

Is Risk Just Too Risky?

BlackHat made me think about risk a lot; I also had a bunch of fun conversations about that very subject. I had a chance to play both sides: for example to argue that “risk is a scam and risk management is voodoo” as well as to argue that “striving towards scientific risk computation is the most important pursuit in security today.” After all, that is what conferences are for..

So. Let’s start our discussion of risk from … compliance. The “enlightened security dogma” goes like this:

  1. Audit mentality + compliance + checklist –> bad for security
  2. Risk mentality + protection + risk-based policy –> good for security.

This comparison looks easy – pick #2 and you automatically join the club of deep security thinkers. Recently I was reading a document written by a noted security consultant and the document started (started!) like this: “1. quantify all enterprise risks.”  Apart from a loud ROFL and possibly even a ROFLMAO, such sentiment does not elicit any other response since few if any organizations can just go and “quantify all risks.”

Now, let’s try this comparison for size:

  1. Audit mentality + compliance + checklist –> bad for security
  2. Risk stupidity + protection of random assets with random safeguards + opinion-based policy –> ???? for security.

Not so easy now, huh? In other words, comparing the “evil checklist” to the “good risk-based approach” requires taking into account the current “state of the risk art” at an average (if there is such a thing…) organization. At least, I think that it IS required to keep this debate practical and not philosophical.

Thus, let’s see what can we do with risk:

  1. Ignore risk: just ignore it, hide under the desk, read a PCI book :-)
  2. Banish risk: read Donn Parker to learn everything about this approach.
  3. Manage risk: this (as they say) requires you to first measure it since, presumably, “you can’t manage what you can’t measure.” So …
  4. … Measure risk: this is where all hell breaks loose since there is no accepted approach for measuring risk in information security (for as long as you stick to the accepted definition of “measure”; and, no, “ALE” isn’t it :-)). Thus, some folks propose that you can just …
  5. …Guess risk: this is where an expert defines what is risky based on his opinion. Approaches such as FAIR seek to replace guessing at risk with guessing at its constituents; they cannot be simply discounted as GIGO since they improve the quality of the guessing – while remaining such.
  6. Reduce risk: this (as they say) does not require you to measure it. It also makes my head spin :-) since whenever I think about it I see a thermometer that moves up and down, but has no numbers or units. I still classify this as a special case of “guessing risk”: such as “Oh, I guess that lowers it!” or “No, that’d be too risky!”

In light of this, let’s do a simple test of “risk-based security.” So, dear risk aficionados, please give me the answer to a simple security question:

What is the risk-driven, correct frequency of changing my email password?

<crickets…. silence… more silence>

Yes, we all can quote that “PCI DSS says 90 days” or “whatever regulation says 30 days”, but what does risk say? What actuarial information we need - if we are to define risk through probability of loss? What info about my email usage? Value of information stored there? Frequency of attacks on other similar email accounts? Chances of attack success? My approach to protecting the password? My personal password reuse “policy?” Anything else? On a related note, maybe this is simpler: what is my risk [of having the account compromised] if I change the password every 30 days, 90 days, 300 days?

So, any idea how to go about it?

This little experiment might well show us that “risk-based security” is an awesome thing – but not one achievable in this world today…

Possibly related pots:

Obligatory “added everywhere” posts :-)

  • I am not at Qualys anymore and looking for the next big security idea to work on! I might be available for consulting projects.

Dr Anton Chuvakin