Coming to Consensus

The security function has a reputation—not wholly undeserved—of a “security at any cost” mindset. We have all been trying to move away from that and start to “manage risks”. This means perform risk assessments and address those risks where the cost of addressing them makes sense given your risk tolerance.

However, there seems to a new movement afoot in the information security space, and it feels to me like it is a move away from risk management.

  • SANS has coordinated a group of security experts to produce a set of Consensus Audit Guidelines. These are 20 controls that they believe everyone should have, based on analysis of real-world vulnerabilities and threats.
  • The US government has a multi-department effort, the National Vulnerability Database, that aims to promote baseline standards with definitions and tools that help automate technical compliance checks of desktop operating systems and other assets.
  • The Center for Internet Security has its Security Configuration Benchmarks. Again, they have worked to create a consensus on a set of baseline hardening standards for some popular applications, OSs, and devices.

Now, everyone is happy to get some considered advice on increasing security, and it is great to see the increasing cooperation of groups that have the resources and influence to create and promulgate good standards.

But I do have to wonder what this means about where we are as a discipline. This sort of checklist approach to security—at least from an organization-agnostic point of view*—would seem to be the opposite of risk management.  Instead of treating vulnerabilities according to risk, the premise of these efforts is that we are all just going to treat all these vulnerabilities because they say we should.

Assuming these efforts are not a waste of time, I guess there are three interpretations, but I find each a little troubling.

  1. The “minimum baseline” interpretation.
    This interpretation says the risk mitigation/cost ratio for these suggestions is so high, they are a no-brainer for everyone no matter what their risk profile.  This may well be true, but if it is: how have we gone so long and still have significant numbers of organizations (including US government agencies—the explicit target of two of these efforts) that need to put such obvious protections in place?
  2. The “compliance automation” benefit.
    Each of these efforts includes the idea that by standardizing your security settings you can more easily monitor compliance. Also, each of the standards either has tools that perform the monitoring or has designed the controls around ease of automated monitoring. This makes sense, and we know that most incidents involve un-implemented basic controls **, so as such this is a great idea. But now, these standards are no longer a baseline, but something you have to stick with so your automated compliance works. That doesn’t sound like risk management, unless risk is spread around pretty uniformly.
  3. The “due care” interpretation.
    This interpretation means that by putting in place the protections on this list, you are trying to protect yourself from accusations of negligence.  Here the risk you are managing by implementing one of the approaches is not the risk of a security incident, but the risk that a security incident engenders a negligence claim. Obviously, very legitimate. The concern I have with this approach is twofold. A) again, we find ourselves selecting controls that are not necessarily reducing our security risk in the best way, but now have to do since the item is on someone’s list. B) When minimum standards of due care get established, people often forget they are a minimum standard, and tend to settle on those standards as enough. After all, they have performed their due care.  Do PCI-compliant companies suffering breaches ring a bell for anyone? The problem with chasing a standard that is not risk-based is, after you’ve battled for the money to address the specifics of that standard (again, PCI is a great example here), how much more political capital do you have left for risk-based security measures?

OK, it’s not so simple as that, and nor are these implications mutually exclusive. As long as you stick to making guidelines that say, “here is a good way to secure this OS”, you are fine. But when they become standards, I think the implications are troubling.

* Once an individual organization has gone through their risk management thinking, having (their own) security baselines and checklists makes a lot of sense.

** For example, see the 2009 Verizon Data Breach Report

Advertisements
Explore posts in the same categories: Risk Management

2 Comments on “Coming to Consensus”

  1. Jeremy Bergsman Says:

    Nice post in the same vein, but on the specific subject of application security:
    http://blogs.csoonline.com/csslp_its_about_time

  2. Jeremy Bergsman Says:

    A couple of old posts from Microsoft with a pretty detailed take on why security guides don’t work:

    Part 1: http://technet.microsoft.com/en-us/library/cc512582.aspx
    Part 2: http://technet.microsoft.com/en-us/library/cc512607.aspx

    Note: the index has part 1 in the wrong place, but link above should work.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: