In a previous article, we explored OWASP Top 10, testing guide, and ASVS, but how does OWASP apply to your security program today?
We’ll look at the quality of testing with the OWASP standard, how ASVS can be implemented in your software development lifecycle (SDLC), as well as how to begin testing your own applications.
How do we balance costs with risk versus the quality of testing?
As an example, let’s talk about building a patch management process for an application. The first thing you're going to do is scan your application. Yes, absolutely scan. Then, you have to do something with that data. Burp suite is a great tool because it finds everything under the sun, for the most part. The problem is that it really has a bad habit of finding things that aren't there. You tend to get a lot of false positives.
A lot of almost all of the low hanging fruit in an application would be identified by this scanner. But the fact that there is so much potential for false positives with using this tool means that there has to be some human element involved. When that human takes the data from the scanner, the next question is what do I do with it? You have to have some mechanism by which to go through that data and evaluate those findings to determine: is it true? Is it false? Is that risk really as substantial as this tool says it is?
The OWASP testing guide is really the beginning to that process. By using the OWASP testing guide, when you take a Burp report see that your application is susceptible to SQL injection, you can investigate the finding. If you don't know how to do SQL injection proficiently then you would rely on the OWASP testing guide to help you through how to evaluate that. On the flip-side, after that's completed, you’d take that testing guide with that Burp suite finding back to your development team and ask them how to fix the problem.
The testing guide is really just the basic guideline. The human element is where the testing is understood and validated. Analysts must investigate and interpret the reports.
Leveraging ASVS in Your SDLC
How should you leverage OWASP ASVS in order to conduct internal application security testing, at the end of the software development lifecycle (SDLC) or throughout?
ASVS is really meant for application-owning organizations and testing organizations, like RedLegg. All of these organizations, application owners, and architects should be using ASVS throughout the design phase and then the developers should be using the ASVS to drive how they’re actually writing that code. Throughout the SDLC we should be doing code reviews and our code reviewers should also be using ASVS so that everyone is staying along that same standards.
When it comes to penetration testing, it’s the same thing. The ASVS does really try to take into account the risk profile of the application. There are three main levels of criticality:
Level One
The level one is basically every application that touches the internet. This is “basic bones” assessment under level one. Level one testing under the ASVS serves as a great starting point for the following levels but it’s pretty rudimentary and requires no access to code and no conversations with developers. In preparing for an application assessment, our team would have interviews with developers beforehand, but that’s the extent of that process.
Level one testing is only going to identify easy to find and easily exploitable vulnerabilities. This may mean a novice application tester with a vulnerability scanner who takes the results of that scan and confirms that what they see is a vulnerability with some confidence.
Level Two
Level two is considered to be most applications, specifically an application that handles sensitive information like business to business, healthcare, any business-critical type application. These should be held to a level two standard under the ASVS.
We’re getting to the point now fortunately in the security space, where we’re seeing more requests for level two testing. People are wanting to give testers access to the code so they can do code reviews. They're wanting to give access to the developers during testing so testers can ask questions. This is important because in order to meet the level two standard under the ASVS, security controls have to be in place and effective to keep the application safe.
Level two is where we're really starting to see the average testing being conducted.
Level Three
This is the high value, high assurance, high safety application: think military, or health and safety, critical infrastructures. When we're talking level three, failure equals direct impact to operations and this requires more in-depth analysis for the architecture, in-depth code analysis, and testing.
This is where there should be a full partnership between the application owners, developers, and the testing teams. Throughout every phase of development and every phase of testing, we can ask questions and coordinate the effort.
The Problem with Levels
The biggest issue with this level structure is that by cordoning off these levels we're almost exponentially seeing a cost increase. And that's because there is so much extra effort involved in jumping from level one to level two and then again from level two to level three. We’re taking time to talk through code concepts, we're taking time to talk through likelihood of successful attack, and things of that nature.
So, we may give some pushback when we start talking about trying to hold an application accountable at level two because it takes substantially more time than it does at level one testing. And these are the things that, as we become increasingly reliant on our digital data, we really have to start changing the way we think about that structure.
It’s not uncommon for management to push back on application testing when they see the cost involved, but unfortunately, you may have to pay a bit of money for good quality testing.
How OWASP Translates To Dollars
The OWASP testing guide encourages organizations to measure security throughout the entire app development process.
Unfortunately, if we can't make the correlation between costs and the business objectives along with technology risks, then money won’t do what it needs to do for us. OWASP helps us relate the costs of insecure software to the business impact which in turn helps us receive more security funding.
Get your web application assessment sample report to see how you can turn OWASP guidelines into actionable next steps. Looking into mobile applications? We've got a sample report for that, too. Get your mobile application assessment report here.
For further reading, check out this beginner's guide to vulnerability scanning, the 7 application assessment components you don't want to miss in your next review, or pretty much everything you need to know about penetration testing.
Or read the next article in the OWASP series to learn how you can apply OWASP with your internal testing team.
