Containment Invariants: Securing Intentionally Vulnerable Systems for Education, Training, and Research

Abstract

The rise of capture-the-flag (CTF) competitions and offensive security training requires the deployment of systems that are, by design, flawed. This creates a unique architectural paradox: how does one host a system intended to be compromised without compromising the host itself? This paper classifies the security principles of “range engineering”—the discipline of engineering the environment. This research study synthesizes evidence across the cyber-range, honeypot, ICS/OT testbed, and cloud-isolation literature to derive a containment-focused classification of threat planes, security invariants, boundary mechanisms and properties, and operational controls for intentionally vulnerable environments used in education, training, and research. Five security invariants are derived under the assumption of expected compromise and mapped to boundary families and measurable operational objectives. The analysis further identifies under-evidenced areas, particularly control-plane isolation, corrective controls for cross-tenant failures, and systematic validation of externalization defenses.

1. Introduction

Over the past decade, intentionally vulnerable systems have become an essential part of cybersecurity education and skill development, from capture-the-flag (CTF) competitions to university cyber ranges and industry training platforms. These environments—typically implemented as vulnerable virtual machines or containerized services—enable students and practitioners to practice penetration testing and incident response techniques against realistic targets without affecting production systems [1]. Increasingly, these experiences are delivered via hosted and scalable “CTF-as-a-service” and online lab platforms, which makes containment and threat prevention an operational requirement rather than a purely local lab concern [2,3,4,5,6]. However, if such targets are deployed without appropriate isolation and hardening, they may themselves become stepping stones for real-world attacks on institutional or cloud infrastructure, introducing risks that are increasingly documented in cyber-range-specific threat analyses [7,8]. Existing work discusses cybersecurity curricula, threat modeling, and vulnerability assessment more broadly, but the knowledge relevant to containment is fragmented across adjacent communities and rarely systematized around the assumption of an “expected compromise” that defines intentionally vulnerable systems.

At the same time, the core containment problem is not unique to education ranges. Honeypot research has long treated the challenge of exposing instrumented, intentionally attackable assets while preventing them from becoming launch pads for further compromise, especially in virtual honeypot deployments and large-scale honeyfarm designs [9,10]. Similarly, the ICS/OT testbed literature repeatedly confronts the problem of enabling realistic and sometimes remotely accessible experimentation without endangering production-adjacent networks or safety-critical processes [11,12,13,14,15]. In parallel, multi-tenant cloud-security research provides a direct analogue for the workload-escape and tenant-isolation concerns by analyzing co-residency, cross-VM leakage, scheduling defenses, and key-isolation mechanisms in shared infrastructure [16,17,18,19]. This paper draws on cyber-range engineering, honeypot, ICS/OT testbeds, and cloud-isolation research to organize containment practices for intentionally vulnerable educational targets. The result is a taxonomy, a set of security invariants, and a gap analysis of where current evidence is still weak.

Real-world competitions illustrate the need for this separation particularly clearly: for example, in Hack-A-Sat-style scenarios, the “target” subsystem is designed to be attacked by participants, while mission-critical subsystems (e.g., flight-control functions) must remain isolated and trustworthy. This paper focuses on engineering those boundaries around the vulnerable asset, rather than attempting to “secure” the intentionally insecure target itself.

A substantial body of work exists on CTFs, labs, and secure-yet-vulnerable training environments, though very little focuses on the “hardening around intentionally vulnerable systems” problem; instead it appears as part of broader CTF/lab design and education research. The closest adjacent bodies of work are (i) honeypot engineering, which treats controlled exposure, containment, and fidelity trade-offs as first-order design goals [9,10]; (ii) ICS/OT cybersecurity testbeds and remote laboratories, which must balance realism against safety and operational separation [11,12,13,14,15]; and (iii) multi-tenant cloud-isolation research, which analyzes the same shared-infrastructure failure modes that underlie the I1 and I3 invariants, as well as scheduler-level and in-VM defenses against cross-tenant leakage [16,17,18,19].

While the early cyber-range and virtual-lab literature focused on heavyweight virtualization stacks (often VMware-oriented) [20,21], contemporary work has increasingly shifted toward containerized architectures and automated range instantiation [3,4,5,22]. This shift requires a move from hardware-level isolation assumptions to software-defined security contexts and layered containment controls to prevent container breakouts while maintaining high vulnerability reproducibility [23,24].

This work examines intentionally vulnerable targets used for training, education, and research, including CTF-style challenges and cyber-range lab exercises. The focus is on environments where the operator has direct control over the hosting stack and can apply containment controls (e.g., self-hosted infrastructure and IaaS-based deployments). The scope of the technical discussion includes targets delivered as virtual machines or containers (including microVM-backed containers) and the surrounding management and network controls required to safely expose them to untrusted participants. The scope excludes (i) red-team exercises conducted against production systems, (ii) physical/embedded targets where hardware safety constraints dominate the design, and (iii) fully managed “range-as-a-service” offerings where the underlying isolation mechanisms and control-plane separation are opaque to the operator. While the primary focus is education and training ranges, the containment logic applies more broadly to contexts with expected or tolerated compromise, such as honeypots and isolated legacy ICS/OT enclaves [7,9,11,12].

This study aims to synthesize fragmented containment knowledge into a practical framework for safely operating intentionally vulnerable systems. Its goal is to assess whether expected compromise can be bounded through threat modeling, security invariants, containment boundaries, and operational controls.

This study follows a structured literature-based systematization method, synthesized from cyber-range, honeypot, ICS/OT testbed, and cloud-isolation research. The sources were selected to cover four adjacent but complementary domains: cyber ranges and CTF infrastructure, honeypot engineering, ICS/OT cybersecurity testbeds, and multi-tenant cloud isolation. These domains were included because each addresses environments in which compromise is expected, tolerated, or simulated, while surrounding infrastructure must remain protected.

This paper is structured around the following research questions:

• RQ1: What is the threat model for intentionally vulnerable targets, and what assets (e.g., platform, control plane, other participants, and external infrastructure) must be protected?
• RQ2: Which containment boundaries are most effective under realistic attacker capabilities?
• RQ3: What operational controls reduce impact scope while preserving reproducibility and pedagogical value?

The following contributions are presented in this paper: (i) the literature on a threat model for intentionally vulnerable education targets that distinguishes participant-facing assets from platform and control-plane assets; (ii) a multidimensional classification scheme spanning boundary type, attacker precondition, failure mode, control mechanism, and validation capacity; and (iii) a taxonomy map that shows which containment combinations are well studied and which remain weakly evidenced. Conceptually, this positions cyber-range security as a concrete instantiation of a broader “secure the environment around vulnerable assets” challenge and clarifies which parts of that paradigm are well supported versus still weakly evidenced.

The findings are intended for researchers, educators, operators, and infrastructure engineers responsible for deploying intentionally vulnerable systems, offering a structured basis for selecting containment controls, defining measurable safety objectives, and identifying where current practice lacks empirical validation.

2. Threat Model for Intentionally Vulnerable Targets

The environments require an attacker model where compromise of the participant-facing target is expected. The key distinction is between legitimate compromise of the target (e.g., obtaining root in a challenge instance) and illegitimate impact outside the target boundary. In other words, solving the challenge is in scope; escaping the challenge boundary is not.

The environment is modeled as four planes with distinct trust assumptions: (i) a participant plane (untrusted users), (ii) a target plane (intentionally vulnerable workloads), (iii) a control plane (orchestration, scoring, provisioning, CI/CD, image registry, and logging), and (iv) a platform plane (host OS, hypervisor/runtime, storage, and network substrate). The cyber-range literature and design guidance motivate this separation as a prerequisite for safe experimentation with untrusted actors [7,8,23,25,26,27]. The same separation also appears in adjacent honeypot, ICS/OT, and cloud-security work, where exposing one plane to attackers is acceptable only if the surrounding control and platform planes remain protected [9,11,12,16].

The targets are accessed by “zero-trust” participant population [28], where attackers may: (a) exploit application flaws to gain user-level access in targets, (b) escalate privileges to root/administrator inside targets, (c) persist within a target until reset, (d) attempt lateral movement across tenant boundaries, and (e) attempt threat externalization (scanning, DDoS, crypto-mining, spam, or data exfiltration). For advanced scenarios, attacker actions include attempts to compromise control-plane interfaces and software supply paths (e.g., CI/CD or image artifacts). This attacker profile is consistent with publicly documented organizer postmortems and practitioner incident reports that describe threat externalization, resource exhaustion, and emergency containment actions during live range/CTF operations [29,30,31].

The systematization workflow consisted of extracting from each source its assumed attacker capability, containment boundary, failure mode, control mechanism, and validation approach. These extracted properties were then grouped into recurring protection objectives, which produced five invariants, I1–I5. The same extracted properties were also used to construct the classification taxonomy in Table 1 and the per-paper classification in Table 2. This workflow separates the synthesized security objectives from the descriptive classification of the literature, making explicit how the invariants and taxonomy were derived from the reviewed sources.

Table 1. Taxonomy used to classify the containment literature.

Dimension	Values	Interpretation
Boundary type	Workload, network, control-plane, and operational	Where the paper places the primary containment boundary or management mechanism.
Attacker precondition	Unprivileged, foothold/user, root/admin in target, and post-escape	Which level of compromise is assumed before the containment question becomes meaningful.
Failure mode class	Escape, control-plane compromise, lateral movement, externalization, persistence, and availability	Which containment failure the paper primarily analyzes and mitigates.
Control mechanism	Preventive, detective, and corrective	Whether the emphasis is on blocking, detecting, or recovering from undesired propagation.
Validation tractability	Directly testable, requires red-team exercise, and difficult to verify directly	How straightforward it is to generate credible evidence that the control actually works in deployment.

Table 2. Per-paper classification of the core containment literature. Codes: Boundary type—W, workload; N, network; C, control plane; O, operational. Attacker precondition—U, unprivileged; F, foothold/user; R, root in target; X, post-escape. Failure mode—E, escape; CP, control-plane compromise; L, lateral movement; EX, externalization; P, persistence; A, availability. Control mechanism—Pr, preventive; De, detective; Co, corrective. Validation tractability—T, directly testable; RT, requires red-team exercise; V, difficult to verify directly.

Paper/Source	Boundary Type	Attacker Precondition	Failure Mode Class	Control Mechanism Emphasis	Validation Tractability
A Virtual Honeypot Framework [9]	W, O	U, F	EX, P	De, Pr	T
Scalability, Fidelity, and Containment in the Potemkin Virtual Honeyfarm [10]	W, O	U, F	EX, E, A	Pr, Co	RT
SCADA Cyber Security Testbed Development [11]	O, N	F	EX, A	Pr	T
Hey, You, Get Off of My Cloud [16]	W	R	E, L	De	RT
Teaching Information Security with Virtual Laboratories [20]	O	F	P	Co	T
Cloud-Based Virtual Laboratory for Network Security Education [21]	N	F	L, EX	Pr	T
Scheduler-based Defenses against Cross-VM Side-channels [18]	W	R	L	Pr	RT
Preventing Cryptographic Key Leakage in Cloud Virtual Machines [19]	W	R	L	Pr	RT
A Survey of Cyber Security Management in Industrial Control Systems [13]	O, N, C	F, R	EX, A, CP	Pr	V
A Placement Vulnerability Study in Multi-Tenant Public Clouds [17]	W	R	L	De	RT
The Cybersecurity Landscape in Industrial Control Systems [14]	O, N, C	F, R	E, CP, EX, A	Pr, De	V
Scalable Containerized CTF Infrastructure [3]	N, O	R	L	Pr	T
Security Scenario Generator (SecGen) [32]	O	F	P	Co	T
Labtainers Framework [4]	O, N	F	P, L	Co, Pr	T
CTF-as-a-Service for Security Education [2]	C, N	F	CP, L	Pr	RT
CyRIS Instantiation System [22]	O	F	P	Co	T
Cyber Ranges and Security Testbeds [23]	W, N, C	R	E, L, EX	Pr	RT
A Review of Cyber-Ranges and Test-Beds [26]	W, N, C, O	R	E, L, EX	Pr	V
Pandora Cyber Range [27]	C, W	R	CP, E	Pr	RT
DC 28 CTF Postmortem [30]	O	R	EX, A, P	De, Co	T
Firecracker Lightweight Virtualization [24]	W	X	E	Pr	RT
Foundation of Cyber Ranges [25]	W, N, C, O	R	E, CP, L, EX	Pr	V
A Cyber-Security Methodology for a Cyber-Physical Industrial Control System Testbed [15]	O, N, C	F, R	EX, A, CP	Pr, De	T
Cybersecurity of Cyber Ranges: Threats and Mitigations [7]	W, N, C, O	R	E, CP, L, EX	Pr, De	V
ICSSIM: A Framework for Building Industrial Control Systems Security Testbeds [12]	O, N, C	F, R	EX, A, CP	Pr, De	T
The Cyber Range: A Guide (NIST) [8]	W, N, C, O	R	E, CP, L, EX, P, A	Pr, De, Co	T
Breaking Isolation of MicroVM-based Containers [33]	W	X	E	Pr	RT

The invariants are derived from recurring failure modes reported across the cyber-range and training-platform literature, then cross-checked against adjacent honeypot, ICS/OT testbed, and multi-tenant cloud work. The systematization process is applied to extract common threat classes from prior work: platform escape, control-plane compromise, cross-tenant movement, threat externalization, and persistence/recovery failures [9,10,11,14,16,17,23,25,26,27,28]. Each threat class translates into a protection objective under the expected-compromise assumption (i.e., even after root in the target). Those objectives are separated from the classification axes used to compare prior work. This allows to define the five invariants I1–I5 as synthesized protection objectives, while the classification itself is introduced below as a taxonomy for comparing how the literature describes containment.

Table 3 provides the invariant matrix. A checkmark indicates that the reference discusses the corresponding concern in a way that informs the invariant design. Sources cited for background context (e.g., pedagogical topic coverage, platform descriptions without containment analysis, or general motivation) are intentionally omitted from Table 3 unless they provide direct evidence for at least one invariant.

Table 3. Invariant matrix: prior papers vs. synthesized invariants I1–I5.

Paper/Source	Year	I1	I2	I3	I4	I5
Teaching Information Security with Virtual Laboratories [20]	2014					✓
Cloud-Based Virtual Laboratory for Network Security Education) [21]	2014			✓	✓
Scalable Containerized CTF Infrastructure [3]	2017	✓		✓
Security Scenario Generator (SecGen) [32]	2017					✓
Labtainers Framework [4]	2017			✓		✓
CTF-as-a-Service for Security Education [2]	2017		✓	✓
CyRIS Instantiation System [22]	2019			✓		✓
Cyber Ranges and Security Testbeds [23]	2020	✓	✓	✓	✓
A Review of Cyber-Ranges and Test-Beds [26]	2020	✓	✓	✓	✓
Pandora Cyber Range [27]	2020	✓	✓	✓
DC 28 CTF Postmortem [30]	2020				✓	✓
Firecracker Lightweight Virtualization [24]	2020	✓
Foundation of Cyber Ranges [25]	2021	✓	✓	✓	✓
Cybersecurity of Cyber Ranges: Threats and Mitigations [7]	2022	✓	✓	✓	✓
The Cyber Range: A Guide (NIST) [8]	2023	✓	✓	✓	✓	✓
Breaking Isolation of MicroVM-based Containers [33]	2023	✓
Emerging Cybersecurity Threats in Education [28]	2022				✓
smileyCTF 2025 Infrastructure Postmortem [29]	2025				✓	✓
Effectiveness of CTF Education (Operational Safety Context) [6]	2025				✓
Cyber Range Crypto Attack Incident Report [31]	n.d.				✓
This paper (synthesized set)	2026	✓	✓	✓	✓	✓

2.1. Security Invariants Derived Under Expected Compromise

Given full compromise of a target instance, the literature implies that the following invariants must continue to hold:

• I1—Target-to-platform non-interference: a fully compromised target must leave the host, hypervisor, runtime, and adjacent infrastructure unaffected [16,23,24,25].
• I2—Target-to-control-plane non-interference: orchestration, scoring, CI/CD, registry, and management credentials remain outside the reach of any participant who has obtained control of a target instance [2,25,27].
• I3—Tenant isolation: compromise of one team’s instance must not enable access to other teams’ instances or network segments [2,3,16,26].
• I4—Constrained external effects: compromised targets must not generate unauthorized outbound activity beyond explicitly permitted policy [6,23,28,31].
• I5—Bounded persistence: reset and reprovision operations must reliably eradicate attacker state within a defined time window [20,22,32].

For this paper’s scope, each major threat class identified above maps to at least one invariant, and each invariant addresses a distinct containment objective with recurring support in the literature; no invariants are redundant. This provides a reproducible baseline derived from the surveyed literature.

To compare how the literature describes and categorizes containment, each paper is classified along five dimensions correlated to I1–I5. The first, boundary type, records where a paper places its primary containment mechanism: at the workload, network, control-plane, or operational layer. Attacker precondition captures the assumed entry point—unprivileged, foothold, root inside the target, or post-escape from the host boundary—since the same control can be adequate against one assumption and irrelevant against another. Failure mode identifies what kind of containment breakdown the paper addresses, whether escape, lateral movement, externalization, control-plane compromise, persistence, or availability collapse. The remaining two dimensions are more evaluative: control mechanism distinguishes preventive, detective, and corrective orientations, and validation tractability records whether a claimed control is directly testable in routine operations, requires a dedicated red-team exercise to assess, or is difficult to verify in practice at all. I1–I5 remain the protection objectives; this taxonomy is the device that reveals which combinations of assumptions, mechanisms, and validation strategies the literature actually covers.

Table 2 applies this taxonomy to the core literature used in the systematization. The goal is not to force each paper into a single bucket; many papers span multiple dimensions. Instead, the table highlights the dominant boundary, strongest attacker assumption, primary failure mode, principal control orientation, and most realistic validation mode emphasized by each source.

While adversarial approaches provide the strongest evidence that containment boundaries are present, they are resource-intensive and cannot be used continuously. Operators can complement drills with a set of lower-cost routine checks that provide ongoing assurance for each invariant. For I1 and I5, automated rebuild pipelines can assert image provenance and baseline hash integrity on every deploy cycle, and synthetic reset tests (spinning up a canary instance, verifying its state, and confirming full teardown) can be scheduled on a per-event or per-cohort cadence without participant disruption. For I3 and I4, network policy regression tests—executing scripted probe traffic from a reference tenant and asserting expected deny responses—provide directly testable, repeatable evidence that segmentation and egress allowlists remain correctly configured after any infrastructure change; this approach is analogous to policy-as-code testing in production environments and can be integrated into CI/CD pipelines for range configuration changes. For I2, token audit reports (TTL compliance, idle session counts, and privilege-scope distribution) generated from IAM logs offer continuous visibility into credential hygiene without requiring an active attack simulation. Collectively, these lightweight checks occupy the “directly testable” column of Table 1: they do not substitute for red-team validation of the workload boundary, but they close the assurance gap for the operational and network layers where configuration drift is the dominant failure mode. A practical minimum is to gate every range configuration change on passing network policy regression tests and image provenance checks, reserving full adversarial exercises for pre-event readiness reviews.

The taxonomy reveals an asymmetry in what the literature studies. Workload-boundary papers are comparatively mature for root-level and post-escape attacker assumptions, but they concentrate on preventive controls and often require specialist adversarial testing for validation [10,24,33]. Network and tenancy papers provide stronger directly testable guidance, yet they are much thinner on control-plane compromise and on the interaction between lateral movement and operational recovery [3,17,18]. Operational papers are comparatively strong on persistence, rebuild, and availability handling, but the workload-escape resistance has to be measurable [22,29,30]. By contrast, combinations involving externalization under root compromise, corrective controls for cross-tenant failures, and rigorous validation of control-plane isolation remain relatively underexplored, even in adjacent cloud and ICS/OT work [14,15,19]. That asymmetry is the key research result of the systematization: the literature is richest where boundaries are tangible and easiest to benchmark, and thinnest where controls span organizational or multi-plane dependencies. Table 4 summarizes this coverage asymmetry by mapping recurring taxonomy combinations to their coverage level, typical evidence, validation mode, and interpretation.

Table 4. Taxonomy map and typical evidence.

Combination	Coverage	Typical Evidence	Validation Mode	Interpretation
Workload boundary + escape + preventive control	High	MicroVM, container, and sandbox studies	RT	Mature technically, but evidence often depends on specialist escape testing.
Network boundary + lateral movement + preventive control	Medium–High	Segmentation and cyber-range deployment papers	T	Operationally actionable and measurable, but frequently scoped to tenant separation only.
Operational boundary + persistence + corrective control	Medium–High	Reset, rebuild, orchestration, and postmortem evidence	T	Strongest guidance for recovery semantics and repeatability.
Control-plane boundary + control-plane compromise + preventive/detective control	Medium	IAM, orchestration, and admission-control discussions	RT/V	Recognized as critical, but rarely validated with strong adversarial evidence.
Any boundary + externalization + corrective control	Low	Incident reports and postmortems	T/RT	Real incidents exist, yet systematic comparative study is thin.
Cross-plane combinations involving availability collapse	Low	Organizer postmortems and practitioner reports	V	Important in practice, but weakly formalized and under-benchmarked in research.

2.2. Threat Events of Interest

Under this model, the highest-priority threat events are: platform escape, control-plane compromise, cross-tenant lateral movement, and threat externalization. These events are evaluated by both impact (safety, operational exposure, and service availability) and exploitability (required privileges, required preconditions, and detectability). Competition postmortems further show that service collapse can occur even without boundary escape (e.g., runaway exploit load or orchestration bottlenecks), which justifies treating availability failures as containment events [29,30].

2.3. Assumptions and Non-Goals

It is expected that baseline host patching is applied, hardened identity boundaries for operators are separated, and the chosen isolation primitives are correctly implemented. The exploitation of the intentionally vulnerable target itself is expected and should not be prevented by security measures; rather, the impact scope is constrained and prevents propagation beyond the allowed attack envelope.

2.4. Validation Criteria

A deployment satisfies this threat model only if invariants I1–I5 are testable through repeatable confirmation. Examples include escape tests for I1, control-plane access tests for I2, lateral-movement tests for I3, egress-policy tests for I4, and reset-integrity tests for I5. The measurable metrics in Table 5 summarize these criteria.

Table 5. Containment metric for containment invariants I1–I5.

Invariant	Boundary Under Test	Measured Signals	Validation Pattern and Pass Evidence
I1 Platform	Target ↛ host/runtime/hypervisor	Escape: platform escape success rate Integrity: host-state deviation Attempts: denied host-access events	Run controlled escape probes from a compromised target while monitoring host processes, kernel state, filesystem state, and runtime events. Pass evidence: no successful host access, no unauthorized host-state change, and denied attempts visible in logs.
I2 Control plane	Target ↛ orchestration/scoring/CI/CD/registry	API abuse: unauthorized API success rate Secrets: exposed credential count Hygiene: credential TTL compliance	Attempt access from the target plane to orchestration, scoring, registry, CI/CD, metadata, and logging interfaces. Pass evidence: zero successful unauthorized calls, no reusable control-plane credentials inside targets, and complete audit trail.
I3 Tenant	Team A ↛ Team B networks/services/storage	Reachability: cross-tenant connection success rate East–west: denied movement attempts Exposure: shared-state findings	Run scripted probes from one tenant/team instance toward other tenant networks, services, storage namespaces, and scoring paths. Pass evidence: zero successful cross-tenant access and denied traffic recorded by segmentation policy logs.
I4 Egress	Target ↛ unauthorized Internet/abuse channels	Policy: egress violation rate Response: time-to-quarantine Blocking: blocked outbound ratio Abuse: external abuse signals	Simulate scanning, mining-beacon, spam, DNS-tunnel, or unauthorized callback traffic from a compromised target. Pass evidence: unauthorized traffic blocked or rate-limited, quarantine within SLO, and no uncontrolled outbound path.
I5 Persistence	Compromised target → known-good baseline	Recovery: reset success rate Latency: reset completion time Baseline: known-good restoration rate Residue: remaining artifact count	Compromise a target, trigger reset/rebuild, then verify image hash, filesystem state, process state, credentials, and network membership. Pass evidence: approved baseline restored within the defined time window, attacker artifacts removed, and rebuild provenance verified.

Each invariant can be associated with measurable containment metrics. They measure whether compromise remains confined to the intended boundary. The relevant unit of evaluation is containment preservation after expected compromise. Table 5 maps invariants I1–I5 to measurable outcomes, example tests, and evidence sources. The metrics are intended to enable repeated evaluation across deployments, challenge classes, and infrastructure changes. They can be collected through controlled escape tests, lateral-movement probes, egress-policy regression tests, reset-integrity checks, audit logs, and orchestration telemetry.

The framework therefore treats each invariant as a falsifiable property. A containment design satisfies an invariant only if routine tests and telemetry provide evidence that the corresponding boundary continues to hold under the assumed attacker precondition. This does not replace adversarial red-team validation for high-risk deployments, but it provides a repeatable baseline for measuring containment effectiveness and detecting misconfigurations.

2.5. Invariant-by-Invariant Implementation Profile (I1–I5)

To outline the structured classification, Table 6 maps each invariant to a practical implementation profile: design intent, dominant failure modes, minimum baseline controls, advanced controls for higher-risk events, and a concrete validation test. The table is intended as a systematized comparison artifact: baseline controls capture recurring minimum practices in the literature, while advanced controls capture higher-assurance patterns used where attacker capability or exposure is greater.

Table 6. Implementation profile for invariants I1–I5.

Inv.	Design Intent	Common Failure Modes	Minimum Controls	Advanced Controls	Validation Test
I1	Prevent target compromise from affecting host/platform	Container escape, unsafe host mounts, privileged runtime flags, and vulnerable hypervisor/runtime path	Non-privileged workloads, hardened runtime profile (seccomp + LSM), read-only host exposure, and routine patch cadence	VM/microVM isolation for high-risk targets, reduced virtual device surface, and hardware-assisted isolation tiers	Execute controlled escape attempts from compromised target; verify no host/process/kernel impact and no privileged host access
I2	Prevent target-to-control-plane compromise	Leaked automation tokens, shared admin networks, over-privileged service accounts, and participant API reachability	Strict plane separation, least-privilege IAM, short-lived scoped credentials, and no participant access to admin APIs	JIT privileged access, one-way telemetry channels, signed workload admission, dual-control for high-impact actions	Attempt control-plane API access from compromised target; verify denied access, no token reuse, and immutable audit trail
I3	Preserve tenant isolation between teams/instances	Flat east–west networks, shared state backends, policy drift, and namespace crossover	Per-team segmentation, isolated storage namespaces, east–west ACLs, and deny-by-default intra-tenant routing	Micro-segmentation with policy-as-code regression checks, per-tenant service identity, and automated impact-scope isolation	Run lateral-movement playbook from Team A instance; verify inability to reach Team B services/data across network and storage layers
I4	Constrain unauthorized outbound effects	Permissive egress, missing DNS controls, metadata-service exposure, and delayed quarantine	Egress allowlists, metadata endpoint blocking, outbound rate limits, and threat telemetry with auto-quarantine hooks	Chokepoint proxy enforcement, adaptive throttling, destination reputation gating, and automated ticket + reset workflow	Launch controlled outbound compromise simulation (scan/mining beacon); verify block/quarantine latency within SLO and no policy-bypassing path
I5	Ensure bounded persistence and reliable recovery	Partial reset semantics, stale mutable images, failed rebuild pipeline, and long reset queues under load	Immutable golden images, volatile writable layers, deterministic rebuild pipeline, and documented reset semantics and SLO	Provenance-attested image supply chain, pool health admission gates, degraded-mode reset orchestration, and continuous reset drills	Compromise instance, trigger reset, and verify state eradication + known-good redeploy within defined time window

3. Containment Boundaries

This section describes where ranges and challenge platforms draw isolation boundaries, why specific boundaries are selected, and how those boundaries fail. For the purpose of this paper, the “boundary” is defined as a mechanism that forces an attacker to complete an additional exploit step before causing impact beyond the compromised target.

3.1. Design Objective and Boundary-Selection Criteria

Given invariants I1–I5, boundary selection is a constrained engineering decision, which makes it distinct from a binary “VMs vs. containers” choice. In this paper, a boundary is selected when it improves at least one invariant without creating disproportionate operational risk. Candidate boundaries are evaluated against five criteria:

• Exploit-step amplification: Does the boundary add a distinct attacker step (e.g., requiring a kernel or hypervisor escape after gaining root in target)?
• Failure independence: Does the boundary fail differently from other layers, reducing common-mode compromise?
• Operational recoverability: Can the boundary be reset/reprovisioned quickly enough to support I5 and class/lab cadence?
• Fidelity impact: Does the boundary preserve pedagogical realism (tooling, latency, networking behavior, and exploitability) for the exercise objective?
• Policy verifiability: Can operators continuously test and monitor whether the boundary is still enforcing intended constraints?

These criteria lead to a layered strategy: workload isolation to protect I1, control-plane separation for I2, tenant/network segmentation for I3–I4, and reset semantics for I5.

3.2. Heavyweight Virtualization and Hypervisor Isolation

A traditional approach is to run each challenge instance inside a dedicated virtual machine under a type-1 or type-2 hypervisor. The VM boundary provides strong separation of kernel state, devices, and memory, and it remains a common choice when the threat model includes container-escape attacks or when challenges require full-system exploitation.

From a selection perspective, VM isolation is primarily chosen for I1 (platform non-interference) and secondarily for I3 (tenant isolation). After target compromise, the attacker typically needs a further guest-to-host escape path (or control-plane credential path) to produce out-of-scope impact. This exploit-step amplification is the main reason operators accept VM overhead.

However, the protection is not absolute. Boundary failure modes include hypervisor vulnerabilities, risky virtual device exposure, misconfigured shared folders, and management-plane shortcuts (e.g., broad API tokens attached to guest automation). Consequently, VM-based deployments are most defensible when combined with hardened VM templates, reduced virtual hardware surface, and strict separation between guest networks and hypervisor/orchestration interfaces.

Operationally, VMs are selected when security margin is prioritized over density, when exercises require custom kernels/system calls, or when legal/risk posture demands stronger isolation for untrusted participants. In high-scale teaching contexts, this usually implies image caching and automated rebuild pipelines to keep startup latency and reset time within course constraints.

3.3. Containerization with Additional Sandboxing

Container-based ranges improve density and startup time, but they weaken the isolation boundary by sharing the host kernel. As a result, production deployments often layer multiple controls: running containers as non-root, dropping Linux capabilities, enforcing seccomp and AppArmor/SELinux policies, and avoiding privileged containers. Some platforms also place an additional sandbox boundary beneath the container runtime (e.g., user namespaces or microVM-based container runtimes) to narrow the impact of a container breakout [23,24]. Recent work further shows that microVM-based container stacks can expose additional forwarding-related attack surfaces, reinforcing that these mechanisms should be treated as defense in depth [33].

The reason to select this stack is mostly operational: fast instantiation, high host utilization, and easy per-team cloning support large cohorts and short-lived labs. Containers score strongly on recoverability and fidelity for many web/network exercises but weakly on exploit-step amplification unless additional sandboxing is present.

For that reason, “plain containers” are generally insufficient for hostile multi-tenant settings. Practical selection favors composed boundaries: container hardening plus runtime sandboxing plus network policy. This composition restores some failure independence by ensuring that a single application-level compromise does not immediately imply host compromise or unrestricted lateral movement.

A key design trade-off is fidelity versus restriction. Aggressive seccomp/capability removal can invalidate intended challenge behavior, while permissive profiles increase breakout risk. In reported deployments, this trade-off is commonly handled with challenge-class-specific policies (e.g., web exploitation, binary exploitation, and kernel exercises) that are validated in lab CI for both solvability and containment.

3.4. Network-Level Containment and Impact-Scope Reduction

Regardless of whether the workload runs in VMs or containers, most ranges rely heavily on network controls to contain compromise. Common measures include per-challenge network segments, strict egress filtering (default-deny outbound), service allowlists, and rate limiting. These controls aim to prevent compromised targets from being used for scanning, lateral movement, or exfiltration into the hosting environment. Prior virtual-lab deployments similarly argue for strict separation between the lab network and institutional networks (both physically and logically) as a foundational safety measure [21].

Network boundaries are selected because they directly enforce I3 (tenant isolation) and I4 (constrained external effects) even when workload isolation is partially bypassed. In other words, if an attacker gains root inside a target, network policy can still block threat externalization and cross-team pivoting.

This boundary family is often the highest leverage control for legal and institutional risk reduction, since outbound misuse (scanning, botnet traffic, spam, and denial of service) is what external stakeholders observe first. Common operational patterns include per-team virtual networks, explicit egress proxy chokepoints, metadata-service blocking, and DNS controls to prevent covert policy bypass.

Failure modes are mostly configuration and lifecycle errors instead of novel exploits: stale allowlists, overly broad “temporary” rules, policy drift across environments, and missing enforcement in control-plane exception paths. Accordingly, mature deployments tend to implement network boundaries as code (versioned policies, pre-deploy checks, regression tests) instead of a one-time firewall configuration.

3.5. Privilege Separation and Management-Plane Isolation

A common failure mode in training environments is insufficient separation between the participant-facing plane (the intentionally vulnerable target) and the management plane (orchestrator, scoring, logging, and provisioning). Observed designs isolate control-plane services on separate networks and credentials, enforce least privilege for automation, and avoid exposing management APIs to participant networks.

This boundary is selected primarily for I2 (target-to-control-plane non-interference). Without strong identity and API separation, even perfect workload sandboxing can be defeated indirectly: attackers exfiltrate deployment tokens, exploit CI/CD runners, or invoke management APIs to spawn privileged workloads.

Observed patterns include short-lived scoped credentials, one-way telemetry flow from targets to logging infrastructure, and dedicated operator jump paths with denied participant-plane reachability to registries/orchestrators. The key principle is asymmetry: the control plane observes and resets targets, while targets have no management authority over the control plane.

Because this layer involves both technical controls and operator procedures, selection is shaped by operator workflows as well as technical controls. Studies and incident reports indicate that overly complex access models are frequently bypassed during live events, whereas simpler separation models remain operable under time pressure while preserving least privilege.

3.6. Selection of Boundaries

The four boundary families above are selected as a set because each maps to different high-impact failure classes and offers partial independence: workload isolation resists direct host impact (I1), control-plane separation prevents orchestration takeover (I2), network segmentation/egress control limits spread and impact (I3–I4), and reset-friendly designs support bounded persistence (I5). Combined together, these invariants allow expected target compromise to be managed and recoverable [7,33].

This allows for the categorization of risk-differentiated deployment profiles. Lower-risk courses often combine hardened containers with strict network and control-plane separation, whereas higher-risk public competitions more often add VM or microVM isolation and tighter egress mediation. In both cases, selection is typically captured as an invariant-to-control mapping and then evaluated through recurring tests.

Table 7 summarizes this mapping as an attack-path and boundary-violation matrix that distinguishes what is pedagogically allowed inside the target from what must be detected, blocked, and recovered outside it.

Table 7. Attack-path/boundary-violation matrix for expected-compromise environments.

Attack Action	Participant Plane	Target Plane	Control Plane	Platform Plane
Privilege escalation in challenge	Allowed in exercise scope (participant attempt)	Allowed as learning objective; detect exploit chain for scoring/audit	Block participant-originated admin/API paths; detect token-based exploitation attempts	Block host escape primitives; recover by forced instance rebuild
Lateral-movement attempt	Detect cross-team probing behavior	Block east–west movement via per-team segmentation; recover by isolating affected tenant networks	Block orchestration-assisted pivoting (e.g., API exploitation to spawn privileged workloads)	Detect anomalous inter-segment traffic; recover by network quarantine and policy rollback
Egress exploitation (scan/DDoS/mining /spam)	Detect abusive tooling patterns and rate spikes	Block unauthorized outbound destinations and protocols; recover with pause/reset	Detect policy exceptions and emergency bypass requests; enforce approval workflow	Block raw external egress except approved chokepoints; recover by revoke+reprovision
Control-plane probing/credential misuse	Block direct participant access to management interfaces	Detect secret scraping and metadata probing from workloads; recover via credential rotation	Never allowed; detect anomalous API calls and privilege escalation attempts; recover via JIT revocation	Detect host-level control-plane access anomalies; recover via host isolation and key rollover

4. Operational Mechanisms

This section addresses RQ3 by analyzing which operational mechanisms are associated with lower impact scope while preserving reproducibility and pedagogical value. Architectural boundaries alone do not determine safety in expected-compromise environments. Many severe incidents in training infrastructure arise from operational drift (stale images, weak credential hygiene, permissive temporary rules, slow resets, and untested response paths) to avoid failure of a single isolation primitive [29,30].

4.1. Control-Selection Logic

Operational mechanisms are characterized by whether they provide at least one of the following under realistic attacker behavior: (i) reduced time to detection, (ii) reduced time to containment, (iii) reduced time to recovery, or (iv) preserved repeatable learner experience after reset. This maps to the set of invariants: containment and exploit controls support I3–I4, identity and workflow controls support I2, and reset/rebuild controls support I5 while reinforcing I1 (see Table 6).

4.2. Ephemerality, Reset, and State Hygiene

Since compromise is expected, many deployments treat challenge instances as ephemeral. Automated reset mechanisms (scheduled rebuilds, per-team instances, snapshot revert, or immutable infrastructure patterns) reduce attacker dwell time and simplify incident response. Educational virtual-lab work also emphasizes “clean-slate” reset semantics (e.g., immutable or reset-on-power-off disks), so each learner starts from a known baseline [20,22,32]. Ephemerality also supports reproducibility: the same vulnerable state can be re-created for each participant or cohort, which is particularly important for education. Recent CTF postmortems also highlight operationally expensive failure modes when instancing and reprovisioning paths are not stress-tested (e.g., instance storms, resource starvation, and manual failover under time pressure), reinforcing the need for reset SLOs and tested degrade modes [29].

For RQ3, the approach is to “have resets” but to define reset semantics: which state is destroyed, which state is preserved (e.g., scores, submissions, and audit logs), and which maximum reset latency is acceptable. A commonly observed baseline combines immutable challenge images, volatile writable layers, and deterministic rebuild pipelines with provenance checks. This reduces persistence opportunities and makes post-incident recovery auditable.

4.3. Identity, Secrets, and Control-Plane Workflow Hardening

Operational safety depends on how humans and automation interact with orchestration and scoring systems. Even with strong workload isolation, leaked long-lived tokens or over-privileged service accounts can bypass technical boundaries. Empirical deployments use short-lived scoped credentials, separation of duties for build/deploy/admin actions, just-in-time operator access, and strict prohibition of participant-plane access to management APIs.

To preserve usability during live events, these controls are typically workflow-aware: emergency access paths are time-bounded, logged, and automatically revoked. This balances two competing requirements in RQ3: minimizing operator friction while preventing ad hoc privilege escalation that erodes I2.

4.4. Exploitation-Focused Telemetry and Automated Containment

Range operations often prioritize monitoring for exploitation outcomes: outbound scanning, denial-of-service patterns, crypto-mining behavior, policy-violating egress destinations, and metadata-service probing. These indicators are directly tied to institutional and legal exposure and therefore provide higher operational value. Practitioner incident reports from cyber-range operations similarly show crypto-mining attempts and cloud-provider alerts as early signals, with egress controls (e.g., deny-by-default outbound NSG rules) used for containment [31].

Detection alone is insufficient. High-value controls couple telemetry to pre-approved actions: rate-limit, quarantine network segment, revoke credentials, pause team instance, and trigger forced reprovision. The objective is to limit propagation scope under operator time pressure.

4.5. Case Studies

RQ3 can be used in security practices to operations. To illustrate this, containment invariants are applied to representative incidents from publicly available CTF postmortems and cyber-range incident reports [29,30,31]. These case studies are not intended as an exhaustive list; they are used to analyze recurring failure classes and derive practical containment lessons.

The taxonomy (as detailed in Table 2) outlines each case with tags for boundary type (B), attacker precondition (P), failure mode class (F), control mechanism emphasis (M), and validation tractability (V).

Case study 1: Threat externalization from compromised targets [B = N/O; P = R; F = EX; M = De/Co; V = T]. Practitioner reports describe challenge instances being repurposed for crypto-mining and abusive outbound traffic, with first detection often coming from cloud-provider alerts and egress anomalies [30,31]. The recurring failure mode is overly permissive outbound policy (I4). Effective response combines immediate quarantine and forced reprovision, followed by stricter default-deny egress and policy-as-code checks.

Case study 2: Instability during peak event load [B = O; P = R; F = A/P; M = Co; V = T]. Large-event postmortems report service degradation from instancing storms, orchestration bottlenecks, and manual failover under operator time pressure [29,30]. Even when no boundary escape is confirmed, this creates containment-relevant risk by extending attacker dwell time and reducing recovery reliability (I5). The operational lesson is to treat reset and rebuild pipelines as safety-critical controls with tested degraded modes.

Case study 3: Control-plane misuse pathways [B = C/O; P = F/R; F = CP; M = Pr/De; V = T]. Cyber-range threat analyses and design guidance emphasize that over-privileged or long-lived credentials can bypass workload boundaries by abusing orchestration and management APIs [7,8]. This is an I2 failure class in which compromise propagates through management paths and is not a direct sandbox escape. Practical mitigation strategies include short-lived scoped credentials, separation of duties, and strict network isolation between participant and control planes.

Table 8 summarizes these case-study patterns and maps each to violated invariants, immediate containment actions, and preventive controls.

Table 8. Incident-to-control lessons for cyber-range and CTF operations.

Incident Type	Observed Symptom	Violated Invariant	Likely Root Cause	Containment Action	Preventive Control
Crypto-mining attempts from challenge instances	Cloud compromise alert, sustained CPU spike, and unusual outbound pool traffic	I4	Permissive outbound egress and delayed compromise detection	Quarantine tenant segment, pause affected instances, and force reprovision from clean image	Default-deny egress, mining IOC detection, per-team rate limiting, and immutable rebuild pipeline
Outbound scanning/spam from compromised targets	Bandwidth spike, connection fan-out, and complaints from upstream providers	I4	Broad network policy and missing egress chokepoint enforcement	Apply emergency outbound block, throttle traffic, and reset offending workloads	Egress allowlists, DNS filtering, explicit proxy chokepoints, policy-as-code regression tests
Cross-tenant lateral-movement attempt	East–west scan signatures and unauthorized service access between teams	I3	Weak guest segmentation and shared network trust assumptions	Isolate affected guest VNet/VLAN, revoke shared credentials, and rebuild touched instances	Per-team network isolation, micro-segmentation ACLs, and no shared admin paths across guests
Control-plane misuse/credential abuse	Anomalous API calls, unexpected workload creation, and privilege escalation in orchestrator logs	I2	Long-lived over-privileged credentials or leaked automation tokens	Revoke/rotate credentials, disable compromised service account, and freeze control-plane changes pending review	Short-lived scoped credentials, separation of duties, JIT operator access, and management-plane network isolation
Persistence after scheduled reset	Reappearing attacker artifacts and reset not returning known baseline	I5	Partial reset semantics and non-immutable state paths	Trigger full teardown/rebuild, validate image provenance, and verify baseline hash	Immutable golden images, volatile writable layers, and reset-integrity checks in CI/CD

4.6. Validation, Drills, and Service-Level Objectives

Operational controls exhibit drift without continuous verification. RQ3 is treated as an engineering assurance problem with service-level objectives (SLOs), for example, reset timeliness, credential exposure window, time to quarantine policy-violating egress, and the share of instances rebuilt from approved images. The literature supports the structure of such objectives more strongly than universal numeric cutoffs: the NIST cyber-range guide emphasizes measurable assessment, while postmortem and practitioner sources provide examples of minute-scale remediation [8,29,31].

Table 9 therefore presents these goals as measurable objectives, qualitative target bands, evidence basis, and automated responses. This makes the evidentiary strength of each target explicit with supported numerical precision.

Table 9. Operational SLO table.

Objective	Metric	Target Band	Evidence Basis	Detection Source	Automated Response
Bound persistence duration (I5)	Instance reset latency	Minute scale under routine conditions; tens of minutes in degraded mode	Postmortem evidence and operator practice [29]	Orchestrator job telemetry and reset pipeline logs	Trigger forced reprovision, mark unhealthy pools unschedulable, and page operator on threshold breach
Limit credential abuse window (I2)	Credential time to live (TTL) for ops and automation tokens	Sub-hour by default; shortest practical window for break-glass access	Practitioner consensus; no direct empirical basis found in the surveyed literature	IAM audit logs and token issuance events	Auto-expire tokens, revoke idle sessions, and require JIT re-approval for privileged actions
Constrain externalization impact scope (I4)	Time-to-quarantine policy-violating egress	Minute scale from alert to enforced block	Postmortem and practitioner evidence [29,31]	NDR/flow logs, IDS alerts, egress proxy telemetry	Apply deny rule at chokepoint, rate-limit source tenant, and snapshot and reset offending instances
Preserve tenant isolation (I3)	Cross-tenant policy violation rate	Zero tolerance for critical violations; warning-level events should remain rare	Derived invariant; no direct empirical basis found in the surveyed literature	Micro-segmentation logs and east–west firewall counters	Auto-isolate violating segment, rollback last policy change, and run lateral-movement regression suite
Guarantee trusted rebuild path (I1/I5)	Share of instances rebuilt from approved signed images	Full coverage during production operation	Governance target derived from control-plane and supply-chain guidance [8]	Image registry attestations and CI/CD provenance checks	Block unsigned image deployment, rebuild from last verified artifact, and open incident ticket

Regular adversarial drills (escape simulation, cross-tenant movement tests, egress-policy evasion tests, and control-plane credential misuse scenarios) provide evidence that procedures and automation still work under realistic stress. RQ1/RQ2 design assumptions and real operations ensure that containment remains reproducible throughout semester-scale or competition-scale deployments.

5. Discussion

RQ1–RQ3 support a single design principle: in expected-compromise environments, security is achieved by constraining where compromise can propagate. RQ1 establishes the protection objectives by deriving invariants from the surveyed literature (protect platform and control plane, prevent cross-tenant impact and threat externalization, and ensure bounded persistence). RQ2 then maps these objectives to concrete boundary families—workload isolation, control-plane separation, and network/egress segmentation—showing why no single invariant is sufficient in isolation. RQ3 completes the model by specifying the operational mechanisms that keep those boundaries effective over time under real event pressure.

This classification has two implications. First, range design should be treated as a challenge with measurable properties: operators can define service targets with invariants as properties (e.g., reset latency, egress quarantine time, and credential lifetime) and continuously verify them through drills, in line with current cyber-range guidance [7,8]. Second, pedagogical realism and platform safety are not inherently conflicting goals when containment is engineered as a system with deterministic recovery. Thus, intentionally vulnerable targets remain educationally valuable, while the surrounding infrastructure remains resilient and auditable.

5.1. Operational Cost Trade-Offs

Containment controls introduce technical trade-offs that must be treated as engineering constraints. Layered boundaries increase system complexity (more control planes, policies, and automation paths), which raises configuration-drift risk and operator cognitive load during incidents. Stronger isolation and redundancy increase runtime and orchestration overhead, requiring careful capacity engineering to preserve reset reliability and containment responsiveness under load. Performance impact is workload-dependent: deeper network inspection, stricter sandboxing, and aggressive rate controls can reduce challenge responsiveness and distort exercise fidelity if not tuned to scenario goals. Threat-focused detection pipelines trade recall against precision: lower thresholds improve early detection but increase false positives, which can trigger unnecessary quarantines and learner disruption. Operators manage these trade-offs by mapping each control to specified risk reduction and SLO contribution and then selecting a technically minimal control set that still enforces I1–I5 for the event’s threat profile [7,8,29].

5.2. Trade-Offs (Safety–Realism–Cost)

The deployment design is modeled as a decision surface over (i) containment safety assurance, (ii) exercise realism, and (iii) operational cost/effort. For a fixed threat model, moving toward higher realism (e.g., richer protocols, looser interaction constraints, and longer-lived state) can increase attack surface and operational burden unless compensated by stronger isolation and automation. Conversely, maximizing safety through strict mediation and aggressive resets can reduce realism by constraining attacker maneuver space and timing characteristics. The engineering objective is therefore a spectrum in which no objective can be improved without degrading at least one of the others.

Table 10 provides a qualitative decision matrix that maps common deployment profiles to this frontier. The table is intended as a design aid: operators choose the profile that satisfies minimum safety invariants (I1–I5) while preserving enough realism for the learning objective and keeping operational load within sustainable limits.

Table 10. Qualitative trade-off frontier across safety, realism, and operational cost.

Profile	Typical Scenario	Safety Assurance	Real.	Op. Cost	Representative Control Mix
Low-fidelity training	Intro labs, short guided exercises, and constrained tooling	High	Low–Medium	Medium	Strong egress deny-by-default, fast reset cadence, strict sandbox profiles, and simplified network topology
Balanced teaching range	Semester coursework, mixed-difficulty challenges, and moderate autonomy	Medium–High	Medium–High	Medium–High	Per-team segmentation, selective egress allowlists, scoped credentials, and periodic immutable rebuilds
High-fidelity adversarial simulation	Open competitions, advanced red/blue scenarios, and complex service interaction	Medium (without extra controls)/High (with hardened stack)	High	High	VM/microVM isolation plus segmentation, high-capacity orchestration, intensive telemetry correlation, and automated quarantine and rollback paths

5.3. Pedagogical Effects of Containment Choices

Containment mechanisms have pedagogical consequences. Although this paper focuses on security and operational assurance, the same design choices that improve containment can affect challenge realism, learner motivation, and perceived authenticity. For example, strict egress filtering reduces externalization risk but may prevent learners from using realistic reconnaissance, package retrieval, callback, or command-and-control patterns unless these are explicitly emulated. Aggressive sandboxing and capability removal reduce platform risk but may change exploit behavior, disable expected tools, or make some vulnerability classes unrepresentative of real systems. Frequent reset policies reduce attacker persistence and improve recovery, but they can frustrate participants when stateful investigation, long exploit chains, or collaborative debugging is part of the intended learning objective.

These effects suggest that containment could be treated as a safety mechanism and as a pedagogical design variable, indicating whether the selected controls preserve the minimum realism needed for the exercise objective while keeping residual risk within an acceptable boundary. Introductory exercises may tolerate lower realism in exchange for stronger mediation and simpler recovery, whereas advanced adversarial simulations may require richer interaction, longer-lived state, and more permissive network behavior, compensated by stronger workload isolation, telemetry, and automated quarantine.

5.4. Failure Cases and Residual Risk After Controls

Even with layered controls, containment can fail through external factors. Common break paths include policy exceptions that bypass segmentation, leaked automation credentials that bridge target and control planes, delayed reset pipelines during load spikes, and egress-rule gaps that permit malicious attempts before quarantine. Case reports also show that availability collapse (e.g., orchestration backlogs or instance storms) can indirectly weaken containment by extending attacker dwell time and reducing operator response quality [29,30,31]. Residual risk therefore remains in three categories: (i) unknown implementation vulnerabilities in runtimes/hypervisors, (ii) operational drift and human-error pathways under event pressure, and (iii) detection/response latency that allows for bounded but non-zero external impact before enforcement. The practical objective is an identifiable bounded risk with pre-defined failure domains, rapid recovery semantics, and auditable incident pathways tied to I1–I5.

5.5. Limitations

This study is a systematization, which creates several limitations. Although the set of invariants (I1–I5) is derived from the prior literature and operational practice, this paper does not report a large multi-site empirical classification that quantifies effect sizes for specific controls across diverse institutions and threat intensities. The boundary analysis is intentionally platform-agnostic at the architectural level; consequently, implementation-specific factors (hypervisor versions, kernel hardening profiles, cloud-provider defaults, and orchestration stack choices) may materially change realized risk and operational cost. This paper classifies containment and recoverability mechanisms, but it does not fully model pedagogical outcomes (e.g., learning gain, participant motivation, or realism perception) as co-equal optimization targets. The scope excludes fully managed range-as-a-service platforms and many hardware-constrained environments, so transferability to those contexts should be treated as reasoned but not yet validated.

In fully managed range-as-a-service platforms, the underlying isolation stack is inaccessible by the operator, and invariants I1–I3 cannot be directly verified or configured by the range consumer. However, the framework remains applicable as a procurement and evaluation tool: operators can use I1–I5 as a structured checklist to assess provider documentation, audit reports, and SLA terms, asking whether the service offers evidence of workload isolation, tenant separation, control-plane segregation, egress mediation, and reset semantics.

In physical and embedded targets, hardware-constrained environments introduce domain-specific safety constraints that exist outside the current scope, but the invariant logic has a potential to be transferred with adaptation. I4 (constrained external effects) and I2 (control-plane non-interference) are directly relevant to ICS/OT enclaves and embedded testbeds, where physical process impact and safety-system integrity replace the cloud-infrastructure risks modeled here. I1 and I3 require reinterpretation: “platform escape” in an embedded context may mean unauthorized firmware modification or physical bus access rather than hypervisor escape, and “tenant isolation” may map to safety-zone separation rather than network segmentation.

5.6. Future Work

Future work should convert this systematization into a benchmarkable research agenda. One of the directions is a controlled, cross-platform experimentation that compares isolation stacks and operational policies under standardized attacker playbooks, with common outcome metrics such as escape success rate, time to containment, recovery latency, and collateral impact, building on current range-design guidance and risk taxonomies [7,8]. It is possible to conduct a longitudinal field evaluation in semester-scale courses and competition operations to measure how invariant adherence drifts over time and which automation patterns most effectively preserve safety under operator pressure.

The present study does not empirically measure learning gain, motivation, or perceived realism under different containment profiles. Therefore, future work should evaluate these trade-offs through learner studies and instructor/operator observations, comparing containment profiles against outcomes such as perceived realism, challenge completion, frustration, collaboration quality, and measurable learning gain.

In the context of range-as-a-service platforms, the invariants can be developed as a provider-facing assessment derived from the invariants, similar to cloud-security frameworks such as CSA CCM translate architectural security objectives into auditable control assertions, without requiring the consumer to have direct infrastructure access.

Future work could extend the invariant set with domain-specific safety and cyber-physical invariants (e.g., process-state integrity and physical actuator containment) and validate whether the same boundary-selection and operational-control logic applies when hardware safety constraints are co-equal design goals alongside containment.

At a more technical level, there is a challenge of joint optimization of safety, including experiments that quantify trade-offs among exercise fidelity, scalability constraints, and learner outcomes. Finally, broader validation is needed in adjacent expected-compromise domains (e.g., deception environments and constrained ICS/OT enclaves), where domain-specific safety constraints may require extending the current set of invariants while preserving the same assurance logic. Furthermore, there is a scarcity of datasets that contain hypervisor-level sandbox escape event logs.

6. Conclusions

Intentionally vulnerable systems are valuable pedagogical assets whose risk profile is determined by containment engineering. This paper argues that the relevant knowledge is best understood as a systematization problem: secure operation depends on protecting the surrounding platform and control plane; attempting to “harden” the intentionally insecure target is contradictory to the design of the exercise.

The synthesized threat model and the invariants include platform escape, management-plane compromise, cross-tenant impact, and external threat. The invariant matrix and boundary analysis show that no single layer is sufficient: workload isolation (VMs or sandboxed containers), network segmentation with egress control, and control-plane privilege separation provide complementary failure independence. The operational synthesis further links ephemerality, predictable reset semantics, and compromise-oriented monitoring to reduced attacker dwell time and impact scope while preserving reproducibility for learners.

The resulting taxonomy map shows that the literature is comparatively mature on workload escape and tenant segmentation but much thinner on cross-plane externalization, corrective containment, and validation of control-plane isolation under strong attacker assumptions, despite useful adjacent evidence from honeyfarm containment, cloud co-residency studies, and ICS/OT testbed methodology [10,14,15,17]. An open research direction is comparative evaluation of isolation stacks and operational policies under realistic attacker behavior, including the trade-off among exercise fidelity, scalability, and safety. Containment choices are simultaneously security decisions and pedagogical design variables: the same controls that bound propagation risk can alter challenge realism, tool availability, and learner experience, and future work should treat this trade-off as a co-equal design objective rather than a side effect.

More generally, this approach is transferrable beyond CTF and cyber-range settings: environments that intentionally operate known-vulnerable assets (e.g., deception/honeypot deployments or constrained legacy ICS/OT segments) exhibit the same invariant-driven containment logic, with adaptations for domain-specific safety and operational constraints.