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.
Developing sound application security fundamentals
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:
- Secure coding practices – The security team must ensure that developers get the appropriate training. Awareness programs and requirements to be certified to work on certain projects will improve the quality of developer code.
- Supporting tools – Tools like DAST, SAST, IAST and RASP can be valuable additions in development, QA and testing environments, where they can serve as additional elements of due diligence. By leveraging these tools at these stages, developers can go back and fix security bugs before they are introduced to a production build.
- Threat modeling – This type of risk analysis takes a deep dive into all aspects of an application to see where potential threats could happen. Threat modeling can begin at the inception of an app, when the development team anticipates where problems may arise, and they build protections into the design; or developers can employ third parties or peers with relevant security experience to provide an assessment.
- Real-Time Penetration Testing – Unlike the tools mentioned above, which look for predetermined patterns or signatures, real-time penetration testing relies on testers who are trying to evade standard techniques. This manual human inspection element is valuable in finding vulnerabilities that automated testing may not uncover.
Sign up for Computerworld eNewsletters.