Application Security Debt & Application Interest Rates

1. Application Security Debt & Application Interest Rates Chris Wysopal CTO & Co-counder Veracode AppSecUSA

2. My Background Veracode’sCTO and Co-Founder @stake, VP Research & Development BBN, Sr. IT Security Analyst L0pht Heavy Industries, L0phtCrack, Netcat for Windows Lead author of “The Art of Software Security Testing” published by Addison- Wesley.

3. Intro • This is a thought experiment to find new ways of thinking about the cost of application risk • We need much better data on breach cost and root causes • Developers and managers understand technical debt

4. Technical Debt “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.” • Ward Cunningham, the programmer who developed the first wiki program

5. Technical debt sounds a lot like security weaknesses. Invisible from users but has negative value. This diagram was part of a presentation on technical debt by Philippe Kruchten

6. Application Security Debt • The latent vulnerabilities in a piece of software is the application security debt. • Security debt accumulates over time as more code is written without performing security processes during the development life cycle. • Design Phase • 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. • Coding Phase • 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.

7. Debt is Good! • 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.

8. Application Interest Rates • Application interest rates 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.

9. Likelihood • When your application was first written, your application’s adjustable interest rate, might be low • Attackers just aren’t interested in your application • No good tools to find vulnerabilities on the OS or platform you developed on • Can’t monetize attacks • Your application may not be popular • Your brand damage is low because you have no users

10. Example Dept 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. • How this debt was paid down differed by product. • IIS 6.0 was a complete rewrite (cost ??) •  From 2000-2002, OSVDB recorded 85 vulnerabilities in IIS alone •  In 2003, IIS 6.0 was only impacted by one disclosed vulnerability

11. Successful Startup Scenario • Build cool new app as fast and cheap as possible and iterate, iterate, iterate. • Nothing done to make sure their application is secure and start building up security debt. • The company hits it big and starts attracting millions of users. A vulnerability is found. It hits the news. They fix it but then another is found. More press. Their interest rate keeps rising. • Decision is made to hire some application security people, add security processes, do some major security re-architecting and coding • 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.

12. We can think of security debt as principle + interest • Principal is the cost to remediate. • Interest is the variable cost out of your control

13. Denim Group Remediation Cost Data Source: http://www.slideshare.net/denimgroup/real-cost-of-software-remediation

14. Source: http://www.slideshare.net/denimgroup/real-cost-of-software-remediation

15. Calculate Remediation Cost Remediation Cost = Overhead Cost + Sum per flaw category (Flaws * Remediation Time * Developer Cost)

16. Interest rates are tricky • We will use example of a company writing their own custom app AND operating that app • They bear the breach burden of the code they write • Not sure what to do with vendors as they shift the burden of their debt principle to their customers.

17. Monetary risk due to variable interest rate • Question: What is the monetary risk from vulnerabilities in your application portfolio? • Useless Answer: Monetary risk is expected loss; averagebreach cost multiplied by average probability of breach • Useful Answer: Monetary risk is your expected loss; derived from your vulnerabilities, your breach cost, threat space data Threat Space Data Your Breach Cost Your Vulnerabilities

18. Vulnerabilities in Your Application Portfolio

19. Your Breach Cost • Use cost analysis from your earlier breaches • Use breach cost from public sources • Example: April 2010 Ponemon Institute Report Ponemon average and per-capita US breach cost (US Dollars) Ponemon per-capita data by US industry sector (US Dollars)

20. Threat Space Data Top 7 application vulnerability categories 40% of data breaches are due to hacking Source: Verizon 2010 Data Breach Investigations Report 62% of organizations experienced breaches in critical applications in 12 month period Source: Forrester 2009 Application Risk Management and Business Survey

21. How to Derive Your Expected Loss ) ( expected loss % of orgs breached X breach cost X breach likelihood from vuln. category = f vulnerability category Baseline expected loss for your organization due to SQL Injection* ( ) 62% X $248 X 100,000 X 25% expected loss = f Sql injection *If your SQL Injection prevalence is similar to average SQL Injection prevalence, assumes 100,000 records

22. Monetary Risk Derived From Relative Prevalence Assume 100,000 customer records. For SQLi the expected loss is: 62% * $248 * 100,000 * 25% = $3,844,000 • Veracode 2010 State of Software Security Report, Vol. 2 • De-identified financial service company data from Veracode industry data

23. Summary • With good breach cost & likelihood data we can calculate expected loss from latent vulnerabilities • We can calculate remediation cost • Can model when it makes sense to remediate

24. Questions? Contact info: cwysopal@veracode.com Twitter: @WeldPond