DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Join us tomorrow at 1 PM EST: "3-Step Approach to Comprehensive Runtime Application Security"
Save your seat
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. IAST, RASP, and Runtime Instrumentation

IAST, RASP, and Runtime Instrumentation

How IAST and RASP have evolved in the application security market, and what the differences are between the two.

Zaid Al Hamami user avatar by
Zaid Al Hamami
·
Jan. 26, 17 · Opinion
Like (5)
Save
Tweet
Share
3.42K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Instrumentation (computer programming) Application security

Published at DZone with permission of Zaid Al Hamami. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Explainer: Building High Performing Data Product Platform
  • Debugging Threads and Asynchronous Code
  • Why It Is Important To Have an Ownership as a DevOps Engineer
  • Handling Virtual Threads

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: