RASP: A False Sense of Security For Apps & Data

Reports about data breaches have become so common that we no longer react with shock or outrage, we merely treat them as business as usual. Whether it be a hack at the Office of Personnel Management, UCLA, the Army National Guard or countless smaller breaches, we have become indifferent and desensitized to these violations - unless it impacts us personally.

Web-based applications have been, and will continue to be, a primary target for attackers seeking a means to penetrate organizations’ networks. What’s worse, hackers are finding easier openings when security takes a back seat to achieving faster development and deployment cycles. A number of technologies have been introduced to help secure apps, while fostering faster development. But are they really all they’re cracked up to be?

Let’s consider one technology that’s getting a lot of buzz these days: runtime application self-protection (RASP). The idea behind using RASP for security, according to Joseph Feiman, a research vice president and fellow at Gartner, is that applications can be better protected when self-protection capabilities are built into their runtime environments. This provides security and development teams with full insight into application logic, configuration, and data and event flows. And, because RASP operates in the runtime environment, it is able to control application execution, and detect/prevent attacks in real-time, as opposed to a more reactive model that is more focused on minimizing impact. 

RASP clearly offers a number of benefits, such as a granular approach to combatting attack vectors and better scalability minus the additional hardware costs. Because RASP has that direct connection to the self-protected app, it has a clear sense of what that app needs to remain secure. When the application is executed, RASP enables it to monitor itself, detect malicious or errant behaviors, and alert IT to problems.

RASP is growing in popularity because it eliminates a lot of the time and effort that organizations would typically take to build security checks into their processes. But in many ways, I see such handy shortcuts could foreshadow serious problems with the quality of the underlying code.

This is not speculation; there is a reason why SQLi/XSS are consistently on the Open Web Application Security Project (OWASP) Top 10. The concern is that the reliance on this solution can mask a developer’s tendency to let software security best practices take a back seat to new capabilities, particularly with increasingly aggressive go-to-market timelines and continuous delivery models.

Unintended Consequences

Though RASP’s goals are noble, it could also have unintended consequences rendering it unusable. Introducing a re-write of software execution at the last minute could be very risky from a support/incident response perspective, particularly as applications are modularized and supported by numerous teams. Expect there to be a fair amount of contention and finger pointing should there be any type of operational issue (regardless of relevance).

More often than not, checks could be paused, alarms silenced, and anything causing these issues could take a back seat to revenue generation as a company essentially accepts a high level of risk out of sheer annoyance (similarly to WAF implementations). Certainly this is not the most effective way of responding to security issues.

RASP also could have a negative impact on service level agreements (SLAs). Allowing RASP to stop code running in production in the midst of an attack certainly paves the way for a pretty effective self-imposed Denial of Service (DoS) engine. In today’s high-performing environments, where availability is expected at four or five 9s, downtime could have a serious impact to SLA’s and subsequently result in lost revenue and impact the company brand.

Having been on the frontlines of building security into solutions and development code for high-profile retailers, including Walmart and PetSmart, I believe there are a number of red flags surrounding RASP that must be considered. It is still a nascent technology, as less than 1 percent of all web and cloud applications are leveraging RASP for self-protection today. If companies experience security breaches as a result of their reliance on RASP, they’re not likely to fess up to it publicly. Hence, we don’t know, and won’t know, how effective it is.

Without a doubt, RASP can be a valuable addition in development, QA and testing environments, where it can serve as another element of due diligence and allow you to go back and fix security bugs before they are introduced to a production build. But to truly mitigate these attack vectors, we need to look to properly secure what is at the core of the businesses, the application code itself. Betting on a single runtime tool - like RASP - to magically eliminate risk is not the answer.