IAST, RASP, and Runtime Instrumentation

The Application Security Testing (AST) technology market is made up of the following categories:

1st Gen

• SAST (Static Application Security Testing)
• DAST (Dynamic Application Security Testing)
• WAF (Web Application Firewall)

2nd Gen

• IAST (Interactive Application Security Testing)
• RASP(Runtime Application Self-Protection)

There are other categories that can be lumped into AppSec as well, such as developer training (eg CBT and SCA) — but for the most part, the classification above is how most people think of the AppSec Testing market.

Each of the technologies listed above has practical uses, benefits, as well as constraints and limitations. The key to implementing, and eventually maturing a successful AppSec program is to pick the set of technologies and practices that are best suited for the specific circumstances. For example, a company striving to secure a highly evolving PHP application will have different “good-options” than a company trying to secure a relatively static J2EE enterprise application.

Now, in general, SAST, DAST, and WAF’s have existed for over a decade, and many of us in the industry believe they have reached their technological potential. Don’t get me wrong — there are still places, quite a few places in fact, where it makes sense to use these solutions. However, the technology itself has seen a decade of incremental improvements; it's just not going to get that much better anytime soon. The big issue with these technologies is that you can have either accuracy and effectiveness (low false positives / low false negatives) or minimal/easy tuning, operations, and expertise requirements. You can have one, or the other, but not both. In short, for these products to be effective you have to be willing to invest heavily in expertise and operations, or you will pay a price in terms of agility.

Most AppSec experts are shifting their attention towards IAST and RASP, which offer a significant step up in this regard. The promise is that these 2nd generation technologies will have lower false positives/negatives, and yet will require fewer resources to deploy properly. This is extremely significant in an era where agility, continuous development/release, and DevOps are expected. In fact, I would argue that it is precisely these trends that are showing the aging signs of the 1st generation technologies. They may still be there, but they can no longer be the central bedrock of an AppSec program.

Both IAST and RASP live in runtime, and promise different things:

• IAST: accurate and easy identification of common vulnerabilities at testing time
• RASP: accurate and easy prevention of exploitation of common vulnerabilities in production

We think of both of these technologies as manifestations of a wider Runtime Security Instrumentation technology. To use a loose definition, I would describe Runtime Security Instrumentation as the technology that instruments various parts of the application to identify events at runtime that may have a security relevance.

Both IAST and RASP instrument the application (although vendors vary widely in how sophisticated and powerful this instrumentation can be - more on that in a future blog post), but what they look for (how they define “identify events at runtime that may have security relevance”) and what they do with those events is different.

For example, some IAST products will do source-sink analysis and identify places where untrusted user input made its way to the database. Other IAST products will identify
which lines of code a particular payload from a DAST were successfully exploited.

In the case of RASP, some products will identify a clearly malicious payload about to hit the database and stop it from executing.

However, there are more general use cases for “Runtime Security Instrumentation” than IAST and RASP. For example, this type of instrumentation technology can tell you which parts of your application has received security testing, and which parts have not, understand if an application is under attack, by whom, and how. You can also use instrumentation to enhance the high fidelity security logging that you have for your applications. There are quite a few more examples that our security instrumentation technology brings to the table.

We think that the future will see runtime security instrumentation evolve, with the lines delineating the application of such instrumentation, blurring over time. That is a good thing: add instrumentation — gain insights, identify vulnerabilities — get protection, receive operational security intelligence — enhance logging, and more — all from one solution.