Blog Viewer

WAF and RASP: Best Practice for Defense in Depth

By Simon Dickerson posted 03-13-2020 08:43
Many would ask why do you need a RASP solution if WAF's layer of defense is so powerful.  I will answer that question in this blog. 

With all the high profile security breaches the topic of application security forefront, a
ll internet-facing applications are subjected to a constant barrage of probes and attacks.  A good solid security strategy is vital with the many different forms of attacks needing to be considered.

A multi-layered approach, such as Imperva Application Security provides protection including a Web Application Firewall (WAF), DDoS protection, Bot management, and RASP and can provide a full solution stack for securing and monitoring application access.

The WAF is an essential part of protecting applications by allowing legitimate traffic through and bad traffic out. It protects against the critical risks such as SQL injection and cross-site scripting. 

RASP (run-time application self-protection), conceptually, appears similar to the functionality of a WAF, being designed to detect and block exploit payloads. But let's look at the WAF and RASP.

Web Application Firewall

The WAF sits in front of applications, inspecting incoming HTTP request traffic for known attack payloads and abnormal usage patterns. When a suspicious payload or usage is detected the request can be reported or report and blocked. The benefits cannot be understated with the WAF inspecting every request including SQL injection attacks, cross-site scripting etc. It will allow for customization of rule-sets for application protection, in addition to providing full visibility with real-time alerts and reporting.

Most organizations have adopted the philosophy that WAF is best utilized to keep known bad traffic as far away from critical assets as possible. We know that about half of the traffic on the internet is categorized as “non-human”. This “non-human” (bot) traffic is typically trying to execute things like data harvesting, scraping, Account Takeovers and credential stuffing. The WAF can provide for some bot traffic mitigation but full protection will be provided by an advanced bot management solution.

The WAF separates bad traffic from good traffic and ensures that your application is not processing information or requests which do not pertain to the application’s intended functionality.

The WAF deflects bad traffic at the edge before it is processed by the application protecting your apps from security attacks.  Working with an application delivery module, providing Content Delivery Network (CDN) and load balancing, a Cloud WAF can ensure that your data and resources are being distributed and allocated correctly.

The downside to most WAFs is they must be tuned in order to block exploits. There needs to be a reactive approach identifying exploit payloads before applying protections. This can allow unwanted false positives to be introduced especially in fast moving application development with agile development practices. 

Run-Time Application Self-Protection (RASP)

The RASP approach is to tightly couple with the application code by plugging into the application at the server level.

The benefits of this approach are numerous as it is able to provide application awareness and context sensitive protection. At this level it will integrate into the software development lifecycle (SDLC) and able to prevent zero-day attacks and to secure legacy applications.

RASP uses contextual awareness to detect threats and provide assurance that a particular payload will not be able to exploit the application code. RASP technology inspects the complete (and often-times transformed or obfuscated) payload in the context of how the application will use it only when the application will attempt to use the data.

The result is a low false positive and high visibility into vulnerabilities which includes weaknesses previously unknown to the organization. RASP does not require continual maintenance or significant tuning. It provides location appropriate security complementing the WAF and the other elements of an Application Security solution suite.

Whilst the policies of the SDLC may mandate that vulnerabilities found with security testing tools (e.g. DAST) must be remedied before the application gets to production.  It is often the case that business pressures mean the application is released with known issues. Application code is rarely bug free.  Developers typically do not have strong security training. The case for a solution that provides default protection against exploits at the application level becomes very strong.

The Case for WAF and RASP

Security at the edge, such as the WAF, is excellent protection against known attacks. But frequent application code changes and 3rd party libraries mean the environment is under constant change and edge protections must be reactive or risk unwanted false positives.

When an attack does get past the edge protections then further defense is essential to protect the application and data. The Imperva RASP solution provides this layer of security, giving the application security by default. The location/context awareness of the application provides usability and security. Because it is a solution in the right place, it minimizes false positives.

The question of the merits of RASP vs WAF and which is better is frequently asked. RASP and WAF are complementary with the WAF protecting known bad traffic at the edge and RASP providing location appropriate security enforcement in the context of the application.

The two different approaches to security provide a defense in depth solution.