/feb 22, 2016

Why RASP does not negate the need for testing

By Joseph Feiman

When one calls a technology “transformational” as I have with RASP, there are expectations that this technology will change the direction of a market. The market expects the solution to address a serious problem in such a way that the problem is made much smaller. One misconception is that this transformational technology will replace all previous technologies aiming to solve the same problem. While RASP may spur future innovations, one thing it will not do is negate the need for application security testingRather than completely negate the need for application security testing, RASP is more likely to change the way testing is done. For example, one of RASP’s incarnations – interactive application security testing (IAST) – is a highly accurate application security testing technology, which will continue to work in conjunction with run-time protection.

In its first – protection – incarnation, RASP runs on a production server with protection features turned on. But what if we deploy the RASP agent on a test server, and then turn the protection feature off, leaving only its reporting feature active? In that case, we get IAST. The agent (the same one for RASP and IAST) has a comprehensive insight into application logic flow, data flow, and configuration. It watches test attacks initiated by attack inducer (typically, by DAST technology). At the end of the test, with high degree of accuracy, IAST reports to a developer the stack of code instructions that can lead to an exploit.  

Like all technologies, despite its power, IAST does have its limitations. As a runtime testing solution, it cannot be used at the programming phase. Therefore, we also need a technology capable of testing application code during this phase of the application lifecycle. That technology exists: it is static application security testing (SAST).

Now, we can see that each technology takes its own place: SAST analyzes code at the programming phase. IAST analyzes application behavior at test phase, using DAST as an attack inducer. RASP protects applications at production phase against attacks induced by hackers.  Altogether, these technologies form a single powerful platform for detection and protection.

As the IT industry seeks ways to secure DevOps, these technologies offer a comprehensive solution: SAST and IAST (the latter – with DAST as an inducer) address the ‘Dev” part of DevOps (programming and testing phases) and RASP addresses the “Ops” (the operation part of DevOps).

Applications are a primary target for cybercriminals, and there is no one silver bullet for securing applications. That is why using a combination of static and runtime solutions, a combination of detection and protection technologies, a set of technologies that spread across development and operation phases of the software lifecycle is an optimal scenario for creating and deploying secure applications.

Related Posts

By Joseph Feiman

Joseph Feiman is Chief Innovation Officer at Veracode. In this role, Joseph is responsible for advanced technologies that drive innovative detection and protection strategies. Joseph is a recognized industry leader with nearly two decades’ experience in application development and security, analyzing the market for Gartner Research.