What RASP Should Have Been

Understanding the Evolution of Runtime Application Self-Protection (RASP)

In recent years, the world of application security has seen the rise of Runtime Application Self-Protection (RASP) technology. This innovative security solution integrates directly into an application or its runtime environment, enabling real-time attack detection and prevention. However, many Web Application Firewall (WAF) companies have attempted to leverage the term RASP, introducing “RASP”-like agents at the network layer. This approach falls short of fully embracing the true definition and potential of RASP technology.

The Inefficiencies of Traditional Security Measures

Traditional RASP solutions, not based on advanced techniques like tainting and syntax analysis, suffer from high false positive rates and limited sampling capabilities. These solutions often rely on pattern matching and heuristics, leading to inaccuracies and delayed responses. This results in a high number of false positives, as these RASPs lack the necessary context to distinguish between legitimate and malicious activity. Moreover, many security solutions advise running in a sample mode, which means only a fraction of the requests are tested, leaving the majority unchecked and vulnerable to attacks.

In contrast, modern RASP solutions provide continuous real-time protection without the need for extensive configuration or sampling. They monitor the application’s data flow, inputs, and outputs, enabling precise threat detection and mitigation. According to research, RASP tools effectively prevent exploitation by blocking attacks as they happen, providing a robust layer of security directly within the application’s runtime environment​ (Source: ar5iv).

The Pitfalls of Traditional RASPs

1. Most Alerts Are False Positives

   The issue with traditional RASPs is that they rely heavily on heuristic methods, which are unable to control application execution as they lack the context of the user and application functions. This leads to high false positive rates, long wait times, and poor performance as these solutions can only make guesses about the nature of a vulnerability based on past exposures.

   Imagine a guard dog that stands in the yard, inside the fence, barking every time it hears a noise beyond the barrier. These noises may be the approach of an intruder, but they could also just be cars passing by. The guard dog is unable to accurately gauge the difference and so the severity of any given noise is lost on it. It reports all noises the same way, making it impossible for the people inside the house to know which alerts are genuine and which are false positives. This is essentially the capability of the common “RASP” offering.

2. Only Capable of Testing a Sample

   Some vendors advise against running their security solution in production environments unless operating on a sample rate. This means only a fraction of requests are tested, leaving the majority unchecked. Traditional RASPs cannot handle the performance requirements of testing each request, leading to compromised security.

3. Latency Affects Performance

   Traditional RASPs introduce significant latency as they analyze payloads, causing delays that can deter users. Unlike genuine RASP solutions, which integrate deeply with the application to optimize both performance and security, these solutions struggle to maintain efficiency.

The Shift to Software-Defined RASP

The need for a more scalable and efficient security solution has led to the development of Software-Defined RASP (SD-RASP). This approach leverages machine-readable definition files and high-level descriptive coding languages to apply immutable and continuous security behaviors. SD-RASP automates the process of patching known vulnerabilities and inserting security rules to block unknown ones (zero-days), significantly reducing the reliance on human intervention.

Studies have shown that automating these processes can eliminate false positives and negatives, making security efforts more efficient and scalable. By integrating deeply with the application runtime, SD-RASP solutions ensure minimal performance overhead, allowing security teams to focus on strategic tasks rather than manual vulnerability remediation​ (Source: SANS Institute)​​.

Waratek’s Innovative Approach

Waratek’s approach to RASP exemplifies the benefits of SD-RASP. Utilizing non-heuristic detection techniques such as data tainting and syntax analysis, Waratek accurately identifies and prevents code-injection attacks. Data tainting marks all user inputs as “untrusted,” while syntax analysis detects anomalies in the application’s data flow, providing precise threat detection without the inaccuracies of heuristic-based solutions.

Central to Waratek’s approach is the utilization of non-heuristic detection techniques for code-injection attacks based on two features: data tainting and syntax analysis. Waratek deliberately chose not to use heuristic-based techniques such as pattern matching, regular expressions, exploit signatures, blacklists, or whitelists. This decision avoids the inaccuracies, false positives, continuous tuning, and performance degradation that plague heuristic-based approaches.

Data Tainting: Data tainting (also known as taint checking) marks all user-input data to a Java app (like HTTP request parameters) as “untrusted.” This aids in distinguishing between developer-written code and user-inputted data.

Syntax Analysis: Once data is tainted, Waratek performs syntax analysis to identify if the user-input data is a code-injection exploit. For example, by intercepting SQL statements before they reach the database, Waratek can detect SQL injection attacks according to the formal grammar of the SQL dialect of the application’s database. This method ensures accurate threat detection and avoids the false positives associated with heuristic-based approaches​.

For example, Waratek’s ARMR rules include policies to prevent common vulnerabilities such as insecure deserialization and Cross-Site Request Forgery (CSRF). An ARMR rule for insecure deserialization could look like this:

app("Insecure Deserialization Prevention"):
  requires(version: ARMR/2.2)
  process("Deny deserialized data execution"):
    execute("*")
    protect(message: "Blocked deserialized data", severity: 7)
  endprocess
endapp

For CSRF protection, ARMR rules can include synchronized tokens and same-origin policies:

app("CSRF Same-Origins"):
  requires(version: ARMR/2.8)
  http("Deny HTTP requests with invalid origin header (for all HTTP endpoints)"):
    csrf(same-origin)
    request()
    protect(message: "HTTP origin validation failed", severity: 7)
  endhttp
endapp

In contrast, a traditional RASP solution might use RegEx patterns to detect insecure deserialization attempts. Below is an example of what such a rule might look like:

rule "Detect Insecure Deserialization" {
  match /(?:\bObjectInputStream\b|\bXMLDecoder\b|\breadObject\b|\bfromXML\b)/
  action block
}

Limitations of RegEx-based Rules for Insecure Deserialization

1. Limited Coverage: The above rule attempts to catch instances where deserialization methods like ObjectInputStream, XMLDecoder, readObject, or fromXML are mentioned. However, attackers can use various deserialization techniques and libraries that might not be covered by this pattern.
2. False Positives: Legitimate usage of these methods in safe contexts would also be flagged, resulting in false positives and potentially blocking valid application functionality.
3. Evasion Techniques: Simple obfuscation or using alternative libraries and methods can easily bypass these RegEx-based rules.
4. Lack of Context: RegEx does not understand the context in which these methods are used, leading to inaccuracies. For instance, these methods might be safely used within specific secure implementations that the RegEx cannot discern.

For CSRF protection, it might use a RegEx pattern similar to this:

rule "Detect Missing CSRF Token" {
  match /^(?!.*(\bcsrf_token\b|\b_csrf\b|\bcsrf\b)).*$/
  action block
}

Limitations of RegEx-based Rules for CSRF

1. Limited Coverage: The above rule tries to detect the absence of common CSRF token parameters like csrf_token, _csrf, or csrf. However, it might not cover all variations and custom implementations of CSRF tokens.
2. False Positives: Legitimate requests that do not require CSRF tokens (e.g., GET requests or safe operations) might be incorrectly flagged and blocked.
3. Evasion Techniques: Attackers can rename token parameters or use less common names, bypassing the RegEx detection.
4. Lack of Context: RegEx cannot understand the context of the request, such as whether the request is a state-changing operation that requires a CSRF token or not.

It’s evident that RegEx-based solutions are limited in their ability to provide comprehensive and accurate detection of insecure deserialization attempts. Waratek’s advanced techniques offer a more robust and efficient solution, addressing these inherent weaknesses of traditional RASP methods:

• Context-Aware Detection: Waratek’s data tainting marks all user inputs as “untrusted,” allowing the system to accurately distinguish between trusted and untrusted data flows.
• Precise Threat Detection: Syntax analysis helps identify anomalies in data flow, preventing deserialization attacks without generating false positives.
• Integration with Runtime: Waratek’s approach works within the application’s runtime environment, ensuring real-time protection and minimal performance overhead.

According to research by the SANS Institute, RASP solutions like Waratek’s provide significant advantages in protecting applications from real-time threats. They offer a scalable, efficient, and effective security solution that aligns with modern software development practices, ensuring robust protection without compromising performance​​.

Benefits of Waratek’s Approach

By performing attack analysis in this manner, Waratek avoids all the false-positive risks of heuristic-based approaches, resulting in the following benefits:

1. Immutability

   Immutability is a cornerstone of effective security, ensuring that the protective measures you define remain consistently active, preventing vulnerability regressions with each deployment and user input. Security must be continuous and integrated within the runtime environment to achieve true immutability, rather than being a one-time operation in the CI/CD pipeline. Automating these processes eliminates false positives and negatives, reducing the need for expensive hardware and making security efforts more efficient. This decreased friction enables security teams to scale effectively with modern software development practices for the first time.

2. Scalability

   Cost and human capital are significant barriers to the scalability of current security solutions. Traditional Web Application Firewalls (WAFs) and Runtime Application Self-Protection (RASP) platforms function as massive data pipelines, ingesting, analyzing, and making heuristic-based assumptions on HTTP payloads to assess risk. This reliance on HTTP payloads, which are lagging indicators, leads to a high incidence of false positives and negatives, exacerbating the scalability issues of existing security solutions. To achieve true scalability in security, automation is essential. Just as compilers have automated performance optimization for decades, the same philosophy can be applied to security. By automating the process of patching known vulnerabilities and inserting security rules to block unknown vulnerabilities (zero days), we can eliminate false positives and negatives and reduce the need for expensive hardware.

3. Performance

   While theoretical infallible security solutions might seem ideal, they must also meet real-world business demands. Consequently, many security solutions recommend running in sample mode, protecting only a subset of requests to minimize performance impact. However, this trade-off is unnecessary when your RASP is deeply integrated with applications within the runtime. By adopting principles from compiler design, Software-Defined RASP implementations can achieve comprehensive protection with minimal performance overhead. Software-Defined RASP solutions average less than a 2% performance impact at scale. This allows companies to achieve robust security without compromising on performance, ensuring they can stay both protected and competitive​ (SANS Institute)​​.

By integrating SD-RASP solutions like Waratek’s, organizations can enhance their application security, achieving real-time protection with minimal performance overhead. This approach ensures continuous, context-aware security that scales with modern development practices, providing a robust defense against ever-evolving cyber threats.