SecurityBSides London - Jedi mind tricks for building application security programs

  • 3,934 views
Uploaded on

Presentation by David Rook and Chris Wysopal

Presentation by David Rook and Chris Wysopal

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
3,934
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
24
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. David RookJedi mind tricks for building applicationsecurity programsSecurityBSides, London
  • 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 (www.securityninja.co.uk)• Speaker at international security conferences• Nominated for multiple blog awards• A mentor in the InfoSecMentors project• Developed and released Agnitio
  • 3. Agenda• Using Jedi mind tricks on your developers• s/Application Security Alien/Business Language/i;
  • 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. 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.”http://securosis.com/blog/good-programming-practices-vs.-rugged-development
  • 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. Application Security Alien• We speak an alien language • We talk of injections, jackings and pwnings
  • 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. Application Security Alien• I will use CVSS as an example • Let’s pretend we are analysing a SQL Injection vulnerability
  • 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. Application Security AlienCVSS Temporal EquationTemporalScore=BaseScore*Exploitability*RemediationLevel*ReportConfidence
  • 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. 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. 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. The Business Language• How does your business score risks? • Let’s pretend we are analysing a SQL Injection vulnerability
  • 16. The Business LanguageA simple (common!) risk equationProbability*Impact Probability Impact Score Appetite 3 5 15 12
  • 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. 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. QUESTIONS?www.securityninja.co.uk @securityninja /realexninja /securityninja /realexninja
  • 20. Jedi mind tricksfor buildingapplicationsecurity programsChris WysopalCTO & Co-founder
  • 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. 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. 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. Speaking the language of executivesCEOsCFOsCIOs
  • 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. Different types of riskLegal risk – Legal costs, settlementcosts, finesCompliance risk – fines, lost businessBrand risk – lost businessSecurity risk - ????
  • 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. 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. Threat Space Data40% 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. 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. 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. 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. 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. Q&A Speaker Contact Information: Chris Wysopal (cwysopal@veracode.com) Twitter: @WeldPond David Rook www.securityninja.co.uk @securityninja /realexninja /securityninja39 /realexninja