An Introduction to the AppSec Market

In today’s world of complex, modern web applications, accurate and automated Dynamic Application Security Testing (DAST) tools are rare, but do exist. What characteristics should you look for in a DAST tool to give you greater accuracy and ease of use?

Given the various dimensions upon which you can compare vendors, finding the right DAST tool for you isn’t always a walk in the park. The following are common challenges during the buying process:

  • Often, when organizations are looking to purchase a DAST tool, they are doing so under a very compressed time frame.
  • You need to test a real application with known vulnerabilities; otherwise, it can be difficult to compare one solution’s effectiveness against that of another’s. By knowing the vulnerabilities present in advance, you can determine which DAST tool is more apt to identifying any and all vulnerabilities. When possible, work with your development team to seed a test application with a variety of SQL injections, XSS, and other vulnerabilities.
  • Results from DAST tools will naturally differ quite a bit, due to the differences in configuration, scanning techniques, and reported findings.
  • You will be, in certain instances, forced to rely on the word of the DAST vendor. Why? The technology that underlies DAST tools can be a black box.
  • It takes a lot of time (time that not many teams have to spare) to check and re-check reports for accuracy.

In this guide, we comprehensively outline the major features and capabilities you should be looking for when selecting a DAST tool. To help you cover all your bases, we’ve also included some questions and techniques you can leverage to get the most out of your evaluation period. Our goal? To equip you to select the best application security for your organization — one that is automated, accurate, and easy to use. For more advanced application security programs, we’ve included a few other considerations that will not only improve the effectiveness of your DAST solution, but also its ability to fold seamlessly into the workflows of your development counterparts.

Dynamic Application Security Testing Requirements

1. COVERAGE OF MODERN WEB TECHNOLOGIES
Coverage is the first step of accuracy. A DAST tool can’t test what it can’t find or doesn’t understand. Most DAST tools were built to scan HTML, and they do so quite effectively. But times have changed, and in reality very few applications are built solely in HTML. Today’s applications have gone beyond static pages to involve advanced web clients and web services that make use of new technologies. These applications are powered by JavaScript and AJAX on the client-side, and often have interfaces built in JSON, REST, and SOAP with CSRF protection thrown in for good measure. Thus, you need a tool that is built to scan apps utilizing modern web technologies, on top of just basic HTML.

2. FUTURE-PROOF STRATEGY
Modern DAST tools need to understand and adapt to new application technologies as they become popular. Inevitably, we will continue to see an increase in application complexity with the emergence of new technologies. While most DAST tools continuously work toward understanding and attacking classic web apps of the past, modern DAST tools need to be architected so that new technologies can be bolted on like drill bits on a drill.

3. QUICK START CAPABILITIES
The best pen testers love to do things by hand, leading to a comprehensive yet slow, manual process. The reality is that you need those smart pen testers to cover the work that can’t be done by automation. A good DAST tool’s real value is in its capacity for automation, thus reducing the need for manual testing. The best tool is the one that will work well in a “point and shoot” mode. In many cases, that is all that’s possible for understaffed security teams.

4. ARCHITECTURE AND SCALABILITY THAT MEETS YOUR NEEDS
DAST tools can be deployed in a number of ways: onpremise, in the cloud, or as managed services. In addition to where security data is hosted, scalability is also an important component; some organizations may manage just a few dozen web applications, while some organizations can have thousands to tens of thousands of web applications that all need to be secured. Finally, not all organizations are able to execute application security programs in-house due to the lack of staffing, necessitating external consultants to run and manage scans as well as validate vulnerability findings.

5. AUTHENTICATION AND SESSION MANAGEMENT (DEVELOPER’S FUNZONE, SECURITY’S NIGHTMARE)
Developers seem to revel in creating innovative, complex, and difficult-to-automate schemes for authentication and session management. Your DAST tool needs to have advanced capabilities to authenticate automatically and have backup plans (macros and advanced settings) to tweak, in case there is a clever edge case.

6. CUSTOMER SUPPORT AND CUSTOMIZATION
The reality of application scanning today is that your applications are highly customized, making it extremely difficult for DAST tools to address 100% of cases. Each custom application uses unique technical approaches that can trip tools up and cause them to crash. You need to seek out a solution that is flexible and responsive in the face of unique, complex applications.

7. SOPHISTICATED ATTACK TECHNIQUES
All DAST tools must find a balance between comprehensiveness and performance. In order to improve performance, some DAST tools randomly limit the set of attacks to send based on proprietary choices. Others intelligently profile applications to determine which attacks are useful, and dynamically adjust attacks for each input. This latter approach increases not only the efficiency of the scan, but also its ability to find valid vulnerabilities.

8. REDUNDANT FALSE POSITIVE CHECKING 
False positives are simultaneously the bane of automated scanning and a time suck for security teams. Web applications often behave in mysterious ways, and per the nature of the beast, smart DAST tools must check and recheck findings to avoid false positives.

9. RELEVANT DATA INPUT
During automated scans, there are usually two phases: crawl and attack. During the crawl phase, it is imperative that a tool provide valid data for each input field as expected by the application. For example, if a form is asking for a shipping address, some tools enter random values into each input instead of the expected values. Certain fields such as the ZIP code would be invalid, and the application would subsequently reject the request. In this case, the scan is actually halted, resulting in a less comprehensive scan and the potential for missed vulnerabilities.

10. INCLUSION OF EVERY
The point of automation is to handle the repetitive tasks against every input, but this can also lead to slower scan times. To save time, some web application security solutions only check the first several parameters on each page. However, each parameter could use different filters. Why is this important? Tools could be arbitrarily missing vulnerabilities for the sole sake of saving time. Our take? Time savings may not be worth the increased risk.

11. SCAN SCHEDULING AND BLACKOUT PERIODS
Continuously assessing your web applications for vulnerabilities is more critical than ever in today’s world of rapid development release cycles. In response, automated scan scheduling can be leveraged to help your program stay on top of the vulnerabilities that appear in constantly-evolving applications. Blackout periods can also be useful to ensure scans don’t run during times of high activity on an application, and in turn prevent potential negative user impacts.

12. INTERACTIVE AND USABLE REPORTING 
As you know all too well, “reporting” in most tools takes the form of very, very long PDF files that are difficult to work with. Your team doesn’t want to send them, and those in charge of remediation most definitely don’t want to open (let alone read) them. A good DAST solution provides you with results that can be used by auditors and developers alike. Reports should be easy to navigate through, and allow you to reproduce the attacks with a few clicks. It should also be easy to understand the context around issues, with the ability to read summaries, drill into details, and view the information in different ways. The unfortunate reality is that developers with limited security training often have a difficult time replicating vulnerabilities, thus slowing down or stopping remediation.

13. ATTACK REPLAY
When developers are handed a list of security bugs in their applications, they’re often skeptical that the bugs truly exist and aren’t just false positives. Some DAST tools offer “Attack Replay” or “Validate” features that enable developers to replay attacks directly
within exported vulnerability findings reports. This is game-changing, as developers can now validate that security bugs truly exist, and also test potential source code patches for the vulnerabilities without running another DAST scan.

14. COMPLIANCE REPORTING
Many organizations will launch application security initiatives in response to regulatory compliance requirements like PCI, HIPAA, and SOX. Often, there are security compliance requirements to adhere to as well, such as the OWASP Top 10. In order to make your life easier, your application security solution should facilitate your journey towards compliance.

15. CUSTOM MOBILE APPLICATIONS
Custom mobile applications are the new frontier for security teams. They provide native mobile interfaces, but then communicate with web services or APIs (JSON, REST/XML, AMF, etc.) that have the same range of potential vulnerabilities (SQLi, authentication, and session management weaknesses) that web applications have.

To Read Full Info Download the Whitepaper:
Application Security Buyer’s Guide

SEND ME WHITEPAPER