The document provides tips on using "Jedi mind tricks" to build successful application security programs. It discusses speaking the business language to gain executive buy-in, translating technical risks like vulnerabilities into monetary risks, and deriving an organization's expected monetary loss from applications risks. It also recommends getting the right stakeholders involved early, doing a security assessment to demonstrate real risks, and integrating the program into the SDLC and other processes.

1. David Rook
Jedi mind tricks for building application
security programs
SecurityBSides, 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 developers
Jim Bird, blog comment:
“I’m a software guy. I don’t need a meme. I need practices and tools that
work, that help me get software out the door, better software that is more
reliable 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

11. 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

12. Application Security Alien
• I will use CVSS as an example
• Let’s pretend we are analysing a SQL Injection vulnerability

14. Application Security Alien
CVSS base score equation
BaseScore = (.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 if
Impact=0; 1.176 otherwise

15. Application Security Alien
CVSS Temporal Equation
TemporalScore=BaseScore*Exploitability*RemediationLevel*ReportConfi
dence

16. Application Security Alien
CVSS Environmental Equation
EnvironmentalScore=(AdjustedTemporal+(10-
AdjustedTemporal)*CollateralDamagePotential) *
TargetDistributionAdjustedTemporal = TemporalScore recomputed with
the Impact sub-equation replaced with the following AdjustedImpact
equation.AdjustedImpact = Min(10, 10.41*(1-(1-
ConfImpact*ConfReq)*(1-IntegImpact*IntegReq)*(1-
AvailImpact*AvailReq)))

18. 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

19. 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

20. The Business Language
• How does your business score risks?
• Let’s pretend we are analysing a SQL Injection vulnerability

21. The Business Language
A simple (common!) risk equation
Probability*Impact
Probability Impact Score Appetite
3 5 15 12

22. 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

23. 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

24. QUESTIONS?
www.securityninja.co.uk
@securityninja
/realexninja
/securityninja
/realexninja

25. Jedi mind tricks
for building
application
security programs
Chris Wysopal
CTO & Co-founder

26. The formative years… Padawan?
It was all about attack.
Early web app testing: Lotus Domino, Cold Fusion
Windows Security: Netcat for Windows, L0phtCrack
Early disclosure policies: RFPolicy, L0pht Advisories

27. 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

28. Why do we need executive buy in?
Application security programs will require
developer training
Application security programs will require
tools/services
Application security programs will impact
delivery schedules
Application security cannot be “voluntary”
Authority

29. Speaking the language of executives
CEOs
CFOs
CIOs

30. If money is the language of execs what do they
say?
How do I grow my top line?
How do I lower costs?
How do I mitigate risk?
Talk in terms of business risk and
use monetary terms when
possible.
Then we can we can speak the
same language.

31. Different types of risk
Legal risk – Legal costs, settlement
costs, fines
Compliance risk – fines, lost business
Brand risk – lost business
Security risk - ????

32. 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

33. 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 Business
Average 264,208 500,321 1,514,819 4,472,030 6,751,451
Per-capita 8 15 46 135 204
Ponemon 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
248
Ponemon per-capita data by US industry sector (US Dollars)
33

34. Threat Space Data
Error Attack Type Hacking Root Cause (Vulnerability
Physical Category)
Misuse Remote File Inclusion
Social
Insufficient Authentication
Hacking
Command Injection
Malware
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

35. How to Derive Your Expected Loss
expected 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 records
35

36. 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

37. Executives want…
An organizational wide view. Am I lowering overall
application risk?
– Internal code
– Outsourced
– Vendor supplied
– Open source
A program that has achievable objectives. What am I
getting 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?

38. 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

39. Q&A
Speaker Contact
Information:
Chris Wysopal
(cwysopal@veracode.com)
Twitter: @WeldPond
David Rook
www.securityninja.co.uk
@securityninja
/realexninja
/securityninja
39
/realexninja