When a new vulnerability is discovered in (for example) an operating system, does that mean the system was vulnerable all along? As I see it, the answer is “No”.

The rationale behind this answer is based on the fact that weakness (a.k.a. vulnerability) is a relative term. Logically, a relative term requires at least two components – one relative to another. Oh, it’s true that the “flawed” condition within the operating system existed all along, but in order for that condition to actually BE vulnerable, the capability to exploit the condition had to exist. And within the context of a human threat community, capability requires two things: knowledge and resources. Consequently, until the condition was known to be exploitable, it couldn’t be leveraged and wasn’t a vulnerability.

So, if a vulnerable condition occurs when available force becomes greater than the ability to resist that force, then vulnerability can come about in one or more of three ways:

1. Resistance strength is diminished in some manner (e.g., cutting part-way through a rope)

2. Available force increases so that it exceeds existing levels of resistance (e.g., more weight is added to the end of the rope)

3. An asset is newly exposed to threat elements, either because the threat elements are new to its landscape or it enters a threat landscape it didn’t exist in before (more on this in a second)

Regardless of the cause, whenever available force becomes greater than the ability to resist, you have what can be referred to as a “vulnerability event” – i.e., vulnerability now exists where it didn’t before.

In our operating system scenario, nothing changed about the operating system itself. What changed was threat capability, which increased as soon as the threat community became aware of the condition’s exploitability. At that instant, the knowledge component of the threat community’s capability changed, and their resources likely changed soon after, when exploit code was developed.

Vulnerability, not loss

Here’s another example prompted by an excellent question posed by Stacy on the “layer8.itsecuritygeek blog — essentially, how should we classify “near miss” events where, for example, someone sends sensitive information unencrypted over the Internet? Is that a “loss event”? By my reckoning, the answer is no – unless and until actual loss to the organization materializes. Instead, it’s another example of a vulnerability event – i.e., vulnerability to loss now exists where it didn’t before (ref. #3 above).

Why “vulnerability events” matter

If history provides any clues to the future, some folks are going to question why I feel the need to define yet another term. It’s a fair question (pun intended).

If you’re familiar with FAIR you already know that we define two other event types – Threat Events and Loss Events. Threat events occur when a threat agent acts against an asset. Loss events occur when loss results from a Threat Event (i.e., as happens when force exceeds resistance). The reason it’s important that we make distinctions between event types is three-fold:

• It helps us to better understand our problem space, which is always a good thing,

• It allows us to communicate more consistently and effectively, and

• It enables us to identify and make meaningful use of metrics

This last point is especially important as we try to make better use of metrics.