How to Choose a Web Application Scanner: DAST, SAST, RASP, IAST, HAST…Holy SaaS!
Five penetration testers and five developers walk into a bar. Not just any bar, but a bar that serves up the finest automated web application security scanning cocktails you can find. The bartender asks the first penetration tester, “What’re you drinking?” NoName Hacker responds that he would like the SAST. The other pen-testers scoff at this. One claims that his skills for manual testing outweigh any tools at this bar. Apparently his home-made scanning cocktails made with age-old moonshine are the best. Another screams that SAST is inefficient since it requires customizing the scanner to the application’s stack. Now it’s time for a developer to step up and order. The crowd is screaming behind her, so what should she do? What would you do?
Imagine what the inventory of this bar would look like for a minute. It’s probably similar to a World of Beer with 550+ beers on tap, except instead of Hefeweizen, Kolsch, IPAs, and Stouts, we have DAST, SAST, RASP, IAST, and HAST tools. Oh, and I almost forgot, the huge list of open source tools that exist. Making a decision is a nightmare. Everyone has a different opinion, and what works for NoName Hacker might not work for the Developer Code Queen.
So where should you start?
It’s best to decide whether or not automating Web Vulnerability Scanning is important to your organization. As with many business functions, automation saves time and money. Your solution needs to increase the efficiency of your organization’s Software Development Life Cycle (SDLC). But, since you are reading this, you have probably already decided that you can save money and time, which means more money, by automating your scanning and avoiding continuous manual application penetration tests.
Just to pound this home, imagine that your application contains merely 50 different entry points and you want your security engineer to test for 10 different vulnerabilities that have 10 variants each, each week. That’s a total of 100 tests for each of the 50 entry points. If a single test takes 3 minutes, your security engineer will be testing your application for 52 hours per week every work week of the year.
It’s time to choose an automated solution.
What should you look for and where should you start? There are a few areas to focus on:
- Implementation
- Integration
- Scale
Implementation
You are busy and you need a solution that implements easily. It should be simple to deploy, accurate, secure, and give usable and actionable information. A tool that is complicated and timely to learn will waste more time. If you spend an extensive period training an engineer on a complicated tool that you spent a ton of money on, you will have to repeat that process when, not if, that engineer eventually moves on to another project or to a different company.
Determine what stack you are running. If you decide on a SAST, RASP/IAST, or HAST solution, there will be several steps in the implementation process that require you to customize the scanner to your stack. Are you a modern organization running several apps on different stacks? Perhaps this isn’t the best solution for you.
A quick example: Elixir has boomed in popularity since it first appeared on the scene in 2011. The scalability and speed of Elixir and the Phoenix Framework make it popular for building web applications, APIs, and the like. Or maybe you are using Go. Your static code analyzer would have to continuously update to your stack, and you will have a tough time finding a tool that supports this modern language with the granular accuracy you need. RASP and IAST tools also require you to install a dependency on every single web server that you are running, adding infrastructure pain. Because of this and the stack-specific nature, it adds latency.
Some tools will openly state that they have low CPU impact, say, less than 4%. FOUR PERCENT?! That’s huge latency if you are someone who cares about latency like a bank. That type of latency is simply unacceptable.
Integration
Imagine a world where you have a vulnerability scanner that not only automates the scanning for vulnerabilities, but creates a ticket in your bug tracking tool containing vulnerability information. Once developers verify and fix the vulnerability, they kick off a rescan using the API. The scanner identifies that the vulnerability is indeed fixed, and automatically closes out the ticket. Months later, the team builds an update and runs a scan which finds the same vulnerability has reappeared. The process starts again with automatically creating the ticket, but instead of creating a new ticket, it reopens the past vulnerability tickets containing all of the history.
Does it sound amazing? Great. Because it’s not just a dream, it is reality.
Your scanning solution MUST integrate and enable your CI/CD processes. Look for something that connects to Jira and Jenkins (or any other ticketing and build tools you use) and automates the tasks of creating tickets, provides developers the details needed to verify that the vulnerability is not a false positive, and closes out the tickets once a vulnerability is fixed.
Can the tool scan staging and live servers?
Are all of the features and data available through the API?
Does the scanner output results in XML or JSON?
Scanners that iterate over the application’s source code, such as SAST and elements of RASP/IAST do not interact with the application like a hacker would. SAST does not run against an actively running application and only looks for things that look like a vulnerability, but which might not actually result in a run-time vulnerability. False positive alert!
You know your processes better than anyone, and you know what your applications look like. Find a solution that makes your developers’ lives easier, not one that overloads them with a high number of false positives.
Scale
Your tool should be easy to scale with your organization. Perhaps the first initiative is to scan the top 10 most critical external facing applications. But the long-term vision is to integrate scanning into the development of all 50 of your applications. The implementation and integration considerations above apply to each and every application you manage. The easier the training and deployment for the first application, the more time you will save in integrating the solution into your entire organization.
DAST tools do not require customization for scanning your stack. They interact with your website and find vulnerabilities that actually exist. At Tinfoil, we built our scanner with the goal of creating an automated solution that scans your application like a real hacker. It is simple to get up and running, and you don’t need to spend weeks training on the functionality. You can scan 50 different applications running Elixir, ASP.net, PHP, Angular, React, Ruby, Node.js, Go, and any other language your heart desires. The setup will be the same, and you will save many many headaches.
Now it’s time for you to do some work.
Before getting free trials and evaluating everything on the market, prepare your team so that you increase efficiency. High speed, low drag… am I right?
- Take an inventory of your web applications. Identify the most critical to scan first, and consider the implementation issues we talked about earlier.
- Look into the tools that you use in development. Make sure that the solutions you test integrate easily into the workflow you already have in place.
- Decide what is most important to your organization. Do you want the cheapest solution to check the box? Do you want the most expensive solution that comes with all of the doo-dads and frillies that make your security engineers heart’s race? Do you want to increase efficiency through high quality integration and automation?
Keep in mind that not every tool is built equal. As we have already seen, the process is different for each classification of a tool. But even more important, each tool in that category was built to satisfy a need using a different methodology.
Okay time for my shameless plug: Tinfoil Security’s DAST is, bar-none, the cream of the crop for DAST tools. It is premier in performance, simple to learn and deploy, and integrates seamlessly.
We also offer a patent-pending API scanner. There is no other API scanner on the market that truly interacts with your API like a hacker would, finding vulnerabilities and scanning for best practices. To learn more about this, see how to scan APIs the right way.
Are you interested in seeing a demo of our web application scanner or API scanner? You can set up a demo here. Use that link also if you need tips on good hair products, or to hear the rest of the story with NoName Hacker and Developer Code Queen.
Stay classy.
*** This is a Security Bloggers Network syndicated blog from Tinfoil Security Blog authored by Derek Jackson. Read the original post at: https://www.tinfoilsecurity.com/blog/How_to_Choose_a_Web_Application_Scanner
