Vulnerability Lifecycle

Before discussing how to manage the risk from vulnerabilities, it is important to understand where vulnerabilities come from, and how they ultimately result in a security patch being issued.

The National Infrastructure Advisory Council (NIAC) is an advisory council that advises the President on the security of information systems for critical infrastructure. NIAC defines the vulnerability lifecycle in nine steps:

1. Research A vulnerability is discovered , either by a third-party researcher, by the software or hardware vendor themselves , or when it is found while being exploited in the wild. In practice, the majority of vulnerabilities resulting in patches are found by parties external to the vendor.

2. Verification The vulnerability is verified and found to be exploitable through a repeatable process. This action is normally also taken by the researchers who discovered the vulnerability.

3. Report A report is created and communicated to the vendor. This report contains details of the vulnerability including methods that can potentially be used to exploit the vulnerability.

4. Evaluation The vendor evaluates the report, working with the researcher if required, in order to confirm the existence and the potential impact of the vulnerability.

5. Acknowledgment The vendor acknowledges the vulnerability, responding to the researcher with updates and next steps that the vendor has planned.

6. Repair The vendor creates a patch for the vulnerability, or a potential workaround if no patch is planned.

7. Advisory and Patch Evaluation The vendor creates a security advisory, intended for public distribution, and ensures the reliability and integrity of the security patch.

8. Patch Release The patch is released to customers and the general public.

9. Feedback and Case Closure Feedback is processed on potential defects in the patch. This may include situations where the patch does not meet its goal of resolving the vulnerability, or new incompatibility problems that may have been introduced as a result of the patch.

This process illustrates how the vulnerability lifecycle works in an ideal scenario. While the process has become generally accepted behavior for both researchers and vendors , and to a large extent is followed, there is nothing that dictates that it always will be. In fact, there are many situations where a vulnerability is disclosed directly to the public, without any advanced notice to the affected vendor. While this uncontrolled disclosure may serve the researchers' intentions of garnering attention, it puts those affected by the vulnerability at substantial risk until a vendor patch becomes available.

When discussing the release of vendor patches, we should make a note that in some situations vendors provide tiered releases, meaning they will release patches to different constituents at different times. This may occur for example in the face of a serious vulnerability that may affect core network infrastructure. Major carriers and core internet infrastructure providers may receive verbal notification of a new patch several weeks or even months before the general public receives access. This is provided in an effort to protect the core Internet first and avoid any chance of the vulnerability leaking and an exploit being developed. This normally only occurs for vulnerabilities whereby their inadvertent release and subsequent exploitation could result in widespread outage of core Internet routing.

In addition to the NIAC vulnerability lifecycle just described, the Organization for Internet Safety (OIS) has also created a document called "OIS Guidelines for Security Vulnerability Reporting and Response." It contains many similarities to the NIAC guidelines and disclosure process, while having been developed in parallel. A current version of this document is available at http://www.oisafety.org.

Vulnerabilities may also be discovered when they are found to be actively exploited in the wild. Called zero-day vulnerabilities, as they are not publicly known and have no patch available, they are of the greatest concern to the security community. As a result of having no patch available, all affected systems are exposed and susceptible until a workaround or official vendor patch has been provided. Zero-day threats have the potential to cause widespread damage should they become more commonplace in the future.

Security researchers seek out new vulnerabilities for a number of reasons. Some are individual researchers whose goal is to show their astuteness at analyzing and discovering these flaws. Others are employed for this task by security companies who benefit from the attention that they receive, and the resulting rights to tout their discoveries. In such scenarios, these security companies have an ultimate goal of impressing and winning over new customers.

The vulnerability lifecycle as described by NIAC takes into account the process only up until a patch is issued. From an organizational standpoint, the vulnerability lifecycle reaches far beyond that and includes additional steps required to assess and implement these patches.

The vulnerability lifecycle management process can be summarized into a distinct set of steps that are followed by most organizations. While these three steps are oversimplified, they serve to illustrate the high-level requirements for a vulnerability management process: