Schneier once proposed a vulnerability life cycle in a Crypto-Gram newsletter. He was wrong. During the time of writing my thesis, there were several important pieces of research no-one had put together to come up with a 'more correct' vulnerability life cycle. Given some recent discussions between Symantec and Verizon, I thought I would provide this is a more accessible format that a previous presentation I did on the subject, so that I could refer to it later.
The benefits of having an understanding of the life cycle, is that it provides a model to 'predict' the behaviour of various role players (e.g. bad guys, vendors and administrators) and understand how that behaviour impact on important parts of the risk management equations such as vulnerability, threat and impact. This is an important building block of any threat model.
The detail after the jump.
Let's get into it. Schneier's (and others) theorised model looks like this:
This life-cycle has the following stages:
- The creation of the vulnerability. This is when the vulnerability is created during the implementation of the vulnerable product.
- The discovery of a vulnerability. The vulnerability in the product is found. Several people could discover the vulnerability at different times. Little is ever publicly known about this step.
- The discovered vulnerability is disclosed. The disclosure could come from a variety of sources, in a variety of ways. It could be announced by the vendor or an independent researcher, or secreted away in a product’s Change Log.
- The vulnerability is corrected. This is usually done by the vendor releasing a patch or workaround. This should lead to an overall reduction in successful intrusions.
- The vulnerability is publicised. This can happen in a variety of ways; for example news reporting, publishing an advisory, worm activity; but the end effect is that many people know about the vulnerability.
- The exploit is scripted. This can mean that workable exploit code was released, or instructions on how to produce one are released. In either case, the result is that the number of attackers is greatly increased as those with less skill (script kiddies) can now perform the attack.
- The vulnerability becomes passé. Attackers become disinterested in exploiting this vulnerability. This is not guaranteed to happen with every vulnerability, and some vulnerabilities (and exploits) are shown to have cyclical popularity.
- The vulnerability dies. This happens when the number of possible targets vulnerable to exploitation drops to an insignificant level.
Now, if we take into account a bunch of research, available on page 30 of my thesis, we get the following corrected life-cycle:
The notable differences are:
- The scripting of an exploit leads to a surge in the number of attempted intrusions.
- The spike in exploitations will level off and tend towards a constant over time (e.g. SQL slammer intrusions are still floating around the internet at a fairly constant level).
- The number of vulnerable machines have a half-life.
- Most exploits are scripted before the end of the first half life.
- Vulnerabilities rarely die, but some do become passé and attacks stop trying to exploit them. If anything, the exploits re-spike several times.
Tracked: Jan 17, 10:15
Tracked: Feb 05, 09:23
Tracked: Dec 15, 06:29