You take your web application’s security seriously. Perhaps you’re rightly worried about the potential destructive power of a data breach, or you need to reassure your customers that you’re implementing best-in-class security procedures. Regardless, you aren’t interested in playing games or security theater. You need effective solutions.
But where to begin? It’s a confusing market, full of competing technologies, bold claims, and acronyms. Oh, the acronyms.
You’re no doubt wondering (having made it this far!) how Sqreen (a Runtime Application Self-Protection, or RASP, solution) is different, what its advantages are. In this article, we’re going to go deep, and compare Sqreen to a group of technologies collectively called Application Security Testing, or AST. You’ll learn how each part in this group of technologies works, what makes RASP different, and understand in detail why Sqreen is an important part of your security program.
Application Security Testing
There are, broadly speaking, two kinds of AST: Static (SAST) and Dynamic (DAST). Usually, these two appear together, as they complement each other: Where SAST works from the source code-out, DAST works from the outside-in.
Static Application Security Testing
The goal of SAST is to identify vulnerabilities in your source code before you deploy to production. SAST tools examine your application’s source code directly, typically as part of your Continuous Integration (CI) pipeline, using static code analysis techniques to look for problems without having to execute your code.
Because of the way it works, SAST offers two distinct advantages: First, it helps you find problems early, before deployment. And second, because it’s looking at your code directly, it provides detailed information that your engineering team can easily use to fix the issues.
But for the same reasons, SAST has some serious drawbacks. First, because it doesn’t actually execute your code, SAST is prone to inaccurately modeling code behavior. The result is a frustrating combination of false positives and false negatives.
False positives are the most readily observable: SAST tools are notorious for flagging perfectly safe code as vulnerable. Because there is, in general, no way to prove that a given flag is a false positive, your engineers are forced to spend time tracking each flag down to verify whether it really is a problem. The result is unnecessary distraction that can lead to lost time and productivity, or perhaps worse, turning off otherwise useful SAST features that are too noisy.
False negatives are less obvious: These are problems in your code that the SAST tool is not able to detect. While SAST tools are generally excellent at spotting language-level and framework-level vulnerabilities, like unsafe SQL calls, their code models are not (and cannot be) sophisticated enough to detect runtime vulnerabilities, like authentication bugs (leading to account breaking and takeovers), server misconfiguration (possibly exposing infrastructure credentials or backdoors), or subtle flaws in business logic (opening the door to fraud).
Dynamic Application Security Testing
DAST was conceived as a way to partially ameliorate some of the shortcomings of SAST. Instead of examining your code, DAST runs outside of your application, treating it like a black box. DAST automates stressing it in much the same way that an attacker would. Like its static cousin, DAST can be deployed as part of your CI pipeline, but it requires a running instance of your application to stress, either in a production or (ideally) a staging environment.
Moreover, because DAST is testing against a running application, it is much better situated to spot the kinds of run-time vulnerabilities that SAST misses, like that stemming from misconfiguration or defects in your business logic.
However, unlike static code analysis techniques that can be used off-the-shelf, the rules that power DAST tools must be fully bespoke, customized for your application and tech stack, before they can be fully effective. This requires significant white-hat security expertise. Moreover, the rules must be kept up to date as new attack vectors are discovered by security researchers, and as your application grows and changes over time. The result is that DAST can be prohibitively expensive, and slow to keep up with your face-paced development lifecycle.
Moreover, because DAST treats your application as a black box, it has no insight into the underlying causes of the vulnerabilities it uncovers—your engineering team will still need to spend time hunting down the bugs, and correlating them with DAST reports. There is no guarantee that bugs uncovered by DAST have been fully accounted for in engineering.
Vulnerabilities vs Attacks
The common theme to both sides of the AST stack is an emphasis on detection of vulnerabilities in your code. The idea is to discover potential mechanisms that attackers could exploit.
This kind of thinking is, however, reactive: We can only build rules to test for what we’ve already seen. SAST rules highlight language patterns that caused problems in the past; DAST rules can only check against attack patterns we’ve seen work in the past. Neither can anticipate the future, and neither can protect your app when something new comes around. Moreover, these rules are written so as to be as generic as possible, rather than tailored to your app, increasing the risk of false positives.
Runtime Application Self-Protection (RASP), in contrast, focuses not on the mechanism of attack, but the outcomes of an attack. Attackers aim to change the state of your web application to suit their aims: To gain access to information that is not theirs or to alter your database in ways that benefit them. There are many ways to achieve these ends, not all of them known, but the end states of an attack are well-understood. By focusing on attackers’ desired outcomes, Sqreen can ensure that your security evolves as new threats arise, without false positives or false negatives.
How does Sqreen work, then?
Runtime Application Self-Protection
Sqreen is different: Unlike AST, Sqreen is Runtime Application Self-Protection (RASP) that actually lives inside your code. Rather than looking for vulnerabilities, Sqreen focuses on detecting and blocking attacks. It installs as a dependency, and when your application launches, Sqreen hooks into the various modules and frameworks that you use to build your application. In this way, Sqreen traces each HTTP request your application receives, observing closely how the request interacts with your application with minimal performance impact.
And because Sqreen understands when a state change is malicious, it can detect and block all and only actual attacks triggered by actual vulnerabilities.
Because it knows where in your code the attack triggered a vulnerability, it can notify your security team, and provide your engineers with a detailed, actionable report that shows where in the code the vulnerability was found. In the meantime, Sqreen will stop the attack immediately, giving you the breathing room you need to fix your app.
By focusing on the outcomes of attempted attacks, rather than the vectors of attack, Sqreen automatically adapts to new threat environments, and to your rapidly growing and evolving codebase, eliminating false negatives.
Moreover, because Sqreen is watching your application’s behavior, it doesn’t rely on inaccurate code modeling like SAST, eliminating entirely false positives. Your developers will only ever see actionable engineering reports worth their time.
Finally, unlike both SAST and DAST, Sqreen continuously monitors your applications security posture, keeping you, and your Security, Ops, DevOps, and Engineering team fully appraised of who is attacking, who is threatening, and the next steps to effectively handle each case.
Sqreen’s emphasis is, therefore, not on identifying vulnerabilities that might or might not be a problem in the future, but on identifying and stopping actual threats, as they happen.
Summary
- AST focuses on finding vulnerabilities
- AST relies on modeling of code execution and known attack mechanisms, leaving it open to false positive and false negatives
- Sqreen and RASP focuses on detecting and stopping attacks as they happen
- Sqreen is both future-proof and is not prone to false positives or false negatives.
