Skip to main content

System vulnerabilities: the good, the bad and the ugly

Posted by: , Posted on: - Categories: Digital skills, Our services, Security and Architecture

I’m a Senior Security Engineer at the MOJ and part of a team of talented technology specialists using skills such as penetration testing, incident response, cryptology, vulnerability research, and digital forensics to keep our systems and services secure.

Part of our role is to break systems to find out how secure they really are, and how vulnerable they are to attacks. System vulnerabilities vary in severity, but the standard scoring system doesn’t take account of the potential combined impact of multiple low severity vulnerabilities. Find out why this matters and how we’re working to address this.

Assessing the severity of vulnerabilities

In the wake of high profile attacks such as the NHS WannaCry outbreak, or the more recent Spectre & Meltdown attack and wireless vulnerability KRACK, we recognise that dealing with vulnerabilities is challenging.

When we discover vulnerabilities, the industry standard for assessing their severity is the Common Vulnerability Scoring System (CVSS). However when a score is assigned this can be misinterpreted because it doesn’t take account of multiple vulnerabilities being added together, or ‘chained’, to have a greater impact. This can have the effect of diluting down the overall vulnerability.

Vulnerability chains are difficult to fix or ‘patch’. The organisation running or selling the service or system will need to balance resources to fix vulnerabilities while also developing new features and maintaining the organisation’s reputation. The challenges of tackling vulnerability chaining make it a lower priority, which makes an attacker’s life easier.

Being a vulnerability manager is hard

Human nature looks for shortcuts so it’s common to start thinking ‘let’s focus on the critical and high vulnerabilities then we may be able to fix the others later’ which is a classic cause of technical debt. From a simple logic perspective this makes sense but fails to address chained vulnerabilities that represent a high or critical vulnerability when considered together, though individually they are less impactful.

This makes life as a vulnerability manager much more complex, since deciding the most important patches based just on an individual CVSS rating is not clear cut. It’s often tempting to take the following approach:

  • Patch the critical and high rating issues first, and quickly.
  • Tackle the medium rating issues over the following few months.
  • Accept that low rating issues might never be fixed.

But this is too simplistic. An attacker may be able to exploit a low rated vulnerability to take over a victim’s machine and use a second low rated vulnerability to pivot further into an environment and gain greater access.

A different mindset is required, introducing a cultural shift towards patching being the norm rather than the exception. It might be acceptable to delay or defer applying a patch for a while, putting an interim remedy in place such as disabling a feature to reduce the risk. But delay should not be the default as it will continue to build technical debt.

A much better approach is to say 'of course we will apply the patch' while accepting that occasionally you might not be able to for exceptional reasons. This has the added benefit of testing your change and continuity processes on a regular basis, and encouraging these types of processes to be streamlined. It’s clear from the recent attacks that applying all security patches is worth it to avoid the possible consequences of selectively patching.

What we’re doing about it

Our suppliers and teams proactively maintain and update our systems, but considering which patches to apply and when can always be improved. Removing friction from our change processes in deciding if a patch should be supplied is supporting this goal. Our overall technical strategy is a cloud first approach that helps us decrease the number of services we are responsible for patching and updating as we move to a shared responsibility model such as those available with AWS or Azure, who are able to dedicate more time to patching vulnerabilities than we would be able to.

We’re the first in-house team of security experts in a central government department as we believe security should be a priority for everything we build, deliver and support. We work closely with the National Cyber Security Centre (NCSC), and have collaborated with the Government Digital Service (GDS) and other departments to improve government security and help them build up their own in-house security teams.

Please get in touch if you have any questions or comments. Subscribe to the blog for updates on our work, or follow us on Twitter.

Want to work on things that matter? Find out more about working at MoJ Digital & Technology.

Sharing and comments

Share this page

Leave a comment

We only ask for your email address so we know you're a real person

By submitting a comment you understand it may be published on this public website. Please read our privacy notice to see how the GOV.UK blogging platform handles your information.