The Vulnerability Lifecycle

by Paresh Borkar

In some ways software vulnerabilites have close resemblance with a living organism. It goes through much the same stages of lifecycle from being born ( discovered ) to information getting added , exploits getting published , patches made available by vendors / reserachers and systems and services eventually getting patched and newer things getting discovered about the same vulnerability.

It might seem that these state / lifecycle changes follow a fixed pattern or are predictable, however thats usually not the case, which makes it necessary for organizations to track these transitions very closely and adapt the vulnerability management / patching process to the changing threat perception.

Severity and Rating:

Very often severity and CVSS score get the attention when a new vulnerability gets discovered, however often these are based on initial observations / information and get revised as new facts get uncovered. Puting too much emphasis on vendor published rating / severity might not be a good strategy as vendors have their own scale which differs from other vendors / NVD. ThreatWatch takes an approach of normalizing the severity over a 5 point scale which provides a basic level of consistency.

Relationships:

A common question that many in the security world get asked, “Are these vulnerabilites related ?”. The reason this question pop’s up is because very often multiple advisories and bulletins get published by vendors that provide information about the same vulnerability across different platforms. Understanding these dependencies and realtions are important for effective mitigation planning.

Affected Products:

Investigating and concluding which products are vulnerable isnt always known and clear when a new vulnerability is discovered. A rookie mistake is to look at this information when a vulnerability is published and arriving at a decsion. It can take vendors and developers anywhere between days and weeks and in some cases years to include new products as being exposed to a vulnerability that has existed for a while.

Exploits and Patches:

Another common misconception is the beleif that exploits are only relevant during the window of vulnerability discovery and patches being available. Exploits often lead to vulnerability discovery. The most recent and publicly known example of this was the vulnerability in Apache Struts which resulted in the massive Equifax breach. An individual resercher had the exploit ready and published as part of his github repository an entire week before the vulnerability even had an official identifier ( CVE ).

Patches are released at different cadence and for vulnerabilites that span different software stacks , the developments have to be tracked.

Putting it all together

An ability to visualize the timeline of the vulnerability overtime and overlap that with your asset lifecycle / asset impacts is key for prioriatization and operational effectiveness of the overall patching process. Using ThreatWatch you can just do that, get in touch for more details ( info@threatwatch ) or request a demo.

Leave a Reply

Your email address will not be published. Required fields are marked *