It pays to PRIORITIZE!

Not all data was created equal- neither are vulnerabilities! Not all data is worth protecting, and not all vulnerabilities represent the end of the world.  With limited development man-power available to build and maintain web assets, security teams must carefully pick their battles. Building a classification system and taxonomy will improve the process, and will create a due-care paper trail for auditors. After a vulnerability has been identified, there are a couple of ratings that will affect its priority:

Establish a Value for the Web Site – This is probably the easiest and most overlooked starting point. If you haven’t inventoried your web properties, start there. After you’ve identified web sites serving your organization or carrying your logo (or affecting your brand..) assign a value to them.

The web applications that handle sensitive data (PCI, HIPAA, SOX related, NPI / PII / whatever) are going to have an impact on audit results, breaches may require public disclosure, notification, fines, free press in WSJ, etc (read: rate these higher…)

Classify the Vulnerability – What kind of threat are we communicating? When enlisting support from development in correcting a vulnerability, use consistent language. This will streamline developer training and vulnerability communication. Go visit WASC to get started…

Only Accurate Findings, Please – okay, so this isn’t a rating criterion, but more a warning about burning bridges. You only have so much political capital, and crying “wolf!” isn’t going to make any friends. To be effective in managing vulnerabilities, please PLEASE only communicate accurate findings to the development team. (read- don’t run a scanner, print a PDF, and email it to dev as an action item list…. you *will* be sorry)

Threat – How difficult is this threat to exploit? Is this novice class, vulnerable to a script kiddie? Does the attack require some elegant filter evasion through encoding foo- some sort of ninja would be exploring?

Severity – How bad is it really? The potential for damage by a particular vulnerability class will vary, and that impact must have a rating. SQL Injection and Cross Site Scripting are no-brainers, and have huge implications (and are all over regulatory radar). I would place them at the top.

RISK – This will be a cumulative value of the individual vulnerability. Something to the effect of <value of website> + <percieved threat> + <severity of impact> = <projected risk> allows a group of similar vulnerabilities to be addressed in order of risk, with at least a sense of urgency or comparable value.

The idea is to get away from vulnerability whack-a-mole. With simplistic metrics, addressing vulnerabilities becomes a function of risk, not a list of to do items. Managing vulnerabilities after detection enables business decisions to be made on merit and value- as a function of cost.


One Response to “It pays to PRIORITIZE!”

  1. Chicken or Egg - Selecting Websites for Testing « Trey Ford - Security Spin Control Says:

    […] My counsel has historically been driven by the business value of the site, or the value of the data served by the site (regulatory bodies, SLAs, etc).  I state that because I now more clearly see that as an outsider, my focus is in protecting business sites and providing safety- not in political justification inside an organization I work for… […]

Leave a Reply

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

You are commenting using your 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: