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.

Application Security Debt
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 projects 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.

The Changing Application Security 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.

Example Debt Repayments
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.

A Security Debt Model
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.

Veracode Security Solutions

Veracode Security Threat Guides

I like to consider myself a “web guy”. I keep up to date on what the browser vendors are doing and generally keep track of specifications and how web developers are using the new abilities granted to them. As most people in the web community know by now, the Cross Origin Resource Sharing (CORS) specification has pretty much dominated over the competing Uniform Messaging Policy (UMP) specification. CORS was put forward as a safe method of easing the restrictions of the Same Origin Policy. CORS has now become widely adopted by browser implementers and can be used to transfer content across different domains, effectively loosening the Same Origin Policy so two servers can communicate easier.

So what is a “Web” example of code rot leading to vulnerabilities? Recently, I’ve found numerous cases of web developers passing in client supplied input into an XMLHttpRequest (XHR) object without checking or validating the URL. Some developers like to take information from the URL such as a URL fragment, or query parameter and then pass this as the URL value into the XHR Object’s open method. The response from this request would usually be content that is either evaluated or injected into the DOM of the current page in an asynchronous manner. Usually, this would not be a problem because requests were restricted to the same domain, so the worst that could happen is someone could load (or cause the page to not load) content from that very same site. However, with the advent of CORS, this now becomes a serious liability.

This example of code rot can even be found in systems designed to train web application developers in how to design secure applications. You will notice the text in the below image: “XHR requests can only be passed back to the originating server.” You can quickly assume this application was created prior to the CORS specification becoming commonplace.

In this example, the WebGoat developer is taking the value from the “Enter a URL” box and passing it directly into the XMLHttpRequest object’s open method:

xmlHttp.open("GET",document.getElementById("requestedURL").value,true);

Prior to CORS and provided they trust the content on their site, this wouldn’t be considered a serious issue. With CORS however, the XHR object will now be able to send requests to third party sites. In the above example it does this by sending a preflight request to veracode.com which tells the browser; webgoat.veracode.com wants to read your data, do you allow it? If veracode.com responds with an “Access-Control-Allow-Origin: *” header, then a secondary request is made by the browser (from webgoat.veracode.com) and the data is extracted from the veracode.com site. If veracode.com was hosting malicious html or script code, and depending on how the victim page handles that response data, we could easily find our site becoming a victim to Cross Site Scripting attacks.

A similar issue to the one above was found way back in July 2010 and was used to exploit a facebook.com sub-domain. For more information on that particular issue I suggest you read Matt Austin’s blog post about it, as it captures the issue perfectly: http://m-austin.com/blog/?p=19.

My goal here is to not blame CORS or any other browser specification or implementation but rather highlight an issue that is easy to forget about. Code rot isn’t just about letting your code deteriorate and become unusable; it’s also about understanding your security posture and how to meet the demands of a changing environment.

So next time you see a cool new feature in a Browser or a Framework think to yourself, is my code still OK?

Veracode Security Solutions

Veracode Security Threat Guides

Veracode Security Guides

Data Security Resources