Runtime Protection: RASP, WAF and ASLR

Why Runtime Protection Matters
No matter how carefully software is designed, coded and tested, vulnerabilities will reach production. Zero-day flaws, third-party library weaknesses, configuration drift and attacks that only emerge once real users and real adversaries interact with the system all mean that security cannot stop at release. The CSSLP domain Secure Software Deployment, Operations and Maintenance emphasizes that security must be maintained while the software is running. Runtime protection provides this last line of defense: it detects, blocks or neutralizes attacks against deployed software in real time, buying time for patches, reducing the blast radius of exploits, and supporting defense in depth. Three technologies dominate this topic: WAF (Web Application Firewall), RASP (Runtime Application Self-Protection) and ASLR (Address Space Layout Randomization).

What Runtime Protection Is
Runtime protection refers to security controls that operate during execution of the software rather than during development or testing. These controls fall into layers:
• Perimeter / network layer – controls that sit in front of the application and inspect traffic (WAF).
• Application layer – controls embedded in or instrumented into the application itself that understand its logic and data flow (RASP).
• Platform / operating system layer – memory-protection mechanisms provided by the OS and compiler that make exploitation of memory-corruption bugs unreliable (ASLR, along with DEP/NX, stack canaries, CFI).

Web Application Firewall (WAF)
What it is: A WAF is a filtering device or service placed between clients and a web application. It inspects HTTP/HTTPS requests and responses and blocks those that match known attack patterns or violate a defined policy.
How it works:
• Signature / blacklist (negative security model) – matches traffic against known attack patterns such as SQL injection strings, cross-site scripting payloads, path traversal sequences and known exploit kits.
• Whitelist (positive security model) – only permits traffic that conforms to an explicitly defined profile of acceptable input (allowed URLs, parameters, lengths, character sets).
• Anomaly / behavioral detection – learns normal traffic patterns and flags deviations.
• Virtual patching – when a vulnerability is discovered in an application, a WAF rule can be written to block exploitation attempts immediately, protecting the system until the code fix is developed, tested and deployed. This is one of the most frequently tested WAF concepts.
• WAFs commonly implement the OWASP ModSecurity Core Rule Set and are a compensating control recognized by PCI DSS Requirement 6.4 (formerly 6.6) as an alternative to code review for public-facing web applications.
Deployment modes: reverse proxy, transparent bridge/inline, or out-of-band monitoring; cloud WAF services are also common.
Limitations: WAFs lack visibility into application internals, so they generate false positives (blocking legitimate traffic) and false negatives (missing novel or obfuscated attacks, encoding tricks, business-logic flaws). They cannot inspect encrypted traffic unless TLS is terminated at the WAF. They protect only web/HTTP traffic.

Runtime Application Self-Protection (RASP)
What it is: RASP is a technology built into or linked with the application runtime environment (for example via Java agent instrumentation, .NET profiler hooks, or SDK integration). It allows the application to monitor its own execution, detect attacks in context and protect itself.
How it works:
• RASP instruments key points in the application – database calls, file system access, command execution, deserialization, output rendering – and watches how untrusted input actually flows into these sensitive operations.
• Because it sees the actual SQL query being built or the actual system command being executed, it can determine with high confidence whether an input is malicious. For example, if user input changes the structure of a SQL statement, RASP identifies that as injection regardless of how the payload was encoded.
• Modes of operation: monitor (detect/log only) and block/protect (terminate the request, raise an exception, or alert).
• RASP has full application context (user session, code path, data values), so it produces far fewer false positives than a WAF and can detect attacks a WAF cannot, such as insecure deserialization and some logic abuse.
Limitations: Adds performance overhead inside the application; is language/runtime specific; must be deployed with every instance of the application; requires developer/operations coordination; a compromised application may compromise the RASP agent too. RASP is not a substitute for secure coding.
Related concept: IAST (Interactive Application Security Testing) uses similar instrumentation but during testing rather than production; RASP is the production counterpart.

Address Space Layout Randomization (ASLR)
What it is: ASLR is an operating-system memory-protection technique that randomizes the locations in virtual memory where key components of a process are loaded: the executable base, stack, heap, shared libraries/DLLs and memory-mapped regions.
How it works: Many memory-corruption exploits (buffer overflows, use-after-free, format string attacks) depend on the attacker knowing the exact memory address of shellcode, a return address, or a library function (as in return-to-libc or return-oriented programming). By randomizing these addresses each time a process starts, ASLR makes hard-coded addresses fail, turning a reliable exploit into a probabilistic one that usually crashes the process instead of succeeding.
• Works best combined with DEP/NX (Data Execution Prevention / No-eXecute), which marks data pages non-executable so injected shellcode cannot run, forcing attackers toward ROP, which ASLR then frustrates.
• Other complementary mitigations: stack canaries/cookies (/GS), SafeSEH, Control Flow Guard / CFI, PIE (Position Independent Executables), which are required for full ASLR of the main binary on Linux.
• On Windows, ASLR is enabled through the linker flag /DYNAMICBASE; on Linux via kernel setting randomize_va_space and compiling with -fPIE -pie.
Limitations: Effectiveness depends on entropy – 32-bit systems offer few random bits and can be brute-forced; information leakage vulnerabilities (memory disclosure) can reveal addresses and defeat ASLR; all modules must be compiled as ASLR-compatible or a single non-randomized module gives attackers a fixed anchor; it mitigates exploitation but does not remove the underlying bug.

Comparing the Three
• WAF – external, network/HTTP-level, signature or policy based, protects without changing the application, enables virtual patching, higher false positives, web-only.
• RASP – internal, application-level, context-aware, low false positives, requires integration into runtime, protects against injection, deserialization and other application attacks.
• ASLR – OS/compiler-level, memory-protection, defends against exploitation of memory-corruption flaws in native code, transparent to the application once enabled, strongest when paired with DEP/NX.
All three support defense in depth and the CSSLP principle that security controls are layered so that failure of one does not mean compromise of the system.

Where Runtime Protection Fits in the Secure SDLC
Runtime protection belongs to deployment, operations and maintenance, but decisions about it should be made earlier: compiler flags (ASLR, DEP, stack protection) are set during build; RASP agents are chosen during design/implementation; WAF policies are tuned during pre-production testing. Operations teams must monitor logs from WAF and RASP, feed findings back to developers, maintain rule sets, and treat virtual patches as temporary measures pending actual code fixes. Runtime protections also support incident response, providing attack telemetry, and continuous monitoring requirements in frameworks such as NIST SP 800-137 and NIST SP 800-53 (SI-3, SI-4, SI-16).

Exam Tips: Answering Questions on Runtime Protection: RASP, WAF and ASLR
1. Identify the layer. If the question describes inspecting HTTP requests before they reach the application, think WAF. If it describes the application monitoring its own execution or instrumentation within the runtime, think RASP. If it describes randomized memory addresses, defeating buffer overflow or return-to-libc attacks, think ASLR.
2. Virtual patching = WAF. When a question asks for the fastest way to protect a production web application from a newly discovered vulnerability without changing code, the answer is almost always a WAF rule (virtual patch), followed by a proper code fix.
3. Context and low false positives = RASP. If the scenario stresses accurate detection, visibility into actual SQL queries or data flow, or protection that travels with the application, choose RASP.
4. ASLR pairs with DEP/NX. Questions on memory-corruption mitigations often expect you to recognize that ASLR alone is incomplete; DEP/NX, stack canaries and CFI are complementary. Also remember ASLR is weakened by low entropy (32-bit) and information-leak vulnerabilities.
5. Compensating control questions. PCI DSS allows a WAF as an alternative to application code review for public-facing web apps – recognize the WAF as a compensating control, not a replacement for secure coding.
6. Watch for "not a substitute" distractors. The CSSLP exam favors answers that treat runtime protection as part of defense in depth. Any option claiming a WAF, RASP or ASLR eliminates the need to fix the code or perform security testing is wrong.
7. Know limitations. Expect questions on why a WAF missed an attack (encrypted traffic, encoding/obfuscation, business-logic flaw) or why ASLR failed (a non-ASLR module, address leak, brute force on 32-bit).
8. Choose the "best" answer using CSSLP priorities. When multiple options seem correct, prefer the one that is risk-based, layered, aligned with the SDLC and includes monitoring and feedback to developers.
9. Terminology precision. Do not confuse RASP (production self-protection) with IAST (testing-time instrumentation), or a WAF (layer 7 application filter) with a traditional network firewall or IDS/IPS.
10. Remember the build-time link. ASLR, DEP and stack protection are enabled through compiler/linker settings (/DYNAMICBASE, /NXCOMPAT, /GS, -fPIE, -fstack-protector); questions may frame these as secure build or hardening tasks.

Key Takeaways
Runtime protection acknowledges that vulnerabilities will exist in production and provides layered defenses to detect and block their exploitation. WAFs filter malicious web traffic at the perimeter and enable virtual patching; RASP gives applications contextual self-defense with high accuracy; ASLR, with DEP/NX and related mitigations, makes memory-corruption exploits unreliable. For the CSSLP exam, map each scenario to the correct layer, remember each technology's strengths and weaknesses, and always frame runtime protection as a complement to, never a replacement for, secure design, coding and testing.