Bridging Vulnerability Governance & Patch Management: A Playbook

Every place I’ve worked, vulnerabilities have been out of control. A lot of it has to do with a shitty inventory system. Many companies use what’s called a CMDB to store their inventory, a configuration management database, and they are never fully populated. At one place I worked, I took over the vulnerability governance program and motivated the patch management teams to get some traction.

The usual vulnerability process is when you take the inventory from the CMDB, put it into your vulnerability scanning tool, and then give the results to the owner/manager of the devices to fix the vulnerabilities. The reporting out of the box of any vulnerability management tool won’t correlate the asset owners. I can tell you first hand, that this process, without any experience of having done it, just sucks, and it causes fights between cybersecurity and IT peers as it looks like you’re throwing each other under the bus, making each other look bad. It gets very frustrating.

So let’s take a step back first, usually Vulnerability Governance is called Vulnerability Management. I don’t like calling it that because there is some weird stigma about people who do vulnerability scanning are also patching, but that’s not so. I like calling it vulnerability governance because we govern the whole process. We literally help create the policy documentation of how the process works, how we scan, how we score the vulnerabilities, and how we assign them. The Patch Management team needs to be part of the IT teams that have the relationships with the business where they can take production down at agreed upon times. It is set up this way so that when we do weekly/monthly meetings about the state of our vulnerability exposure, we can better delineate which team did the scanning for vulnerabilities and which team did the patching.

I was able to convince my line of business, technical leaders to not maintain their own inventories in their own spreadsheets and to put them into the CMDB. I think they only agreed because I said I would dedicate some resources to help them enter them. I also was able to get a data analytics person who could pull asset data from the CMDB, correlate it to the vulnerabilities found on those assets.

First problem came up. It wasn’t clear in the CMDB which line of business the asset was associated to. We had to go back to the line of business, technical leaders to find out whom the asset was mapped to.

We ran reporting again. Now it was clear that a vulnerability was tied to an asset tied to a line of business… But second problem arose. “Those aren’t my vulnerabilities!”. They were correct, some were application level vulnerabilities, some were operating system level vulnerabilities, and there was also middle-ware vulnerabilities. We worked with teams to figure out who was supposed to fix those as well. My analytics person really made things work with a lot of that logic.

Now that we had repeatable process on correctly assigning vulnerabilities, it was time for metrics and advancement.

We used a product called Tenable. It came with values that were out of the box, like a vulnerability priority rating. It also had its own severity rating, if it was exploitable, and if it was susceptible to remote attack. In the CMDB, the assets were marked if it was internet facing or not.

We created a rating system, so that we didn’t just take vulnerabilities at face value, when a vulnerability came in, we rated all those values and assigned a criticality that had remediation targets assigned to them.

We coded this into the process, so when a tool labeled a vulnerability as a high, within our environment, depending on if it was internet facing or not, it might be urgent or it might be high or moderate.

Because this was such an advancement, we ratified our vulnerability governance policies to reflect it, got leadership sign off, and this because ‘the standard’ for the company.

Now to automate!

We invested into an add-on in our ticketing system called a vulnerability response module. We now had an output and the ability to assign vulnerabilities to the right teams and would start relying less and less on spreadsheet reporting.

So all in all, if you have ever heard of SIPOC, which stands for Supply, Input, Process, Output, Customer, which is a high level way of looking at a process. Like this

On a weekly basis, I would host meetings with all my stakeholders to find out if there was anything inaccurate with the reporting, if the teams had enough information to do their work, and if there was anything else we could do to help them. If teams could not remediate a vulnerability within the SLA, we would create a separate meeting to not put them on the spot, understand their challenges, find out if we could implement any mitigating controls, and then hold a meeting with the GRC team to help them present their case for an exception.

Monthly, we would all pick a time and date to pull data from reports for our presentations to executive leadership. We would both, show that the teams are making traction at reducing vulnerability risk to the company and also to which ones need an exception provided that leadership could agree on it.