Update: Windows Onecare is saying the site that was linked here has a virus on it. Sorry folks, it was completely my fault for sending you a link that was susceptible.  It has the Decdec.A virus - Sophos information here.

Thought I’d point out posts with a theme for us today:

THE ROI THING

Ken Belva takes Richard Bejtlich’s pragmatism to task on speaking value to business.

In a related post on the same Bejtlich article, Cutaway says:

An overall security plan is not designed, or should not be designed (unless it is the SBP Security model), to merely “prevent or reduce loss.” It should be designed with the intent of providing an organization’s personnel with additional tools and practices to manage their processes and technologies while reducing risk. The technologies that are implemented as a part of a security plan should not be utilized by the organization to only prevent, identify, and mitigate security related issues. The administrators within the organization should be using them to help identify problems that are impacting performance and availability.

Cutaway later posits the following definition for ROI:

“the ratio of money gained or lost on an investment relative to the amount of money invested.”

I believe he’s right in both of those cases, and that unfortunately means that we are SOL concerning ROI. Risk & Risk Management (his first paragraph) is a probability issue (Risk = LEF & PLM, right my FAIR folk?) that definition does not include probability.

That’s not to say that we can’t show worth. You remember what we’ve been saying about IRM’s ability to show value, right? We can reduce risk, reduce loss, or provide operational efficiencies. That’s it. Well you actually can, with historical loss data show that our investments reduced loss, yes. And you might be able to show the result of a productivity increase due to an investment in a new security control. However, unless you change the definition of ROI to reflect reduction of probable losses, we can’t speak *well* to showing an ROI because most of what we do is attempt to reduce the frequency and magnitude of probable loss events.

BACK TO KEN BELVA

I want to point out something Ken says, because his writing here is very well thought out, but they beg consideration by the erudite readers of this blog:

Let’s return to the question I assume the CISO is trying to ask:

“Why can’t risk be quantified in the Information Security field like it can be in the field of finance?”

Here are a number of ways to respond (and he lists the following - my comments in italics)

• InfoSec can be quantified but it is a young field and we do not have mature models

Readers know that I think this *has* been true, but I believe we now have the basis to create mature models.

• InfoSec can be quantified with existing models but is not worth the time and effort to adapt it to each environmental architecture (especially due to the volume of changes within a particular architectural landscape)

I can’t agree with this. If you can’t quantify risk in a meaningful, timely manner and use it to make your business decisions, then either 1.) your model sucks (insert link to 800-30/OCTAVE here) or 2.) your risk management program sucks (or both).

• Quantified analysis is not as meaningful as qualified analysis when describing InfoSec events [Note: This is my personal belief and I think it’s one reason why DHS uses colors and words instead of numbers.]

I could pick on his use of DHS as a shining example here (see threatmeter.com, above), but there is truth in that where the source of the analysis has a history of transparency, consistency, and their conclusions are defensible - then oversimplified qualitative analysis can be used. My guess is that DHS hasn’t been transparent, consistent or able to defend their analysis. The accuracy provided by *real* quantitative analysis opens all sorts of doors of perception.

• Not all risk can be translated into numbers (unquantifiable risk)

My first reaction to that one was “bullcrap”. Now whenever I have such an adverse reaction to a statement, especially when stated from someone as smart as Ken, I have to kind of wonder what I’m missing. It’s a gut check thing, “Don’t be so quick to judge, Alex” I tell myself. So in thinking about this last bullet, A couple things come to mind.

First there’s the fuzzy definition thing - risk (LEFxPLM) vs “risk” some non-specific concept used to describe the fact that a threat can act against us. Moving beyond the murky definition issue (because we do know what Ken is saying here) - I’m trying to think of a threat scenario that I couldn’t quantify. Can you? Leave some comments - I’m wondering - if we use a FAIR definition of risk, what *can’t* we quantify in a non-useful manner?

Posted on July 13