Software Security
Group project:
application security verification
using OWASP ASVS
Brainstorm
What would you do if you if someone asked you to check if some
piece of software that they use (and possibly bought) is secure?
Assurance
Big challenge:
how can we provide assurance that an application is secure?
NB: it is much easier to
demonstrate that an application is not secure
than it is to
guarantee that it is secure
Assurance
Why is the question below silly?
how can we provide assurance that an application is secure?
The question is meaningless. We only hope to answer this
meaningfully if we know
• what the security requirements are
• what kinds of attacks we are consider
Assuring security of software
Before trying to get some assurance about the security of any piece
of software
1. What does it mean for this application to be secure?
2. How important is it? ie how big is the impact if it is insecure?
Does the application involve the crown jewels of the organisation?
3. What is the attacker model?
ie what can attackers do to attack the system?
Thinking about abuse cases can be useful in all this.
You may decide after all this that it’s not worth the effort to try and
provide some assurance.
Group Project

We do a security code review of a web-application

following the OWASP standard


Application Security Verification Standard (ASVS) – 2014 edition
trying out some source code analysis tools
Time for this +/- 30 hours, ie afternoon/morning per week for next months
(white box) code review vs (black box) pen test
7
Goals

experiencing a software security review process


how useful are existing standards and approaches?


esp OWASP Application Security Verification Standard
how good are tools we can use?


ie white-box code review, rather than a black-box pen test
eg Fortify, RATS, CheckMarx
how should security design and implementation decisions wrt security
have been made and documented?
Non-goals
• For some, this is throwing you in at the deep end.
I realise your experience varies a lot!
• Don’t be tempted in copying results from other groups
– whether or not find any security problems is not important, it’s
about forming an well-argued opinion about code reviews, the
ASVS as guide for this, static analysis tools, etc.
• My hidden agenda: getting some empirical data on doing code
reviews
I
OWASP ASVS
Application Security Verification Standard (2014)
aims to normalise the range in coverage & level of rigour in performing
web application security verifcation
NB not “verification” in the mathematical
or even testing sense
OWASP ASVS Process
• sadas
OWASP ASVS Levels
Categories of Verification Requirements
V1 Security Architecture
V9. Data Protection
V2. Authentication
V10. Communication Security
V3. Session Management
V11. HTTP Security
V4. Access Control
V12. Security Configuration
V5. Input Validation
V13. Malicious Code Search
V6. Output Encoding/Escaping
V15. Business Logic
V7. Cryptography
V16 Files and Recourses
V8. Error Handling & Logging
V17 Mobile
V1 & V12 removed in 2014 edition
V10, V15, V17 out of scope
ASVS Security Requirements
ASVS provides checklists of security requirements to check

clustered in categories
where security requirements are stated in a ‘positive’ way , eg

‘negative’
there are no XSS attacks

‘positive’
all HTML output that contains user-supplied input is properly escaped
Note: checking positive instead of negative statements is very different
Verification Techniques

Dynamic
Static

using running application
using source code

aka (penetration) testing
aka code review
This can be


manual application
penetration testing
automated application
penetration testing
This can be
manual
automated using code
analysis tools
Focus of the group project
static source code analyzers

RATS
basic old tool – glorified GREP/CTRL-F

Fortify SCA & CheckMarx
modern state-of-the-art commercial tools
•
RIPS
open source tool, but RIP?
Any other tools you know or have experience with?
Yasca, PHPLint, FindSecurityBugs ....
16
Caveat: tools cover at best 45%? [study by MITRE]


All application security tool vendors’
claims put together cover only 45% of
the 695 known vulnerability types
Very little overlap between tools, so to
get 45% you need them all (assuming
their claims are true)
More generally: it is hard to get objective
evidence about quality & usefulness of
these tools really are. You have to
experience using them to get an idea.
17
To start
• Form groups
• Fix a weekly morning/afternoon/night to work on this?
• Keep a log what you are doing, and who does what
• Read the AVSV
• Look at the code
• Install the code to get a feel for functionality?
• Try some of the code analysis tools?
• Think about you divide the work & organise this
18
Remember: we’re skipping the most important steps
By jumping straight to look at the code using the ASVS
we skip the most important first steps of any security analysis:
1. identifying security requirements and their importance
– ie. threats and impacts, for a good risk assessment
2. defining attacker model
– eg `standard’ online attacker, insiders, vandals, hacktivists, mafia,
NSA, …
– should also consider capabilities & motivation
even if your site has little value, an attacker might still be interested in
using it to break into the machine hosting it, or to use it as an attack
vector to attack your visitors, to steal re-used passwords, …