Data Protection expectations on Vulnerability Management

Legal cases aren’t often a source for guidance on system management but, thanks to the cooperation of the victims of a ransomware attack, a recent Monetary Penalty Notice (MPN) from the Information Commissioner (ICO) is an exception. Vulnerability management was mentioned in previous MPNs (e.g. Carphone Warehouse, Cathay Pacific, and DSG), but they don’t go much beyond “do it”, and “unpatched for more than four years is not acceptable”. Now we have information on factors to include in patch prioritisation, steps that a vulnerability management process may include, and the features of data protection law that should encourage vulnerability management. The last is particularly interesting, as those features aren’t just in UK law, but are common to privacy laws across the globe.

In this case, intruders stole documents containing personal data from an archive server, before encrypting it and demanding ransom. It was suspected that access was obtained via an unpatched vulnerability in software, though this wasn’t proven. The vulnerability had been announced by the software vendor in December 2019 and mitigations provided, a patch was made available in January 2020, but the system was not patched until June (para 51). The ICO stresses that:

  • The original announcement “strongly urges affected customers to immediately upgrade to a fixed build OR apply the provided mitigation” (52);
  • The UK National Cyber Security Centre (NCSC) published an alert in late January warning “that malicious actors were exploiting” the vulnerability, with a tool to detect the vulnerability (53);
  • The NCSC published a further joint advisory with the US Department of Homeland Security in April (54);
  • The vulnerability was given a Common Vulnerability Scoring System (CVSS) Base score of 9.8, “Critical” (57).

There are clear messages here that organisations should monitor security announcements by vendors of software and operating systems, as well as the NCSC and similar (inter-)national bodies; also that CVSS scores and reports of active exploitation should be considered when prioritising remedial action.

Not actually explicit in the MPN, but strongly implied, is that we should be prioritising among vulnerabilities. It seems unlikely that this was the only vulnerability announced during the relevant period: the MPN’s focus on factors creating urgency implies that resources should have been allocated first to the high-severity, actively-exploited one. However, even for this urgent vulnerability, the ICO recognises that immediate patching may not be the appropriate response: there is explicit mention (59) of “test[ing] the patch prior to deployment” and reference (56) to ISO27002’s “suggestion that organisations should define a timeline to react to notifications of potentially relevant technical vulnerabilities, and once a vulnerability has been identified, associated risks should be identified and actions taken, such as patching the system to remove the vulnerability”. Application of the patch should be “prompt” (59) and the Cyber Essentials timescale of 14 days is referenced (57).

The MPN therefore appears to be a strong endorsement of risk-based vulnerability management, using tools such as vendor and NCSC alerts, CVSS scores and likelihood of exploit tools such as Forum of Incident Response and Security Teams’ Exploit Prediction Scoring System (EPSS) and the CISA known exploited vulnerabilities catalogue. The MPN also discusses multi-factor authentication and encryption, so could be a useful reference for those, too. Four features of data protection law should provide a particularly effective incentive to adopt such good practice: the law applies to behaviour, of an individual organisation (the ICO has explicitly rejected comparisons with “industry practice” in previous MPNs), expects risk to be considered (through words such as “appropriate measures”), and can apply sanctions irrespective of harm or causation. I’ve found these features in laws from six continents so, wherever you are, demonstrating how security measures relate to a law of this kind should be a good way to communicate their importance between technical, compliance and regulatory spheres.


By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *