Article

The Fork in the Road: Prioritizing Application Vulnerabilities vs. Runtime Protection

In the relentless pursuit of secure applications, security teams face a critical decision: where to focus their investments in time and resources. The result is the emergence of two distinct philosophies, each offering a unique approach to mitigating application risks.

One camp emphasizes the never-ending identification and prioritization of vulnerabilities for remediation, aiming to fix flaws at the source. The other champions instant application remediation through Runtime Application Self-Protection (RASP) that shields applications in real-time and neutralizes threats as they occur. While both aim for the same ultimate goal – secure applications – their methodologies, strengths, and weaknesses differ significantly.

The Traditional Approach to Vulnerability Remediation

The road often taken centers around identifying vulnerabilities before an application enters production or before they can be exploited as the app runs. This involves a range of security testing tools, including Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA). These tools scan application code, running applications, and their dependencies to uncover potential weaknesses, generating a list of vulnerabilities that need to be addressed.

The crucial next step is prioritization. In the traditional mode, remediation efforts tend to focus on the most critical risks based on factors like severity, exploitability, and business impact. The strength of this approach lies in its active nature.

By identifying and fixing vulnerabilities early in the Software Development Life Cycle (SDLC), organizations can prevent them from ever being exploited in a production environment. This “shift left” strategy aims to build security into the application from the ground up, reducing the attack surface and minimizing the potential for breaches. Understanding the root cause of vulnerabilities also allows development teams to learn from past mistakes and write more secure code in the future.

However, this approach also faces significant challenges. The sheer volume of vulnerabilities identified by scanning tools can be overwhelming, complicating the prioritization decision.

Remediation can be time-consuming and resource-intensive, too, often requiring significant code changes and retesting. Even with rigorous testing, it’s virtually impossible to identify every single vulnerability. New threats and zero-day exploits can emerge after deployment, rendering previously secure applications vulnerable.

The RASP Approach

In contrast to the traditional find & fix approach to vulnerability remediation, RASP takes a different tack. Instead of focusing solely on pre-production vulnerability identification and remediation, RASP embeds security directly within a running application.

RASP agents monitor application behavior in real-time, analyzing traffic, user input, and system interactions to detect and block malicious activity. When a potential attack is detected, RASP can take immediate action, such as blocking the request, terminating the session, as well as virtually patching a vulnerability in real-time without requiring code changes.

The value of RASP lies in its ability to provide immediate protection against both known and unknown threats. It acts as a last line of defense, safeguarding applications even if vulnerabilities slip through pre-production testing or when zero-day exploits emerge.

Instant application remediation capabilities, while still evolving, offer the promise of automatically mitigating certain types of attacks without requiring manual intervention or downtime. This can be particularly valuable for legacy applications where code changes are difficult, risky, or both.

Waratek’s RASP Approach

Waratek Secure takes a new approach to providing runtime protection for applications today. Central to Waratek’s approach is the utilization of non-heuristic detection techniques for code-injection attacks based on two features: data tainting & syntax analysis.

Waratek deliberately chose not to use existing heuristics-based techniques for detecting code-injection attacks as used by Web Application Firewalls (WAFs), 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 as “untrusted” all user-input data to a Java app (like HTTP request parameters). 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.

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

  • Immutability – Ensuring that the protective measures you define remain consistently active, preventing vulnerability regressions with each deployment and user input.
  • Scalability – The key to improving security scalability is to automate the process of patching code.
  • Performance – Waratek Secure averages less than a percentage performance impact at scale.

Is there a Best Approach?

So, which approach to prioritization is better – traditional or RASP-based? The reality is that the two approaches are complementary and address different stages of the application security lifecycle.

Prioritizing and remediating vulnerabilities in pre-production helps to reduce the attack surface from the start, while RASP provides a critical safety net for in-production apps. Waratek Secure offers immediate protection against threats that were missed during testing or those that emerge after deployment.

Instead of viewing these as mutually exclusive options, security teams should strive for a holistic approach that leverages the strengths of both. The fork in the road doesn’t always require a single path; often, the most secure journey involves traveling both.

Related resources

Ready to scale Security with modern software development?

Work with us to accelerate your adoption of Security-as-Code to deliver application security at scale.