Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

The unintended consequences of a RASP-focused application security strategy

Mark Carrizosa, VP of Security, Soha Systems | Sept. 3, 2015
RASP can help safeguard applications, but it isn’t a silver bullet.

Runtime application self-protection (RASP) is a promising solution for strengthening the security posture of an application while supporting faster development, but RASP can introduce serious unintended risks, particularly if developers are not producing quality code from the start.

RASP is a technology approach being evangelized by Joseph Feiman, a research vice president and fellow at Gartner. Last fall, in a report entitled “Stop Protecting Your Apps: It’s Time for Apps to Protect Themselves,” Feiman noted that application self-protection must be a CISO’s top priority because “modern security fails to test and protect all apps. Therefore, apps must be capable of security self-testing, self-diagnostics and self-protection.”

In a world where cloud-based applications are growing in prominence and use, legacy technologies just don’t suffice in terms of offering the best protection. Feiman’s report noted that “infrastructure and perimeter protection technologies inherently lack insight into application logic and configuration, event and data flow, executed instructions and data processing. Thus, they lack the necessary means to ensure accurate detection of application vulnerabilities and protection against application-level attacks.”

An emerging technology, RASP is built into or linked to an application’s runtime environment to control execution and prevent real-time attacks. This additional layer of application logic integrates with underlying code libraries and protects vulnerable aspects of the application at the source level by monitoring and detecting malicious inputs or errant behavior.

Addressing the deficiencies in application security is critical, particularly since web-based applications are a primary target for attackers seeking an easy means to penetrate networks. The opening for hackers is getting wider, too, as security controls are often deprioritized, particularly when they conflict with increasingly rapid development cycles.

The reason RASP is so attractive to developers is because it reduces the time and effort needed to build foundational security into their processes. Developers also believe that security will be stronger when self-protection capabilities are built into app runtime environments because the apps themselves have full insight into application logic, configuration, and data and event flows.

But, using RASP as a shortcut in the development process could leave the application open to other vulnerabilities once it is deployed, particularly if it’s the only security barrier being applied. Thinking that the app will be secure in the runtime, developers may be tempted to let security coding best practices slide in order to deliver new capabilities in today’s continuous delivery models and when trying to meet hyper-aggressive go-to-market timelines.

Examining the Risks

Today, less than 1% of all web and cloud applications are leveraging RASP for self-protection, so it is difficult to say whether it will live up to the hype. But it seems doubtful that RASP will be a panacea for application security.


1  2  3  Next Page 

Sign up for Computerworld eNewsletters.