1. ^
About the

2. What questions does ASVS answer?
How do I know how much trust can be placed in a web application or web service?
How do I know what features to build into security controls used by a web application or web service?
How do I acquire a web application or web service that is verified to have a certain range in coverage and level of rigor? ? ?

3. How is the ASVS intended to be used?
It can be used to provide a yardstick with which to assess the degree of trust that can be placed in their web applications and services,
It can be used to provide guidance to security control developers as to what to build into their commercial products in order to satisfy web application and service security requirements, and
It can be used to provide a basis for specifying web application and web service security requirements in contracts.   

4. What is the status of the ASVS as an OWASP standard?
OWASP SoC 08 RFP – March, 2008
ASVS proposal accepted – April, 2008
ASVS Alpha draft released – October, 2008

5. What does the ASVS look like?
“Verification Levels” section
“Detailed Verification Requirements” section
“Verification Reporting Requirements” section

6. What are ASVS verification levels?

7. Earning a level… Security control behavior
Is the control designed right?
Security control use
Is the control used right?
Security control implementation
Is the control implemented right?
Security control verification
What do you have to do to verify the control?
Documentation
How do you have to write it up?

8. Levels in more detail Level 1 – Automated Verification
Level 1A – Dynamic Scans (Partial Automated Verification)
Level 1B – Source Code Scans (Partial Automated Verification)
Level 2 – Manual Verification
Level 2A – Manual Pentesting (Partial Manual Verification)
Level 2B – Manual Source Code Review (Partial Manual Verification)
Level 3 – Design Verification
Level 4 – Internal Verification

9. Breadth – Number of Requirements
Coverage
Depth – Level of Rigor
No malicious developers
The design has to be right
The controls have to be right
Scan 
Breadth – Number of Requirements   

10. Level 1 in more detail
Automated verification of a web application or web service treated as groups of components within single monolithic entity.

11. Application Security Verification Techniques
Find Vulnerabilities
Using the Running Application
Find Vulnerabilities
Using the Source Code
Manual Application Penetration Testing
Manual Security Code Review
Main Point
All four techniques are required to perform an efficient and thorough review
Teaching Points
Automated tools will try 500 signatures for every 5 that a pen tester might try.
Maybe the 450th signature is the successful attack
Automated feeds the manual process
Manual code review feed pen testing, Man pen testing feeds code review
Automated code analysis feeds manual code review – limits the LOC that must be manually reviewed
ALL 4 techniques feed each other.
Examples, Demonstrations, Stories, Notes
Note the overlap between manual and automated approaches as the most efficient activities.
Automated Application Vulnerability Scanning
Automated Static Code Analysis

12. Tools – At Best 45%
MITRE 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)
Now everyone WANTS to buy a tool that will solve application security for them. Let me start by saying that we have extensive experience with the application security tools on the market. We’ve been hired by four different tool vendors. In fact, we even developed and sold a static analysis engine for Java and .NET bytecode to one of the companies here.
But we don’t recommend starting with tools. And actually, neither do the tool vendors. Pretty much everyone agrees that you need to have a process in place that the tools can support.
There are two key problems with tools.
First is coverage. As you can see here, MITRE has identified about 695 types of security weaknesses. If you put ALL the tools together and add up what they CLAIM to be able to identify, you get about 45% coverage of the space. What’s worse is they don’t even find the right 45% - the ones that are riskiest to your organization. They find the 45% that is most amenable to finding automatically. And the tools simply aren’t smart enough to know what’s allowed and not allowed in your business logic. They can’t find most problems with authentication, authorization, logging, or encryption.
The second problem is extracting value from the data. The tools generate lots of data. In a recent customer review we ran Ounce and it generated 15,000 items. We carefully reviewed all of this data and isolated about 20 real findings. This isn’t easy work – you really have to understand application security to do it. Of the 20 findings, 16 were duplicate instances of the same underlying flaw. So after a few days of work we ended up with about 4 real findings, none of which were critical. In that same time, another Aspect engineer on the project identified 13 real vulnerabilities including 2 criticals using code review and penetration testing.
We can help you get value from the tools, but you’ll want a team to run the scans, lots of tailoring of signatures, and a process for extracting risks from all the data.

13. Level 2 Options Level 2A Manual Penetration Test
Level 2B Manual Code Review
Need BOTH to achieve a full level 2
But requirements can be filled by either

14. Level 2 in more detail
Manual verification of a web application or web service organized into a high-level architecture.

15. Level 2 Options Level 2A Manual Penetration Test
Level 2B Manual Code Review
Need BOTH to achieve a full level 2
But requirements can be filled by either

16. Level 3 in more detail
Design verification of a web application or web service organized into a high-level architecture.

17. Level 4 in more detail
Internal verification by searching for malicious code (not malware) and examining how security controls work.

18. What are ASVS verification requirements?
Security architecture verification requirements
Security control verification requirements 
Security architecture information puts verification results into context and helps testers and reviewers to determine if the verification was accurate and complete?

19. What are ASVS verification requirements?
V1 – Security Architecture Verification Requirements
V2 – Access Control Verification Requirements
V3 – Authentication Verification Requirements
V4 – Session Management Verification Requirements
V5 – Input Validation Verification Requirements
V6 – Output Encoding/Escaping Verification Requirements
V7 – Cryptography Verification Requirements
V8 – Error Handling and Logging Verification Requirements
V9 – Data Protection Verification Requirements
V10 – Communication Security Verification Requirements
V11 – HTTP Verification Requirements
V12 – Security Configuration Verification Requirements
V13 – Malicious Code Search Verification Requirements
V14 – Internal Security Verification Requirements

20. A positive approach Negative Positive
The tester shall search for XSS holes
Positive
The tester shall verify that the application performs input validation and output encoding on all user input

21. Requirement Summary

22. What are ASVS reporting requirements?
R1 – Report Introduction
R2 – Application/Service Description
R3 – Application/Service Security Architecture
R4 – Verification Results 
Is the report sufficiently detailed to make verification repeatable?
Does the report have sufficient types of information to allow a reviewer to determine if the verification was accurate and complete? 

23. Where do I go from here?
You can download a copy from the project web page:
You can send comments and suggestions for improvement using the project mailing list:
See “Mailing List/Subscribe” link on project web page.