According to recent research we conducted with the Ponemon Institute, one in two enterprises today admit that they need better application security — demonstrating both the scope and the reality of the problem.
Dynamic Applications Security Testing (DAST) and Static Application Security Testing (SAST) are two timeworn tools used to successfully identify vulnerabilities in Dev and QA cycles. But with applications being released into production as often as multiple times per day, most enterprises are confronting the enormous challenge of staying ahead of threats. We have seen that in most companies, the backlog of vulnerabilities is significant and the pressure to be agile is intense.
Instead of looking for potential vulnerabilities, a new solution category emerged to protect applications against "actual" attacks: Runtime Application Self-Protection (RASP). Preventing even the most sophisticated of houshold attack vectors like cross-site scripting (XSS), SQL injections (SQLi), and cross-site request forgery (CSRF), RASP tools enable business to allow exceptions on vulnerabilities based on actual, real-time exploits and more applications can be pushed into production.
Here, we take a closer look at each of these three "pillars" of application security and how they complement each other:
Pillar 1: Dynamic Application Security Testing (DAST)
DAST, often referred to as “black box testing”, is designed to detect conditions that would indicate security vulnerabilities, and analyzes code as it is running to identify vulnerabilities that an attacker could find when the application is running in production. The benefit of a DAST solution is that, because it looks at applications from outsider's perspective, it can tell whether a weakness could potentially be exploited, or at the very least, identify the type of weakness so that exploitability can be determined manually.
Pillar 2: Static Application Security Testing (SAST)
SAST, often referred to as “white box testing”, assesses the source code from an insider's view for security vulnerabilities and coding flaws. It’s more commonly used early in the development process because it can be implemented while the code and modules are still being created. One of the main benefits of SAST is that it’s typically able to identify the exact lines of code where a weakness or flaw is introduced.
But while DAST and SAST solutions are often referenced as the two pillars of application security, there’s a strong case to be made why RASP (Runtime Application Self-Protection) is the third pillar.
Pillar 3: Runtime Application Self-Protection (RASP)
The ability to continually monitor and protect applications during runtime is becoming increasingly important. RASP solutions offer this in spades, and do so quickly, accurately, and in a way that’s easy to implement and maintain.
Even with DAST and SAST solutions, many developers and security professionals are still left searching for a way to gain increasingly greater visibility and control across their ecosystem and block sophisticated attacks and fuzzing, which bypasses testing measures and impacts runtime environments. And much of the need for a third pillar is the continual shift of applications and workloads to the cloud. Having an application in the cloud is just having an application in multiple data centers. Companies have to understand what is being done to protect the applications in every environment.
Simply put, RASP empowers enterprises to move security to the core of an application, and then builds the security infrastructure into the application itself. And researchers and analysts are continuing to find that this is what security and risk professionals want, need and are increasingly demanding — for a solution that builds security into their products and services, so that they know they’re protected in any and every environment.
This built-in security creates a generation of self-defending applications that are able to keep pace with modern security threats, address and protect against vulnerabilities, and do so quickly and efficiently.
In closing, it is important to mention that just as no two application security testing tools are alike, not all RASP solutions are created equal. In an upcoming blog post, we'll discuss how to differentiate between different RASP solutions. A peek at the questions we'll ask:
1. What methodology does the RASP Use? For example, LANGSEC is an emerging methodology that makes some runtime solutions better than others.
2. Does the RASP provide threat intelligence on real production attacks in an integrated dashboard (such as with your SIEM or logging tool)?
It is an exciting time for application builders and defenders alike as there are now a small but growing list of RASP vendors as well as an emergence of partnerships between dynamic testing tools and RASP solutions -- all in the name of making applications more secure for businesses and their users.