So yesterday I asked readers to comment on thoughts I had that came from a question asked on the ISO 27001 Google Group:

“How I can communicate the value of an ISO implementation to non-security management?”

This question came to me after one of the posters on the ISO Google Group asked about KPIs for ISO implementation.  Got great responses in email, blog comments, and on Twitter from current/former CISO folks and consultants and analysts.  Some really great thought and effort, by the way - thank you.  It’s really great to be able to have these sorts of conversations online.

First, I have to point out some resources Brian Honan linked to from Gary Hinson, just because they’re so cool.  Gary has invested gobs of time and effort to become one of the defacto resources on the ISO (you might also want to read or re-read Gary’s web post on the 7 myths of metrics).   Brian links to an implementation guidance document(pdf) and a metrics example(pdf) document.

As full of awesomeness as they are, though, these are simply metrics “mapped” to the ISO (i.e. the ISO isn’t a pre-requisite for generating this information).  They are not KPI’s that express the value of ISO implementation.  Problem is the metrics created here still require some level of “translation” in order to create some value statement that data owners can understand.  As Myrcurial twittered me “27001 is orthoganal to process” meaning (I hope) that metrics have their foundation in events that are generated by processes.  27001 by itself was never meant to create metrics (see above), and so we’re asking a question the ISO can’t answer.  But the desire, the need to measure still exists.  To that extent we can google “ISO compliance” (whatever that means) and if something can be certifiable or deemed “compliant” we can and are “measuring”.  But does that have value? Rybolov (my favorite Guerilla CISO) wrote:

“Whatever you do, don’t start measuring percentage of compliance. Eventually, that’s what all metrics efforts around a framework devolve into.”

I have to agree.  Being ISO “compliant/certified” has little expressive business value prima facia. I find that one KPI that absolutely asserts value when expressed properly is risk - and similarly  Shrdlu wrote:

“I really have no idea. I personally wouldn’t try to justify an ISO implementation by itself. If I could show traceability on how it affected our overall security risk, then that’s what I’d do.”

And that’s a delightful answer.  That “traceability” (geeze-louise Shrdlu - what a word!) is absolutely what I’m after here.  How do I get that?  

If you’re going to do something with corporate budget (time, money - and goodness knows an ISO implementation is time & money) you better be able to communicate the value.  And while the zealotry for ISO implementation differs from person to person, I have yet to come across someone who says that ISO adoption is totally without value.  It’s just not apparent what that value of adoption is and how we can measure (metrics) and express it (KPIs).

Jenean Paschalidis wrote what he thought that value was in a very nice email in which he puts a qualitative name on the value of adoption:

“Transparency and accountability-this is what all executive/senior management (the company) is on the hook for. ISO provides that. If you want to understand and have confidence in your operations as supported by security (because you will know the who, what, where, when, why and how of a system (human, technical etc.) and you want to be able to trace back why a decision (risk-vetted) had been made - then adoption of this best international practice will assist in providing these answers.”

So working with our above thoughts a little here - if we agree with Shrdlu that the only value of an ISO implementation can only be expressed if we can say how said implementation affected our overall security risk - and we agree with Jenean that the primary benefit is an ability to have confidence in operations as supported by security, then….

The value of the ISO should be expressed as a KPI or set of KPIs that cleary explain how the confidence it generates helps us understand (and then reduce) our risk.

If risk is a probability issue,  ISO adoption helps generate confidence in our predictive analytics.  The dollar value the ISO generates (the ultimate KPI) is part of the cost of being able to make wise risk decisions.

So what is that (making wise risk decisions) worth to you?

SOME CONCLUDING THOUGHTS

First, it occurs to me that this is a real shame.  In a sense, an inability to generate a quantitative value statement for ISO use is simply more witch-doctory (“use it because we, the wise men of the tribe say you should”).  In some future version, the ISO should include some mechanism for measuring and expressing the worth of adoption to the organization (a better reason to use the ISO than “because we said so”).

Second, It should be noted that of Jack Jones’ 3 true value statements from which all metrics/KPIs should point to - we’re only talking about one of those value statements - the ability to reduce risk.  Using the ISO in an organization most certainly could create operational efficiencies (help us do more with less) - but the ISO isn’t a standard that creates operational efficiencies as a primary goal, nor does it give implicit direction on how to create operational efficincies.    The ISO folks do, however, play fast and loose with the idea of “risk” and “risk management” so it’s within this context that I interpreted our conversation.

Finally if you’re going to hire someone to help you with ISO adoption in your organization, the deliverables you ask for in your RFP/SOW/what-have-you should include quantitative (probability) statments about risk reduction and the creation of operational efficiencies.  If the firms answering can’t tell you what value their work will be to your company, then drop me a note and I’ll gladly point you to some friends of RMI’s that know FAIR & all our Risk Management frameworks and also do great ISO work.

On Gary Hinson’s excellent ISO 27001 Google Group, the following question was just posed:

Dear Implementers:
What could be the KPIs by which I, being Management Representative,
can show complete picture in a compiled brief/short report? Your
response would be highly awaited.

Which I think is a great question!  Talk about no-nonsense.  None of this “high-falutin” nonsense about ISO adoption providing ‘piece of mind’ and ‘common language’ or ’strategic currency’.  No this is straight from the hip - tell me right now how I can communicate the value of an ISO implementation to non-security management.

I’m not sure I’ve got a good answer.  Do you?  You guys (loyal, cool, readers) are really bright and many of you CxSO’s in your own organizations.  Leave comments and in our next post  I’ll publish the best and brightest (as well as some of my own thoughts).

Usually I beg off of doing posts that link to other posts (Liquidmatrix does a great job of this on a regular basis), but I was afraid that James & Dave’s usually excellent intern might miss some items of note and so I thought I’d offer up a couple of things today:

1)  Gunnar has put up his speech as the Quality of Protection Keynote:  “The Economics of Finding and Fixing Vulnerabilities in Distributed Systems.” Don’t worry if that title doesn’t turn you on, his post is one of the best this year.  I wanted to make today’s blog post some reflection on what he says there, but I haven’t the time today and we’ll have to table that until next week.  Anyway, it’s excellent.

2)  Aleks Jakulin writes about The Future of Data Analysis.  I spoke with a CSO who is morphing into a CRO role and one of the things he plans on doing is hiring about  a half dozen data analysts.  If you think better use of Security Information is in your future, you’ll want to take a look at that blog.

3)  Brent Huston of the Ohio voting machine fame writes about an incident he just worked on and risk and rational security.

4)  Our friend Mike Rothman and our friends at Business Of Security/Cisco are doing a Pragmatic CSO thing.  Mike is always entertaining and practical (dare I say, pragmatic) so I think this should be a fun webex.  Hope you’ll sign up.

Namaste Risk Geeks!

Hope you all had a great weekend.  I had meant to point you earlier to a FAIR analysis that Chris Hayes did over at his Blog.  But I’ve been a little busy, and before I could mention it, Stuart King put up a kind of angry response on his ComputerWorld blog.  Snark aside, there are a couple of other really troubling aspects of Stuart’s reaction to Chris’ analysis that I thought we could talk about this morning.

The problem is that (Chris’ analysis is) completely impractical. I’ll take a recent, and fairly typical situation as an example. I was taking issue with the manner in which remote access was being provisioned for a third party vendor to connect to a system hosted by one of our European business units. To cut a long story short, it was not only a breach of policy but highly insecure. I wanted the access to be disconnected, the business unit director wanted my risk assessment. And he didn’t want to wait for it.

To quote Chris Hayes, spending time on working out the expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force was not going to pacify an angry Italian fearful that my decision was going to cost him money. He wanted my explanation of the risk and more importantly, what I was going to offer as a solution to keep his business functioning

As Chris is someone who actually does this for a living in a large company, and this is typical of his actual day job, I really find Stuart’s “impractical” comment to be, um, misinformed.

Also, I think Stuart mistakes the purpose of a risk analysis.  The purpose of the risk analysis is not to force someone to be “secure”, but to provide knowledge for decision making.  Using it as a “hammer” to knock in the nail of your personal risk tolerance impairs efficiency and in the long run retards “security” as it creates political resentment.  Seriously, who cares if something might violate policy or not in a pre-implementation discussion?  Policies are not stone tablets handed down from on high, they are state-in-time codification of the data owners risk tolerance.  This risk tolerance changes sometimes, and that’s OK.

To that extent, I appreciate (and I’m sure Chris does, as well) that risk analysis does not create rationality in the data owner.  Someone who sees you as a speedbump on the route to progress they may not be ready to appreciate your point of view even if it is stated in the most rational manner possible.   But it’s worth noting (and Stuart’s example is indicative of this point) that risk analysis does not create rationality in the analyst, either.  If one is being so “security minded” as to ignore the risk tolerance of the business owner - we’re bound to get a reaction similar to that Stuart encountered.  In fact, a practical risk analysis like Chris performed on his blog, done in 30 minutes, should identify the critical point of disagreement between Stuart and the data owner (again, Stuart doesn’t own the data, the agitated Italian does).

But let’s stay rational and open to alternatives to what Chris offers.  Stuart states his approach to risk analysis as:

When I need to document a risk assessment I use a very simple form: list the threats, state the level of vulnerability, list the associated operational costs and potential revenue hits. High, medium, or low risk? Describe the controls and options. Write up who needs to do what, and how much of their time it’s going to take. Job done.

At first glance, I don’t think what Chris has done is any less efficient, and it provides greater insight (using Frequency and Capability instead of just ‘listing the threats’).  But what is key here is that Chris’ approach is consistent and defensible.  Less generous risk geeks and CSO’s I know would have no little difficulty with Stuart’s approach.  But to particularly answer Stuart’s main objection (impracticality) I would offer that with practice, Chris’ work is probably quicker and easier than Stuart’s described process as it eliminates much of the ambiguity an immature risk analysis creates - reducing the need for further discussion and arguments with data owners (regardless of disposition or nationality).

Finally the irony of Stuart’s post is that the reason he had this confrontation may in fact be because he was incapable of bringing a salient model for risk to the table, one that identified the factors that create risk and developed a defensible belief statement concerning risk.   We’ll never know if one would have helped him in this isolated instance, but I can tell you that in organizations like Chris’, good risk models and strong risk anlayses create operational efficiencies, reduce costs, and streamlines intra-departmental communications.

Pre-Script - It should be noted that the outcome of this discussion - in the last paragraph - is one smart way you can approach the “We need to reduce your budget” discussion (if that discussion hasn’t come already).

I’ve often read people who say that we (security, risk management) need to “think like the attacker”.  And when you read this sort of article, that usually alludes to trying to anticipate the tactics an attacker might use to mess with your C, I, or A.  Smart stuff, that, and very useful when architecting security solutions.  But as I was training some folks Monday, I was thinking in the back of my head about Threat Capability (TCap) in FAIR.  As you might know, we like to estimate the capability of a threat to apply some level of “force” against our assets.  This ability to apply force is a byproduct of the attacker’s skills and resources.  And thinking of how an attacker applies skills and resources, I came across another way we might “think” like an attacker.

Traditionally, I’ve thought of “skills” as being a byproduct of the toolset an attacker has.  This mindset probably stems from my time with Penetration Testing teams, where in the process of scoping the  PenTest I would ask our clients to select the level of effort that they wanted us to throw at them.  If a client chose “high” we’d throw every ‘spoit we had at them.  If they chose “low” we’d limit ourselves to a more commonly available toolset.

But while the resources part of TCap is time & materials (money) - the skills are really more than just the toolset.  Skills would include the ability of the attacker to be creative and innovative.    As an example of that innovation from those PenTesting days - when we got a “high” effort request, we would always try to couple that with some “social engineering”-type of attack, or some unique means of delivering an existing exploit.  Our creativity was not necessarily a byproduct of a unique exploit or tool we had, but the process by which we might deliver pre-existing or commonly available exploits.  I remember when we first got ahold of a handful of 32mb thumb drives (hey, 32mb was huge back then) and “dropped” a few in the lobby of a client’s retail space.  The keystroke loggers and phone-home script weren’t new, but using the thumb drive as delivery vehicle certainly was.

So I’ve started to really think about this concept of innovation, and how if “thinking like an attacker” means to be innovative, we ought to do the same.  I’ve been thinking of two main categories of innovation this morning.

INNOVATION

The first I’ll call Technology Innovation.  And by Technology Innovation, I mean some new, unique, “ahead of the curve” technology that an attacker can use against us.  The obvious example of which is a zero-day.  It’s that “high” tool set our PenTesters would use against the clients.  For security departments, this might be the latest security product designed to enhance our ability to P, D, and/or R.

Alternately, we can be creative in the way we deliver (manage) existing technology.  I think of this as Process Innovation.  It’s doing more with what we already have, just like the PenTest team would be creative in the delivery of an existing exploit.

Unfortunately for us - attackers have traditionally had quite a leg up on us in terms of Process Innovation.  It is much easier fro them to be creative, as they are free of political constraints and bureaucracy.  In contrast, when the security industry tries Process Innovation, the results are checklists and “standards”.  It’s committees and consensus.  An extreme example of which might be something like SABSA - a great work if you want to understand some very smart people’s comprehensive understanding of organizational security  - but the “adoption”of which will do very little to help you be innovative in P/D/R.

It’s worth noting that ultimately, this is one reason I don’t like regulatory compliance efforts - they simply serve to prove how mundane your security department is,  wasting valuable resources that could be spent on creating ways to be more effective.

PROCESS INNOVATION AS A SUBSTITUTE FOR TECHNOLOGY INNOVATION

As we come to the close of 2008, some surveys suggest that security spending isn’t horribly impacted yet by the economy (the latest from E&Y points to only 5% of their respondents getting budget cuts).  But if this is a protracted downturn, and because InfoSec is an operational expense, I would expect cash to become more and more difficult to keep.  And regardless if technology spends do slow, I believe it makes sense to think about Process Innovation because I see Process Innovation as a means to increase effectiveness without significant capital expenditures (effectiveness increases because our ability to manage risk has a direct correlation to the amount of risk we have).

The bad news is, of course, that great innovation is hard.  It is R & D.  Failure is usually a pre-requisite to success.

The good news is, our current state is so bad that many of us don’t need to come up with a whizbang new way of reducing software defects in the SDLC as innovation.  Simply inserting a risk analyst into the PMO’s processes might count as a big enough victory. Be cautioned, though,  that if we’re substituting the risk reductions provided by technology acquisition - Process Innovation might actually be even more “expensive” as it requires us to expend political capital.   But there are (forgive the term) innovative ways to spend this political capital.

For example, by taking a second now and figuring out the 3 things that the rest of the organization can do to make your life easier, when that “I need to reduce your budget” talk comes, you can be prepared to negotiate.  Get a political capital “loan” or “investment” from the C-Suite reducing your budget.  Something to the effect of: “I expected this, and am happy to give up my budget.  But if our tolerance for risk hasn’t changed, what I’d like to do is get you to personally back my office on three projects I’ve identified that can reduce our risk without requiring significant capital expenditure.”

There’s been quite a few people talking about what sorts of strategies make sense for security and security departments in a downturn.  And they’re all very good - but there’s one thing that I’d like to add.

One easy, inexpensive way to actually increase your effectiveness in 2009 is to, right now, make a quick review your risk management processes.  As you take a look at how you’re using risk in your organization, I’d ask you to make sure that those processes are providing value for the energy you’re spending.  If they’re not - if you’re not successfully using risk within security and with the other lines of business that you serve - then I’d like to invite you to  come take advantage of RMI’s public training session for 2008, held in Columbus, Ohio on December 10-12.  >A brochure is here<.

For three days and $1,995 - you’ll get real answers to many of the commonly voiced frustrations RMI hears concerning risk & risk management.  Answers around measurement, application, communicating risk to other lines of business, heck, basic answers as to what risk is and how to get consistent, defensible values that actually mean something.

Not to mention - Strengthening your Risk Management processes increases your ability to manage risk, which reduces the amount of risk you actually face.

NEW TO THE PUBLIC STUFF!

I’m personally excited because this is the first time that our public training will feature measurement “calibration” exercises and include excel tools to take home and use for quantitative FAIR analysis.  These are benefits we’ve only previously reserved for private client workshops.

I know that FAIR can help you and your organization, but as the sales guys always say, “don’t take my word for it”.  Here’s something we recently received (unsolicited) from the CSO of one of the 10 largest banks in the US, who has had several of his analysts receive this same basic training:

I would like to also add my deep appreciation for what FAIR and RMI has brought to (us) and how we go about the business of risk analysis. We have had some great conversations around risk with the lines of business that have ended very favorably for us.

More information can be found on RMI’s website here:  http://www.riskmanagementinsight.com/12_2008_training.html

Thanks.

Oh and tomorrow, we’ll talk a little bit about quantitative and qualitative risk.

==================================

UPDATE:  @MYRCURIAL from the great site Liquidmatrix says that I need to post the following warning:

YOU MAY NOT WANT TO PROCESS THIS PRIOR TO YOUR 11TH CUP OF COFFEE

==================================

Carrying on from yesterday’s post a bit, I’m happy to admit that Chris’ poem is right: we don’t have nearly the information we need now when we’re supposed to have “control” over our assets, putting things in a hosted/asp/cloud/buzzword model ain’t going to help our quest for visibility. My intention was/is to show that you need visibility (in part one) and then today explain that unfortunately, that’s only half the picture.

Today’s follow-on is about the fact that whatever visibility we can contractually enforce (be it in the “cloud” or in our own perimeter) has to be informative (Amrit, this is why I was plugging you with those variance questions on Twitter yesterday).  That is, we can ask whatever IT department (ours, theirs, whomever) for all sorts of information, and maybe they’ll even give it to us.  But we’re not really ready to:

• Know what to ask for
• Use it to create wisdom

A really salient example of this from outside IT hit my browser this morning.  Now it’s not at all my intention to be political or endorse one candidate over another.  Those who know me know I’m fiercely independent.  But this morning there’s a headline on a well-read news website about how one candidate is now “+2″ over another in a Gallup poll of “likely voters”. The source is here.

That is a screen grab from Gallup’s website that shows the “+2″.   I have to ask - how informative is this information?  Part of the problem is that Gallup’s methods are hidden as some sort of “secret sauce” (their FAQ section doesn’t help much, either).  But regardless of the quality of the measurement, this “+2″ has no context - we don’t really know what this information means with regards to an actual election.  Nor is there any predictive element (I hate the using the word predictive, but it’s common nomenclature - so there you go).  We don’t have what we need from this Gallup poll to create wisdom about the ability of either candidate to be elected.

Allow me show you what I mean by way of contrast.  Take a look at Nate Silver’s work at http://www.fivethirtyeight.com/.  Now I’ve been long familiar with Nate due to his work in baseball.  He’s been at these sorts of ‘predictive’ analytics around our shared passion: creating wisdom from baseball statistics.

What Nate is doing at 538 is applying that acumen from his baseball work to the political process.  He’s breaking down the vote not just on popularity among likely voters, but in the context of the electoral college, accounting for variance and uncertainty, running Monte Carlo simulations and taking into account all sorts of polling information.  The result is really quite amazing. Here’s just one graph he presents - it’s the most similar to the Gallup one above, but you should really visit the site to understand the difference in quality of information and to check out the predictive elements he creates.

NOT ALL INFORMATION IS CREATED EQUAL, AND NOT ALL  JUDGMENTS ARE CREATED EQUALLY

And take a look at the contrast, here:

On one hand you have Gallup giving us a “+2″ advantage to a particular candidate.  Now Gallup themselves draws no conclusion but, as digested, how many readers do you think take this as evidence that the election is *really* close?

On the other hand, 538’s predictions show a 348/189 electoral college split, and one candidate winning 96% of the time in simulated elections.  That doesn’t seem close at all!

RISK MANAGEMENT

It is these predictive elements that we need in order to make better strategy and decisions.  I’ve been talking in the past about risk management’s inability to link current state to systemic causes, and this “context” is what predictive analytics provide.  We might have all sorts of visibility into our environment, and measurement of various amounts of variability that visibility gives us. But unless we have context to create wisdom, it’s all just, as Chris says, “machinations”.  We have to move beyond “+2″.

So Cloud/Grid/Utility/ASP/TimeShare/Whatever you want to call it - security will have to clean up our own mess first before we can do a good job with or without a perimeter.  Once we can start moving beyond “+2″ statements, then we can know what sort of visibility we require into an ability to Prevent, Detect, and Respond.

Crazy, Man.

Lots being written about the Cloud, most of it quite dark and gloomy.  In fact I’m surprised, that Hoff hasn’t got a preso spooled up called “The Toxic Cloud” or something similarly ominous for his next speaking tour.
That said, the Economist does a great job distilling the issue into a simple statement -

Cloud computing is a trade-off between sovereignty and efficiency.

Let me ask you -  if you had to put your money on one of those horses, considering your average profit-preoccupied business, which would it be?  I’d put my bottom dollar on the thoroughbred named “Cost Center Reduction”, to place.

WHO ARE WE TO STAND IN THE WAY OF “PROGRESS”?

I’m always fond of Jack’s rule that the role of information risk management boils down to three deceptively simple premises:

• Reduce Risk.
• Reduce Loss.
• Create Operational Efficiencies.

So it would seem antithetical to the charter of the Chief Security Officer to stand in the way of progress as embodied by “cloud computing” (not to mention dangerous to long-term job security).  And I think that this presents opportunities to discuss strategies for managing risk, strategies that aren’t too theoretical and have practical application (though actual “cloud” use by enterprises may be rare at this point).

ON RISK REDUCTION IN THE CLOUD (or, How To Learn From the Shortcomings of PCI DSS)

The good news is, there’s already a well-established model for managing the risk around outsourcing the processing of “confidential” information.  The bad news is, that model kinda sucks it.

The Payment Card Industry, known as the “PCI” or “meal ticket” to many in the industry, faced a similar problem with the introduction of GLBA.  As I see it (and I’m not at all close to the PCI, at all, so this is all just abstract soliloquy) the PCI had one of two choices when faced with the prospect of other people managing their sensitive information:

1. Accept the *massive* amount of GLBA risk their business creates and spend a TON of money to build out the infrastructure (both process and IT) to manage the consumer data themselves (in conjunction with the banks, of course) and never have it grace the computing systems of the retailer.  Or,
2. Transfer the GLBA risk down to the retailer and have them bear the majority of the risk (and cost of reducing risk to a level that might be tolerable to the US Government).

(Martin, you may recall our Twittering about PCI a while back.  This is the crux of my view on the subj.)

Now fortunately, the CSO’s of the world are going to be a little more “invested” in protecting the information they are stewards over, and unlike the PCI, will remain primarily responsible for the C, I, & A of the data in the Cloud.  The cool thing is, this actually presents a great opportunity to start building a meaningful model for co-management of risk!  In fact, we can take the PCI model of contractual risk transference but modify where it goes all wrong, and start working to create something better.  And we can start by euthanizing some faulty assumptions.

JUST HOW INFORMATIVE IS PCI DSS?

What might be the.greatest.mistake of the standards compliance mentality is the assumption of value for the past-state measurement.  That is, I believe that the CSO needs more than some “past-state” assurance in order to understand their risk.    If you look at the concept of “PCI compliance” it really is an examination of a past state of nature that is assumed to be relevant to current and future states.   Many people (myself included) are not at all convinced that this past-state is nearly as informative as those who mandate it’s measurement believe it to be.

That’s not to condemn past-state measurements as completely non-informative,  they most certainly are useful.  It’s just that no self-respecting CSO sleeps well because they were deemed “PCI compliant” 10 months ago.  They sleep well because they have good visibility into current-state information and confidence in their strategy concerning future-state (based on that visibility and the outcomes of sound IRM models).

MOVING PAST THE VULNERABILITY SCANNER INTO INTELLIGENCE AND WISDOM

So realizing this new importance (to me, at least) concerning visibility and IRM models, I’m lead to the conclusion that if we are to manage risk in the Cloud, we’ll have to move beyond “PCI Compliance” or the concept that some regular “audit” of controls in place at the host is all we need to understand our ability to manage risk.  No, the CSO must have good information concerning current and probable future states.   This is that “visibility” I spoke of above.  In fact, we’ll need significant amounts of piercing, transparent visibility.  And in order to gain that visibility, our insight into Cloud Risk Management must include significant provisions for understanding a joint ability to Prevent/Detect/Respond as well as provisions for managing the risk that one of the participants won’t provide that visibility or ability via SLA’s and penalties . These SLA’s must be expressed in measurable terms (more visibility), and those metrics must have their roots in the things that help understand how we manage risk (those aforementioned IRM models).

THE CLOUD COMPUTING SECURITY SILVER LINING (sorry couldn’t resist)

As I mentioned earlier, I do see an opportunity to create insight.  The need for visibility and IRM models would allow us to create a “guidance” if you’ll allow me to use the term.  Not a standard or a “best practice” to audit by, but simply a reference document that says “if you’re going to put information on somebody else’s systems and still hold some significant responsibility for that information, here’s the considerations, why they are considerations, and how you might go about collaborating on the management of risk”.

And I think that if we undertake this journey, there is going to be a lot of growth and risk management innovation along the way.  But keen insights into what it means to manage risk will be necessary, and secure and forthright collaboration will be of absolute importance.

I say that last bit because, if these pundits are right about the utility of a hosted computing model - the Cloud will happen regardless of the CSO’s ability or desire to manage it.

Sounds like the beginning of a joke, right?  So these two guys walk into a bar…

“The” Bruce Schneier and Marcus Ranum have an article up on TechTarget/Information Security Magazine called, creatively enough, “Bruce Schenier, Marcus Ranum debate risk management“.

Unfortunately, to get to the article, you’ll have to either already be a subscriber to IT Security, a subscriber to TechTarget, or go through the 20 minute process of signing up by giving TechTarget all sorts of “market information” about how you’re really Brandon Walsh, CSO of “The Peach Pit” Industries in Beverly Hills, CA 90210 (phone 714-867-5309).

For those of you who are already a TechTarget person, the link is above.  For those who aren’t, or those who just don’t have the time, I’ll summarize.  The “debate” is kind of awkward because both authors seem come to the same conclusion:

Risk Management, it’s something our profession should do, something humans do naturally, it’s necessary in business, but gosh - we don’t have enough data.

I’m not a cryptographer.  I don’t *nearly* have the insight on privacy and politics that Bruce has.  I’m not deep in IP communications.  I haven’t got a proven track record of innovation in IP Security products like Marcus has.  But here’s the thing, I hope you’ll never hear me pretend that I have the skill set to speak authoritatively on those subjects.  Heck, I wouldn’t claim to be a “risk” expert because I have a some insight into my shortcomings and what is needed to tackle such a complex problem.  But such a tepid article on something that (at least I think) is so important kind of, well, confuses me.

Why is it such a boring article?  I’m not sure.  Maybe because they’re just two guys who would rather debate the merits of specific controls or control activities (after all, their penetration testing debate was a huge success), but there’s no new information in the “debate”.  It’s the same old “insurance companies know risk because they have scads of data and we don’t have that” complaint. You know what?  I’m tired of hearing that line, so let’s talk about it.

HOW DO YOU KNOW WE DON’T HAVE THE AMOUNT OF DATA WE NEED TO DO RISK MANAGEMENT WELL?

Not particularly picking on Marcus, but in the article he uses the common complaint, “We lack the data to do risk management well.”  This mantra is repeated to the point where I’m blase’ about it.  But for some reason, this sentence really jumped out at me this time for two reasons.  It made me ask:

1.)  How do you know we don’t have the proper amount of data?

2.)  Can we even define “well” (i.e. what “good” risk management is) yet?

I really don’t know that the industry, especially concerning IT risk, is mature enough to really conclude that we don’t know (in the case of the former), nor that we can define (latter), conclusively.

PLAYING THE CONTRARIAN

Just because I’m feeling kind of zany this morning, let me suggest something.  Maybe there actually is lots of evidence out there for us to use.  Maybe:

1.)  It’s just that we don’t have particularly good models that provide context.

2.)  When that evidence isn’t an obvious phenomena that lends itself to easy measurement, we throw our hands up in disgust and fall back on “lack of data”, “can’t quantify risk”, “best practices work just fine” or any other number of arguments, no, excuses we use to justify our inability to be precise about the past (more or less the present or future - apologies to Niels Bohr).

IT’S IN THE WAY THAT YOU USE IT

Now I actually am happy to acknowledge that we don’t have enough data to be precise.  You, me, even smart guys like Marcus and Bruce - we’ll never be able to “engineer” risk management.  But you know what?  Neither can Insurance companies.  Sure, there are plenty of places where they have enough data to apply a traditional frequentist approach to risk valuations.   But there are plenty of times Insurers actually insure and they don’t have centuries or decades of data.  There are plenty of times when they rely on the “estimates” of subject matter experts.  There are many times they have enough information to be accurate rather than precise, and that’s good enough for them.

For that matter, it’s worth noting that there are plenty of scientific disciplines that have to deal in imprecise prior information, or evidence that’s fraught with uncertainty (what Ranum calls “squishy”, and what I’ve heard real honest to goodness physicists call “noisy”).  Unfortunately, we’re going to be like them.  Until we can read minds and predict the future, there will always be uncertainty in our measurements and posterior conclusions.  The trick is in how you deal with it and express it.  And while I really don’t know how much time Marcus or Bruce have really spent in the deep end on the subject of risk and its management - I have seen people doing brilliant things around risk (though they just aren’t mainstream).  Whether the tools are Bayesian methods, Monte Carlo engines, reductionist models of complex problems, there are risk analysts trying to deal with the problem.  These analysts are applying scientific method(s) and developing reasonable approaches to a very complex problem.  There are people trying, and our body of knowledge is growing, growing well beyond “gee, I haven’t got an obvious solution so I’ll blame it on lack of data”.  Heck, I’ve seen readers of this blog suggest Douglas Hubbard’s book in other security forums!*

I’VE GOT YOUR DATA RIGHT HERE…

But we don’t have enough data?  I have to ask, how much more do we need?  I mean crikey, JPMC just visited our ISSA chapter claiming, like, a bajillion events an hour.  There’s not one, but several companies out there that will want to tell you about how they have deep “insight” into the attacker community.  The boundaries of IT Risk losses are pretty well established by events that happen to public companies.  We have pretty mature testing/assessment tools and methodologies now that help us test our ability to resist the force an attacker can apply to us.  So what part of the Threat Landscape, Asset (Controls) Landscape, or Loss Magnitude landscape is too incomplete (and what are you doing to find the information you need)?

SO WHY DO WE FAIL?

Which brings me to a final, somewhat depressing conclusion.  Maybe there’s data, and maybe we’re starting to see the means to use it.  But in the end I do have to agree with Marcus that the vast majority of the infosec world *is* doing a really, really bad job with regards to “risk” and “risk management”.  The majority of people I know consider GRC to be a cruel, expensive joke.  Risk Assessment Methodologies tend to be built on the faulty premise that if we create a repeatable process, our measurements and conclusions will magically become accurate and wise.  Risk models tend to be factors loosely measured by ordinal scales and then somehow “multiplied” together to create a relatively meaningless qualitative value.  The State of the Union here is not good.  But after reading such a superficial treatment of an important and complex subject, I am left wondering if Bruce and Marcus were the right people to write about risk management in a mainstream publication.  As Inspector Callahan says, “A man’s got to know his limitations.”

===============================

* Speaking of which, if you want to do one cost effective thing to address your uncertainty - go find Douglas Hubbard’s book. It’s even got a nice recommendation from Peter Tippett.  The book is called “How To Measure Anything” - the title sounds rather hyperbolic, but there are good techniques in it we can use to identify useful information and refine our ability to frame that qualitative information into quantitative values. The key is how Hubbard has you deal with your uncertainty.  For those of you who are more scientific minded and want to dig deep into the subject, I have on good authority that E.T. Jaynes “Probability Theory, The Logic of Science” is a rather under appreciated work.