Minerva Studio - Fotolia
Published: 02 Mar 2015
At some point in the early days of information security, somebody decided to circle the wagons and defend the perimeter rather than fix the broken code on the inside. It was a pragmatic decision that doomed us to an eternity of insecure code at the systems and application layers alike.
Some people might now be wondering if that strategic mistake is being repeated on a more intimate scale with runtime application self-protection (RASP) technology, which application security vendors such as HP have adopted. Like perimeter defenses, however, it's hard to argue against the practical reasons behind this evolutionary approach to protecting on-premises, cloud and mobile applications from attackers.
With RASP, you aren't building a secure application. Instead, you add "shielding" components to whatever your developers have cooked up, however flawed. The RASP add-ons come into play when the application is executed (the R stands for runtime, after all), causing the program to monitor itself and detect malicious input and errant behavior.
If you've studied computers, you may recall the Halting Problem -- an exploration of what can and cannot be computed. From there, you can hypothesize that a computational program capable of examining itself and definitively determining anything meaningful about its own behavior cannot be written -- at least not without first executing itself and seeing what happens. RASP isn't quite the same situation, but some of the same complexities surely apply here.
That complexity hasn't stopped several vendors from trying. In addition to HP, application security companies such as Arxan Technologies, Prevoty, Waratek and Bluebox Security have all introduced RASP technology, though Gartner estimates that only 1% of today's defenses use these products.
RASP is made available to developers as a series of function calls (pre-programmed security instrumentation procedures) that may be included in source code. Another approach to RASP is to take a finished executable application and put it in a wrapper that has various kinds of onboard instrumentation.
The first method gives you a more precise application of security checks. Developers make explicit decisions about which portions of the code should be protected (logins, database queries, administrative functions and so on).
Either way, you get something akin to the protections a Web application firewall might offer, but neatly bundled into the application's runtime context. RASP vendors are quick to argue that a direct connection to the self-protected application means they are more tuned in to what it needs to remain secure.
It's easy to poke at potential flaws in the RASP security model, as it joins the growing list of application security testing acronyms, like SAST, DAST and IAST. For one thing, either category of RASP has to apply somewhat generalized instrumentation and protection. This "attach to any app" approach just cannot be the same thing as having truly built-in security from the get-go. Software security is as much about well-vetted design as it is about coding errors.
There are also performance implications to RASP: Calls to the security libraries add overhead. The computational cost will be more apparent to the user, because it's happening mid-interaction. But how much of a performance hit one sees, and whether it's even enough to be noticed, is something we'll only figure out as more applications deploy the approach.
RASP may prove useful despite the potential red flags because it offers a clean solution to some of the pitfalls of mobile security. When you send an app out into the mobile world -- and particularly if you are embracing a BYOD strategy -- you can't necessarily count on the operating system to fend off the attackers. If it's every app for itself out there, having firewall-like capabilities built into runtime environments may turn out to make a lot of sense.
Robert Richardson is the editorial director of TechTarget's Security Media Group. Follow him on Twitter @cryptorobert.