Last Updated on May 5, 2020
You’ve got a web application that needs tested.
Or architecture that you want to make sure is safe, secure, and will let your customers do business with you with confidence.
So you head out into the big, bad, world and say, “I need an application security assessment.”
And then you sit back and are assaulted by dozens of people claiming that they’ve got the best hackers in the world, and they can break everything, so they can help you secure your environment.
Which makes you ask, “Okay that’s great, but how do I know that you’re going to test ALL of the things I need assessed?”
To which they reply, “Don’t worry, we’ve got the best hackers in the world. They know what they’re doing.”
On this episode of the Virtual CISO podcast, we talk with Daniel Cuthbert. He’s one of the premier authors of the OWASP ASVS, and he came on the podcast to discuss exactly that, the Application Security Verification Standard, or ASVS.
What is ASVS?
Simply put, ASVS gets rid of the ambiguity around application testing, because let’s face it: not many people know how to properly test applications.
Gone are the days of “Have they looked at this?” or “Do they know they’re supposed to look at this critical piece of code?”
ASVS is a standard for testing applications, but more importantly, it allows everybody in the circle to align their requirements and offerings.
At its core, ASVS is categorized into 3 levels.
The first is what Daniel and his team call “low assurance.”
It’s the bare minimum. It’s that fully automated testing. The testing that ought to be built into every code scanning tool on the planet. Any code-scanning tool that you deploy ought to at least have this level 1 built into it.
The second level is for those applications with any sensitive information.
Obviously, sensitive information is an incredibly broad term that can encompass any number of data types. But a few of the things that Daniel and his team define as “sensitive information” for this level include:
- PII (personally identifiable information)
- PCI (payment card information)
- Passwords, etc.
This is where MOST apps are going to fall.
The third level will apply to only about 1% of applications, but it’s for the most critical applications. Those applications that house our medical data, keep our nuclear weapons secure, and help the government entities like the IRS and the unemployment office operate.
As you can imagine, you wouldn’t want to use level 1 standards for a level 3 application.
Don’t Forget Threat Modeling
If you’re building an application, you’re likely, at least hopefully, thinking about threat modeling at some point.
You’d be expected to be doing threat modeling. To be doing a definition and analysis of all of the architecture and connected remote services so that you understand where your pieces are.
How is the application being used? How is it being mapped in? What’s the SLDC? This clearly isn’t falling into a level 1 ASVS.
This is the point where Daniel and his team would say, “Look, for this level, we expect you to have some kind of SLDC that addresses security. We expect you to be doing threat modeling.
Because what are the attackers doing?
They’re going off the stuff that’s often forgotten, like databases that got spun up during the dev process that never got shut down. They’re still on and running in the background, but they’re not being patched anymore.
This is where the ASVS is going to start saving your life.
What About OWASP Top 10?
“Okay, I hear you. But our pen test team tests against the OWASP top 10. Does this mean we shouldn’t bother with that anymore?
According to Daniel, the OWASP top 10 had a purpose. It was treated as the end-all-be-all when it came to application security.
The whole point of the OWASP top 10 is that it’s generic. It’s vague. It’s meant to cast a wide net.
Specifically, the top vulnerability in OWASP10, A-1 injection. Injection is still a massive problem. But how do you test it? How do you know how to best defend and protect against it?
The ASVS would say, “Here’s what an ASVS level two says injections should not do, or an application should not do to be vulnerable to it.” Then you link from there to the OWASP top 10.
Start with ASVS.
Then move to the OWASP Top 10.
Don’t throw the OWASP Top 10 out, but make sure that it’s not all you’re using to test your applications.
This post is based on an episode of The Virtual CISO Podcast, featuring Daniel Cuthbert. To hear this episode in its entirety, and many more like it, you can subscribe to The Virtual CISO Podcast here.
If you don’t use Apple Podcasts, you can find all our episodes here.