Modeling Reality: The Life of a Vulnerability

Erik Anderson (2)From the developer’s desk, Erik Anderson

Modeling Reality is a series of blog posts describing how real world scenarios are modeled by our software. This is the first installment.

The average end user has a rather simplistic view of a software vulnerability: they receive a notification telling them to update their software, and sometime later they finally get around to performing the update. The reality is much more complicated, as shown in the lifecycle diagram below.

 

vulnerability

Disclosure

We use the disclosure date as our starting point for determining the lifecycle of a vulnerability. We do this simply because that’s the information we have available to us in the National Vulnerability Database.

Discovery

In modeling a vulnerability, we first have to determine who discovered the vulnerability, because the lifecycle varies depending on the type of individual who discovered the vulnerability. We model three basic types of discovery: private, public, and bad actor.

The likelihood of each type of discovery depends on the software vendor’s security review policy, quality review policy, bug bounty program, and the accessibility of their source code. Our security experts rate each vendor that our software supports based on these four characteristics.

Bad Actor

The diagram above shows the lifecycle of a vulnerability discovered by a bad actor, an individual who keeps their knowledge of the vulnerability private so they can use it for their own nefarious purposes.

In this case, we have to work backward from the disclosure date to determine the date that the bad actor begins to use in the vulnerability in their attacks. This date is determined by a model based on analysis by our security experts, and can vary from a few weeks before disclosure to several years before disclosure.

Public

Public discovery is similar to bad actor discovery, except the discoverer releases his knowledge of the vulnerability to the public, usually in an effort to force the software vendor to fix it. Thus, the timeline is collapsed such that discovery and disclosure occur simultaneously.

Private

Private discovery encompasses any situation where only the vendor knows about the vulnerability until they disclose it publicly, which usually occurs simultaneously with the release of a patch. This can include discovery by a developer, a user who only reports it to the vendor, or a bug bounty hunter.

Patch Release

For vulnerabilities where the vendor does not have the luxury of developing a patch before disclosing its existence, there are a number of factors that determine when the patch is released. First, there is the amount of time before work begins on the development of a patch, which is dependent on the severity of the vulnerability and the vendor’s ability to divert resources from other projects to the development of a patch. Next, there is the amount of time required to actually develop the patch, which is dependent on the complexity of the vulnerability. Finally, there is the amount of time until the patch is released, which is dependent on the vendor’s patch schedule. For example, Oracle rarely deviates from its quarterly patch release schedule, whereas Microsoft has a monthly scheduled patch release and releases critical patches more frequently as necessary.

Patch Application

The patch application date is dependent on a business operation’s patching policy. We model a range of patching policies from daily patching to quarterly patching. We also model scenarios where the operation may patch low severity vulnerabilities (as determined by the Common Vulnerability Scoring System) less frequently or not at all.

 

Comments are closed. Posted by: raflores@sikernes.com on

Tags: , , , ,