The Inside-Out Application Security Opportunity with RASP by Signal Sciences

Digital transformation projects demand that developers continually roll out new applications to fuel those efforts. These new applications and APIs can surface sensitive data and must be protected in production: RASP (runtime application self protection) provides developers a defensive means to instrument their code, gain observability at runtime, and defend their apps against malicious web requests.

NIST focuses on RASP with new guidance

To respond to this rapid change, the National Institute of Standards and Technology (NIST) released a revision to Security and Privacy Controls for Information Systems and Organizations, NIST SP 800–53 Revision 5. With NIST’s new focus on RASP, developers have an opportunity to take an inside-out approach to protecting their applications and APIs by embedding protection at the application. In doing so, dev teams can embrace NIST’s new standard that addresses runtime application self-protection ( RASP):

The key here is instrumentation where application layer telemetry is generated by sensors (or software agents/modules) embedded within the software.

Not all RASP implementations are created equal

There are several RASP approaches available in the market. In order to understand why Signal Sciences RASP is superior to our competitors, this blog will cover two other primary RASP approaches in comparison to Signal Sciences. RASP can be implemented in the following methods:

• RASP overhead layer: intercepts calls to the underlying Java runtime environment (JRE) or common language runtime (CLR)
• RASP library or SDK: this approach utilizes specific calls to a library within the application but has major pitfalls
• RASP embedded as language- or framework-specific module: Signal Sciences approach empowers developers to easily deploy RASP protection so they can leverage precise instrumentation and inline detection and request blocking.

Method One: the Overhead Layer

In this technical approach, the RASP intercepts calls to and from the runtime environment. This is accomplished by replacing the Java virtual machine (JVM) or using a custom Java archive (JAR) wrapper or dynamic link library (DLL). In doing so, the RASP supposedly provides deep inspection into the call stack. But there are several negatives:

Interference with APM tools

These low level inspections can interfere with application performance monitoring (APM tools) you may be already using.

JVM or wrapper tuning that does not readily scale

Some users experience performance problems because the developers rely on the RASP vendor to tune the JVM or wrappers to work for their unique application. So they must tune policies to get the RASP to work-multiply this by dozens or even hundreds of applications and you can see the laborious and daunting challenge here already.

Intra-team coordination that prolongs implementation

Dev and ops teams must coordinate between teams to install the deep instrumentation: this can drag out the implementation. Heartburn abounds if one team struggles with the deployment, which can keep other teams from even trying it out.

Limited language and attack coverage

Only provides attack coverage for Java and .NET apps. Other advanced attack coverage is also limited.

Method Two: RASP Library and SDK

With this approach developers call a RASP library or SDK for specific calls that generate granular results that they can handle in their code. When you’re writing a new app from scratch, this may be acceptable from a workflow perspective. Otherwise, it requires rewriting pre-existing applications. And then there’s the political aspect: you’ll have to convince each software development team to modify the app code so it can be instrumented in production.

Looking through the performance lens, the RASP engine can experience delays and performance hits. We’ve seen documentation from vendors that state doubling the response time for a typical request-that’s a nonstarter for most development teams.

The last negative aspect: if the call to the library or SDK fails to accurately detect, false positives result. Rules tuning to reduce false positives is common in this RASP approach, even for basic rules to detect cross-site scripting (XSS) and SQL injection (SQLi), but this requires more of your time away from higher value work that drives your business forward.

Method Three: embed with the app as language- or framework-specific module for effective protection

Given the pitfalls of the early RASP approaches, Signal Sciences has taken a fundamentally different approach that’s now patented.

Signal Sciences RASP implementation provides a granular level of observation at runtime required for precise web request inspection and attack detection. This is accomplished by embedding our language-specific module with your application. Our RASP is compatible with a range of languages, from Java to PHP to Node.js and several others.

• Signal Sciences leaves the app code, libraries, JVM and Java runtime environment all untouched. This is done by using a lightweight HTTP servlet filter in Java. In other languages and frameworks it is done by wrapping HTTP handlers. These are lightweight and function as a loopback to the Signal Sciences RASP module.
• The dual filter plus module piece is the patented part since it enforces performance and reliability with a fail-open design: if the filter doesn’t receive a response back from the module in a set number of milliseconds, the request will go through to the app.
• Detection is done quickly and accurately in the RASP module by our proprietary SmartParse technology. Our average latency in production customer deployments averages between one and three milliseconds, which is the fastest in the industry. Top-ranked sites running at massive scale run Signal Sciences in blocking mode and report no noticeable impact to their service.

Our module constantly receives asynchronous updates on new threats from our Cloud Engine based on web traffic telemetry collected from across our installed customer base. We also take a threshold approach to blocking, allowing 95% of our customers to trust us to run in full, automated blocking mode in production with virtually no false positives. You can learn more about our language- and framework-specific RASP modules in our product documentation.

With threshold blocking, our RASP module does not decision on each request like other RASP implementations, but instead examines suspicious payloads over time and with context to determine whether web request traffic poses an actual attack.

Lastly, our Power Rules provide customers instrumentation for any application flow. With other vendors’ RASP deployment options, customization around unique business logic is severely limited.

Our approach also makes it possible to get stack traceability through integrations with APM tools that already capture that information. Combined with Signal Sciences Power Rules, you get deep insight into any HTTP transaction or flow, but without the computational overhead that the other RASP options require.

Learn more about how Signal Sciences RASP can protect your business-critical applications without performance impact by requesting a demo today.

Additional Resources:

• Signal Sciences RASP data sheet
• Blog: Dear RASP: We Need to Talk About the Friction in Our Relationship

Originally published at https://www.signalsciences.com on September 3, 2020.