Tech Insight: The Five Stages Of Vulnerability Management

About the author: Greg Thompson is vice president of enterprise security services at Scotiabank. This article appears as a special to Dark Reading courtesy of the (ISC)2 Advisory Board of the Americas Executive Writers Bureau.

Many of us remember 2003 as the "year of the worm." On Jan. 25 of that year, we saw the SQL Slammer worm take down automated teller machines across the United States while infecting millions of vulnerable Windows PCs and servers worldwide. This worm exploited weaknesses in the Microsoft SQL Server that were well-known -- in fact, Microsoft had patched them more than six months earlier.

Later that year, the Blaster worm hit, exploiting another vulnerability that had been patched just a month earlier. The trend was becoming clear: The time between the disclosure of vulnerabilities and the emergence of malware exploiting them was shrinking -- fast. And a new era in vulnerability management was born, sending organizations feverishly scanning their networks for vulnerable devices.

As is often the case in information security, something had to go really wrong before any action could take place. With the launch of Slammer and Blaster, IT security departments were now able to make compelling business cases to deploy enterprise-class network scanning technology with the ability to discover and report on the status of vulnerability risks. So we deployed tools from vendors such as Foundstone, nCircle, Qualys, and Rapid7, to name a few.

These vulnerability management tools gave us important intelligence data on the health of our network-connected endpoints and the quality of our asset inventories. There was so much data, in fact, that it took some time to sort out our priorities and how we report to the responsible support groups within our organizations. We now have the ability to react with intelligence -- and a boatload of data.

Unfortunately, having the vulnerability data is only half of the problem. The other half is doing the remediation; for that, we need help from other teams within IT. The challenge: How do we get support teams to acknowledge that there's a problem, and that they need to remediate it quickly before the weaknesses get exploited?

In this article, I'll explain the five stages of vulnerability management and provide some advice on how to get to the end stage: acceptance.

The concept of the five stages came to me during a recent meeting with one of the nine major support units in my organization. One of the team members was bargaining with me regarding my assessment of the risk level associated with the several thousand devices the support team had to manage. The argument was that our risk assessment was unfair because some devices have dependencies that are outside of this support unit' scope of control.

As the argument continued, it struck me that it was following a path very similar to the K�bler Ross Model, which describes the five stages of grief individuals go through when faced with death or tragedy. Like many vulnerability management discussions, it went something like this...