Understanding OWASP ASVS Standards for Web Application Security

1. ^ About the

2. 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? What questions does ASVS answer? ? ? ?

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…

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. Coverage Depth – Level of Rigor  Breadth – Number of Requirements No malicious developers  The design has to be right  The controls have to be right Scan 

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 SecurityCode Review Manual ApplicationPenetration Testing 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)

13. Level 2 Options • Level 2AManual Penetration Test • Level 2BManual 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 2AManual Penetration Test • Level 2BManual 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? • 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 • 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: http://www.owasp.org/index.php/ASVS • You can send comments and suggestions for improvement using the project mailing list: • See “Mailing List/Subscribe” link on project web page.