Runtime Security Definition Document v1.1
Essential Definition and Technical Framework of Runtime Security
v1.1 (Fully Integrated Edition) · March 2025 · Public Edition
§1Conceptual Definition
§1.1Single-Sentence Definition of Runtime Security
Runtime Security: A technology framework that detects attacks, anomalies, and unauthorized activities in real time during runtime — the state in which a processor executes its instruction set (ISA) and program code and execution data are loaded into RAM — and maintains system controllability.
§1.2Expanded Definition: Detection-Based Protection
Essential Definition of Runtime
"Runtime" as used herein refers to any execution state in which a processor executes its instruction set (ISA) and program code and execution data are loaded into RAM (memory). This definition is domain-agnostic and time-independent.
§1.3Three Design Principles of Runtime Security
Principle 1: Detection-Driven Approach
Detection of attacks, anomalies, and unauthorized activities serves as the starting point for security measures. Based on the premise that no response occurs without successful detection, detection accuracy and speed are given the highest priority. The existence of detection gaps is acknowledged, and coordination with detection-independent structural protection (Runtime Immunity) is designed into the architecture.
Principle 2: Dynamic Control and Constraint
After detection, the behavior of attack processes is directly constrained, and response is executed without halting the entire system. Graduated and dynamic control measures — including process isolation, resource limitation, communication blocking, and file access control — enable flexible response to attacks.
Principle 3: Real-Time Responsiveness
Minimizing the time between attack detection and response execution is a design goal. Shorter response times reduce both the probability of attack success and the scale of damage.
§1.4Position within Runtime Stability and Contribution to 7 Attributes
Runtime Security is positioned as detection-based protection within the Runtime Stability framework.
Table 1: Runtime Security's Contribution to the 7 Attributes
| Attribute | Contribution | Runtime Security's Role | Relationship with Runtime Immunity |
|---|---|---|---|
| Safety | ★★★★★ | Detects dangerous control operations and forces safe-side transitions | Coordinates with structural safety design |
| Reliability | ★★★★☆ | Continuous monitoring of protection functions and fault detection | Coordinates with automatic recovery mechanisms |
| Availability | ★★★★★ | Blocks attack propagation and maintains service continuity | Primary responsibility of Security |
| Controllability | ★★★★★ | Maintains system controllability even under attack | Coordinates with state awareness mechanisms |
| Confidentiality | ★★★☆☆ | Detects and restricts access to confidential data | Fundamental protection through encryption |
| Data Integrity | ★★★☆☆ | Detects and prevents data tampering operations | Coordinates with tamper-proof structures |
| Inexploitability | ★☆☆☆☆ | Effective in coordination with Immunity | Structure-based protection is primary |
⚠️ NOTICE: Regarding Inexploitability: It is difficult for Runtime Security alone to achieve Inexploitability. Only through the coordination of Security's "detection and control" with Immunity's "structural nullification" can Inexploitability be realized at a high level.
§2Problems Addressed
§2.1Limitations of Conventional (Perimeter-Centric) Security
From the 20th century through the early 21st century, the majority of security relied on "perimeter defense." Firewalls, VPNs, and DMZs protected physical and logical boundaries, and everything inside was considered "safe."
However, in modern computing environments — particularly cloud, container, and microservice architectures — this premise no longer holds. Boundaries become ambiguous due to scalability requirements, internal communication increases, and once penetrated, control becomes difficult.
Runtime Security fills this gap as a technology that directly protects the "post-intrusion runtime environment."
§3Technical Definition
§3.1Implementation Forms and Detection Logic
Runtime Security implementation methods are classified by combinations of protection targets and detection technologies.
§3.2Four Implementation Forms
Form 1: Process Memory Monitoring
Uses kernel-level and user-level hooking mechanisms such as eBPF, kprobes, and uprobes to monitor process memory access and detect anomalous memory operations. Provides high detection accuracy with relatively low system overhead. Examples: Falco, Tetragon.
Form 2: Runtime Application Self-Protection (RASP)
Embeds protection capabilities within the application layer, detecting and responding to threats directly from executing code. Enables deep integration with application languages and frameworks for high-precision detection. Examples: Contrast Security, Rapid7 AppSpider.
Form 3: Cloud Workload Protection Platform (CWPP)
Monitors the execution state of entire workloads — virtual machines, containers, pods — and detects process, network, and file access activities. Supports dynamic scaling in cloud environments. Examples: Palo Alto Prisma Cloud, Aqua Security.
Form 4: Endpoint Detection and Response (EDR)
Monitors process, network, and file operations across entire endpoints (nodes), detecting threats through Indicators of Compromise (IoC) and anomaly detection. Records past process execution history, enabling root cause analysis during incidents. Examples: CrowdStrike Falcon, Microsoft Defender ATP.
§4Relationship with Existing Technologies
§4.1Relationship with RASP, CWPP, and EDR
RASP (Runtime Application Self-Protection), CWPP (Cloud Workload Protection Platform), and EDR (Endpoint Detection and Response) are all implementation forms of Runtime Security.
§5Achievement Evaluation Framework
§5.1Runtime Security Level (SL-0 to SL-3) and Three-Axis Evaluation
Core Change: Expansion of SL Evaluation to Three Axes
Conventional security evaluation often relies solely on "Recall (detection rate)," which is insufficient. By simultaneously evaluating Precision and Response Latency, the complete picture of implementation quality can be assessed.
Axis 1: Recall
- Definition: The proportion of actual threats that were detected
- Formula: Recall = (Threats Detected) / (Actual Threats)
- Significance: Measures whether threats are being missed
Axis 2: Precision
- Definition: The proportion of detections that were actual threats
- Formula: Precision = (True Threats) / (Total Detections)
- Significance: Prevents Alert Fatigue
Axis 3: Response Latency
- Definition: Time from threat detection to response execution
- Significance: Faster response minimizes damage
§5.2SL Level Definitions
| Level | Recall | Precision | Response Latency | Description |
|---|---|---|---|---|
| SL-0 | < 50% | Any | Any | No runtime protection |
| SL-1 | ≥ 50% | ≥ 30% | < 60s | Basic Detection |
| SL-2 | ≥ 80% | ≥ 60% | < 10s | Multi-Layer Detection |
| SL-3 | ≥ 95% | ≥ 85% | < 1s | Integrated Detection |
§5.3RS-6 (Maximum Level) Limitations and Notes
⚠️ NOTICE: RS-6 Definition and Limitations:
- ✅ RS-6 = "Maximum feasible protection"
- ❌ RS-6 ≠ "Complete protection"
- 100% detection of 0-day attacks is not practically achievable
- Physical access attacks, quantum computer attacks, and side-channel attacks are outside the scope of this definition
- Validity period: 2025–2030 (Classical Cryptography Era). Post-Quantum adaptation is required after 2030
§6Application Domains
Runtime Security applies to the protection of running processes across all computing environments.
- Cloud environments (AWS, Azure, GCP managed services)
- Container orchestration (Kubernetes)
- Autonomous vehicles and connected cars
- Medical devices and healthcare information systems
- Critical systems in financial institutions
§7Glossary
- Runtime Security Level (SL): Detection- and control-based protection level (0–3)
- Recall: The proportion of actual threats that were detected
- Precision: The proportion of detections that were actual threats
- Response Latency: Time from detection to response
- Runtime Stability Level (RS): Integrated level combining SL and IL
§8Revision History
- v1.0 (March 2025): Initial release
- v1.1 (March 2025) Precision Edition: Expanded SL evaluation to 3-axis (Recall + Precision + Latency). Documented RS-6 limitations.
- v1.1 (March 2025) Fully Integrated Edition: Integrated v1.1 revisions into the complete v1.0 body.
§9About This Document
§9.1Purpose
This definition document establishes the essential definition of Runtime Security and systematically positions existing security technologies (RASP, CWPP, EDR, etc.) within the Runtime Stability framework.
§9.2Cross-References
- Runtime Stability Definition v3.3: Overall framework concepts, design philosophy, and 7-attribute integration
- Runtime Immunity Definition v1.1: Structure-based protection system (2-axis NL definition, PQN readiness)
| SL / IL | IL-0 | IL-1 | IL-2 | IL-3 |
|---|---|---|---|---|
| SL-1 | RS-0 | RS-1 | RS-2 | RS-3 |
| SL-2 | RS-1 | RS-2 | RS-3 | RS-4 |
| SL-3 | RS-2 | RS-3 | RS-4 | RS-5/6※ |
*Runtime Stability — Technology that controls an unstoppable world. Breached, yet unshaken.*