Improving your response to vulnerability management
How to ensure the ‘organisational memory’ of past vulnerabilities is not lost.
A while ago the NCSC published a research paper describing A method to assess ‘forgivable' vs ‘unforgivable' vulnerabilities.
The paper proposed a method that would allow the reader to objectively assess if a vulnerability was 'forgivable’ or 'unforgivable’. The method outlined in the paper effectively quantifies how easily the mitigations required to manage the root cause behind a vulnerability could be applied.
The paper acknowledged that the ‘unforgivable vulnerabilities’ – originally coined by Steve Christie in his 2007 MITRE paper – is a loaded term, and suggested that organisations reframe the issue by assigning an ‘ease of implementation’ score to classes of vulnerability. This score would reflect the ease (or not) by which mitigations could be applied to address the root cause of a given class of vulnerability, and considered not just the technical feasibility of applying mitigations, but also the cost and knowledge required.
As we said at the time, all systems contain vulnerabilities, and many are complex and hard to avoid. At the same time, it’s important that organisations work to eradicate unforgivable vulnerabilities those vulnerabilities with top-level mitigations that are are ‘easy’ (and therefore expected) to be implemented. If these are discovered, developers (by which we also include vendors, SaaS providers, open source maintainers or contributors, vulnerability disclosures to open source projects, and team or individual developers) should focus on adapting their processes and ways of working to ensure they find and fix other vulnerabilities which share the same root cause. This is to ensure that:
- future products or services don't re-introduce the same mistakes
- the organisational memory of past vulnerabilities is not lost
The remainder of this blog looks at how you can modify your approach to vulnerability management, focussing on vulnerability researchers, developers, and the wider organisation.
Tips for vulnerability researchers
There are a number of ways vulnerability researchers can help mature the disclosure and response process. For example they could:
- Coordinate the vulnerability disclosure with the developer and provide ways the vulnerability could be fixed at its core.
- Share ways other similar vulnerabilities could be found, or provide other information that would aid in the remediation.
- Work with the developer to ensure they acknowledge that addressing the mistake is a key part of coordinated disclosure. Ideally, the developer should perform root cause analysis to systematically eradicate the vulnerability.
These informal approaches are particularly suitable for smaller organisations including open source projects, where resources are limited and where – you could argue – it’s even more important for the researcher to help the maintainers by providing a detailed vulnerability report, and also by providing a potential fix.
Tips for developers
For developers, the following behaviours can help them to learn from mistakes, and reduce the impact to users by ensuring the organisational memory of past vulnerabilities is not lost.
- Readiness to work collaboratively with researchers.
- Readiness to perform root cause analysis on vulnerabilities.
- Readiness to perform automated regression testing on code changes to detect re-introduction prior to release.
- Readiness to work to expedite realistic mitigation development timelines.
- Communicates effectively and directly with affected customers and ensure timely, accurate and updated information is provided, particularly regarding exploitation.
- Publishes an advisory that clearly and accurately explains the vulnerability, what product(s) are affected and the immediate actions you want customers to take.
- Explicitly state if the vulnerability is being exploited and how to detect exploitation.
- Where there is exploitation, engages with the NCSC and other national cyber security agencies so they can help understand the impact and work on identifying exposure and amplifying mitigation advice.
- Publish a CVE and include Vulnrichment information to support Stakeholder Specific Vulnerability Categorisation (SSVC) based vulnerability response.
Maturing your organisation’s approach
We’d encourage larger organisations with more resources to implement a more mature framework that developers could use to measure and improve their response to vulnerabilities. In the example below, a framework to identify key mitigation activities has been created by cross referencing types of risk (Strategic, Operational, Reputational) and maturity level (Basic, Advanced, Expert). This isn’t intended to be an exhaustive list, but highlights the kinds of activities that should be employed.
- Strategic risk is about reducing the potential harm to the organisation/vendor/customer, such as catching issues missed in development and testing.
- Operational risk is about reducing the exposure of vulnerabilities and reducing the opportunity for exploitation, such as having a clear and simple internal workflow to track, triage and remediate vulnerabilities.
- Reputational risk is about creating positive publicity and public perception and ways to positively impact the user relationship.
| Basic | Advanced | Expert | |
|---|---|---|---|
| Strategic | Policy | C-Suite understanding | Dedicated team |
| Operational | Ingress | Track, triage and fix | SDL feedback |
| Reputational | Acknowledgement | Root cause analysis | Information sharing |
So rather than framing the debate in terms of ‘unforgivable vulnerabilities', it’s probably more constructive to focus on adopting approaches that will ensure developers (and organisations) don’t forget what they’ve learned so they can find and fix other vulnerabilities which share the same root cause. System owners and network defenders should also learn from these vulnerabilities by employing robust and resilient vulnerability management processes.
Ollie N
Head of Vulnerability Management Team, NCSC
Share and print this article
Written by
