Red, Yellow, Ugh…

I have been frustrated by the state of prioritization in security for several years. I recently wrote about how a data-driven approach can help prioritize remediation when there are a large amount of issues to contend with. It seems that much of the industry got together years ago and decided we could drop millions of issues into buckets of red, yellow and green. Simple. Now all I have to do is start with all the red issues and fix those right away, after all they are RED! The problem with this approach when you dig into the issues is that prioritization can be complex and include a lot of different factors. Adding to the complexity, those factors are often different from organization to organization. I am all for breaking things down to their simplest parts but doing so by obfuscating the complex factors that go into this, NOT eliminating them.

Information Security Needs a Decisioning System

Lets start with a seemingly simple example from a world I know well.

What factors should we know about a defect or vulnerability to help guide how we prioritize remediation? Here are a few things directly off the top of my head…

• Exploitability
  • How easy is it to exploit this vulnerability?
  • Are there publicly available exploits through Metasploit, Core, ExploitDB?
  • What is the access vector? Does it require a multi-vector attack? Is it behind authentication or an additional control thus reducing the attack surface?
• Asset Affected
  • How do we value this particular asset?
  • What type of data is stored or processed by this asset?
  • Is the asset part of a larger system (see Business Process Affected)?
  • Are there specific confidentiality, impact or availability requirements tied to this asset?
  • Are there compliance requirements or additional SLA’s for this asset?
• Network Location
  • Is the vulnerability/asset publicly available?
  • Does it sit within a DMZ or core network?
  • What additional assets or systems can a threat agent access from here (see Multi-Vector Attacks)
• Business Processes Affected
  • Is the asset above part of an important business process?
  • Does exploiting this vulnerability interrupt or compromise this process? (CIA)
• Number of Users Affected
  • How many users are affected by an exploit of this vulnerability?
  • Is the attack directly against users of the application?
• Discoverability
  • How easy is it to discover this vulnerability? (through automated tools, specialized skills, etc)

There are likely several more including some unique to your company but lets use this quick list for brevity sake.

A Simple Example

So lets apply this criteria to a single example.

Vulnerability: Persistent XSS on public web site www.foo.com

• Cross Site Scripting issues can vary quite a bit but we’ll call this one trivial to exploit. While there isn’t a publicly available exploit as this is a custom web application, it can be exploited with a small amount of skill and a browser.
• www.foo.com is our public facing web site. It doesn’t process much data and mostly serves as informational. It’s important for our sales, marketing and public relations.
• Our public site is available directly and not behind authentication. There are several systems within the DMZ that can be accessed from www.foo.com. Some of these systems include processors of “confidential” but not “sensitive” information.
• The primary business processes associated with the site is public relations and marketing.
• Our public site receives millions of unique visits per month and the exploit of this vulnerability can directly attack these visitors. The payloads can vary but assume the worst.
• Discovering this cross site scripting issue is trivial and can be done through automated tools or manually via a web browser.

In this simple example we start to get a feel for how serious or not this vulnerability is. Just by running through this off the cuff list of decisioning factors I can see how this can result in an attack against a large amount of our users and the likelihood is fairly high based on the lack of skills needed to both discover and exploit this defect.

We Can Be More Quant Than This

Have I over simplified this? You bet. There are likely several other factors that drive prioritization here, including competing with other priorities (opportunity costs). I’ve also simplified this down to a qualitative decision but there’s no reason why this can’t be more quantitative. My point here is even a short, simple off the cuff list can bring a lot more relevant factors to my remediation priorities than red, yellow and green.