The unintended consequences of a RASP-focused application security strategy
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.
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.
The fundamental problem with RASP is the serious potential for diminished code quality. It’s not that developers will intentionally write code that is insecure, but rather that they won’t focus on security when their primary mission is building out functionality quickly.
Over the course of the last five years, there has been an increase in focus on application security, with the introduction of practices and tools – such as dynamic or static application security testing (DAST and SAST, respectively) and interactive application security testing (IAST) – that can be built into the development cycles. Developers who use DAST, SAST and IAST tools will ultimately have better code, in terms of extensibility, quality and security.
With RASP the concern is secure code development skills will diminish because they are used less frequently. Continued practice of solid coding is the most failsafe way to ensure that developers become experts in building the requisite checks and balances into their code. Of course, RASP, as well as DAST, SAST and IAST, can be effective tools when they run properly, but they are not substitutes for quality code that can stand alone if tools fail or people don’t use them.
There are other consequences of RASP that must be considered, too. For example, it 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 an 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.
Another issue that could arise is increased latency. While RASP’s impact on performance may be negligible, adding yet another check to the process will come with a cost. Depending on the latency budget of a project, it may not be that big of an issue. But when you’re dealing with high-performance applications, such as those used by online retailers where processes that take more than 50 milliseconds are not acceptable, added latency may not be worth it when considering the potential impact to the customer experience.
RASP alone simply is not sufficient to ensure the security of your apps, particularly since its protection is applied in the application runtime environment. By applying security there, hackers are invited deeper into your stack at a time when other approaches are seeking ways to keep them even further outside your network borders.
The most effective approach to application security is a collection of sound software security fundamentals that are aimed at reducing risk and enabling the business when implemented correctly. The core elements include:
While RASP can be a valuable tool in the early stages of the development process, it should not be viewed as a comprehensive, foolproof approach to application security. To truly mitigate attack vectors, you must apply sound security fundamentals to the application itself, from the start.
The security team must always be one of the key stakeholders in the software development lifecycle and security testing must be incorporated into the development timeline. Once organizations adopt this approach, they will have successful innovation and continuous development cycles, without exposing their apps or their business to security threats.
Carrizosa is VP of Security at Soha Systems, a cloud-based application security provider for enterprises and SaaS providers. Carrizosa joined Soha Systems in 2015 from Walmart where, as principal security architect, he developed and implemented the company’s global e-commerce security architecture framework. Prior to Walmart Carrizosa held security management roles at Wells Fargo and PetSmart.