Last Updated on December 8, 2020
The Application Security Verification Standard (ASVS) from the Open Web Application Security Project (OWASP) seeks to elevate the maturity of web application security testing across our industry. The ASVS defines three levels of cybersecurity assurance, with more controls (and hence more testing effort) needed to achieve each level.
OWASP has stated that ASVS Level 2 is the baseline for any application that processes PII, credit card data or other sensitive data. But not every organization will have the budget to write or test code to that level, especially if it involves code review or other manual assessment.
What is the expected balance of automated and manual verification methods within the three ASVS levels?
To get the straightest answers possible on all aspects of the ASVS, The Virtual CISO Podcast featured an interview with Daniel Cuthbert. Daniel is an ASVS project leader and co-author. Hosting the episode as always is Pivot Point’s CISO and Managing Partner, John Verry, a long-time ASVS proponent and user.
John sets up the discussion: “So in application security we have the concept of dynamic application security testing, which is more what most people would consider vulnerability assessment, penetration test… And then you’ve got static, which is code review, and then you’ve got architecture assessment, let’s say, or a technical audit, if you will, which is digging into the deeper stuff.”
“Talk about Level 1, Level 2, Level 3, and which blend each one of those might be, right? So as an example, when you get to Level 2, are we getting to the point where we’re doing code review?,” John asks.
“No, so I’m still a believer that Level 3 are code reviews,” replies Daniel. “Code reviews are very expensive, they’re time–consuming, they’re hard to do because the person doing the code review does need a fair amount of skills.
“For me, a good code review person is the unicorn of the security world because one, they have to understand the languages, two, they’ve got to understand the architecture and how the components work, and three, they’ve got to understand how bugs happen and bugs are exploited, and that’s where the complexity comes in. That’s not a skill you can easily pick up,” Daniel says.
John further notes that a code reviewer must also understand the application’s business use case; otherwise they’ll likely miss some logic errors.
“So I think that’s why we always thought code review was a Level 3 type thing, because it’s not something that’s easily done; it’s expensive,” says Daniel. “No matter what any vendor says, when they say they can do fully automated code reviews, they can’t.”
So does that mean that you can complete ASVS Level 1 and Level 2 verification using only automated methods? Not exactly…
According to the ASVS V4 standard:
In version 4.0, we decided to make L1 completely penetration testable without access to source code, documentation, or developers. … Where possible, access to developers, documentation, code, and access to a test application with non-production data, is required when performing a L2 or L3 Assessment. Penetration testing done at these levels requires this level of access, which we call “hybrid reviews” or “hybrid penetration tests.”
While that might seem like a high bar, Daniel and others at OWASP assert that it is necessary to defend against persistent attackers, who have proven again and again that they can ferret out flaws.
To get more answers about the ASVS Version 4 and how best to use it, click here to listen to Daniel’s podcast episode. If you prefer not to use Apple Podcasts, click here to access any and all the episodes from The Virtual CISO Podcast in your browser.