Implementing Dynamic Application Security Testing (DAST) Tools into the SDLC

One of the questions that always came up at the end of my API talk was around Dynamic Application Security Testing (DAST) for APIs. I mention DAST in the talk but never really went more in-depth due to time constraints. The questions usually revolved around vendors. In this post I want to talk about how DAST works, I’ll mention vendors from my experience, and finally I’ll go over implementing DAST in the Software Development Lifecycle (SDLC).

HOW IT WORKS

DAST tests an application when it’s stood up and running, usually in a test environment. The test itself looks for the low hanging fruit because it’s running automated tests with no context or awareness of the business function of the application. It will run the same test against a finance system as well as an operational system. This tool is not a replacement for manual testing.

The tool will simulate what an attacker might do to an application. It will check for injection vulnerabilities and weaknesses within connections and protocols to the application. Again low hanging fruit so it will struggle with more involved techniques and misses simple things like URL enumeration and other abuse cases. Overall this tool is a great starting point for applications as it’ll capture a lot of the low hanging fruit but it won’t go much more in-depth than that.

Vendors

OWASP has a list of Vulnerability Scanning Tools AKA DAST available. The main ones I usually recommend are Tenable, Rapid7, and Invicti because I have familiarity with them. I always recommend evaluating multiple vendors before deciding on one. If you’re needing a DAST because of compliance reasons, I’d suggest Tenable or Rapid7 depending on which vulnerability management suite you already own.

If you’re wanting something for more than just compliance look at Invicti because that’s their only focus. This allows them to focus solely on the DAST technology. A Tenable or Rapid7 is looking at providing other security solutions not just DAST. From a low-cost perspective OWASP ZAP or BurpSuite are two free options that can be run manually or setup to automatically run in a CI/CD pipeline. The cost here is a resources time for learning and setting up the open-source tool.

IMPLEMENTATION

DAST is the easiest application security tool to setup in an SDLC. You need a URL, some login credentials, and a timeframe to scan. I recommend scanning as close to production as possible. Scanning in production is never a good thing because it’s throwing a lot of malicious types of attacks at an application. This can cause issues such as taking down the application or putting a junk data into your production environment databases. Scans can be setup to not be as aggressive but then it ends up missing vulnerabilities.

Scanning in a User Acceptance Testing (UAT) allows scans to run at the most aggressive level and not impact production. That is as long as the database isn’t shared with production. The only catch here is finding a time to run the scan so it doesn’t impact user testing. Scans can be setup to run in the afterhours.

The frequency of scanning should be based on how often code is released to UAT. If development is on two-week sprint then it’s reasonable to setup scans to run every two weeks. Some industries only require scanning applications once a month and that’s fine as well because as the vulnerabilities are addressed the need for DAST becomes less important.

Boom! Done!

Not so fast my friend!

Now that we’re scanning we need someone to look at and tune the results. This person should ideally be someone with application security experience because they’ll need to understand how the application woks or willing to dive in and learn. DAST has false positives. Not as many as a Static Application Security Testing (SAST) tool but it will have some. If results are taken from a DAST tool and sent to developers without any sort of vetting it will either tick off the development team or not get addressed. Often times both scenarios are the response.

If an application security person or someone willing to learn isn’t available then setting up a meeting with the development team to share findings and ask questions will go over a lot better. Developers are good people and love talking about their code (baby) and they’ll want to make sure it’s protected from the bad guys on the outside. This meeting will need to be a regular one for any new applications loaded into the DAST. As the vulnerabilities get tuned or addressed the meeting can be less frequent. As trust is built the meeting can become an email unless there’s some misunderstanding or a more complicated vulnerability needs to be addressed.

Summary

DAST is easy to setup but it’s the last tool to be kicked off. As more security tooling get’s implemented and the program matures the importance of DAST becomes less. It’s still a great starting point for any application security program. Always evaluate multiple DAST vendors. If it makes sense to go with a DAST that is already part of a suite of other tools then go with that.

The strategy for implementing DAST is the same for web applications as it is for APIs. You won’t see as many results for APIs because their use is more restrictive than a website. The main concern with APIs is authentication and authorization issues. DAST will be able to call out weak protocols but it will not be able to identify if a person has the access they need. Remember to work with the development team on getting DAST setup because their help will be needed for addressing vulnerabilities.

If you’re looking for an API vendor focused on testing, I’d recommend 42Crunch.

Drop a comment below if there are any questions or other topics you’d like me to cover. If you’re interested in services I have sponsorship, consulting, and speaking engagements available. Reach out via the contact form.

This blog post first appear on Exploring Information Security.