Fault Injection and Stress Testing

Why Fault Injection and Stress Testing Matter
Most functional testing confirms that software does what it is supposed to do under normal, expected conditions. Attackers, however, do not operate under normal conditions. They deliberately supply malformed data, exhaust resources, trigger timing anomalies, and provoke error paths that developers rarely exercise. Fault injection and stress testing exist to answer a critical security question: How does the software behave when things go wrong?

In the CSSLP Secure Software Testing domain, these techniques are tied directly to core security principles such as fail secure (the system should default to a safe state when it fails), resilience, and availability (the "A" in the CIA triad). A system that leaks sensitive data in a stack trace, grants access when an authentication service times out, or crashes into an exploitable state under load has a security defect even if every functional requirement passes. These tests uncover those defects before an adversary does.

What Is Fault Injection?
Fault injection is a testing technique in which errors, faults, or abnormal conditions are deliberately introduced into a system to observe how it responds. The goal is to validate error handling, exception management, recovery mechanisms, and fail-secure behavior. Rather than waiting for a rare fault to occur naturally, the tester forces it to happen.

Common categories of fault injection include:
• Software fault injection – modifying code, return values, or program state at runtime (e.g., forcing a function to return an error code, corrupting a memory value, throwing an exception in a dependency).
• Hardware fault injection – introducing physical anomalies such as voltage glitches, clock manipulation, or electromagnetic interference, often used against embedded systems and smart cards to bypass security checks.
• Environmental / resource fault injection – simulating disk-full conditions, lost network connectivity, DNS failures, unavailable databases, expired certificates, or denied file permissions.
• Interface / input fault injection – supplying invalid, malformed, unexpected, or boundary-violating inputs at APIs and interfaces. This overlaps heavily with fuzz testing, which is essentially automated input fault injection using random or semi-random data.
• Compile-time vs. runtime injection – faults can be inserted into source code before compilation (mutation-style) or injected into a running process using debuggers, hooks, or instrumentation tools.

What Is Stress Testing?
Stress testing evaluates how software behaves when pushed beyond its normal operating limits. Where load testing checks performance at expected volumes, stress testing deliberately exceeds those volumes to find the breaking point and, more importantly for security, to observe what happens at and after that breaking point.

Key questions stress testing answers:
• Does the application degrade gracefully or crash abruptly?
• When it fails, does it fail secure (deny access, protect data) or fail open (bypass controls)?
• Are there race conditions, deadlocks, or time-of-check/time-of-use (TOCTOU) flaws that only appear under concurrency?
• Do resources leak (memory, handles, connections) in a way that enables denial of service?
• Does error output under load expose sensitive information?

Related terms you should distinguish:
• Load testing – measures behavior at expected or peak expected load.
• Stress testing – pushes beyond expected load to find limits and failure behavior.
• Soak / endurance testing – sustains load over a long period to detect leaks and degradation.
• Spike testing – applies sudden, extreme surges in demand.
• Volume testing – tests with very large data sets rather than high request rates.

How Fault Injection Works in Practice
1. Identify fault targets. Use threat models, architecture diagrams, and data flow analysis to find trust boundaries, external dependencies, error-handling code, and security-critical decisions (authentication, authorization, cryptographic validation).
2. Define the fault hypothesis. State what fault will be introduced and what the expected secure behavior is (e.g., "If the authorization service is unreachable, the request must be denied and logged").
3. Inject the fault. Techniques include mocking dependencies to return errors, using tools to corrupt memory or alter return values, cutting network connections, filling disks, manipulating system clocks, or sending malformed inputs.
4. Observe and record behavior. Capture logs, error messages, system state, resource consumption, and whether security controls remained enforced.
5. Evaluate against fail-secure principles. A defect exists if the system grants access, leaks data, exposes internal details (stack traces, paths, versions), enters an undefined state, or fails to log the event.
6. Remediate and retest. Fix exception handling, add proper defaults, sanitize error output, and re-run the injection to confirm.

Fault injection is also the foundation of chaos engineering, where faults are injected into production or production-like environments to verify resilience at the system level.

How Stress Testing Works in Practice
1. Establish baselines. Determine normal and peak expected load from requirements and operational data.
2. Define security-relevant success criteria. Beyond response times, specify that authentication must never be bypassed, sessions must not be shared or mixed, and errors must not disclose sensitive data.
3. Ramp load beyond limits. Use load-generation tools to exceed concurrent users, transactions, bandwidth, or data volume thresholds, including sudden spikes.
4. Monitor for security symptoms. Watch for memory exhaustion, handle leaks, deadlocks, thread starvation, race conditions, authentication timeouts that default to allow, cache poisoning under contention, and verbose error pages.
5. Test recovery. Remove the stress and verify the system returns to a correct, secure state without lingering corruption or orphaned privileged sessions.
6. Document and remediate. Findings typically lead to rate limiting, resource quotas, connection pooling fixes, proper locking, circuit breakers, and improved exception handling.

Security Defects Commonly Revealed
• Fail-open conditions when a security dependency is unavailable.
• Information disclosure through unhandled exceptions and verbose errors.
• Denial of service via resource exhaustion or unbounded allocation.
• Race conditions and TOCTOU vulnerabilities under concurrency.
• Improper state after partial failure (e.g., half-completed transactions leaving inconsistent authorization data).
• Missing or incomplete logging of error and failure events, undermining accountability.
• Buffer overflows and memory corruption triggered by malformed inputs.

Where These Fit in the Secure SDLC
Fault injection and stress testing are primarily performed during the testing phase but are informed by earlier phases: threat models identify what faults matter, security requirements define expected fail-secure behavior, and design reviews identify dependencies to target. Results feed back into defect tracking and risk acceptance decisions. They complement, but do not replace, static analysis, code review, penetration testing, and functional security testing.

Exam Tips: Answering Questions on Fault Injection and Stress Testing
1. Know the core purpose. If a question asks which technique validates error-handling, exception management, or fail-secure behavior, the answer is almost always fault injection. If it asks about behavior beyond capacity limits or availability under extreme conditions, think stress testing.
2. Distinguish load vs. stress vs. soak. Load = expected conditions; stress = beyond limits to find the breaking point; soak/endurance = prolonged duration to find leaks. Questions often hinge on the word "beyond" or "exceed."
3. Connect to fail secure. The CSSLP consistently favors answers where the system denies access, protects data, and logs the event upon failure. If an option describes a system granting access when a control is unavailable, that is the defect, not the desired behavior.
4. Recognize fuzzing as a form of fault injection. Fuzz testing is input-focused fault injection. If the question describes random or malformed input supplied automatically, fuzzing is the specific answer; if it describes forcing error conditions, timeouts, or dependency failures, fault injection is the broader answer.
5. Link stress testing to the CIA triad. Stress testing primarily supports availability, but remember it also uncovers confidentiality issues (verbose errors) and integrity issues (race conditions, corrupted state).
6. Watch for "deliberately" and "intentionally." These words signal fault injection—the tester introduces faults on purpose rather than waiting for them to occur.
7. Hardware fault injection appears in embedded and smart card contexts. Voltage glitching, clock manipulation, and electromagnetic interference used to bypass security checks are hardware fault injection, not stress testing.
8. Recovery matters. Questions may ask what to verify after a stress or fault scenario ends. The best answer includes confirming the system returns to a correct, secure state with no lingering compromise.
9. Think "most secure" and "best" answers. When multiple options seem valid, choose the one that validates security behavior (fail secure, no information leakage, proper logging) over the one that only measures performance.
10. Eliminate distractors. Options referencing code review, static analysis, or requirements traceability are generally wrong for questions specifically about runtime behavior under faults or extreme load. Penetration testing is broader and attacker-focused; fault injection and stress testing are targeted, controlled techniques.

Quick Review Summary
• Fault injection: deliberately introduce faults to test error handling, exception management, recovery, and fail-secure behavior; includes software, hardware, environmental, and input (fuzzing) variants.
• Stress testing: push beyond normal limits to discover breaking points, resource exhaustion, race conditions, and failure behavior; primarily supports availability.
• Both are about behavior when things go wrong, and the exam expects the secure outcome to be: deny by default, protect data, avoid information disclosure, log the event, and recover to a known-good state.