Rational Survivability

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
management.

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
examiners.

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.

/Hoff

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 😉