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 Kbler 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...

1. Denial. "The scan results are inaccurate -- there are a bunch of false-positives in your scan results!"

Denial is usually only a temporary defense for the individual (or support team). To move beyond this stage, you must keep support teams focused on positive actions. In other words, park the items they feel are false and focus on the items they agree are true positives. This will keep attention on what needs to be done, instead of feeding their belief that if they somehow discredit the results, they won't have to respond.

2. Anger. "Who is to blame? Did you raise a change request to do those scans?"

Many support units will deflect ownership of the findings by challenging your right to scan their devices on their networks. To get through this stage, it's imperative you have sufficient and demonstrable preauthorization to scan these networks. That could be confirmed via the change control process, but it typically involves negotiations on scan times, with senior-level authorization to conduct the scans on a predefined and ongoing basis.

3. Bargaining. "What's the real risk? Can you please delay your scans until next quarter because we're so busy? I don't own this! Can I have a security deviation that will lower my risk scores?"

The third stage involves the hope that the individual (or support team) can somehow postpone, deflect, or delay the inevitable. Ownership of the risk and accountability for remediation are the themes in this stage. To move through this stage, you must determine where the buck stops and work this from the top down. Identification of dependencies and defining responsibility for removing the barriers are critical success factors.

4. Depression "I keep patching, but new vulnerabilities are killing me. I can't seem to make any progress -- damn [insert name of software program here]!"

During the fourth stage, the support team begins to understand the certainty of the emergence of new vulnerabilities -- and how big the problem is. At this stage, the support unit will require your support. They'll want to know their efforts have yielded fruit. One useful tactic is to ensure your scanning and reporting process also captures risk avoidance and risk score reductions as key metrics. In other words, if you can quantify the effects of the good remediation efforts, then support teams can begin to accept the fact that success requires more than a one-time effort -- and that sustainable processes must be implemented to keep pace.

5. Acceptance. "It's going to be OK. I can't fight it, so I may as well prepare for it."

With this final stage comes peace and understanding -- and in the case of vulnerability management, a better focus on risk. Once the support teams realize this is an ongoing effort -- and that the scan results actually help to proactively identify areas of risk -- they are usually ready to implement meaningful process changes, and are more able to help protect the assets under their control.

A final note: Regression through the stages is normal, but as long as you are armed with the knowledge to understand the motivations behind the reactions, you will be equipped to help your support teams get through them. If possible, engage the responsible units at the beginning of the assessment process to help minimize the negative responses during all of these stages -- and deliver positive results.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.