Jul 19
Security

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:

  1. The creation of the vulnerability. This is when the vulnerability is created during the implementation of the vulnerable product.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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:

  1. The scripting of an exploit leads to a surge in the number of attempted intrusions.
  2. 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).
  3. The number of vulnerable machines have a half-life.
  4. Most exploits are scripted before the end of the first half life.
  5. Vulnerabilities rarely die, but some do become passé and attacks stop trying to exploit them. If anything, the exploits re-spike several times.

Posted by Dominic White

Last modified on 2008-07-19 23:04

0 Trackbacks

  1. No Trackbacks

2 Comments

Display comments as(Linear | Threaded)
  1. Kyle Maxwell says:

    How does this corrected model handle disclosures of vulnerabilities without a coordinated patch? That is, what about when the patch is somewhat delayed from the disclosure for whatever reason?

  2. Dominic White says:

    The patch and disclosure are similar events in terms of threat activity, but not in terms of vulnerability. If a vulnerability is disclosed, but there is no patch (or exploit) available, it is likely that you would see the same increase in attempted exploitation, but not the corresponding decrease in vulnerable machines. You may see a small decrease if a workaround is provided.

Add Comment


E-Mail addresses will not be displayed and will only be used for E-Mail notifications

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA