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.
