Page 83 - Cyber Warnings

The problem is compounded by having to create and maintain nearly identical rules for different
URLs in the worst case scenarios. These drawbacks also apply to Cross Site Scripting and
Command Line Injection and other attacks.

When we compare the WAF approach to the more mature RASP implementations which can
disable all SQL Injection with almost 0% chance of generating a false positive with a single one-
line rule, the benefits of RASP to the business start to become clearer. The same can be said
for mitigating other vulnerabilities and while some instances may require slightly more work than
defining a single rule, the configurations are far simpler and more robust than their WAF
analogues.

The simplicity and power of RASP in the sphere of vulnerability mitigation alone makes a strong
case for including RASP technology as part of a comprehensive Cyber Security strategy. This is
especially true for Java applications. Java’s ubiquity in the enterprise and the frequency of new
vulnerabilities being identified in open and propriety APIs as well as the 90-day Critical Patch
Update (CPU) cadence of the Java Virtual Machine (JVM) itself all contribute to the difficulty and
cost of securing Java.

However, recently two other significant benefits of RASP have come to the fore namely Zero
Day Vulnerability mitigation and Virtual Patching.

Blocking Common Zero Day Attack Vectors
The generic nature of the rules that can be configured for RASP technologies means that they
can disable the most common execution vectors exploited by Zero Day Attacks.

For example, a RASP enabled Java Virtual Machine can be configured to deny the creation of
client and server sockets or file descriptors, either entirely if the application has no need of them
or allowing descriptor creation for the exact port numbers and file locations used by the
application.

This fine grained control can stretch to every aspect of the runtime so, in keeping with our Java
example, RASP could prohibit access to specific classes or packages irrespective of the any
other native Java security facilities. While the vulnerability still exists in the application logic,
exploits are rendered harmless and alerts can be raised for further investigation when illicit
attempts are made to access protected resources.

While this kind of fine grained resource access control can be configured at the OS or
Hypervisor level it remains cumbersome and error prone for many large enterprises to manage
application security at the OS level. The cost of having an infrastructure team attempt to
manage the security of large numbers of applications using OS level resource control gets more
and more expensive and time consuming with each new application.

Another drawback of OS level resource access control is that affecting a change to an
application’s security profile will normally require the application to be restarted. While this may
not be an issue for low SLA applications in small numbers, for large enterprises with thousands

83 Cyber Warnings E-Magazine – August 2016 Edition
Copyright © Cyber Defense Magazine, All rights reserved worldwide