The OWASP Application Security Verification Standard (ASVS) project was designed to help organizations vet and measure the security of applications, both internal and third-party. In this video, learn how to leverage the ASVS to assess and track the security of your entire application portfolio.
- [Narrator] At this point, I bet you're thinking, oh man, there is a lot that goes into verifying whether or not an application is secure. I really wish OWASP had a project that could help me out here. Well, you're in luck. OWASP maintains the Application Security Verification Standard project to help organizations manage their application security conversations with internal developers, external developers, and security testers. You can use the ASVS to document and track metrics around how secure your applications really are, inline with your organization's security maturity targets. Metrics aside, the ASVS contains extensive guidance on the application security controls that you should consider testing. And then there's the piece of the ASVS that I personally consider the most significant, procurement support. If you're looking for a clear set of application security expectations that you can share with your vendors, you can simply choose the right level within the ASVS and let your vendors prove to you that any apps developed by them meet that same level. What exactly do I mean by levels? The ASVS follows a capability model approach in defining three distinct levels of application security, based on your organization's security goals and capabilities. OWASP describes level one security as low assurance. You might choose level one if your development team is just getting started in security and you're focusing on just the basics. Level one goes after the simplest security controls and it's usually reserved for applications that don't store or handle sensitive data. For apps that do handle sensitive data, you'll want to consider going for level two security. Level two is intended to cover most of the apps in your portfolio and anything regulated by external standards, things like HIPAA or PCI, should definitely be vetted using at least the level two controls. The ASVS reserves level three security for business critical applications. These are often apps that need to be online 24/7, apps that your organization either lives or dies by. Level three requires the most effort to test, but if an app achieves level three certification, you can rest assured that the app meets your organization's security needs. The ASVS is structured using control objectives and requirements. There are 10 control objectives in total, with each objective representing a category of application security controls. like authentication, session management, error handling, and the like. These are the specific security things that an app needs to do. The stored cryptography objective, random values, and secret management. Each requirement is assigned one or more security levels. The basic requirements are all flagged as level one, but the more advanced requirements are flagged as level two and, in some cases, level three, depending on how much additional security the requirement adds to the application. Another thing I dig about the ASVS is that each requirement maps to the CWE, the same resource that SANS and MITRE used when they put together their top 25 list. When applied appropriately, the ASVS can provide you with a reasonable level of assurance, regardless of whether that application was developed internally or by a third party. As a security tester, you can perform offline tests, online tests, or a combination of both for each requirement, within your organization. This is an excellent resource that can help you put guardrails around your application security testing activities.
- Security frameworks
- OWASP Top Ten
- Building Security In Maturity Model (BSIMM)
- Planning your testing projects
- Creating security policies
- Source code reviews
- Application threat modeling
- Offline testing for OWASP Top Ten vulnerabilities