Last Updated on July 28, 2020
The Application Security Verification Standard (ASVS) V4 from the Open Web Application Security Project (OWASP) was created to help the industry advance the maturity and consistency of web application security testing. It’s no secret that hackers are always upping their game. The ASVS seeks to raise the bar for secure web apps in response.
To get first-hand insight into the ASVS and its intended uses, a recent episode of The Virtual CISO podcast features Daniel Cuthbert, ASVS project leader and co-author. Host John Verry, Pivot Point Security’s CISO and Managing Partner, is a big fan of the ASVS and has helped many clients apply it in their real-world environments.
A critical point that Daniel brings up multiple times in the conversation is the importance of understanding application architecture and mapping data flows to facilitate security testing. Daniel asserts point-blank: “We’re trying to bring that level of maturity up for the industry. … For Level 2 [for applications that handle any sensitive data], we expect you to have some kind of software development lifecycle that addresses security, right? We expect you to be doing threat modeling. We expect you to do a definition and analysis of all the architecture and connected remote services so you understand where your pieces are.”
By understanding application architecture and data flows upfront, you can more efficiently and effectively apply the ASVS because you’ll know which controls at a particular level apply to your application and which don’t.
The ASVS is extremely comprehensive. For ASVS Level 1, which supports basic security, 131 controls are described. For Level 2, which is recommended for any application that processes PII or other sensitive data, there are 267 controls. For Level 3, recommended for the most critical “1%” of applications, the number is close to 300.
Daniel clarifies: “It goes back to the architecture stuff, right? How well do you know what you’re building? And a lot of people still to this day don’t do that; they don’t have solid foundations to which they’re building applications. And what we’re trying to say is, if you do that at the start, you understand the data flow between components. Alright then, I don’t need half the ASVS, because I’m not doing that. Here’s the ones that I do need.”
Compliance mandates are also driving a requirement for data flow analysis, which both Daniel and John celebrate. As Daniel puts it: “GDPR made a lot of people finally realize that you have to understand where the data’s going, how it’s flowing, and where it’s being used. And [at OWASP] we’ve been saying this for a very long time.”
John heartily agrees: “Once you start doing data mapping of personal information, the logical next comment is, ‘Why am I not doing this with all of my sensitive data? Why wouldn’t I want to know what assets are processing, where the data’s being stored, who has access to it, what critical third-parties are touching it?’ It’s just logical. It’s information governance.”
If your organization buys or builds web applications, you’ll want to get all the first-hand insights from John and Daniel’s conversation. Click here to listen to this podcast episode. If you’re not an Apple Podcast fan, click here to access this episode and all the others from The Virtual CISO Podcast.