In previous articles, we’ve reviewed what the OWASP Top 10, testing guide, and ASVS are as well as how they may guide your security program.
We’ll now look ahead into ways you can apply the OWASP standard to your internal security testing efforts to help get you better coverage.
What can you do to begin testing your applications?
We’re not trying to be snarky in saying this, but the answer is really to just start.
You can use open source tools: OWASP provides a very comprehensive scanning tool we call the ZAP, Z-Attack Proxy. This is comparable to more premium tools like Burp suite or Web Inspect Pack which you can use to scan your application and to get a good place to start. You can also use these open source tools in conjunction with the OWASP testing guide so that you can understand how those scanners are identifying issues and can start to understand the process of manual testing. But really the point is just to begin.
By starting with an open source tool you're going to show some sort of value; you're going to be able to see some insight into the security posture of the target application which gives you the catalyst to drive the initiative. Push that data upward and say that your team needs to take a closer look.
We recommend getting a Burp suite license which is about $400 a year. We don’t recommend rushing out to buy the most expensive tools on the market, but we do recommend at least taking a baby step and to level-up your perspectives.
As part of our pen testing services, we run as many tools as we can against an application, but it’s also imperative to understand what the tool is designed to do and to recognize its strengths and limitations. All tools are fallible. Regardless of the number of automated tools we use during an assessment, we’re always going back to verify the results as well as look for the points the tools may have missed.
Once you begin scanning though on your end, start making that data actionable. Understand the data and act upon it by using a scanner and the OWASP testing guide.
Should you adhere to OWASP Top 10 or ASVS when looking to test your internal environment?
It’s necessary to layer the two together, because the testing guide provides you with that baseline for understanding how to identify the issue.
Let’s take cross-site scripting as an example. The guide is just going to teach you how to pop an alert box with JavaScript, but that's not really a big deal. In order to really understand the ramifications of cross-site scripting, you have to have a deeper knowledge of the issue. So, it does give you a good starting point by using the testing guide but then you layer OWASP ASVS on top and then that starts to provide you with things like the risk profile of that application and should we be testing at a level one? How important is the data here or should we really be looking at level two?
This is when you really are starting to look at how to manage the security inside, but you want to have to cross the bridge at some point to external testing and having someone else take a look at your application. In order to meet level two criteria, you do have to have a pretty deep knowledge of application security as a whole and to get a good knowledge of how to handle a more advanced exploitation.
Is there a benefit to cycling third-party testing vendors?
We have mixed feelings about that. It's wise to get multiple eyes on an application or any attack surface, frankly. But there’s also significant value in having a partner.
There's a big shift between vendors and partners these days to where some folks just want a cheque, but partners strive to work with your team to build rapport and trust. Partners may still like to get paid because everyone does, but they also want you to feel comfortable with talking with them openly about your security posture so that they can work for a strategy that's best for you.
If you only implement the ASVS on a live application and expect the tester to do the same, you're setting the tester and yourself up for failure there in terms of a creative strategy. Consistency can also be an issue in the tester having a consistent methodology.
So, we recommend finding a trusted partner with a standardized methodology, who can review your previous testing reports to have that long-term perspective, but also finding maybe a secondary tester from one year to the next as well to make sure your partner is accurate.
Getting Started
Although application testing can become pricey, we don’t recommend just taking a vulnerability scanner to your applications.
Vulnerability scanning is a necessary evil. It's a very preliminary starting point and that's it, really. To run a vulnerability scan against your application is a good thing as you’re attempting to identify vulnerabilities in your environment, but our scanning tools are not completely reliable. Anybody that's used any of the modern vulnerability scanning tools from the OWASP project, Z-Attack proxy, Burp suite, HP's Web Inspect can say that each tool has its own downfalls.
Teams can use multiple scanners when conducting the initial testing phase. If we see findings across multiple toolsets, then we get a bit more confidence and that helps to drive the manual testing process. You certainly can use a vulnerability scanner on your web application and be happy with it, but it’s really not the best way to go for your organization’s security.
OWASP can better guide your app security program and SDLC if applied wholeheartedly.
Get your web application assessment sample report to see how you can turn OWASP guidelines into actionable next steps. More into mobile? We've got that a mobile application assessment sample report, too.
For further reading, check out this list of 12 mobile app pen testing tools, 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 review the previous article in the series to learn how to apply OWASP to your application's software development lifecycle (SDLC).
