In recent years, the world of application security has seen the rise of runtime application self protection (RASP) technology. RASP is a security technology that is integrated into an application or its runtime environment, capable of controlling and preventing real-time attacks. Unfortunately, many web application firewall (WAF) companies saw an opportunity to leverage the term and introduced “RASP”-like agents at the network layer, which isn’t fully embracing the definition of RASP technology.
In contrast, genuine RASP technology operates at the application layer, where it has full context of the user, application logic, and domain information. This allows a RASP to make informed decisions about the security of the application and to prevent exploits before they can cause harm. As a result, a true RASP should have zero false positives, reduced latency, and provide an immediate boost in performance. The only way to fully implement the true spirit of RASP is to have a list of immutable rules which use context to understand when a new vulnerability is introduced and act accordingly. You can achieve this by implementing a security platform that bakes rules into the code base at the application layer and does not require any changes once deployed.
Where did RASP go wrong?
1. Most Alerts Are False Positives
The issue with WAFs is that they work at the network layer, which is a lagging indicator of application execution. WAFs are unable to control application execution as they lack the ability to access the context of the user and application functions, which are necessary to make informed decisions about the security of the application. This leads to high false positive rates, long wait times and poor performance as WAFs can only make guesses about the nature of a vulnerability based on what they have already been exposed to in the past.
Imagine a guard dog that stands in the yard, inside the fence, barking every time it hears a noise beyond the barrier. These noises may be the approach of an intruder, but they could also just be cars passing by. The guard dog is unable to accurately gauge the difference and so the severity of any given noise is lost on it. It reports all noises the same way, making it impossible for the people inside the house to know which alerts are genuine and which are false positives. This is essentially the capability of the common “RASP” offering.
2. Only Capable of Testing a Sample
As a matter of fact, some vendors tell you to not run their security solution in production environments at all, unless you’re running on a sample rate. That means it pulls a sample — perhaps one in every 1000 requests — and then tests that sample and cache what happens for the next 999. So if you’re a good actor, your credentials will check out. Regardless of what the next 999 actors do, they’re gonna let them through even if all 999 of them have bad intentions. This is all because WAF-based RASPs can’t handle the performance requirements of having to actually test each request.
3. Latency Affects Performance
What’s more, any time you have a WAF-based RASP, you experience increased latency, since they cannot influence the application’s code base in any way. Meanwhile, widely available “RASP”s have to send entire text payloads to their web analyzer and then send it back, which can take a long time. And if your customers are waiting on payments to go through, they might give up and seek out your competitors instead.
Improving this process is not all that different from code optimization. Let’s look at a simple example:
When creating a list, best practice dictates that a developers always set it up to add new items to the beginning of a list instead of the end, as a person naturally would. This is done to prevent the VM having to rebuild the entire list each time a new item is added, which greatly increases the latency as the list grows. However, by the early 2000s, compiler engineers started to address these issues by implementing just-in-time (JIT) compiling, which automatically optimizes code based on the nuances of the given language. This same principle applies to vulnerabilities, since vulnerabilities are just bad code. When best practices are automatically built into the logic of the program, both exposures and latency are greatly reduced.
Why Has the Definition of RASP Been So Watered Down?
So, why aren’t all security vendors using RASP technology? The answer lies in the level of expertise required. Developing RASP technology requires a combination of security engineering and software engineering skills. To be effective, the RASP developer must have a deep understanding of the architecture of the application and the nuances of the programming language being used. This requires a level of domain expertise that is not common among security professionals.
True RASP Optimizes Code for Performance as Well as Security
In contrast, a genuine runtime application security system does not require retuning. Regardless of any changes made to the application, the security remains constant, as the system has a deep understanding of the language in which the application is built. This enables it to prevent vulnerabilities at the runtime layer, instead of just the network layer, which can be easily bypassed.
Regardless of any changes made to the application, the security remains constant. This philosophy aligns with the philosophy of Infrastructure-as-Code in which you define the desired state of your infrastructure, and no matter what happens in the environment, the state of the infrastructure is immutable.
The next evolution of “RASP” and the first true realization of the original definition is Waratek’s rules-based java security platform, which parallels the principles of Infrastructure-as-Code. This is possible due to the deep understanding of the language in which the application is built. Like infrastructure-as-code, Waratek’s approach uses a definition file to enforce security, making it immutable and ensuring that the rules are applied regardless of changes to the code base.
Our true RASP checks the output of a function each time it is called and switches out any unhealthy functions with healthy ones, ensuring that the application always has only healthy functions in memory. This approach is also deployment agnostic and does not require any changes to the application code, tuning, or waiting for deployment windows. With our approach, pushing a fix results in immediate protection on all running instances of the application, eliminating the need for constant security checks and removing the risk of future exploits.
To learn more about protecting your applications with true RASP technology, click here.
