Description: PPT : - http://2011.appsecusa.org/p/debt.ppt
Application Security Debt and Application Interest Rates Chris Wysopal
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.
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.
Along with discussing application security debt and interest rates, Wysopal will provide examples of debt repayments, such as the famous Trustworthy Computing memo from Bill Gates and the successful online startup scenario, to show how security debt can build up and, in many cases, be managed. He will also provide attendees with steps to take in order to determine how much debt is too much and if there's a way to model application interest rate to see how your debt may be rising.
Tags: securitytube , Confidence , hacking , hackers , information security , convention , computer security , owasp-11 , owasp-2011 ,
Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying.