RASPIn the cyber world, we have an odd propensity to define everything as new and/or a breakthrough.  While having spent the last 20 years of my career in this space, my mechanical engineering degree rears its ugly head and causes me heartburn when this happens. In the non-cyber engineering world, we continually improve the methods (i.e. processes) and elements (technology/components) and speak more in terms of evolution versus revolution. 

As a result, the cybersecurity space tends to generate more buzzwords than most. Remember NAC? DLP?  They all sound great “on paper” but when put to the test in the real world, either the blemishes become apparent or we realize we’ve really been doing this all along in some way (does “cloud” ring a bell? Rackspace has been around for decades). But then the next buzzword comes along and we spin around that.  

This led me to come up with this blog series where I’ll shed some light on a buzzword each month, providing some background on the buzzword and then give you my 2 cents on its likelihood to “Sink or Swim?” All done in efforts to learn, discuss, and unearth (and to have a little fun). 

This month’s Buzzword Bingo is RASP (Run-time Application Self-Protection)

A self-defending application (remember Oracle’s similar campaign a few years back?), what a great sounding thing! An application that can identify and protect itself against incoming threats — who wouldn’t sign up for that? Gartner did its part to fuel the hype, too, calling RASP “transformational” at their 2015 IT Security & Risk Management Summit. RASP had been on many radar screens for a year or two prior (Gartner talks privately a lot before they start talking publicly.) A few RASP startups appeared. HP, Checkmarx, and Veracode all started talking about RASP products they had (or had “in the lab”)… and then reality hit. RASP is very difficult to get right. On a call earlier this year, an investor with >$50m into an application security technology vendor called it “technologically infeasible.”

Personally, I spec’d out a RASP solution in 2007 (called it SharkTank, 2 years before the TV show of the same name first aired) that enabled self-defending applications. I am a nerd and tech junkie at heart; unfortunately, we couldn’t get SharkTank much past slideware because it was technically very difficult — nearly impossible in 2009 in fact. 

The promise of RASP

As with all buzzwords, there is upside, promise, and potential.  From an application security and RASP perspective:

  • We need security built into applications (via secure SDLC) as well as in deployment for defense in-depth (defense in-depth is good)
  • Software can change itself based on input. Hardware (and thus most network security systems, e.g., IPS) is a lot more challenging to change in real-time than is software. The concept that an application can identify an input, e.g., a SQL injection attack such as ‘OR 1=1—, and then edit a software-based blocklist on the fly (in this case perhaps the app didn’t exclude “‘” in its current list) is nothing new, and is a premise upon which RASP is based. 
    • Here’s the rub: the application has to identify EVERY inbound threat/attack correctly, AND have an effective countermeasure for each attack. Even network-based IDS solutions can’t identify all attacks correctly. It’s even more complicated at the software layer. Multiply that complexity by the exact match for each unique software-based attack and that’s the matrix (assuming you stay in 2 dimensions) that RASP must nail to be effective. 
  • If RASP can be even 50% effective, it would give IT teams more time to fix issues whilst the RASP-enabled app is batting away easily identified attacks. 

The reality of RASP

Also with all buzzwords, there is downside, disillusionment, and disappointment:

  • If we are realistic as to where we are today, as an industry we all still long for the "silver bullet” to solve our insecure application riddle… some technology to solve our biggest problem(s).
  • RASP, like many AppSec solutions, has the potential to make development teams lazy and less concerned about security because they think RASP will cover up their warts. This false sense of security is something we see with firewalls, WAFs, and other operational technology. 
  • Let’s accept we are years away from an effective RASP solution, if we can ever achieve one. We have barely mastered intrusion detection in network space, let alone prevention (which is dependent on accurate detection). 

The future of RASP

If I were to tackle the RASP challenge today (as opposed to my grandiose slideware solution of 2007), I would start by attacking one problem/threat/attack type at a time — such as the example I used above, SQL injection. Pick my favorite list: OWASP Top 10? Why not. Then move on to XSS once I’ve mastered SQL injection. Start with the top of the list (most common/serious threats) and move down the list methodically. 

I want to see a working, comprehensive RASP solution. I would BUY a working, comprehensive RASP solution. But the path we’re on now is not a path to success as I see it. I see another buzzword being beat to death in the chase of yet another promise that can’t be delivered upon.  RASP =  Random Application Semi-Protection or Real-Time Application Semi-Protection.