The concept of ‘security debt’ has started to gain traction as a way to measure and manage vulnerabilities. Highlighting the accumulation of unresolved vulnerabilities within organisations by increasing the “cost” or impact of the debt as it ages. This notion, akin to technical debt in software development, underscores the risks associated with deferring necessary security actions. It also provides organisations with the ability to set risk appetites by setting debt budgets, similar to the reliability world where you have error budgets. It is probably time we consider adopting a similar approach to manage post-incident action items (PIAs) as well. While immediate responses to critical incidents are imperative, it’s the lingering, unresolved issues — the ‘long tail’ of post-incident tasks — that often pose significant threats if left unaddressed as byAlex Stamos during OneCon 2024. It’s the final few percent of unresolved work that often lead to compromises.
To effectively manage this security debt, organisations could implement a strategy that tracks and not only prioritises post-incident action items but adds a time based cost, or an age factor. As a result long outstanding issues can become of equal importance to the planning to a team or business unit as a high severity issue because of the impact it is having to their debt budget. It will also help shift away from arbitrary SLAs. It also empowers team to manage the workload of security debt, like vulnerabilities & post-incident action items, great simplifying reporting.
As suggested by Digital Ocean post on using the security debt principles for vulnerability management, you still need to set a recommended remediation date, but this can be set as part of the PIA creation process. Then as the debt ages the debt metric increase based on it’s time and severity. The higher severity the PIA the faster it will accrue due to the recommended remediation time, but so will older items that have been left to wither on the vine.
It is then critical to set realistic but secure security debt budgets with teams. It is recommended where possible that security vulnerabilities, post-incident action items and other security related work is all added to the same budget. This will empower teams to be the masters of their security destiny and moves the need away from the security team to argue within itself to prioritise wether these PIAs or vulnerabilities are more important. It is also important that if you implement this approach, you educate teams that sometimes there will be must do items that fall outside this process (Log4J for example) where the impact and criticality outweight a business impact, but these should be very few, as otherwise you will quickly render this whole metric pointless and loose the trust of the business.
In conclusion, while addressing immediate threats is crucial (and probably should be part of your incident response process), organisations must also focus on the residual tasks that, if neglected, can accumulate into substantial security debt. By implementing an age-based prioritisation strategy, businesses can ensure that older, unresolved issues receive the attention they deserve, thereby enhancing their overall security posture and reducing the risk of future compromises.
