Architects and developers are well aware of the term technical debt but many in the security community have never heard of this concept. Ward Cunningham, a programmer who developed the first wiki program, describes it like this:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
The cost of technical debt is the time and money it will take to rewrite the poor code after you ship and bring it back to the quality required to maintain the software over the long haul. Using debt in the financial world costs more absolute dollars than not using debt but it allows financial flexibility to do things you couldn't do without using debt. It's this flexibility that makes debt a valuable business tool. Technical debt allows development teams to meet a ship deadline or get a particular feature out to customers quickly which ultimately serves the business.
We can think of all the latent vulnerabilities in a piece of software as its application security debt. Security debt accumulates over time as more code is written without performing security processes during the development life cycle. A project takes on a lot of debt during the design phase if there is no threat modeling or architecture risk analysis performed. This will translate into costly redesign work at a later date. If code is written without using static analysis or following secure coding guidelines then security bugs are going to get into the final application that will eventually need to be eliminated at a higher cost. The more code that is written this way the more security debt accumulates.
There are obviously good business reasons for accumulating security debt because we see it everywhere in successful companies. However, there is a point in the lifetime of a lot of software
There are obviously good business reasons for accumulating security debt because we see it everywhere in successful companies. However, there is a point in the lifetime of a lot of softwareprojects where the debt gets too high and needs to be paid off by redesigning and rewriting a lot of code. If it isn't paid off the security debt risks impacting the bottom line. Application security debt has some similarities to technical debt but there are two big differences that we need to think about when deciding if our security debt load has gotten too high and needs to be paid off. Technical debt is all about maintainability and functional quality. Application security debt has breach cost and breach likelihood as factors. These factors are out of your control just like an adjustable interest rate is on financial debt. Breach cost can change over time due to changing compliance requirements and fines or increased brand damage. Breach likelihood changes as the threat space changes. If cost and likelihood go up, your debt goes up. I call these external factors the application's interest rate.
When your application was first written, the factors outside of your control, your application's adjustable interest rate, might be low. Attackers just aren't interested in your application. They might not have good tools to find vulnerabilities on the OS or platform you developed on. They may not have figured out how to monetize attacks where exploiting vulnerabilities in your application matters. Your application may not be popular, so it isn't worth the time to find vulnerabilities and write exploits. Your brand damage is low because you have no users. But if your application is successful, it is likely your application's interest rate will rise and your application security debt will increase to a point where you need to do something about your security flaws. The changing threat space usually comes as a surprise to a business in the form of a breach or multiple breaches. For a software vendor the wake up call will be the public disclosure of vulnerabilities in their products. When these events occur the business typically makes the decision that some security debt needs to be paid down. The pay down can range from a full rewrite of the software to major design changes to just fixing a class of security bug. The amount of security debt repayment will depend on the size of the debt, the interest rate, and the risk tolerance of the organization.
In January 2002, Bill Gates sent out the famous Trustworthy Computing memo. Microsoft had accumulated too much security debt in all their products. Their application interest rate was at an all time high. Something had to change. How this debt was paid down differed by product. One product which I was involved with as a security consultant was Internet Information Server (IIS). This was Microsoft's web and application server, a very security critical piece of software. IIS 4.0 and IIS 5.0 had a steady stream of vulnerabilities disclosed. From 2000-2002, OSVDB recorded 85 vulnerabilities in IIS alone. The rate of disclosures was not going down. The product had a huge mountain of security debt. Microsoft did the right thing and declared security debt bankruptcy on IIS 5.0. They decided to do a complete re-write of the product. In 2003, IIS 6.0 was only impacted by one disclosed vulnerability. It can cost a lot but you can recover from application security bankrupcy. Well, at least if you are a giant software vendor. Many smaller organization don't have this option. The next example is often repeated these days. It is the successful online startup scenario. With minimum funds an online startup wants to build the coolest new breakthrough web application as fast as possible and iterate, iterate, iterate. Application security is the last thing they are thinking about. They do nothing to make sure their application is secure and start building up security debt. The company hits it big and starts attracting millions of users. Their interest rate goes up. A vulnerability is found. It hits the news. They fix it but then another is found. More press. Their interest rate keeps rising. This cycle repeats for a few months. At some point an executive decision is made to pay down some of the security debt. Static and dynamic testing is performed and some bugs are squashed reducing debt, but the vulnerabilities keep flowing into the news. Now, interest is rising faster than debt is reduced as more attackers pile on. So the decision is made to hire some application security people, perform threat modeling, and do some major security re-architecting. Paying down the security debt now is more expensive than doing it securely the first time but security debt gave the company the flexibility to launch quicker and iterate faster.
From these examples we can see that security debt can build up and it is often manageable. If your application is valuable, whether you are an ISV, an online company, or an enterprise, you are going to have to make it secure at some point if it didn't start out that way. So the question for organizations then becomes one of security debt management. How much debt is too much, in an application or a portfolio of applications? Is there a way to model application interest rate to see how your debt may be rising, not due to new security flaws, but due to rising breach costs or rising attack likelihood?
Stay tuned for my next blog post where I will try to rough out a financial model using real data sources.