Do you ever wonder how effective application security (AppSec) testing really is? Or which approach is best? Understanding the differences between static, dynamic, and interactive testing can be challenging. A simple way to explain the differences in the types of AppSec testing mechanisms is to use the analogy of security (bouncers) at a bar.
Assessing the Different “Security Bouncers” at the Bar
Historically, bouncers have been used to determine who can enter a venue, but security in a bar today also includes managing the behavior of patrons who have already entered the venue, including removing them from the premises if they become too intoxicated or unruly. In order for a bouncer to remove a patron from a venue, they must be able to recognize the potential for trouble.
In addition to keeping dangerous patrons out of the bar—and in order to protect other patrons, employees, and property—a bouncer must be able to recognize vulnerable patrons—namely, those who have had their inhibitions lowered from too much alcohol and who may be exploited by bad-actor patrons who initially made it past security. Similarly, application security testing is used to recognize application vulnerabilities that could leave an application open to exploitation.
The idea for using this analogy occurred as I was sitting in an airport bar with fellow 2019 OWASP Global AppSec Conference attendees and was asked to describe AppSec testing in an easy-to-relate way using a familiar setting. To demonstrate, I used the analogy of some bar patrons with black baseball caps—bad actors who were likely to cause damage to other patrons, employees, or property. To counter these bad actors, I used the analogy of bouncers—individuals employed to detect bad actor patrons, and to either prevent them from entering the bar or to find them after entry for removal.
Some bars may have more than one bouncer, and they almost certainly have a variety of tools and training to assist them in doing their jobs—static application security testing (SAST), dynamic application security testing (DAST), and interactive application security testing (IAST).
Getting to Know SAST
SAST bouncers monitor patrons on a security camera as they walk into the bar. Patrons who are visibly wearing black caps are confronted and prevented from entering the bar. However, sometimes blurry video causes confusion, especially when groups of people arrive at the same time or when it is difficult to tell the exact color of a cap. As a result, a SAST bouncer may indiscriminately end up chasing any and all patrons wearing caps out the door, even if they are not causing any kind of trouble.
Because SAST is not in the room, it does not have the context of running code or the data flow passing through code to make the determinations necessary to pinpoint good versus bad code. SAST has been described as “grepping through source” where the code is searched globally for a regular expression and matching lines are printed. Although that description does provide some concept of what is going on, it is a serious oversimplification.
SAST does create a model of what it believes an application looks like together with how the processes flow into each other. However, that model is very basic and cannot provide the context required for adequate testing. For this reason, SAST sees potentially vulnerable code in areas of the application that cannot ever be reached (because the code has been refactored around or is simply never called) and creates false positives.
In addition, SAST will often not see inputs validated in earlier functions and incorrectly flag code as vulnerable further down the line. Due to SAST having no understanding of how the running application is configured, it also may not see problems that would surface in runtime. Managing these false positives creates additional work for developers and security teams and takes valuable time that could be spent tracking and stopping true vulnerabilities.
In sum, bouncers prevent bad black cap patrons from entering the bar, but they can also scare off good patrons wearing caps of other colors, which affects the profitability of the business. Similarly, with SAST, managing false positives affects profitability through a loss of time that developers could be spending writing new code.
Getting to Know DAST
When DAST is the bouncer, it is able to identify black caps by periodically accosting every patron and searching them all over to see if they have a black cap with them. When a black cap is found, they correctly report it, but they often miss caps hidden in pockets, purses, jackets, and so forth. If a patron objects to being searched, the DAST bouncer may conclude that they have a black cap, whether that is true or not. It is also possible that DAST may confuse another color cap with a black one.
Just like SAST, DAST is not in the bar, but rather relies on security cameras or secondhand information to determine whether those with caps are good or bad actors. This type of bouncer may see a dark cap and assume that it is black, only to discover upon closer scrutiny that it is actually dark gray and not a real threat. Investigating these false threats can take up valuable time, leading some bouncers to ignore additional threats because they assume them to be false. As a result, they accidentally let in a bad actor to wreak havoc in the bar. Similarly, a security analyst who spends nearly two days investigating 200 vulnerabilities but does not succeed after 70 of those threats prove to be false positives may also assume other vulnerabilities are false positives and ignore them. But these turn out to be legitimate vulnerabilities that present real risk that needs to be addressed.
Getting to Know IAST
Instead of being an individual bouncer, IAST acts as a team of bouncers. This team has every door, hallway, cash register, closet, and bathroom covered. They passively track the movement of all patrons throughout the bar. At various checkpoints, IAST bouncers verify that patrons have passed through the correct security checks and prevent patrons from moving through subsequent checkpoints unless they can prove they are not bad actors. IAST bouncers not only check for black caps but they also look closely underneath them at the faces and make sure their IDs match.
IAST is the only AppSec solution approach that performs a close look into the code, enabling an understanding of data flow and context. In addition, unlike SAST and DAST tools, IAST tools are able to identify vulnerabilities outside of the code itself. A good example is the ability of IAST tools to follow the data flows of application programming interfaces (APIs) and pinpoint vulnerabilities in the API code, enabling developers to trace the cause of vulnerabilities to the source.
Unlike SAST or DAST, IAST requires no tests to be written for security. It simply traces actions through the system and does not need those actions to be special. Therefore, any tests that development teams have written to ensure functionality works can automatically become security tests. Although this means only code with functional tests will be viewed by the instrumentation and subsequently checked for issues; manual tests can be done to check those missed routes.
While not a one-size-fits-all model, IAST is the easiest way to discover vulnerabilities and automatically get security coverage of every route exercised (automatically and manually) during development and testing. This can cover as much as 60% to 70% for the typical development project, and it can increase to 100% by simply addressing the routes that IAST reports did not detect automatically.
Getting Started with AppSec
When it comes to an effective AppSec program, my recommendation is to start with IAST for everything that is supported, and then follow up with either SAST or DAST for the rest, depending on what resources are in place.
AppSec involves multiple solution areas, and I am hopeful this post helps the audience gain a broader view of the options—both their strengths and weaknesses. Organizations seeking assistance in assessing their AppSec risks or mapping out an AppSec strategy should feel free to reach out to us at Secure Delivery.
Note from Contrast Security: From a security standpoint, readers may want to check out the new Management Guide from Contrast—“AppSec for the Newly Hired CISO/CSO: Recommendations on How to Assess Application Security in the First 100 Days.”
Of course, you can simply get your hands dirty with Contrast Community Edition, which is completely free to developers.
