Tags

,

Runtime Application Self Protection (RASP) is a term coined in a 2012 Gartner article titled “Runtime Application Self-Protection: A Must-Have, Emerging Security Technology“. Joe Feiman has been reviving this concept recently, as shown by his comments at a June 2014 Gartner event that RASP is a way to protect the application in an age where “The Firewall has Failed”.

Here is a rundown on what RASP is, or isn’t, and who is playing on this field.

  • HP call their offering HP Fortify Runtime and is usually offered as part of a bundle of HP security products. They initially gave the acronym RASP their own spin, calling it “runtime application security protection”. Let’s see if that lasts.
    HP are certainly upping their game in the application security world, acquiring and then shotgun marrying smaller companies before rolling them into their Fortify suite.
  • A Los Angeles company is offering a product named “Prevoty Enterprise“.
  • Waratek Ltd, from Ireland, have a product named “Waratek Application Security for Java“.

The basic premise of RASP is to provide additional security to applications. This new layer is located within “the runtime”, that is, in the same execution space as the application itself. Moreover, this new layer can be provisioned and leveraged entirely without the effort, cooperation or help of the software developers who created the application. The assumptions are clear: the developers need not be involved, and so security can indeed be added later, like icing on the cake.

Beyond simply being a new technology, RASP is positioned as providing an answer to a supposedly increasing problem in application security: the insecure network perimeter. This problem statement goes along the lines of this argument: “The network perimeter, protected by the firewall, is no longer controllable. Insider threats, and weaknesses in the supply chain, coupled with more sophisticated attacks all increasingly make the idea of a hardened network shell unworkable and ineffective. Therefore security controls need to be pulled back from the perimeter and applied to the host”. This argument may perhaps have merit, certainly i have experienced ineffective perimeter controls. But is RASP really the best, or even a suitable, control as a replacement or corrective for ineffective firewalls?

Let’s take a look at some weaknesses which I think are inherent to RASP – and to a large part also to Web Application Firewall (WAF) technologies.

* RASP only covers a small class of web application vulnerabilities, such as XSS and SQLi. These are trivially easy to fix by developers, and existing WAF technologies already do a good job here for those teams without the resources to effect a fix.

* RASP is promised to work out of the box, yet prudent implementors should really have a dedicated in house monitoring staff to ensure that false-positives are being corrected and important business transactions are not being prevented.

* RASP intentionally introduces new behavior into a system, but this behavior and the heuristics applied are proprietary to the vendor – a black box. Certification and validation activities for some of the systems using RASP may need to consider this additional complexity. The new behavior becomes part of the application runtime behavior and therefore must also be validatable.

* RASP (and in many ways WAF technologies, too) never actually correct the underlying vulnerability, instead they perform the role of a compensating control. Whilst the compensation is in place, risk from the threat of the vulnerability being exploited is indeed effectively mitigated, but a strong dependency is introduced: without the compensating control, the system becomes vulnerable immediately. If the dependency is not clearly documented and service managers not continually trained on this dependency, it may simply be forgotten. You see, removing the control will lead the system to fail-open.

* With RASP years of license fees for the compensating control now necessary, a new cost is introduced. From a total cost perspective, the analysis which potential implementors need to perform is a cost/benefit one. How much would it cost to license RASP technologies for the application’s entire lifetime, vs the cost of asking one of the members of the original development team to fix the weakness right away?

* RASP is per definition a “Runtime” control. What exactly this means is unclear, most authors seem to have a fuzzy idea of how to define “Runtime” in this context. In many ways, firewalls, WAFs, IDS and IPS tools are also runtime, vs design time or compile time, or deploy time controls. From looking at the products on offer however, it appears that the vendors define “Runtime” as a synonym to “Application Server”. That is, RASP technologies are hosted within the same JVM or .NET runtime environment as the application being protected. Therefore current RASP tools are limited to JAVA and .NET technologies. The absence of a runtime in PHP, Python, RUBY and other popular web frameworks precludes the use of current RASP tools.

* Does RASP introduce new vulnerabilities? It is certainly theoretically possible that RASP software contains security weaknesses in much the same way that almost all software contains weaknesses or defects. The question then becomes one of ensuring that the security tool itself does not introduce a new vulnerability not originally present in the application. Do vendor’s of RASP tools accept liability for security deficits in their products? It would surprise me greatly if they did, but I think customers would be wise to consider requesting liability guarantees from RASP vendors.

* RASP tools bypass the development team: they are introduced to fulfill user’s security requirements, but are not implemented by the developers, but by the server operators. Superficially this distinction is irrelevant, so long as the security requirement is being fulfilled. However the long term consequences can be disastrous. A world in which the development team is no longer held accountable for non-functional requirements is one in which the idea of “building security in” has been seen to fail. I don’t think we should give up on this idea yet.

On the whole, I am very skeptical of RASP. I doubt that it will provide the benefits that potential customers need. Unlike WAF technologies, i would not even consider using RASP as a temporary measure until the application’s security vulnerabilities are patched. I urge strong caution to those who are considering introducing RASP tools.

Advertisements