CISO “How to” Without the Bull: Vulnerability Management

In the latest of my “no bullshit” cyber blogs, I’ll chart a course to better vulnerability management. My name is Nick Harris, and I’m the CISO in Residence at Assured.

Everyone working in cybersecurity has probably handled vulnerability management to some extent – so important is it to the function. And a large number of these individuals have no doubt shared the common frustrations of failed patches and information overload. However, there is light at the end of the tunnel.

It’s a quality question

Most vulnerabilities – with the possible exception of zero-days – arise due to some error in the system. It could be old third-party libraries, apps not updating, OS patching not deploying with your mobile device management (MDM), or even end-of-life systems. Those that know ISO 9001 know it’s about finding the root cause. Remove the cause and you remove the symptoms: in this case, the vulnerabilities.

So if the OS is out of date, why are patch rings failing? If apps are out of date, are they not managed centrally? If there is vulnerable code, what are the reasons this isn’t picked up as the code is written or merged? This is also a Six Sigma-type approach. It recognises there is logic to the “shift left” cliché, and that organisations with a solid quality management system (QMS), should use it to their advantage to focus on solving the root cause.

Add value to the big data

Even in a security-by-design workplace, a few vulnerabilities may slip through the net. In this event, consider first what can actually be exploited. In other words, is the asset public facing? No-one likes a Windows R2008 server, but if it is segregated off to just a few privileged access administrators on a VLAN behind multiple firewalls, it’s unlikely to be a major problem.

“Remove the cause and you remove the symptoms: in this case, the vulnerabilities.” Nick Harris

Of what can be exploited, do your homework to pull the CVSS score alongside which are critical assets with high scores, and present that list of priorities to the “resolve” team. This is a much more useful calculation: CVSS x asset criticality (impact) x exploitability. You’ll get more credit and time with IT, giving them a short, thought-through list rather than throwing a massive xls of CVEs over the fence.

Hearts and minds

The thought-through list shows you’re putting the effort in, and will start winning over the teams that have to do most of the work. IT teams may have to package the patch, test it, build a deployment plan, put it to the change advisory board (CAB), push it at some anti-social hour, and monitor for issues. If this is the case, the cybersecurity team must do its upmost to help with any of these steps, and a decent set of priorities covered earlier is essential.

Equally important is removing false positives. Do the work to take these out of the picture before starting the conversation. This will also help to win over the hearts and minds, by ensuring that you’re not asking colleagues to patch something that doesn’t need patching. It may even be worth trying to get to know them. Buy them a coffee and understand their stresses.

Know your business

Cyber should know the business and the operational impact of pushing updates to certain systems. Maybe it’s an e-commerce website, or operational technology (OT) that requires 24/7 operations—or even a PC running some scientific experiments that take 18 hours to complete. There are times when the risk of a system reboot is intolerable, and pre-planning an outage can be arranged. Having this insight and feeding this into the patching conversation can massively help patching teams.

“Do your homework, prioritise what needs fixing, and other people’s time, and you’ll win them over.” Nick Harris

If a vulnerability can’t be patched, record the risk with the owner and offer thoughts about compensating controls. Maybe this is the time to network-segment the affected assets; limiting  access to it. This pragmatic approach helps show the resolver teams in IT that you value their time.

Another part of knowing the business is putting the right resolver group together to make the changes. You want the people that have decision-making power. Prioritise their time over yours and have separate meetings where needed. Pull everything together that one resolver group can solve – patches, misconfigurations, pentest findings, BloodHound/PingCastle/Purple Knight results – and prioritise these. This way you are really helping expose the extent of what needs fixing, but also using your prioritisation to focus on what matters. I favour a fortnightly forum. A month loses momentum, and a week is too short to get the fix to CAB and see a change.

Avoid the gotchas

If you’ve addressed the root causes, there are hopefully fewer vulnerabilities coming through. Where there are fixes needed, and you’ve won hearts and minds and done all the hard work, things can still go wrong. If the IT team is mature, you’re in safe hands. Find out if they have a set of incrementally larger patch rings starting with a canary group that have less business impact if something happens. Determine if the changes have rollback plans, or you can restore the old configuration. Maybe your advice on how to do this safely, can help IT out.

In a lot of cases, I’ve offered to be both in the initial testing group, and also on standby to monitor for any side effects of a new update.

So there we go. Do your homework, prioritise what needs fixing, and other people’s time, and you’ll win them over. With any luck, it’ll make the next time you ask for a zero day to be patched at 5pm on a Friday go down a lot easier.

One small caveat. My advice is drawn from personal experience of delivering cybersecurity transformation programs across various sectors. But while I find these work, you may have a better way. Apply what works and let me know your own suggestions.