Anchor Case Selection

[sehkone]

Anchor Case Selection

This document defines the anchor cases — the representative axis combinations selected for initial implementation. For the N-dimensional environment model and axis definitions, see the overview document. For the schema format used to express each case, see the Scenario Definition Schema.

---

1. Purpose

The N-dimensional environment model allows a large number of axis combinations. As noted in the overview, even a modest number of axes and values produces thousands of possible combinations. Anchor cases are a small set of representative combinations chosen to:

• Validate the Generator's core functionality end-to-end
• Cover the most important axis values with minimal cases
• Provide concrete targets for Phase 1 implementation
• Serve as a foundation that subsequent phases extend

Anchor cases are not exhaustive. They are the starting points from which coverage expands incrementally.

---

2. Selection Criteria

2.1 Encryption Diversity

Each anchor case uses a different encryption architecture. This is the primary differentiator because encryption architecture fundamentally changes what PCAP data looks like:

• TLS: All captured traffic is encrypted; analysis relies on metadata (SNI, certificate info, flow patterns)
• TLS termination: Internal traffic after the termination point is plaintext; PCAP contains both encrypted and plaintext segments
• HTTPS proxy decryption: Proxy decrypts and re-encrypts; PCAP at the proxy contains plaintext

E2E encryption is deferred to Phase 2+ because it requires specialized tooling and offers the least visibility (by design).

2.2 Threat Diversity

Each anchor case uses a different threat category to ensure the generated datasets cover distinct attack patterns.

2.3 Workload Diversity

At least one case should include server workloads (not just endpoints) to validate server-side artifact generation (Falco, DB logs).

2.4 Implementation Feasibility

Anchor cases align with the Generator's Phase 1 tool availability:

• Phase 1 Early: curl/wget, nmap, Atomic Red Team
• Phase 1 Late: Playwright, Postfix/Dovecot, CALDERA, Metasploit

2.5 Scale

All Phase 1 anchor cases use small scale. This minimizes infrastructure complexity and allows faster iteration during initial development. Medium and large scales are deferred.

2.6 Attacker Model

All Phase 1 anchor cases use human attackers. AI-assisted and autonomous AI Actor attackers are deferred to Phase 2.

2.7 AI Agent

No AI Agent in Phase 1. AI Agent deployment and control axes are deferred to Phase 2–3.

---

3. Phase 1 Anchor Cases

3.1 AC-1: Small Office / TLS / Data Exfiltration

Axis	Value
Scale	small
Encryption	[tls]
Workload	[endpoint]
Threat	[exfiltration]
Attacker	[human]

Rationale: The most common environment — a small office where all external traffic is TLS-encrypted. Data exfiltration is a high-priority threat that produces distinctive network patterns (large outbound transfers, unusual destinations).

What it validates:

• Basic Generator pipeline: provision → run → collect → bundle
• PCAP generation with fully encrypted traffic
• Sysmon collection from Windows VMs
• Multi-phase attack timeline (recon → access → exfil)
• Ground Truth recording for a staged attack sequence

Key artifacts:

• PCAP: Encrypted TLS flows; exfiltration visible only as volume/timing anomalies
• Sysmon JSONL: Process creation, file access, network connection events on Windows workstations

---

3.2 AC-2: Small Service / TLS Termination / External Attack

Axis	Value
Scale	small
Encryption	[tls_termination]
Workload	[endpoint, server]
Threat	[external]
Attacker	[human]

Rationale: A small service environment with a load balancer that terminates TLS. This is common in web-facing architectures. The external attack pattern covers the classic kill chain: reconnaissance → exploitation → lateral movement.

What it validates:

• TLS termination configuration in the Environment Layer
• Mixed workload provisioning (Windows VMs + Linux containers)
• Dual PCAP characteristics: encrypted at edge, plaintext internally
• Falco collection from Linux containers
• DB audit log collection
• Server-side attack patterns (web exploitation, lateral movement)

Key artifacts:

• PCAP (edge): Encrypted TLS flows from external attacker
• PCAP (inner): Plaintext traffic after TLS termination, including attack payloads visible in cleartext
• Sysmon JSONL: Windows endpoint telemetry
• Falco JSONL: Linux server/container telemetry
• DB logs: Database access patterns including attack queries

---

3.3 AC-3: Small Office / HTTPS Proxy / Insider Threat

Axis	Value
Scale	small
Encryption	[https_proxy]
Workload	[endpoint]
Threat	[insider]
Attacker	[human]

Rationale: Government and regulated environments commonly deploy HTTPS proxy decryption. Insider threat is a distinct pattern — the attacker already has legitimate access and the attack originates from inside the network.

What it validates:

• HTTPS proxy infrastructure provisioning (proxy + CA certificate)
• PCAP with proxy-decrypted traffic (full payload visibility)
• Insider threat patterns (no initial access phase; starts from credential abuse or policy violation)
• Normal and malicious activity from the same host (harder to distinguish than external attacks)

Key artifacts:

• PCAP: Full plaintext visibility through proxy decryption; both normal browsing and insider activity captured in cleartext
• Sysmon JSONL: Endpoint telemetry where the attacker is a legitimate user

---

3.4 AC-4: Medium Enterprise / TLS + E2E / Composite Threat (Phase 2)

Axis	Value
Scale	medium
Encryption	[tls, e2e]
Workload	[endpoint, server, cloud]
Threat	[insider, external, exfiltration, automated]
Attacker	[human, ai_assisted]
AI Agent	[internal, external]

Rationale: A composite case that stress-tests the Generator with multiple values on most axes simultaneously. While AC-1 through AC-3 each isolate a single encryption architecture and threat type, AC-4 represents a realistic medium-scale enterprise where multiple conditions coexist: both TLS and E2E encrypted channels, endpoints alongside servers and cloud services, and a mixed threat landscape including AI-assisted attackers. The presence of internal and external AI Agents adds the Phase 2–3 dimensions.

This case is designed to be implemented after Phase 1 infrastructure is proven. It validates that the Generator can handle multi-value axes and complex infrastructure at scale.

What it validates:

• Medium-scale infrastructure provisioning (more hosts, more network segments)
• Mixed encryption: TLS on most traffic, E2E on specific channels (limited visibility by design)
• All three workload types running concurrently (endpoint + server + cloud)
• Multi-vector threat scenario with overlapping attack timelines
• AI-assisted attacker behavior alongside human attacker
• AI Agent traffic generation (both internal and external)
• Cloud service access log collection
• Ground Truth recording for complex, overlapping attack sequences

Key artifacts:

• PCAP: Mixed encrypted traffic — TLS flows (metadata-only analysis) and E2E flows (opaque)
• Sysmon JSONL: Windows endpoint telemetry
• Falco JSONL: Linux server and AI Agent container telemetry
• DB logs: Database access from both legitimate services and attack activity
• Cloud logs: Cloud service API calls, credential usage, unauthorized access attempts

---

4. Coverage Analysis

4.1 What Phase 1 Covers (AC-1, AC-2, AC-3)

Axis	Covered Values	Anchor Cases
Scale	small	AC-1, AC-2, AC-3
Encryption	tls, tls_termination, https_proxy	AC-1, AC-2, AC-3
Workload	endpoint, server	AC-1/AC-3 (endpoint), AC-2 (endpoint+server)
Threat	exfiltration, external, insider	AC-1, AC-2, AC-3
Attacker	human	AC-1, AC-2, AC-3

4.2 What Phase 2 Adds (AC-4)

Axis	Newly Covered Values
Scale	medium
Encryption	e2e
Workload	cloud
Threat	automated
Attacker	ai_assisted
AI Agent	internal, external

4.3 Remaining Gaps After All Anchor Cases

Axis	Uncovered Values	Deferred To
Scale	large	Phase 4
Attacker	scripted, ai_actor	Phase 2+
AI Control	monitoring, enforcement	Phase 3

4.4 Extension Strategy

AC-1 through AC-3 establish the foundation in Phase 1 with simple, isolated cases. AC-4 extends coverage in Phase 2 by combining multiple axis values in a single complex scenario.

Remaining gaps are filled incrementally:

• AI Actor: Add ai_actor attacker variant to proven infrastructure
• AI Control: Add monitoring/enforcement to AI Agent environments in Phase 3
• Large scale: Increase host count and network complexity in Phase 4

---

5. From Anchor Case to Scenario Definition

Each anchor case defined above becomes a concrete .scenario.yaml file. This document defines the what and why (which axis combination and the rationale); the Scenario Definition file defines the how (specific hosts, network topology, activity timeline, tool configuration).

The Scenario Definition files for these anchor cases will be created during Generator implementation and stored in the repository.