Using RASP to Protect Applications and Comply with the PCI DSS

Public-facing web applications are ripe targets for attackers. These applications need security to protect against attacks as well as identify vulnerabilities. Previously, the popular solution was a WAF (web application firewall). A new technology is now available and can be used in addition to a WAF. RASP (runtime application self-protection) protects the application from within the application, rather than in front of the application. The application can be web-based or non-web-based.

RASP is like equipping a WAF within the application’s runtime context (an in-application WAF). RASP can be configured in two modes: Monitor and Protection. The most effective and secure mode is Protection. In this mode, RASP blocks any incoming threats and also attempts to resolve any identified issues. There is also the Monitor Mode. In this mode, alarms and flagging occur, but no blocking occurs. This mode is used for troubleshooting or when usability is a concern. It is not recommended for the production environment if the production environment requires high security or is required to comply with security standards.

RASP is installed by the developer. Read that again. RASP is installed by the developer. It is not an appliance, it is not a script, it is not another server – it’s actually WITHIN the application. RASP does not require a dedicated administrator. How much better can it be to have the protection configured and defined by the person who knows the most about the application? This doesn’t happen with a WAF. RASP is very low-maintenance and can include security from the very beginning.

There are two ways to implement RASP. The first involves the developers accessing RASP through function calls in the application’s source code. This is the most accurate implementation method. RASP specifies which parts of the application to protect. RASP can then monitor logins, database queries, and admin functions. This method is the best approach for the application’s security needs. The second implementation method is to add it to an existing application in the form of a wrapper. This is less secure because it’s not as closely integrated as adding function calls to the appropriate sections of the source code.

Once configured, RASP detects and blocks attacks against an application in real time. If the application moves (to perhaps a different virtual machine or environment), RASP integrates with the runtime environment of the application. As the application moves, RASP moves with it. It’s not reliant on architecture or network design.

RASP is better at combatting zero-day attacks than a WAF. RASP can be signature-based, but it doesn’t have to be. RASP analyzes the application’s activity to determine anomalous behavior and responds accordingly.

If a security event is detected, RASP takes control of the application and fixes the problem (if it can). If it can’t, it assists incident response by providing details that are not available in a WAF. The application threat intelligence capability includes details of the attacker (including full backend connection details), transaction information, currently logged-in user if applicable, how they attempted the attack, the application, and the line of code they are targeting. With this information, the dev team has immediate visibility and can start their investigation more quickly. Does this mean developers are now on call? Probably not… RASP will notify the typical on-call person who will perform the initial triage and escalate only when necessary.

When it comes to compliance, it’s good to have options. RASP opens up another avenue to PCI compliance, specifically Requirements 6.6 (v3.2.1) and 6.4.1 (v4.0), which require this type of protection for public-facing Web applications.  Note that the option to fulfill this requirement via manual or automated application vulnerability security assessment tools or methods (as opposed to an automated technical solution like a WAF or RASP) goes away in version 4.0.