There are some interesting ideas bouncing around on the concept of technical debt and security debt.
The world of economics might seem an unlikely area to find inspiration for information security issues, but it has been a major source of interesting research. A recent paper by Ollie Whitehouse of Recx on the subject of “security debt” (www.recx.co.uk/papers.php) adds to this body of research.
Software developers and other engineers are well aware of the idea of technical debt, even if they don't call it that. The basic idea is very simple: as you develop a product there are often compromises made to get things released on time or to budget. These compromises accrue as a “debt” that needs to be paid off with future work to fix the issue properly.
What tends to happen is that such technical debts build up gradually in the background until they reach critical mass, at which point the whole thing collapses and you suddenly find yourself, Wall Street-crash style, having to pay off a whole load of software debt you'd either ignored or not been aware of with little or no notice – of course, like the financial world, you may end up lumbered with technical debt that you inherited.
Security debt works in a similar fashion, but the results “pay” in terms of security vulnerabilities. Unfortunately, though, whereas every user of a software product acts as a technical debt detective, constantly moaning about broken or missing features, relatively few people outside the company will identify security debt (and, if they do, may consider it more valuable kept secret as a potential attack vector). Equally, if someone outside the business discovers technical debt, the impact is typically less severe than if they find security debt.
Issues from technical debt can often be worked around by users who are (relatively speaking) sympathetic, whereas the “users” of security debt problems are your attackers, and they're generally not interested in helping out.
Perhaps the most useful ideas introduced in the paper are those covering the ongoing management and payback of security debt. The idea of applying interest to security debt is particularly good. By gradually accruing more “cost” due to interest, less major but older vulnerabilities can find their way to the top of the fix-list if they're ignored for too long. I've used a similar idea myself to ensure old but low-priority things on my to-do list don't get ignored. This is a valuable method as it's all too common to find “unimportant” issues ignored for years on end, only to become the chink in the armour that let in an attacker (back in the days of the RTM worm, most of the backdoors used were known but considered unimportant and consequently ignored).
Of course, estimating any sort of debt exposure is more complicated than it first seems. In the financial markets major problems were caused by over-reliance on formulas such as Black–Scholes, and concepts like value-at-risk give a false air of confidence in estimates (although, arguably, this is the fault of the people interpreting the figures rather than the maths itself).
However, as Keynes put it: “I'd rather be roughly right than precisely wrong.” Getting a better if imprecise awareness of security debt and, most importantly, integrating its management and payoff with the development lifecycle of a product or ongoing review process of security systems, is a good step forward. While zero-day attacks and neat technical vulnerabilities tend to grab the headlines, novel concepts such as security debt have a much longer life and the potential to improve security across multiple products and threat types.
It's great to see this sort of thinking published and promoted freely. Thinking about and measuring security debt could significantly improve the appreciation of risks and their ongoing management. In security, as in finance, having an accurate picture of your real exposure is vital to properly appreciate the best areas in which to focus investment. Knowing how much debt you have is the first step in repaying it, whether it's paid back in money or security fixes.