Runtime Application Self-Protection (RASP) is a revolutionary technology that aims at improving application security. RASP integrates monitoring and protection as part of the deployment of web applications making it the first technology to provide protection in real-time.
RASP is a new technology with the promise of improving application security by enabling applications to self-protect in real-time against internal and external attacks. This promise has given way to some talk about RASP replacing WAFs entirely. While, there may be some use cases where RASP can fully replace a WAF, the reality is both technologies have their own strengths and weaknesses and should be looked at as important layers for defense-in-depth.
Many organizations have invested in WAF for quite some time. Large portions of the security budget may be devoted to supporting WAF implementations. However, are you finding that WAF is only useful in some – not all – of attack scenarios? There is a reason you are noticing this lag.
WAFs provide broad perimeter defenses (generally at the data center level) and mitigate threats at the edge of your network. At face value, this is an attractive value proposition, but the deficiencies of WAF are generally only seen during the post-implementation phase when it comes to operating and maintaining the solution.
However, most customers I’ve spoken with use WAF in monitoring mode. This means that while it’s in-line with their app, it’s not taking action on application-level attacks. Instead, its recording the attack requests and letting you know the type of attack, which endpoints it’s hitting, and from where. While that’s important information to know, it doesn’t exactly help you sleep better at night.
On the positive side, WAFs may also tell you that it has successfully defended traffic from known-malicious IPs, automated bots, as well as blocked Denial of Service attacks (if you’ve purchased that add-on). These use cases are actually well suited for WAFs since they are usually network-level attacks that, if not blocked, can cause problems like application availability.
Most often than not, customers are trying to make the best use of their WAF for mitigating application level threats like SQLi and XSS. They start off by trying to maintain the WAF configuration outside the development process by running DAST assessments and using this information to “virtually patch” the WAF. Unfortunately, the more patches applied the greater chance of a negative performance impact. At a theoretical level, “virtual patching” is an effective concept but ultimately fails for the following reasons:
On-going maintenance is impossible to keep up with – AppSec teams generally do not know when App Dev may be pushing a release. This is especially true for large AppSec programs supporting multiple teams.
WAF suffers from this stigma, and consequently serves as an expensive “attack monitor” that only tells you bad news. It also lacks the context – that is, the understanding of how data from the web request is actually used in the application – to mitigate the threat. This is where RASP adds a tremendous amount of value without any “learning” or tuning required. It can respond in real-time, at the run-time, at high performance and with low overhead. Finally, RASP can be integrated back into the SDLC and tested as part of existing functionality & quality tests. This helps ensure RASP does not negatively interfere with application functionality, yet still provide effective application security controls.
So what can RASP offer when combined with WAF? In short: