What Is Vulnerability?

If you are confused by what standards and reputable sources mean by “vulnerability,” or “a vulnerability,” take heart.  You have company.  Our profession has done a great job in confusing itself.  Let’s sort it out. 

We sail in treacherous waters when we try to enlist ordinary English words to the needs of the technical specialist.  “Force” and “resistance” have specific meanings to the scientist that they do not have to the police officer.  Risk management has many of its own monsters in these waters, but none so slippery as “vulnerability.”  Fortunately, the FAIR taxonomy gives us a compass to navigate safely.  This note uncovers the many meanings of “vulnerability” as an ordinary word, as a term of art in risk management, and as refined to its ultimate and spare precision by FAIR. 

The FAIR taxonomy defines vulnerability as “the probability that a threat event will become a loss event.”  More precisely, it is the conditional probability that a particular type of threat event will become a loss event.  This definition shows us directly how to “combine” it with threat event likelihood to get loss event likelihood.

Let’s first examine how we get to the FAIR definition from the ordinary English word.  A dictionary definition of “vulnerable” includes the ideas of “capable of or susceptible to being wounded or hurt,” and “open to assault, difficult to defend,” so vulnerability is just the quality or state of being vulnerable.  In this sense vulnerability is a quality or state of being.   Little Red Riding Hood is vulnerable to the Big Bad Wolf.

The information security literature takes the idea a step further.  Vulnerability now is not only the state of being vulnerable but also something specific that makes an asset vulnerable.  The reader is assumed to fluidly decide which of these two senses is meant in a given context.  Lucky you.

Authoritative sources differ in their exact definitions of vulnerability, but probably the best is from NIST (Special Publication 800-30r1, Guide for Conducting Risk Assessments):

“A weakness in an information system, system security procedures, internal controls or implementation that could be exploited by a threat source.” 

SP800-30 makes it clear that an “exploit” need not be intentional and the threat source need not be human – it could be an earthquake.  This is important and better than what other sources may tacitly suggest because the availability of an asset to authorized users is one of the three pillars of Confidentiality-Integrity-Availability security triad.  Non-human threats and non-intentional attacks need to be managed just as well as Trojans and phishing attacks.

NIST wisely qualifies the definition with “could.”  In contrast, for example, the Official ISC2 Guide to the CISSP CBK (4^th ed., Adam Gordon, glossary, p. 1254) defines vulnerability as a “weakness or lack of a countermeasure,” full stop.  The NIST definition alerts us to the distinction between a weakness being present and the probability that the weakness could actually result in a loss event.  There is a world of difference.  If a company enforces only moderately-strong passwords, but the asset being protected is not of interest to capable attackers, then the vulnerability may be low because the probability that a loss will result is low. 

Another problem with the usual definitions of vulnerability, even NIST’s, is that their tendency to use other words that are just as problematic to define, such as “weakness,” “countermeasure,” “safeguard,” “exploit,” and “threat.”  Defining one vague, abstract word in terms of other vague, abstract terms sets one off tracing down a web of mutually dependent definitions. 

The FAIR definition wisely tosses the maximum amount of such excess baggage overboard: a vulnerability is simply the

“probability that a threat event will become a loss event” (The Open Group, Risk Taxonomy (O_RT), Version 2.0,” p. 55). 

This is a conditional probability, depending on the scenario, that is, given the threat event type and other information. 

A conditional probability means that the probability of something happening may change depending on what you already know.  The odds of drawing to an inside straight in poker depend on what cards have already been dealt. The probability of getting into a crash depends on whether you have just run a red light.  Likewise, the probability that a threat event becomes a loss event depends on what kind of threat event it is, and other circumstances.  Restating the FAIR definition a bit more verbosely:

Vulnerability is the conditional probability that a threat event will become a loss event, given the type of threat event.

This definition is a crucial advance because it defines a measure of the degree to which an asset has the quality of being vulnerable.  Now we can work with numbers instead of colors!

Using this concept is the heart of simplicity:  just multiply the vulnerability by the probability that the given type of threat event will occur.  This gives the probability that a loss event will occur due to that type of threat event.  In pseudo-algebra:

The probability of a loss event due to a given type of threat =

(the probability that that type of threat event will result in a loss event, if it occurs)

X (the probability that the threat event will occur)

In FAIR we usually work with annual frequencies rather than probabilities, in which case the pseudo-algebra is:

 The expected annual frequency of a loss event due to a given type of threat =

 (the probability that that type of threat event will result in a loss event)

 X (the expected annual frequency of that threat event)

More compactly,

Loss Event Frequency = Threat Event Frequency x Vulnerability

A simple example may help to make these ideas concrete.  Suppose the loss event is the exposure of confidential information to unauthorized users, and we need to evaluate loss event frequency for two threat types, loss of a laptop and malicious use of privileged access by an insider.

Vulnerability depends on the type of threat.  The Loss Event Frequency is easily calculated by multiplication.  This is the proper way to “combine” two factors.

All of this depends on what kind of threat event the analyst has in mind, which is part of the scenario definition.  In fact, all of these factors depend on the scenario.  (It is an excellent feature of FAIR to require explicit definition of the scenario.)

Let’s use the FAIR definition of Vulnerability to clear up one point in SP800-30 which NIST muddles rather badly.  The pub states (p. 43) “The overall likelihood of a threat event is a combination of

1. 1. 1. The likelihood that the event will occur (e.g. due to human error or natural disaster) or be initiated by an adversary, and
      2. The likelihood that the initiation/occurrence will result in adverse impacts.”

Translate this into FAIR-ese by recognizing that clause (i) is the probability that a threat event will occur or Threat Event Frequency; and that clause (ii) is Vulnerability.  NIST now makes the astonishing claim that “algorithm[s] or rule[s] for combining the determined likelihood values” could be as diverse as taking the maximum of the two likelihoods, or the minimum, or one but not the other, or a weighted average.  This guidance is offered in the spirit of affording “organizations [the] maximum flexibility on how risk assessments are conducted” (p. 34).  While it may be useful, even necessary, to provide organization leaders with some “flexibility” for the sake of getting them to make a start on risk assessment, NIST risks causing confusion that will only frustrate progress.  FAIR makes it clear that there is only one correct way to combine the two “likelihoods,” provided they have been estimated using FAIR principles, and that is to multiply them:

Loss Event Frequency (for a given threat type) = Threat Event Frequency x Vulnerability

An alternative that NIST does not even mention!  It is the only sensible way to combine the likelihoods of threat and vulnerability.

1-13-17, 1-14, 1-15, 1-16