A RASP Journey To Level 1 Device Security

A RASP Journey To Level 1 Device Security

Speakers: Shane Fry

Conference: S4

YouTube: https://www.youtube.com/watch?v=bOcj9-ETgXo

Overview

Shane Fry's talk, "A RASP Journey To Level 1 Device Security," delivered at S4, starkly illuminated the escalating crisis of memory safety vulnerabilities, particularly within the Operational Technology (OT) and Industrial Control Systems (ICS) domains. Fry presented a sobering analysis, demonstrating that despite advancements in secure software development lifecycles, these critical flaws are not only persisting but growing in number and impact. The core message is clear: existing defensive strategies—ranging from static and dynamic analysis tools to software bill of materials (SBOMs) and even next-generation programming languages—are proving inadequate against the relentless tide of memory safety exploits in systems that underpin critical infrastructure.

The talk makes a compelling case for a paradigm shift in how we approach device security, advocating for the adoption of Runtime Application Self-Protection (RASP). Fry argues that while traditional measures focus on prevention and detection during development or external monitoring, RASP offers a crucial last line of defense by embedding security directly within the running application. This becomes especially pertinent for the OT/ICS sector, where legacy systems, difficult patching cycles, and the severe consequences of compromise demand a more robust, in-situ protection mechanism. The presentation serves as a critical call to action for device manufacturers and asset owners to re-evaluate their security posture and embrace innovative solutions to protect against increasingly sophisticated threats.

Background

▶ Watch: Introduction: The alarming rise of memory safety vulnerabilities (0:00)

The landscape of software security is fraught with challenges, but few are as persistent and impactful as memory safety vulnerabilities. Shane Fry’s presentation underscores that these aren't merely abstract theoretical flaws; they are fundamental bugs in software that can lead to catastrophic consequences, including logic errors, remote control of devices, and denial-of-service (DoS) attacks. In the context of critical infrastructure, such as manufacturing plants, water systems, or substations, these vulnerabilities pose an existential threat, potentially allowing attackers to manipulate industrial processes, disrupt essential services, or cause widespread outages.

Fry highlighted the alarming prevalence of memory safety issues, noting that specific Common Weakness Enumerations (CWEs) like buffer overflows, use-after-frees, heap-based buffer overflows, and out-of-bounds writes constitute a significant portion of exploited vulnerabilities. According to Mitre, five of the top ten most exploited CWEs in 2023 were memory safety related. Furthermore, these vulnerabilities are exceptionally "stubborn," appearing among the top 15 most persistent CWEs over the last four years, indicating their long lifecycle within deployed software.

The talk meticulously dissects why conventional security practices are failing to stem this tide:

1. Ineffectiveness of Current SDLC Practices: Despite increased emphasis on Secure Software Development Life Cycles (SSDLC), including code reviews and static/dynamic analysis, the number of memory safety vulnerabilities continues to rise. This paradox suggests a fundamental flaw in our current approaches.
2. Human Error: Fry emphasizes that any process heavily reliant on human input—from manual code reviews to the configuration of Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools, and even the selection of third-party dependencies—is inherently prone to human error. This human element is a significant contributor to vulnerabilities making it into production code.
3. Limitations of Scanning Tools: A particularly stark statistic from NC State University research revealed that over a 15-year period across ten open-source packages, a staggering 97.5% of identified bugs were never flagged as potential issues by code scanning tools. This highlights a massive blind spot in current automated analysis capabilities.
4. Challenges with Software Bill of Materials (SBOMs): While SBOMs are crucial for supply chain transparency, their current implementation often creates new problems. One unnamed large company, after generating an SBOM for a single product, saw its tracked vulnerabilities skyrocket from a single-digit number to over a thousand, many of which were false positives. This creates an overwhelming burden for triage and remediation, diverting resources from actual threats.
5. Cost and Disruption of Patching: Patching every vulnerability is costly, time-consuming, and disruptive to both developers (who want to focus on new features) and asset owners (who must take systems offline). In the OT/ICS space, patching is notoriously difficult due to system criticality, long update cycles, and validation requirements.
6. Inadequacy of Next-Gen Languages and Hardware: While languages like Rust and Golang are promoted for their memory safety features, Fry points out that they are not a panacea. They can still have memory safety issues, and their dependencies might contain unsafe code. Furthermore, rewriting existing codebases in these languages is a monumental, time-consuming task for teams accustomed to C/C++. Advanced hardware solutions like Arm's Morello chip with Cherry, while promising, are years away from commercial availability and widespread adoption in existing OT/ICS supply chains.
7. Performance Overhead of Compiler Mitigations: Techniques like Control Flow Integrity (CFI) can enhance security but often come with significant performance overhead—up to 25% processor utilization—which is unacceptable for many resource-constrained OT/ICS devices. Moreover, CFI implementations can break existing software, making them impractical for out-of-the-box deployment.

Crucially, Fry debunks the notion that ICS is "different" in a good way, presenting data that shows it's actually worse. While Microsoft and Google report 40-70% of their bugs are memory safety related, Fry's analysis of CVE data for five top-tier ICS device manufacturers over eight years revealed that 72% of their vulnerabilities are memory safety related. This alarming statistic, coupled with an average of 140 days for ICS vendors to release a patch (compared to much shorter cycles in IT), underscores the urgent need for a more effective and immediate defense strategy.

Key Findings

▶ Watch: Limitations and costs of traditional patching and SDLC (2:20)

Shane Fry's talk presented several critical findings that collectively paint a concerning picture of the state of security in OT/ICS, while also highlighting a promising path forward:

• Memory Safety Vulnerabilities are Worsening, Not Improving: Despite increased investment in secure development practices and tools over the past decade, memory safety vulnerabilities continue to show a linear, if not exponential, growth. This indicates that current strategies are failing to keep pace with the problem.
• OT/ICS Is Disproportionately Affected: Contrary to common assumptions, the OT/ICS sector is more susceptible to memory safety issues than the IT sector. While leading IT companies like Microsoft and Google report 40-70% of their bugs as memory safety related, Fry's research into top ICS manufacturers revealed that 72% of their vulnerabilities fall into this category.
• Traditional Security Tools Have Massive Blind Spots: Research from NC State University highlighted a shocking deficiency in SAST and DAST tools, finding that 97.5% of bugs identified in open-source software over a 15-year period were never detected by these automated scanning tools. This implies a vast "unknown world" of exploitable vulnerabilities.
• Patching Cycles in ICS are Dangerously Slow: A study by Trend Micro indicated that ICS vendors average 140 days from vulnerability discovery to patch release. This extended window leaves critical infrastructure exposed for prolonged periods, especially if a vulnerability becomes publicly known.
• Human Error is a Pervasive Weakness: The entire secure software development lifecycle, from code review to tool configuration and dependency selection, is heavily reliant on human input, making it susceptible to human error. This fundamental flaw contributes significantly to the persistence of vulnerabilities.
• Current "Solutions" Are Not Immediately Viable for OT/ICS: While new programming languages (Rust, Golang) offer memory safety benefits and hardware-based protections (Arm's Morello/Cherry) are on the horizon, they are not practical immediate solutions for existing OT/ICS deployments due to the immense effort of code rewrites, lack of hardware availability, or unacceptable performance overheads (e.g., 25% CPU for CFI).
• SBOMs Present Management Challenges: While valuable for transparency, SBOM generation can overwhelm organizations with a massive increase in reported vulnerabilities (over a thousand for a single product in one instance), often including many false positives, making effective triage and remediation extremely difficult.

Technical Deep Dive

▶ Watch: Human error: The inherent flaw in current processes (3:40)

The core technical argument of Shane Fry's presentation, while not detailing a specific RASP product's architecture, centers on the necessity and conceptual advantages of Runtime Application Self-Protection (RASP) as a defense mechanism against memory safety vulnerabilities, particularly in the challenging OT/ICS landscape. RASP operates fundamentally differently from traditional security tools by embedding security directly within the application's runtime environment.

To understand RASP's proposed value, it's crucial to contrast it with the limitations of existing approaches:

1. Pre-Runtime Analysis (SAST/DAST):

• SAST (Static Application Security Testing): Tools like Fortify or Checkmarx analyze source code or compiled binaries without executing them. They look for patterns indicative of vulnerabilities. The major drawback, as highlighted by the NC State University research, is their significant inability to find real-world bugs, missing 97.5% of identified vulnerabilities in open-source software. This is due to the complexity of code paths, context sensitivity, and the difficulty in distinguishing between benign and malicious code flows statically.
• DAST (Dynamic Application Security Testing): Tools or techniques like fuzzing and penetration testing involve executing the application and interacting with it to find vulnerabilities. While more effective than SAST for certain bug classes, DAST relies on test coverage and often fails to uncover deep-seated memory corruption issues that are only triggered under specific, complex runtime conditions not easily simulated by testing. Both SAST and DAST are "shift-left" approaches, aiming to find bugs early, but they are clearly insufficient.

1. Network-Based Defenses:

• Intrusion Detection/Prevention Systems (IDS/IPS) and Web Application Firewalls (WAFs): These operate at the network perimeter or application gateway, inspecting network traffic for malicious payloads or anomalous behavior. While valuable, they are external to the application logic. Attackers can often craft payloads that bypass these external defenses, especially if the vulnerability resides in how the application processes legitimate-looking but malformed input internally. They cannot see or prevent memory corruption happening inside the application's process space.

1. Operating System (OS) and Compiler-Level Mitigations:

• Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Stack Canaries: These are OS-level protections designed to make exploitation harder by randomizing memory locations or preventing code execution from data segments. However, attackers continuously find ways to bypass or chain these mitigations, often through information leaks or by leveraging other vulnerabilities.
• Control Flow Integrity (CFI): This compiler-level technique aims to ensure that the execution flow of a program adheres to a pre-determined, valid graph. It can detect and prevent unauthorized jumps or calls that exploit memory corruption to hijack execution. However, as Fry noted, current CFI implementations often incur a significant performance overhead (up to 25% CPU) and can lead to software incompatibility or breakage, making them impractical for many existing, resource-constrained OT/ICS devices where stability and performance are paramount.

RASP, in contrast, is designed to overcome these limitations by instrumentation within the application. Conceptually, a RASP solution would:

• Monitor Application Execution: It observes the application's behavior from the inside, including function calls, memory allocations, data access, and API interactions.
• Detect Anomalous Behavior: By understanding the application's legitimate flow and data boundaries, RASP can detect deviations that indicate an attack. For memory safety, this means identifying attempts to write beyond buffer boundaries, use memory after it's been freed, or execute arbitrary code.
• Prevent Exploitation: Upon detecting an attack, RASP can take immediate action to prevent the exploit from succeeding. This might involve terminating the problematic request, sanitizing input, or even stopping the application process to prevent further damage.
• Provide Real-time Protection: Unlike pre-runtime tools, RASP protects the application as it runs, offering a dynamic defense against both known and unknown (zero-day) vulnerabilities that leverage memory corruption.
• No Code Changes (Ideally): A key benefit for legacy systems is the ability to deploy RASP without requiring source code modifications or recompilation. This is often achieved through bytecode instrumentation, binary patching, or hooking mechanisms at the OS or virtual machine level.

For OT/ICS, RASP's promise is particularly compelling. Given the prevalence of legacy code written in C/C++, the difficulty of patching, the long operational lifecycles, and the high impact of compromise, RASP offers a way to inject modern security protections into existing, "brownfield" deployments. It acts as an internal guardian, capable of stopping attacks that have bypassed external defenses and slipped through development-phase checks, providing a critical layer of defense at "Level 1 Device Security" – directly on the endpoint where the industrial process occurs. While Fry did not detail a specific RASP architecture, the implication is a solution that is lightweight enough for embedded systems, robust enough for industrial environments, and capable of operating with minimal performance impact.

Demo / Proof of Concept

▶ Watch: Shocking stat: Scanners miss 97.5% of bugs (4:20)

The talk did not include a live demonstration or a detailed proof-of-concept of a specific RASP solution. Instead, the speaker focused on the urgent need for such technologies by highlighting the widespread and persistent nature of memory safety vulnerabilities in critical infrastructure and the limitations of existing security measures.

Defensive Implications

▶ Watch: S-bomb paradox: Overwhelming vulnerabilities and false positives (5:10)

The insights presented by Shane Fry carry profound defensive implications for organizations operating in the OT/ICS space, demanding a re-evaluation of current security strategies and a proactive embrace of advanced protection mechanisms.

1. Prioritize Runtime Protection with RASP: The most critical implication is the urgent need to adopt Runtime Application Self-Protection (RASP). Given the demonstrated failure of pre-runtime tools (missing 97.5% of bugs), the slow patching cycles (140 days average for ICS), and the difficulty of patching in OT environments, RASP offers a crucial, embedded layer of defense. Defenders should actively research and implement RASP solutions that can monitor and protect critical applications from memory safety vulnerabilities in real-time, without requiring source code modification or significant performance overhead. This is especially vital for legacy systems where rewriting code or extensive patching is infeasible.
2. Acknowledge and Mitigate Human Error in SDLC: While RASP provides runtime protection, organizations must continue to improve their Secure Software Development Life Cycles (SSDLC). However, it's imperative to acknowledge the inherent fallibility of human processes. This means investing in automated tools that are more effective than current SAST/DAST (if such tools exist or improve), but more importantly, designing processes that minimize human intervention in critical security decisions. Training developers to write memory-safe code is essential, but RASP serves as a safety net for when human error inevitably occurs.
3. Strategically Leverage SBOMs: While SBOMs are mandated and provide valuable supply chain visibility, defenders must approach them with a clear understanding of their current limitations. Organizations should develop robust processes to filter false positives and prioritize the overwhelming number of reported vulnerabilities. The focus should be on actionable intelligence rather than simply tracking raw numbers. Integrating SBOM data with runtime protection solutions like RASP could help validate whether reported vulnerabilities are actually exploitable in a specific operational context.
4. Demand Faster Patching and Secure-by-Design from Vendors: Asset owners must exert pressure on their OT/ICS vendors to significantly reduce patch delivery times. A 140-day average is unacceptable in today's threat landscape. Furthermore, vendors should be encouraged, or even mandated, to integrate advanced security controls like RASP directly into their products, moving towards a truly secure-by-design philosophy rather than relying solely on post-deployment patching.
5. Address the OT/ICS Specificity: The finding that 72% of OT/ICS vulnerabilities are memory safety related, compared to 40-70% in IT, necessitates a tailored security approach. Generic IT security solutions may not be adequate. OT/ICS security strategies must be specifically designed to address the unique characteristics of industrial systems, including their long lifecycles, resource constraints, and critical operational requirements.
6. Evaluate Performance Critically: When considering any new security technology, especially RASP or compiler-level mitigations like CFI, rigorous performance testing in realistic OT/ICS environments is crucial. Solutions that introduce unacceptable latency or CPU overhead will not be adopted or will compromise operational stability. The goal is robust security without compromising the primary function of the industrial control system.

Key Takeaways

• Memory safety vulnerabilities are a worsening and pervasive threat in software, exhibiting linear to exponential growth despite current secure development practices.
• OT/ICS environments are significantly more susceptible to memory safety issues, with 72% of vulnerabilities in top ICS vendors being memory safety related, compared to 40-70% in IT.
• Traditional security tools and practices are failing: SAST/DAST tools miss 97.5% of real-world bugs, SBOMs create overwhelming triage challenges, and patching in OT/ICS is slow (140-day average) and disruptive.
• Human error is a critical, unavoidable factor in the secure software development lifecycle, contributing to the persistence of vulnerabilities.
• Next-generation languages (Rust, Golang) and hardware (Arm Morello/Cherry) are not immediate solutions for the vast installed base of legacy OT/ICS devices.
• Runtime Application Self-Protection (RASP) offers a vital, immediate defense mechanism by protecting applications from memory safety exploits from within, without requiring extensive code changes or high performance overheads common to other mitigations.

About the Speaker(s)

Shane Fry is a seasoned professional in the cybersecurity industry with extensive experience in vulnerability research. He has spent a considerable part of his career dissecting security flaws and understanding the dynamics of cyber threats across various industries. His insights are informed by a long tenure in the field, contributing to a deep understanding of the challenges organizations face in securing their digital assets, particularly within critical infrastructure domains.