Neil MacDonald

A member of the Gartner Blog Network

Neil MacDonald
VP & Gartner Fellow
15 years at Gartner
25 years IT industry

Neil MacDonald is a vice president, distinguished analyst and Gartner Fellow in Gartner Research. Mr. MacDonald is a member of Gartner's information security and privacy research team, focusing on operating system and application-level security strategies. Specific research areas include Windows security…Read Full Bio

Coverage Areas:

The Market for Dynamic Application Security Testing is Anything but Static

by Neil MacDonald  |  January 4, 2012  |  1 Comment

We’ve just published a new Magic Quadrant for Dynamic Application Security Testing (DAST) for Gartner clients. In Gartner research, we use the term DAST to refer to testing solutions and techniques that are designed to test an application from the “outside in” to detect conditions indicative of a security vulnerability in an application in its running state.

DAST solutions have been around for years, so you’d might think the market is fairly static. Not at all. DAST solutions must and have evolved well beyond the security testing of back-end web applications. In order to dynamically test the next-generation of applications, new DAST capabilities are required and not all vendors support them equally.

Here are several areas where DAST solutions are evolving:

(1) Dynamic application security testing as a service. The market for dynamic testing as a service is growing and some of the DAST solutions we evaluated – Qualys, Veracode and WhiteHat – only offer their solution as a service. However, many organizations tell us they prefer to use a product and a service from the DAST vendor — for example, testing their more-sensitive applications on-premises using a DAST product, and testing their less-sensitive applications via DAST as a service, or testing deployed applications as a service, with testing of applications in the QA phase of the development process using on-premises DAST products.

(2) The ability to crawl and test Rich Internet Applications (RIA). A hallmark of Web 2.0 applications is the use of RIA, mostly in the form of JavaScript (The “J” in Ajax) and Ajax frameworks. In addition, many applications include large amounts of client-side logic in the form of Adobe Flash, Flex, and Microsoft’s Silverlight. The use of client-side RIA logic complicates how applications are crawled and how traditional DAST testing is performed, since the JavaScript and other types of code are rendered at the client, not at the server.

(3) HTML5  More recently, interest has shifted to the use of HTML5 for RIA. HTML5 isn’t a single standard and the multiple standards that collectively represent HTML5 are at different levels of maturity and adoption. Testing HTML5 and keeping up with the fluid standards is an emerging requirement for all DAST solutions.

(4) The ability to crawl and test applications that use other types of interfaces carried over web protocols. For example, many DAST solutions test Web services using protocols and formats, such as Simple Object Access Protocol (SOAP), representational state transfer (REST), Extensible Markup Language (XML) and JavaScript Object Notation (JSON).

(5) Static application testing capabilities (SAST). For comprehensive application security testing, applications should be able to be tested from the “inside out” using static analysis and from the “outside in” using dynamic analysis. Several vendors now offer organizations both DAST and SAST solutions.

(6) Interactive Security Testing. Building on #5, some of the testing providers enable interaction between their static and dynamic security testing techniques. One of the most common ways is to instrument the application while it is being tested dynamically. This provides more detailed information (such as identifying the line of code where a vulnerability occurs and assessing the code coverage of testing). While this may not be suitable for production applications, this approach is quite useful in QA testing in order to provide more meaningful results to developers.

(7) Comprehensive fuzz testing. Some DAST solutions are designed specifically to expand well beyond Web protocols to include non-Web protocols (for example, remote procedure calls, Server Message Block, Session Initiation Protocol [SIP] and so on) as well as data input malformation. This is especially critical for the dynamic security testing of applications used within embedded devices, such as storage appliances, telecommunications and networking equipment, directories, automated teller machines, medical devices and so on.

(8) Testing mobile and Cloud-based applications. Ideally mobile applications would be tested with SAST and DAST; however, pure DAST testing can add value. Beyond the use of RIA and HTML5 discussed previously, most Android and iOS applications (even when written as native applications) are Web-like in nature and communicate over Web or RESTful HTTP-based protocols. At a minimum, the exposed interfaces of the applications should be testable using DAST. Many of the mobile applications communicate with cloud-based applications on the back end, which must also be tested. In addition, many applications have specific code paths for supporting mobile devices. In order to test these properly, DAST solutions must emulate a number of mobile browsers.

These are just a few examples of how the market for DAST solutions is anything but static. The market is evolving rapidly and requires that successful solutions here continue to adapt as well. If you haven’t evaluated DAST solutions in a while, it’s time to take another look.

1 Comment »

Category: Application Security Applications Cloud Cloud Security     Tags: , ,

1 response so far ↓

  • 1 Arian Evans   January 11, 2012 at 5:26 pm

    That’s a great list.

    Another common DAST testing input-vector we see & test daily, which you touch on in #7 and #8 – is what we call OoB (out of band) unique entry points to applications. Think of dynamically generated password reset pages where the link is sent only out via email or SMS. The two most common forms of these are:

    + links with parameters provided by an offdomain/3rd party resource (website, tweet, etc.) that leads into a unique part of the target testing application that can only be accessed by this URL. And that URL and/or parameters are not visible to a scanner via crawling the application, as it’s not linked anywhere on any other pages in the application

    + unique links with parameters generated by an application and send out to users via SMTP, SMS, FTP, Twitter, etc. to access unique or dynamically generated content, again not linked anywhere off the main application. Dynamically generated account setup/management/password reset-pages are some of the most common examples – and that provide access to very sensitive data.

    This is where I believe SaaS can be extra-powerful compared to traditional COTS scanners. For example – with Sentinel we setup unique listeners for the OoB protocols & communications to capture these additional entry-points and feed them into Sentinel for further DAST testing. You could almost call this a form of SAST, as it performs static analysis/parsing on the message to find HTTP entrypoints to feed the DAST. Or possibly this falls under IAST?

    Ideally some of this would be caught by IAST, via SAST finds the code generating links, and alerts DAST for testing. However we often see an application call a 3rd party application/service in realtime to generate the actual emails/SMS and such, so I’m not sure how often pure SAST on source code will find these unique, dynamically generated attack surfaces.

    It’s getting very common to have key functions like this on modern web applications though. I suspect mobile adoption will only make this more so the case. So some form of IAST will be needed to provide coverage on these often-critical functions. Correct me if I’m using the term IAST incorrectly.