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.

1. Banks and other financial institutions have started to use "sitekey" to protect customers from Phishing threat.

2. IE7 has a Phishing filter built into the browser.

3. There are sites like "scandoo" which can help you categorize web sites and eliminate Phishing and Malware web sites.

4. Multitude of other controls built into to existing security tools to prevent Phishing.

Do these controls really prevent a customer from the Phishing threat?  Check out this interesting research paper which make us wonder about:

1. How do customers react when "sitekey" is missing?

2. Do customers recognize the warning from the Phishing filter?

3. What % of customers know about the existence of tools such as scandoo?

It all boils down to how the customers embrace the technology design else it is only the illusion of the designer that technology is working the way the designer expected it to.

No wonder despite all these controls the Phishing trend has not reduced.

It is time to realize that providing an illusion of security is not enough. Educating customers to embrace technology for better security holds the key. This may involve significant time, cost and energy but that is the right path toward real security.