Home > Risk Management > Too Much Risk Management? Not Possible

Too Much Risk Management? Not Possible

I’ll give Rothman the props/ping for highlighting an interesting post from Sammy Migues at the Cigital "Justice League" blog.

Sammy’s post is titled "The Risk of Too Much Risk Management." 

Short of the title and what I feel is a wholly inappropriate use of the "meaning" of risk management as the hook for the story, the underlying message is sound: security for security’s sake is an obstructionist roadblock to business; the deployment of layer after layer of security controls as a knee-jerk reaction to threats and vulnerabilities is a bad thing.

I totally get that and I totally agree.  The problem I have with Sammy’s post is he’s doing the absolute worst thing possible by defining what he improperly describes as "risk management" and it’s meaning to the business and suggesting that a technology-centric application of rapid-fire reflexive information security is the same as risk management.

It’s basically making excuses for people practicing "information security" and calling it "risk management."

They are NOT the same thing. 

By associating the two he’s burying the value of the message and marginalizing the impact and value that true risk management can have within an organization. 

To wit, let’s take a look at how he describes what risk management means:

Let’s put a stake in the ground on what risk management means. I’m
not referring to how it’s defined so much as what it actually means to
business. Risk management means there is a thought process that
includes ensuring the right people with adequate skills are given
useful information and actually decide whether to do this or that to
more effectively achieve security goals. Something like, “The available
data indicate that path A at price B mitigates problems C, D, and E,
but causes problem F, while path Z at price Y, mitigates problems C, E,
and X, but causes problem W. What’s your decision?”

I’m very puzzled by this description because what’s stated above is not  "…what [risk management] actually means to the business."   The first part which describes ensuring that the right people are given access to the right data at the right time is really the output of a well-oiled business resilience operation (information survivability/assurance) which factors risk assessment and business impact into the decision fabric.

However, the "business" doesn’t "…actually decide whether to do this or that to
more effectively achieve security goals"
they factor on whether they can achieve their business goals.  Security is the stuff that gets added on usually after the decision has been made.

Some people have
good gut instincts, shoot from the hip, and end up with decisions that
only occasionally burst into flames. For my risk appetite, that’s too
little risk management. Others wait for every possible scrap of data,
agonize over the possibilities, and end up with decisions that only
occasionally aren’t completely overcome by events. That’s too much risk

Again, neither of those cases describes "good" risk management.  The example paints a picture of "luck, decent guesswork and perhaps a SWAG at risk assessment" or "irrational and inflexible analysis paralysis due to the lack of a solid framework for risk assessment" respectively.

The impact of too little risk management is usually too few security
controls and, therefore, too much unpredicted expense in a variety of
areas: incident response, litigation, and recovery, to name a few.
These are often the result of public things that can have lasting
effects on brand. This is easy to understand.

The impact of too much risk management is usually too many security
controls and, therefore, too much predicted expense in a variety of
areas: hardware, software, tools, people, processes, and so on. These
are all internal things that can setiously impair agility, efficiency,
and overhead, and this is usually much harder to understand.

This isn’t a game of measures from the perspective of "too little" or "too much."  Risk management isn’t a scaled weighting of how many controls are appropriate by unit volume of measure.  Within this context, risk management describes investing EXACTLY enough — no more and no less — in the controls required to meet the operational, business and security requirements of the organization.

The next paragraph is actually the meat of the topic — albeit with the continued abuse of the term risk management.  Substitute "Information Security" for "Risk Management" and he describes the very set of problems I’ve been talking about in my "Information Security is Dead" posts:

Let me clarify that I’m being a little fast and loose with “too much
risk management” above. In my experience, the problem is almost never
too much “risk management,” it’s almost always too much security fabric
resulting from a fixation on or over-thinking of each and every
security issue, whether applicable or not, combined with a natural
tendency to equate activity with progress. As a consultant, I’ve heard
some form of the following dialog hundreds of times: “What are we doing
about the security problem I’ve heard about?” followed by a confident
“We have people choosing A as we speak.” More security controls,
especially generic plug-n-play things, does not automatically mean less
risk, but it sure is highly demonstrable activity (to managers, to
auditors, to examiners).

The last paragraph basically endorses the practices of most information security programs today inasmuch as it describes what most compliance-driven InfoSec managers already know…"good enough is good enough":

All in all, too few security controls is probably the greater of the
two evils. On the other hand, it’s probably the easiest to remedy. Even
if you do no risk management at all, if you have the money to purchase
and correctly install most of the major security technologies out
there, the shotgun approach will in fact reduce security risk. You’ll
never know if you’ve done enough or if you’ve overspent, but you’ll
have a story to tell to the masses. On the other hand, a thoughtful
security approach based on sound risk management will give you a story
to tell to savvy customers and increasingly well-educated auditors and

If the shotgun approach gives the appearance of "reducing risk" why do anything else?  Sammy certainly did not make the case as to why evolving to managing risk is paramount, valuable, and necessary and worse yet, risk management is ill defined.

If you had limited resources, limited budget, limited time and limited enthusiasm, given the options above, which would you pick?  Exactly.

Risk management is hard work.  Risk management requires a focus, mission, and operational role change.  That sort of thing has to be endorsed by the organization as a whole.  It means that in many cases what you do today is not what you’d do if you transformed your role into managing risk.

Managing risk is a business function.  Your role ought to be advisory in nature.  It can even be operational  once the business decision has been made on how best and how much to invest in any controls needed to manage risk to an appropriate level.

Rothman summarized this well in his post "The
point I want to make is that all risk management (and security for that
matter) need to be based on the NEEDS OF THE BUSINESS. If your business
is culturally risk-taking, entrepreneurial and nimble, then you are
probably going to be on the less side of the risk management continuum.
The converse also applies. Just remember to map your security strategy
to the characteristics of your business, not the other way around."

Today, Information Security has positioned themselves as the judge, jury and executioner as a red-headed stepchild outside of the risk management process.  The problem is, it’s not really Information Security’s problem to "solve," but we nevertheless bear the weight of the crucifix we nail ourselves to.

Time to get off the cross…someone else needs the wood.


Update: Of course the moment I hit "Send" on this, my Google Reader alerted me that Alex Hutton had already responded in kind.  He, of course, does it better and more succinctly 😉

Categories: Risk Management Tags:
  1. Mark
    October 30th, 2007 at 09:39 | #1

    In response to this post (without reading your other articles on the state of infosec) I would like to make the comment that I think there are two roles needed within any enterprise; first, a risk management professional who can identify, assess and recommend approaches to information risks (classic CIA); second, an information security control manager, who's job involves ensuring controls are designed, implemented and managed to effectively satisfy the risk mitigating requirements.
    Is this consistent with your views?

  2. October 30th, 2007 at 09:52 | #2

    I think in many cases the dichotomy you present is probably the only way that effecting something even close to a risk management implementation will happen. I'm not really excited about debating the titles you use, but we'll stick with them for the purpose of answering the question…
    Change is painful and unless folks are able to let go and think differently, chances are they will not be able to make the transition from tactical/operational to strategic/advisory.
    I'd *wish* for a single entity, but in many cases you've seen the visceral reaction that folks have to being told that the problems being solved (and thus their efforts) are not in alignment to the business. They puke.
    Supposedly the function of "information security control manager" is already in place with those folks who have internal audit/assurance functions…but it rarely works out given the lack of a common language to describe the "problem."
    Internal audit is often blindly compliance driven and often times this is just as out of whack with what the business needs as it is in InfoSec.
    For someone to be able to grasp/balance both sides of the equation, they have to have had operational experience, audit experience, project management experience, risk/risk assessment experience, etc…and work to achieve equilibrium.
    Not an easy task. Not too many folks can. That's not a knock, but just my observation.

  3. October 30th, 2007 at 17:32 | #3

    I have to disagree. The security architect (control manager) should have salient insight into what aspects of his proposed solution(s) (prevention, detection, response) decrease the probable frequency and magnitude of loss.
    Now that's some seriously sophisticated risk management, but that's why we make the big bucks, right?

  4. October 30th, 2007 at 17:35 | #4

    Hang on…you've just promoted someone in the internal audit department to an "architect" position!? Ever been to an ISACA meeting?
    How does "security architect" = "control manager" !?
    Not at my pay grade! 😉

  5. October 30th, 2007 at 17:53 | #5

    LOL, I think you and I see the job descriptions Mark laid out different. And after I read them again, I totally see your point.
    "information security control manager, who's job involves ensuring controls are designed, implemented and managed"
    I saw designed and implemented as "architect". I missed managed and interpreted "ensure" different than you, I think.
    If we take the auditor tact – even then I'd argue we're (royal "we") doing it wrong STILL. Auditors tend to love well quantified risk analysis, and, in fact, I think you could make an argument that the ideal audit function should simply review risk analysis (and recommendation) for rigor.

  6. Jack
    October 31st, 2007 at 02:29 | #6

    Thanks for an outstanding post!

  1. No trackbacks yet.