The Risk of Too Much Risk Management

IT controls. Corporate governance. Decision support. Right-sized spending (another phrase I thought I coined, but I see it gets three hits in Google). These are all part of the all-too-nebulous activity often referred to as data security risk management.

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?” Or, as happens much, much too often: “Hackers, phishers, and insiders…oh my, what are we going to do?”

Everyone makes dozens, hundreds, or perhaps thousands of risk management decisions every day. These are parents, doctors, lawyers, truck drivers, and everyone else, including CEOs, CIOs, IT security personnel, software architects, developers, and so on. 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.

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.

Which is worse?

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

I think we’ve seen the impact of too few controls all too vividly recently. Just type “data breaches” into your favorite search engine and you’ll be inundated with examples. And that’s just one example of one kind of bad outcome associated with too few security controls.

But, too many controls can also have a direct impact on the very core of an organization. To illustrate, let’s turn to the great triad of operational excellence, product leadership, and customer intimacy.

A company whose success is based on operational excellence requires quality goods at reasonable prices. This requires very efficient operations, excellent supply chain management, and practically flawless execution. Superfluous security controls, whether in people, process, technology or embedded in software, may not prevent flawless execution, but it certainly seems like a good way to slow down a just-in-time supply chain (e.g., we quarantine all email attachments for 12 hours) and disrupt operations (e.g., by implementing ultra-fine-grained entitlements where it just isn’t necessary).

When your success is based on product leadership, you are probably innovating constantly and spending like mad to build brand. Staying ahead of everyone else requires great design and development, a fantastic knowledge of your customers, and quick time to market. Security controls that have no material relationship to any practical attack can easily derail any product process that relies on agility (e.g., SDLC security tools and processes that check for things that have no matching threat slowing down product cycles).

If customer intimacy is your key to success, then you are likely to be extraordinarily focused on customer service, with lots of choices that can be tailored to customer desires. Here you will have to excel in customer management, have product and service delivery that exceeds expectations, and engender client trust. Too few security controls (”Hey, I’m this person you’ve never met, please reset my password.” “Sure thing!”) can certainly end a client relationship, but so can unnecessary security controls (e.g., three personal questions, identify an image, and last four of your SSN just to activate the Forgot My Password page) as it also clearly indicates that you just don’t know what you’re doing. Where it’s obvious that you don’t understand the appropriate intersection between your risk management, your customer’s risk appetite, and the actual risk, a trusted partnership is pretty much out of the question.

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.

Technorati Tags:

7 Responses to “The Risk of Too Much Risk Management”

  1. Mike Coon Says:

    I totally agree on the ‘badness’ of poorly considered security. The example of personal questions and image identification really hits home as we have a banking customer that requires responses like ‘characters 2,3,5, and 7 of your password. Way too onerous for the guy that wants to get in a check the balance on his card.

    I’ve also seen a lot of gratuitous firewalling within corporate networks that just adds a lot of friction to the workday.

    Good Article,

    Mike

  2. Dave Aronson Says:

    “[W]ait[ing] for every possible scrap of data” is just the security equivalent of a well known software engineering “antipattern”, Analysis Paralysis. Happens in every field, probably….

    -Dave

  3. Sammy Migues Says:

    It undoubtedly does happen in every field. I’m sure there are doctors, lawyers, investors, betrotheds, heads of state, shy teenagers, and millions of others at this very minute looking for one more scrap of information before making a decision. And for many of them, it may be the right thing to do (let’s run one more test before amputating). And for others, it may work out okay even if they should have acted sooner (you could have received 0% interest rate last week, but it’s only 2.9% now).

    I think one of the key points here is that when something is a science, we can know or reasonably postulate that there *is* more data that will help us and that we can likely *get it* and then *use it*. “InfoSec,” having not reached the evolutionary level of science, often cannot be a “fact-driven” endeavor. Either you get it or you don’t. And I’m sure that happens in every field also.

    Thanks.

  4. Sammy Migues Says:

    Gratuitous firewalling, proxies in intranets to control surfing, huge logging systems that actually slow down internal applications, etc. I’ve seen a lot of these happen, not for security purposes, but to control undesirable behavior. Of course, and in my opinion, putting in onerous security controls as the primary method used to catch or deter undesirable human behavior is yet another morass.

  5. RiskAnalys.is Says:

    Proper Risk Analysis *Can’t* Mean Unnecessary Controls

    Sammy Migues over at the “Justice League” blog from Cigital has written an interesting article on “risk management”.  Basically, he’s saying that we can have too much of a good thing.  Too much risk management creates to…

  6. Justice League » Blog Archive » Additional Thoughts on “The Risk of Too Much Risk Management” [Cigital] Says:

    […] Cigital Home > Resources > Blog « The Risk of Too Much Risk Management […]

  7. Tom Hunter Says:

    Good article. I think “risk management” get a bad wrap some times and if fact can be misconstrued for “business management”. That said, “risk management” should be viewed as a competency and not a function. Risk comes in many flavors and is a part of any activity out there. I think it will take some time before people strat believing this, however.

Leave a Reply



Resources
> Overview
> Your Account
> Podcast
> Blog
> Case Studies
> White Papers
> Publications
> Books
> Security Articles
> Presentations


RSS

About the Bloggers
  • Pravir Chandra
  • Scott Matsumoto
  • Gary McGraw
  • Sammy Migues
  • Craig Miller
  • John Steven
  • Categories
  • Admin (3)
  • Assurance (6)
  • Data Security (3)
  • Defects, Bugs, and Flaws (3)
  • Enterprise Software Security (11)
  • General Interest (3)
  • Governance and Regulation (5)
  • Risk Management (4)
  • Security Features (2)
  • SOA and Web 2.0 (2)
  • Software Quality (4)
  • Software Security (32)
  • Software Security Touchpoints (7)
  • Software Testing (2)
  • Training (3)
  • Archives
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • By Blogger
  • Craig
  • Gary
  • John
  • Pravir
  • Sammy
  • Scott
  • Guest bloggers
  • Recent Comments
  • Rafal Los on Is Penetration Testing Security Testing?: John, Fascinating analysis. I would like to...
  • gem on Three New Books: Thanks Adam (and sorry not to make your role explicit Andrew). I’m...
  • Adam on Three New Books: Thanks Gary! your copy is on its way. Just a little nit, I’m the...
  • Andre Gironda on Is Penetration Testing Security Testing?: From a book I recently read: Functional...
  • Tom Van Vleck on Security And Market Forces: I can’t come up with a number for how much money I...
  • Recent Entries
  • Unsafe at any bitrate?
  • Three New Books
  • Is Penetration Testing Security Testing?
  • Externalizing Access Control Quandary
  • Making a move
  • Links
  • Cigital
  • Silver Bullet Podcast
  • Blogroll
  • 1 Raindrop
  • Fortify Software's Blog
  • Freedom to Tinker
  • In the Wild
  • Jon Udell
  • Michael Howard's Blog
  • Microsoft Security Vulnerability Research and Defense
  • News.com Security Blog
  • Schneier on Security
  • Security Fix
  • SilverStr's Blog
  • Tao Security