The Lifecycle of a Vulnerability

Livecycle Events

Distinctive points in time divide the lifecycle of a vulnerability in phases each reflecting a certain state and an associate risk. To capture these states, we devise the following four points in time: the vulnerability Discovery-, Disclosure-, Exploit Availability-, and Patch Availability time. These dates are exogenous, in that the user of the affected software cannot influence them. At the Patch Implementation time the user implements the patch of the vendor. This time is endogenous as the user can choose when to implement the patch.

Note that the sequence of the exploit, disclosure, and patch time is not fixed. Both, the exploit- and the patch-time can be before, at, or after the discovery time. However, discovery time is always the first of all these times. In the table below we discuss these points in time individually.

Discovery Time

• The time of discovery is the earliest date that a vulnerability is discovered and recognized to pose a security risk. The discovery date is not publicly known until after the public disclosure of the respective vulnerability, see Disclosure Date.
  

Exploit Time

• The time of exploit is the earliest date an exploit for a vulnerability is
available. We qualify any hacker-tool, virus, data, or sequence of commands that take advantage of a vulnerability as an exploit.

Disclosure Time

• For a typical enterprise, it is not feasible to read all security related mailing lists and underground sources in order to identify new threats to their IT infrastructure. Businesses must concentrate and excel on their core competency, which is not necessarily information security. Therefore, the identification of new vulnerabilities is left to specialists that provide the necessary information in a structured format. The time of disclosure is the first date a vulnerability is described on a public and independet channel or source. See Public Disclosure for the definition.

Patch Time

• The time of patch availability is the earliest date the vendor or the originator of the software releases a fix, workaround, or a patch that provides protection against the exploitation of the vulnerability. Fixes and patches offered by third parties are not considered as a patch as enterprises do not allow third party fixes to be installed. A patch can be as simple as the instruction from the vendor for certain configuration changes. Note that the availability of other security mechanisms such as signatures for intrusion prevention systems or anti-virus tools are not considered as a patch either. Unfortunately, the availability of patches usually lags behind the disclosure of a vulnerability or the availability of an exploit. Patch information was extracted from security bulletins of vendors and software writers. Often, this information has to be manually correlated to the corresponding vulnerabilities.