This is a personal blog. My other stuff: book | home page | Twitter | prepping | CNC robotics | electronics

September 09, 2011

Critical (of) severity

You can tell when a person is desperate to appear authoritative: they often litter their speech with unnecessary, roundabout verbiage. To some listeners, this sounds smart. To many others, it's obtuse and pompous.

I think that one of the cornerstones of vulnerability management is just an example of that. I am talking about the concept of vulnerability severities: I believe that they serve no real purpose, other than obfuscating the true intent of speech.

It's not that we don't need a codified taxonomy; but the term "severity" and the abstract levels attached to it ("critical", "high", "medium", "low") are a remarkably poor proxy for what we actually want to say.

The notion of severity is used in two distinct settings:

  • In a position of authority: For example, when an internal security team is communicating with developers. In this case, the intent of assigning severity is to instruct the developer to do one of the following:

    • Drop all other work and fix the bug now.
    • Fix the issue in a couple of days.
    • Fix at own leisure, or not at all.

  • In an advisory position: Say, when a vendor is notifying end users about the availability of a fix. In this case, the actual message usually is any of the following:

    • You are in imminent danger. Patch now.
    • You are at a limited risk, but prompt action is advisable.
    • We don't think there is a substantial risk.
Every time, the messages are very simple. Yet, instead of just saying them out loud, we create one set of guidelines for the security team to map their assessments to ambiguous codewords; and then furnish another, lengthy phrasebook for the final recipient of a message, to map the codeword back to something they can act upon.

Only we're not running a numbers station: we're trying to tell people something very important, and we need all of them to understand us right away. There is no way around the fact that terms such as "critical" or "high" intuitively mean different things to different people, and almost certainly do not map precisely to the thing you actually wanted to say. If the severity needs to be accompanied with several pages of organization-specific explanatory text, something is horribly wrong.

Instead of "highly critical", start telling your users "patch right away".

1 comment:

  1. "There is no way around the fact that terms such as "critical" or "high" intuitively mean different things to different people"

    It's important to have a consistent message in your org no matter who is approaching dev/ops to fix an issue. If software weakness n is discovered, both Ray and Rick should be able to determine the same severity and SLA in a consistent way, and be able to communicate it using priorities/severities in dev/ops speak (using whatever classification systems that they use).

    Bug bars (security or otherwise) can go a long way to remove ambiguity, and improve handling of y severity issue. Lastly this bug bar should be published in a location that ops/dev can easily find.

    - Robert A.