Technical debt is essentially a metaphor that explains the consequences of using poor practices or taking shortcuts to speed up IT projects, usually applied in the context of software development. A very good overview on technical debt can be found here. If we use it in the context of information security, it still applies on many levels, and we can call it security debt.
What we mean by security debt
Security debt could be considered very similar to technical debt or just a consequence of it, but there are a couple of factors that can set it apart. First of all, technical debt is usually concerned with application quality and code maintainability whereas security debt would be concerned with breach probability and its cost. Also, while technical debt can be paid back with technical solutions (a code rewrite for instance), paying back security debt could involve technical, process, and/or administrative changes.
Another difference is that applying a financial model to security debt is far more complex. As with technical debt, fixing the security problems of a given application or system would be like paying the principle. The cost to the business in case of a breach could be considered a variable interest rate that may go up or down depending on a large number of factors. Some of these factors might be out of your control, such as how attractive to attackers is the system/application/organization where the security problem resides. Therefore the interest you would have to pay can range from zero (you solved the security problem without it ever being discovered or exploited) all the way to business-crippling amounts (like a massive breach affecting thousands of users with long-lasting brand and image consequences). Chris Wysopal at VeraCode has a couple of blog posts, here and here that tackle the subject of security debt in applications and a possible financial model for it. It’s an interesting read and it shows how difficult it can be apply a financial model to security debt.
How does it happen?
There are many ways an organization can accumulate security debt. One of the most common is when a new development project is implemented without applying any type of security review during its life cycle. This type of security debt is the most similar to traditional technical debt. Another way of acquiring security debt is when there is a lack of proper maintenance to systems or applications. This maintenance not only includes all the code developed for the project, but also to every third-party component the system relies on. Skipping the updates required to keep the application up to date generates security debt. This particular type in turn creates two of the 10 most common security problems you might not realize you have: legacy applications and the ancient “rock solid” servers on which those applications reside.
Security processes can also be a source of debt when shortcuts are taken in their design and implementation. For example, an organization installs a log management solution but, due to lack of resources or other constraints, while the logs are gathered, the review process is missing, incomplete, or there is nobody available to perform it regularly or at all. Incurring this type of security debt is even more dangerous, because it can escape notice and at the same time, create a false sense of security.
Just like with technical debt, the purpose of security debt is to raise awareness. This is especially important with security debt, because most of the time, its presence can go unnoticed until it’s too late. Using both the security and technical debts metaphors can go a long way in helping address issues that would otherwise remain unattended.