Vulnerability Events
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.
Walter Mar 31
The problem is that the knowledge of said vulnerability is not common nor shared. There is a delta between when a vulnerability is known by the researcher, and when a vulnerability is known by the vendor and when the vulnerability is known by the industry. That window of oportunity allows the potential to exploit a vulnerability for which there is no known risk. This is why defense in depth is so important, as it is the only strategy which aims to mitigate the risk of defending against the unknown vulnerabilities presumed to exist.
Jack Mar 31
@ Walter — No question. We often can’t be certain about exactly when vulnerability events occur. Consequently, we can’t have perfect information about our risk levels. And you’re also right about defense-in-depth being crucial as a means of compensating for our uncertainty. The point I was trying to make, is that people too often don’t do a good job of distinguishing the data they’re gathering, which makes it difficult if not impossible to draw real meaning from it.
Related to your point about uncertainty, something I too often run into is people who believe that because something can’t be measured precisely (i.e., without uncertainty), then it isn’t worth measuring at all. The point to measurement is to reduce uncertainty - not remove it (which isn’t possible anyway). Depending on the nature of the problem (what’s at risk), even relatively minor reductions in uncertainty can be extremely worthwhile.
Jon Robinson Mar 31
I really appreciate this clarification. I think this is a better and more intuitive definition of vulnerability. I just read an article in ISSA that used the idea that thousands of vulnerabilities exist that we don’t know about yet. As soon as they are known, then we can patch and close them up - hopefully before they are exploited. The article said that we only know about 2% of them so we need to protect ourselves from the unknown ones using HIPS. In your model, HIPS would be adding resistance strength right? This means that even if you had an unpatched vulnerability that had become exploitable, it would be less vulnerable, since vulnerability is a function of the attackers threat capability, which was diminished by the HIPS.
Jack Mar 31
@ Jon - Thanks Jon. I’m glad this rings true for you. As to your question about HIPS adding resistance — you’re absolutely right.
Ben Mar 31
While I understand your reasoning, if you consider vulnerabilities in the context of risk, where risk takes into account the likelihood of a threat event being realized because of the exploitation of a vulnerability, then unknown vulnerabilities can exist and are relevant. It is just the risk would be much less because your perceived likelihood of the threat being realized would be approaching zero.
The benefit of looking at unknown vulnerabilities this way is if the impact of a threat is very high, but likelihood being close to zero (because of the concept of there may be a vulnerability found in the future) then there may be a valid reason that you need to mitigate the risk.
Osama Salah Apr 1
What about a bug in a system that would mess with my data integrity? Nobody knows about it but it could be messing up my data integrity. There is no threat community making use of it, it works on its own and it doesn’t need to be discovered. How would you handle that when considering risk? It could result in a loss, but is this bug a vulnerability?
rgds
Osama S.
Jack Apr 1
@ Ben - You are correct that as-yet-undiscovered weaknesses (potential vulnerabilities) are relevant. This is similar to the fact that undiscovered capabilities of the threat community also represent potential vulnerability. I’ll need to write another post soon about how we measure vulnerability (and, thus,, risk) in spite of these uncertainties.
@ Osama - Great question. Actually, the author of the buggy code is the original threat agent, with the buggy code acting as a proxy, so-to-speak (similar to malware scenarios). A longer blog post is required to cover this well, but suffice it to say that threat events occur at multiple levels in the scenario. The first one occurred when the programmer wrote the code. That gave rise to downstream threat events when the program runs. We have a modeling construct called”object modeling” that helps us to visualize and analyze these multi-level scenarios. As you might imagine from the word “object” in the name, it bears some resemblance to object oriented programming (although that isn’t where the modeling construct originated from).
Vulnerability to the first event (bug introduced into the code) existed because the programmer’s capabilities (threat agent capability) was deficient relative to what they were trying to accomplish. For those of you who have read the white paper and are familiar with FAIR’s Threat Capability and Control Strength factors, this appears to be a reversal in the relationship. It is. In non-malicious scenarios, where error is the problem, vulnerability exists when the difficulty of the task exceeds the actor’s (threat agent’s) capability. Keep in mind too, that capability includes Skill and Resources. Skill includes “Knowledge” and “Experience”, while Resources includes “Time” and “Materials”. It might be that the programmer had all the skills necessary, but was racing to meet a deadline, thus, the error.
Osama Salah Apr 1
Jack,
thanks for the clarification.
rgds
OS
Göran Sandahl Apr 1
Sorry, but this is just a glorified form of how we’ve always reasoned about vulnerabilities - namely that unless we know about them they don’t exist. I believe we need the exact oposit aproach of what you are preaching. Threats are likely to know alot more about vulnerabilities than you are.
If you really must simplify in order to do your calculations, make the assumptions that all your systems are, will be and have been vulnerable at some point. I think thats closer to the truth.
See the concept of The DoB (Date of Birth) of a Vulnerability
[1] for more information of this.
Cheers,
Göran Sandahl
[1] http://gsandahl.net/2007/11/27/the-dob-date-of-birth-of-a-vulnerability/
Ben Apr 1
@Jack: An interesting blog (I really should do something about writing a blog myself) may be the use of risk and the associated threats and the yet-to-be-known vulnerabilities to strengthen the use of the term “worlds/best security practice”.
It would follow a thought process such as:-
1. Based on past experience we have seen similar threats be realized eventually by vulnerability events. [increase risk likelihood]
2. Based on past experience we think there is a good probability we will see a similar vulnerability occur sometime in the future (based on vulnerability in similar technology, or specific product set) [increase risk likelihood]
Due to past experiences, we see a threat with a high likelihood produce a risk output that most people recommend mitigation should occur. While the specific vulnerability is not known, then best security practices are defined to minimize impact if the threat is realized at some point in the future.
Ben
Jack Apr 1
@ Ben - I absolutely agree that we must take prior experience and data into account in our estimates of vulnerability. More on this in next week’s post.
@ Göran - Interesting post you referenced regarding vulnerability DoB. Maybe I misunderstand your position, but if the release date of software is the DoB for a vulnerability, and if patches are software, then the release date of the patch is also the DoB for another vulnerability (simply replacing one vulnerable piece of software with another). That may be an oversimplification on my part, but it isn’t clear to me how that helps us manage the problem.
Actually, however, I agree that everything has the potential of someday being vulnerable. Tune in next week to see whether you agree with anything I have to say then.
Thanks,
Jack