Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Jedi mind tricks for building application security programs


Published on

BSidesLondon 20th April 2011 - David Rook and Chris Wysopal (@securityninja & @WeldPond)
From the perspective of both an employee of a financial transaction provider and a security vendor, this presentation will focus on how to effectively sell the business value of application security to executives, middle management, and development groups
-----------for more about David & Chris go to

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Jedi mind tricks for building application security programs

  1. 1. David RookJedi mind tricks for building applicationsecurity programsSecurityBSides, London
  2. 2. if (slide == introduction) System.out.println("I’m David Rook");• Security Analyst, Realex Payments, Ireland CISSP, CISA, GCIH and many other acronyms• Security Ninja (• Speaker at international security conferences• Nominated for multiple blog awards• A mentor in the InfoSecMentors project• Developed and released Agnitio
  3. 3. Agenda• Using Jedi mind tricks on your developers• s/Application Security Alien/Business Language/i;
  4. 4. Using Jedi mind tricks on developers• Most developers actually want to write secure code • You need to take ownership of the app sec problems with them • Developers generally like producing quality code, use this! • They want security knowledge with good practices and tools
  5. 5. Using Jedi mind tricks on developersJim Bird, blog comment:“I’m a software guy. I don’t need a meme. I need practices and tools thatwork, that help me get software out the door, better software that is morereliable and more secure.”
  6. 6. Using Jedi mind tricks on developers• How you can help developers? • Help them understand how to write secure code • Own application security problems with them • Don’t dictate! Speak, listen, learn and improve things
  7. 7. Application Security Alien• We speak an alien language • We talk of injections, jackings and pwnings
  8. 8. Application Security Alien• We speak an alien language • We talk of injections, jackings and pwnings • We present findings in weird formats with a side order of FUD
  9. 9. Application Security Alien• I will use CVSS as an example • Let’s pretend we are analysing a SQL Injection vulnerability
  10. 10. Application Security AlienCVSS base score equationBaseScore = (.6*Impact +.4*Exploitability-1.5)*f(Impact)Impact =10.41*(1-(1-ConfImpact)(1-IntegImpact)*(1-AvailImpact))Exploitability =20*AccessComplexity*Authentication*AccessVectorf(Impact) = 0 ifImpact=0; 1.176 otherwise
  11. 11. Application Security AlienCVSS Temporal EquationTemporalScore=BaseScore*Exploitability*RemediationLevel*ReportConfidence
  12. 12. Application Security AlienCVSS Environmental EquationEnvironmentalScore=(AdjustedTemporal+(10-AdjustedTemporal)*CollateralDamagePotential) *TargetDistributionAdjustedTemporal = TemporalScore recomputed withthe Impact sub-equation replaced with the following AdjustedImpactequation.AdjustedImpact = Min(10, 10.41*(1-(1-ConfImpact*ConfReq)*(1-IntegImpact*IntegReq)*(1-AvailImpact*AvailReq)))
  13. 13. Application Security Alien• We speak an alien language • We talk of injections, jackings and pwnings • We present findings in weird formats with a side order of FUD • We feel security should just happen without having to justify it
  14. 14. The Business Language• We need to speak the business language • We need to talk about things the business cares about • We need to present findings in a format that makes sense
  15. 15. The Business Language• How does your business score risks? • Let’s pretend we are analysing a SQL Injection vulnerability
  16. 16. The Business LanguageA simple (common!) risk equationProbability*Impact Probability Impact Score Appetite 3 5 15 12
  17. 17. The Business Language• We need to speak the business language • We need to talk about things the business cares about • Present findings in a format that makes sense to the business • Application security is no exception when it comes to resourcing
  18. 18. Jedi mind tricks and alien translations• Apply the KISS principle to everything you do • Keep everything as simple as possible, complexity doesn’t help • Understand what developers want and need to write secure code • Work with the business and use their language and formats
  19. 19. QUESTIONS? @securityninja /realexninja /securityninja /realexninja
  20. 20. Jedi mind tricksfor buildingapplicationsecurity programsChris WysopalCTO & Co-founder
  21. 21. The formative years… Padawan?It was all about attack.Early web app testing: Lotus Domino, Cold FusionWindows Security: Netcat for Windows, L0phtCrackEarly disclosure policies: RFPolicy, L0pht Advisories
  22. 22. Now with professional PR team… Time to help the defensive side Led @stake research team @stake application security consultant Published Art of Software Security Testing Veracode CTO and Co-Founder
  23. 23. Why do we need executive buy in?Application security programs will requiredeveloper trainingApplication security programs will requiretools/servicesApplication security programs will impactdelivery schedulesApplication security cannot be “voluntary” Authority
  24. 24. Speaking the language of executivesCEOsCFOsCIOs
  25. 25. If money is the language of execs what do theysay?How do I grow my top line?How do I lower costs?How do I mitigate risk?Talk in terms of business risk anduse monetary terms whenpossible.Then we can we can speak thesame language.
  26. 26. Different types of riskLegal risk – Legal costs, settlementcosts, finesCompliance risk – fines, lost businessBrand risk – lost businessSecurity risk - ????
  27. 27. Translate technical risk to monetary risk What is the monetary risk from vulnerabilities in your application portfolio? Monetary risk is your expected loss; derived from your vulnerabilities, your breach cost, threat space data Your Threat Your Breach Space Vulnerabilities Cost Data 32
  28. 28. Your Breach Cost Use cost analysis from your earlier breaches Use breach cost from public sources – Example: April 2010 Ponemon Institute Report(US Dollars) Detection & Notification Ex-Post Lost Total Escalation Response BusinessAverage 264,208 500,321 1,514,819 4,472,030 6,751,451Per-capita 8 15 46 135 204Ponemon average and per-capita US breach cost (US Dollars) Comm Consu Educat Energ Financi Health Hotel Manu Media Pharma Researc Retail Serv Tech Transp unicati mer ion y al care & facturin h ices nology ortatio on Leisur g n e 209 159 203 237 294 153 136 149 310 266 133 256 192 121 248Ponemon per-capita data by US industry sector (US Dollars) 33
  29. 29. Threat Space Data Error Attack Type Hacking Root Cause (VulnerabilityPhysical Category) Misuse Remote File Inclusion Social Insufficient AuthenticationHacking Command InjectionMalware Backdoor/Control Channel 0% 20% 40% 60% 0% 10% 20% 30% 40%40% of data breaches are due to hacking Top 7 application vulnerability categories 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 34
  30. 30. How to Derive Your Expected Lossexpected loss vulnerability category = f ( % of orgs breached X breach cost X breach likelihood from vuln. category ) Baseline expected loss for your organization due to SQL Injection* ( ) 62% X expected loss Sql injection = f $248 X 100,00 X 25% *If your SQL Injection prevalence is similar to average SQL Injection prevalence, assumes 100,000 records35
  31. 31. Monetary Risk Derived From Relative Prevalence Vulnerability Breach Baseline Average % of Your % of Your Monetary Category Likelihoo Expected Apps Affected1 Apps Risk d loss Affected2 Backdoor/ 29% $4,459,040 8% 15% higher Control Channel SQL Injections 25% 3,844,000 24% 10% lower Command 14% 2,152,640 7% 6% same Injection XSS 9% 1,383,840 34% 5% lower Insufficient 7% 1,076,320 5% 2% lower Authentication Insufficient 7% 1,076,320 7% 7% same Authorization Remote File 2% 307,520 <1% <1% same Inclusion Assume 100,000 customer records. For SQLi the expected loss is: 36 62% * $248 * 100,000 * 25% = $3,844,000 1. Veracode 2010 State of Software Security Report, Vol. 2 2. De-identified financial service company data from Veracode industry data
  32. 32. Executives want…An organizational wide view. Am I lowering overallapplication risk? – Internal code – Outsourced – Vendor supplied – Open sourceA program that has achievable objectives. What am Igetting for the money I am spending?A program that is measurable: metrics and reporting.Am I marching toward the objectives? – Which dev teams, outsourcers are performing well? – How is my organization doing relative to my peers?
  33. 33. Tips to make the program successful The right people have to understand what is going to happen before you start Do a real world pen test or assessment of a project. Demonstrate relevant risk. Integrate into existing processes SDLC Procurement/legal M&A
  34. 34. Q&A Speaker Contact Information: Chris Wysopal ( Twitter: @WeldPond David Rook @securityninja /realexninja /securityninja39 /realexninja