Secure development (for a
secure planet)
Eoin Keary
OWASP Board member
Senior Manager, Ernst & Young
eoin.keary@owasp.org
OWASP IISF
2010
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org
ME
Leader within OWASP since 2002
OWASP Global Board member
OWASP Testing Guide
OWASP Code Review Guide
OWASP Irish chapter founder
A&P Senior Manager: Ernst & Young
Application Developer &
Application Security: 12 Years
OWASP IISF 2010
OWASP – What’s it all about
OWASP is a worldwide free and open community focused on improving the security of
application software.
Our mission is to make application security visible so that people and organizations can
make informed decisions about application security risks.
Everyone is free to participate in OWASP and all of our materials are available under a
free and open software license.
The OWASP Foundation is a 501c3 not-for-profit charitable organization that ensures the
ongoing availability and support for our work.
OWASP IISF 2010
3
2009 OWASP Supporters
OWASP IISF 2010
The ISSUE…
More and More application level issues……
Sept/Oct 2008 – SQL Injection $9,000,000 in 24
Hours (RBS)
Business Logic Exploited in US Army Servers – May,
2009
HSBC and Barclays sites were both hit by major XSS
vulnerabilities - June 2009
The Telegraph site was exposed by a severe SQL
injection vulnerability - June 2009
“In the last five years, approximately
500 million records containing personal
identifying information of United States
residents stored in government and
corporate databases was either lost
or stolen.” - “www.identitytheft.info”
OWASP IISF 2010
5
Things are not improving
Eg: XSS was discovered circa 1996
Initially is was a curiosity
Evolved to an exploit
Further evolution to a worm

MySPACE- SAMMY WORM 2005
,
first self propagating xss worm
Wide scale problem, 13 years later!
 Toolkits: Mpack, LuckySploit, ISR-Evilgrade etc
 Attacking the client: Phisihing, Malware Upload
Ironically easy to fix and detect but 60%-70% of
sites are vulnerable..
OWASP IISF 2010
6
What’s in your application?
Application Code is like sausages:
Sausage
Code
“Taste nice”
Apps Look Nice
Filling
Fulfil requirement
We don’t want to know
Same with code!!!!!
what's in them, or how they
are made!!!!
Currently software QA (Unit, System, Integration, UAT) tests what
software can do, not what we can make it do!!!!
Negative Testing is still not commonplace within the SDLC but ironically easy to do!
OWASP IISF 2010
7
Where is your Application Perimeter?
Border Router?
WAF/Firewall?
Public facing – Authentication Page
Software food chain?
Lets look at this for a sec:
 Where does your code come from? Who wrote it? How do I
know its secure / developed in a secure manner?
OWASP IISF 2010
8
Software food chain
COTS
(Commercial off
the shelf
Application
Code
Outsourced
development
SubContractors
Third Party
API’s
Bespoke
outsourced
development
Third Party
Components
& Systems
Bespoke Internal
development
“More”
Degrees of trust
“Less”
You may not let some of the people who have developed your code into your offices!!
OWASP IISF 2010
9
How do we (attempt) to fix this
problem?
Secure Software development
Application Security Testing (Manual, Automated)
Code review (Automated, Manual)
CHALLENGES FACING HUMANITY
•
Make solar energy affordable
•
Provide energy from fusion
•
Develop carbon sequestration
•
Manage the nitrogen cycle
•
Provide access to clean water
•
Reverse engineer the brain
•
Prevent nuclear terror
•
Secure cyberspace
•
Enhance virtual reality
•
Improve urban infrastructure
•
Advance health informatics
•
Engineer better medicines
•
Advance personalised learning
•
Explore natural frontiers
http://news.bbc.co.uk/2/hi/7248875.stm
OWASP IISF 2010
10
Solutions
OWASP IISF 2010
11
Philosophy of Secure Development
 Security =F (Quality)
 Write code "properly"!!
 Adhere to business requirements
and no more!!
 "Is it a business requirement that I
can access other users data”
 Negative use case/testing
Design Goals:
“Security at source”
“Self-defending/aware
applications”
Fulfill business requirements
and nothing more, nothing less.
 Lets forget XSS, SQLI CSRF for a
minute.
 There are easier ways to commit
fraud than this:



Breaking business Logic
Breaking authorisation logic
Breaking arithmetic logic
 They require less technical skill but
can be very powerful and automated
tools do not detect such issues.
OWASP IISF 2010
12
Philosophy of Secure Development
 Security Touch-Points (Design, Development, Test, Deployment)
 Catch issues before they go live – Runtime & Static Analysis
 Overall Improvement in quality: Stability, Reliability, Security
Probably the cheapest solution in the long term:
Lower TCO & risk of compromise, overall better quality
OWASP IISF 2010
13
Software security tollgates in the SDLC
Iterative approach
Security
requirements
Design
Review
Risk
analysis
Requirements
and use cases
Design
Risk-based
security tests
Static
analysis
(tools)
Test plans
Manual Code
Review
Code
Penetration
testing
Test
results
Field
feedback
OWASP IISF 2010
Application Security Verification
Techniques – Check out the OWASP ASVS
Find Vulnerabilities
Using the Running Application
(Outside-In)
Find Vulnerabilities
Using the Source Code
(Inside-Out)
Manual Application
Penetration Testing
Manual Security
Code Review
Automated
Application
Vulnerability Scanning
Automated Static
Code Analysis
OWASP IISF 2010
15
360°/Greybox Testing – Pros & Cons
OWASP IISF 2010
16
Runtime Testing
 Automated (“Wide but not Deep”)
 Manual (“Deep but less wide”)
 Good:
 Good:
 Detecting technical vulnerabilities:
 Detecting technical vulnerabilities:
– XSS, SSI, SQLI, Buffer Overflows……
– XSS, SSI, SQLI, Buffer Overflows
 Produce good coverage in a limited
time (if lucky!)
 Cost effectiveness
 Bad:
 Does not detect business logic
issues very well
 False sense of security
 False Positives & (worse) False
Negatives
 Can Fail with complex flows or rich
client apps (Web 2.0, Legacy)
 Non Standard environments, Can be
fooled.
 Business impact identification.
 Contextual aspects, critical business
focus
 Detecting business logic issues
 More Accurate
 Allows for creativity to identify non
standard variants (E.g. “Persisted
XSS”)
 Bad:
 Time limited coverage, variant
coverage (attack vectors)
 Tester skill dependant (think about OWASP
ASVS)
 Can be expensive
OWASP IISF 2010
17
Lets look at Code review
OWASP IISF 2010
18
Code Review (Static Analysis)
 Automated
 Good:
 Generally good (no crawling
setbacks)
 High accuracy in identifying code
violations (not necessarily security
violations)
 Fast and more cost effective
 Manual
 Good:
 Generally good with technical
vulnerabilities
 Somewhat limited but better with
logical vulnerabilities
 Potentially excellent if performed
properly,
– Can detect Denial of Service,
Privacy & Audit issues
– Can detect potential backdoors,
root-kits & malware
 Bad:
 Logical Vulnerabilities
 Runtime binding/relationships not
apparent
 Issues are signature based, may
not detect many variants
 External compensating controls not
apparent.
 High rate of false positives
 Problematic when not all code
available
 Bad:
 Slow and relatively expensive.
(Critical apps only?!)
 Poorly written code (think sausage)
can be difficult to review
OWASP IISF 2010
19
Code review
Key weakness with Automated Code review
 Authorisation logic
 Insecure code: No authorisation code =
No code [to review]
 No code = tool has no issue to report
 No issue to report = secure code!! [clean
report]
 Business Logic:
 Transactions:
– Any transactional function which
does not require re-authentication is
potentially vulnerable to CSRF
– Requires a workflow decision: Tools
don’t understand business workflow
 Mathematical controls:
 Horizontal Authorisation (User
Authorisation)
– A user can not view, manipulate or deny
access another user’s [of the same role]
data.
 Vertical Authorisation ( Role
Authorisation)
– A user can not perform any action
outside their role.
– Negative values
– Limits
– Conversion rates
 Data Transfer
– Funds transfer: source and
destination accounts (Logic)
– Data size
OWASP IISF 2010
20
Code review
Key weakness with Automated Code review
 Password Complexity:
 Unless complexity logic is hard coded;
– RegEx stored in configuration file
– Runtime binding to file: static analysis
tools wont see this
OWASP IISF 2010
21
Tools – At Best 45%!
(SAMATE-2009)
 MITRE (US Gov research
foundation) found that all
application security tool vendors’
claims put together cover only
45% of the known vulnerability
types (695)
 They found very little overlap
between tools, so to get 45%
you need them all (assuming
their claims are true)
OWASP IISF 2010
22
Solution: No single answer
Both Runtime testing and Static Analysis have
their strengths and weaknesses. – we probably
need to use both (360 Analysis)
Simple authorisation and business logic
verification is often overlooked.
Most effective approach is to attempt to build
secure code during the SDLC.
Third-party verification services; “How do I
measure my return on
investment?”………OWASP ASVS!!
OWASP IISF 2010
23
Challenges…
There is a huge range in coverage and rigor
available in the application security verification
market!
“We did a security assessment” ;
Consumers have no way to tell the difference
between:
 Someone running a grep tool, and
 Someone doing painstaking code review and manual testing!
 Security FUD, Snake Oil, Skill of Assessor.
There are differences in coverage and rigor between
types of tools, between tools and manual techniques, and
between types of manual techniques!
OWASP IISF 2010
24
Philosophy of ASVS
 It is intended as a standard for
how to verify the security of web
applications
 It should be applicationindependent
 It should be development lifecycle independent
 It should define requirements
that can be applied across web
applications without special
interpretation
Design Goals:
The standard should define
increasing levels of application
security verification
The difference in coverage and
level of rigor between levels
should be relatively linear
The standard should define
functional verification
requirements that take a whitelist (i.e., positive) approach
The standard should also be
verification tool and technique
independent!
Any such standard also needs to be commercially-viable
and therefore not overly burdensome!
OWASP IISF 2010
25
What Questions Does ASVS Answer?
 What security features should be
built into the required set of
security controls?
 What are reasonable increases in
coverage and level of rigor when
verifying the security of a web
application?
 How can I compare verification
efforts?
 How much trust can be placed in a
web application?
A Success Story:
Application Security Verification
Standards are specifications
produced by OWASP in
cooperation with secure
applications developers and
verifiers worldwide for the
purpose of accelerating the
deployment of secure web
applications. First published in
2008 as a result of an OWASP
Summer of Code grant and
meetings with a small group of
early adopters, the ASVS
documents have become widely
referenced and implemented.
ASVS can answer these questions for applications
ranging from minimum risk applications, to critical
infrastructure applications.
OWASP IISF 2010
26
What are ASVS Verification Levels?
OWASP IISF 2010
27
Level 1
Automated
verification of a
web application
treated as groups
of components
within single
monolithic entity
OWASP IISF 2010
28
Level 2
Manual verification
of a web
application
organized into a
high-level
architecture.
OWASP IISF 2010
29
Level 3
Level 2 + Threat
modeling
information to
verify design
(Secure
Architecture)
OWASP IISF 2010
30
Level 4
Internal
verification of a
web application
by searching for
malicious code
(not malware)
and examining
how security
controls work.
OWASP IISF 2010
31
Verification Requirements
Various levels have different technical
verification requirements.
This is due to the additional effort and rigor
of level 4 compared to level 1 and all inbetween.
Verification requirements are prescriptive
such that fulfilling them helps to achieve a
level of verification.
V1. Security Architecture
V2. Authentication
V3. Session Management
V4. Access Control
V5. Input Validation
V6. Output Encoding/Escaping
V7. Cryptography
V8. Error Handling and Logging
V9. Data Protection
V10. Communication Security
V11. HTTP Security
V12. Security Configuration
V13. Malicious Code Search
V14. Internal Security
Verification Requirement
Level
1A
Level
1B
Level
2A
Level
2B
Level
3
Level
4
V1.1 Verify that all application components
(either individual or groups of source files,
libraries, and/or executables) that are present
in the application are identified.






V1.1 Verify that all components that are not
part of the application but that the
application relies on to operate are identified.




V1.1 Verify that a high-level architecture for
the application has been defined.[1]




V1.1 Verify that all application components
are defined in terms of the business functions
and/or security functions they provide.


V1.1 Verify that all components that are not
part of the application but that the
application relies on to operate are defined in
terms of the business functions and/or
security functions they provide.


V1.1 Verify that threat modeling information
has been provided.


Example Security Architecture Documentation Requirements
OWASP IISF 2010
How do I get started using ASVS?
 Buyer and seller: agree
how technical security
controls will be verified
by specifying a level from
1 to 4
 Perform an initial
verification of the
application
This is where the
Contract Annex can
be used to specify an
ASVS level
Educate and
Collect
The OWASP ASVS, OWASP Contract Annex, and OWASP ESAPI
can be used to support your Software Development Life Cycle
(SDLC).
Here is where you find
out if your application
has vulnerabilities
such as Cross-Site
Scripting (XSS), SQL
injection, CSRF, etc.
Perform Initial
Verification
This is where
ASVS can be
used
Using ASVS requires planning and in that respect is just like any
other testing exercise!
OWASP IISF 2010
33
Integrating ASVS into your SDLC
(Outsourcing not required)
Define your own
application risk
levels mapped to
ASVS for security
requirements
definition
Requirements
Definition by
Risk Level
Here is where you plan
how you are going to
meet all your selected
ASVS security
requirements.
App A:
Design for a
Particular Risk
Level
Use ESAPI as
part of your
Design to
meet the
ASVS req’ts
Build your ESAPI by
extending ESAPI
controls, integrating
your standard
controls, and
implementing
needed custom
controls. Use it to
protect your app.
Implementation
Here is where you find
out if your application
has vulnerabilities
such as Cross-Site
Scripting (XSS), SQL
injection, CSRF, etc.
Perform Initial
Verification
Fix
vulnerabilities
Remediate
and Reverify
Verify against
your selected
ASVS level
Iterate App Enhancements
OWASP IISF 2010
34
Questions
Questions
www.OWASP.org/index.php/Ireland