Implementing the Assumed Breach Doctrine: A Practitioner's Guide to Telemetry-First Detection Engineering

Abstract

The Assumed Breach Doctrine states a fundamental inversion in how we approach security operations: we are breached until our telemetry proves otherwise. While the theoretical implications of this shift are profound, replacing binary alerts with continuous inference, and static rules with Bayesian belief states, the practical reality of implementing such a system can be daunting for many organizations.

This paper serves as the technical companion to the Assumed Breach Doctrine. It is written specifically for detection engineers, security architects, and SOC leads who must turn this philosophy into operational reality. We discard abstract theory in favor of actionable engineering. You will find no hand-waving here. Instead, we provide a structured, phased adoption path (Crawl, Walk, Run, Fly), concrete tooling recommendations, code snippets, and configuration architectures designed to build a telemetry-first detection capability that can survive the real world.

Whether you are a five-person team struggling with SIEM costs or a mature enterprise building a cross-domain security data lake, this guide provides the blueprint to systematically measure, manage, and reduce your epistemic uncertainty. We focus on continuous inference, mathematical frameworks, and practical deployment models that scale.

---

Part I: Foundations

Chapter 1: Minimum Viable Inference (MVI) and The Telemetry Tax

The instinct of most security organizations moving toward a telemetry-first model is to collect everything. This is a profound mistake. Comprehensive telemetry is brutally expensive, and ingesting petabytes of unparsed logs into a SIEM creates noise, not inference. In a traditional enterprise, log volume grows exponentially as the business adopts microservices, cloud infrastructure, and multi-factor authentication everywhere. If you blindly route everything to a SIEM, you run headfirst into the "telemetry tax."

The Telemetry Tax

Comprehensive telemetry is expensive. Not theoretically, brutally, in actual budget terms. Consider the reality of SIEM ingestion. Commercial SIEMs often cost approximately $4.30 to $5.59 per gigabyte, while legacy systems can run significantly higher at enterprise scale. A mid-size enterprise easily generates 500GB to 2TB of security-relevant logs per day. At an average of $5/GB, ingesting 1TB/day equals roughly $1.8 million per year just for data ingestion, before accounting for storage retention, compute overhead for queries, or the engineering talent required to maintain it.

Security organizations spend 5-15% of the overall IT budget on security, and roughly 70% of that goes to prevention, operations, and compliance. Detection engineering usually gets less than 10%. You cannot brute-force the Assumed Breach Doctrine through indiscriminate data collection.

The Three Laws of Telemetry Thermodynamics

To avoid bankruptcy while pursuing Assumed Breach, engineers must internalize the three fundamental laws governing data collection:

1. The Law of Diminishing Returns (The Volume Paradox): The volume of logs generated by a system scales exponentially, but the unique tactical value of those logs scales logarithmically. Collecting 10 million DNS requests provides immense value; collecting the next 10 million provides almost zero marginal value unless an adversary is actively beaconing in that exact slice of time.

2. The Law of Conservation of Complexity: Complexity cannot be destroyed; it can only be shifted. If you choose not to filter logs at the endpoint (to save CPU cycles on the host), you shift that complexity to the SIEM, requiring massive compute to parse and correlate the noise. If you choose not to normalize logs centrally (to save engineering time), you shift that complexity onto the detection engineer, who must write five different variations of the same rule for five different vendors.

3. The Law of Entropy (Log Rot): Data without a strictly defined schema and an active, validated detection rule running against it will decay into noise. Unqueried logs sitting in an index are indistinguishable from random bytes. You pay to store them, but they provide zero inference.

Defining Minimum Viable Inference (MVI)

Instead of collecting everything, we borrow a concept from software engineering and apply it to detection: Minimum Viable Inference (MVI).

MVI is defined as the smallest set of telemetry, detections, and inference logic that meaningfully reduces the probability of an undetected breach in the most critical segments of your organization. It forces a focus on signal over volume.

The MVI formula is strict: MVI = High-Value Telemetry + Top Technique Coverage + Explicit Coverage Visibility

To achieve MVI, you must stop asking, "What logs can we collect?" and start asking, "What logs provide the highest inference value per dollar spent?" A telemetry source that costs $50,000 a year to ingest but only covers three obscure MITRE ATT&CK techniques is actively harming your security program. MVI ensures that every byte of telemetry ingested actively contributes to reducing the epistemic uncertainty of a breach.

MVI Across Organization Sizes

The implementation of MVI varies drastically based on the size and architecture of the organization.

• The 50-Person Start-Up (Cloud-Native): MVI means collecting AWS CloudTrail logs and Okta authentication logs. You don't need endpoint telemetry immediately because endpoints are stateless thin clients. Inference relies on API gateway anomalies, IAM role assumption shifts, and access token manipulation.
• The 500-Person Mid-Market Company (Hybrid): MVI means EDR telemetry on endpoints and servers, plus Entra ID / Active Directory authentication logs. Network logs and firewalls take a backseat to endpoints and identity. The focus is on processes and user behavior.
• The 5000-Person Enterprise (Multi-Domain): MVI expands to include hybrid multi-cloud integration, but still restricts ingestion to high-ROI event IDs. EDR, Identity, and DNS are the bedrock. Everything else is routed to a cost-effective data lake. This architecture achieves a 40-70% savings compared to traditional SIEM ingestion, while maintaining high-fidelity inference capabilities.

---

Chapter 2: Telemetry ROI Tiers

Not all telemetry is created equal. Some log sources cover exponentially more attack surface than others. To operationalize MVI and avoid the telemetry tax, we categorize telemetry into four explicit ROI tiers. This structured approach allows organizations to iteratively build their inference engine without overwhelming their infrastructure or their analysts.

Tier 1: Must Have (High Signal, Low/Medium Volume)

• Sources: EDR telemetry, Identity/Auth logs (Entra ID, Okta, Active Directory Event IDs 4624/4625).
• ATT&CK Coverage: Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Lateral Movement.
• Why it matters: Identity is the new perimeter. EDR is the ground truth. Together, they form the core of any inference engine. Without these, you are flying blind. Attackers must authenticate, and they must execute code on an endpoint.
• Priority: Deploy first. If you don't have this, do not proceed to Tier 2.

Tier 2: High Value (Medium Signal, Medium Volume)

• Sources: DNS logs, Firewall/Proxy logs, PowerShell Script Block Logging (Event 4104), Process Creation (Sysmon Event 1 / Windows 4688).
• ATT&CK Coverage: Command & Control (C2), Exfiltration, Initial Access, Execution.
• Why it matters: DNS is the nervous system of modern malware. Almost every C2 beacon must resolve a domain. Process creation logs provide the lineage and context that standalone EDR sometimes misses, especially for living-off-the-land techniques.
• Priority: Week 1-4 rollout.

Tier 3: Contextual (Low/Medium Signal, High Volume)

• Sources: Cloud Control Plane (CloudTrail, Azure Activity), Email Gateway, Data Loss Prevention (DLP), Web Application Firewalls (WAF).
• ATT&CK Coverage: Collection, Impact, Cloud-Specific TTPs.
• Why it matters: Cloud logs are immensely valuable but incredibly noisy. A single misconfigured automated lambda can generate millions of events. They provide critical context but require advanced filtering and normalization to be useful for inference.
• Priority: Month 2-3.

Tier 4: Full Spectrum (Domain Specific)

• Sources: OT/ICS logs (Modbus, DNP3, Historians), SaaS API telemetry (Salesforce, GitHub), NetFlow.
• ATT&CK Coverage: Full cross-domain inference, specialized environments, supply chain attacks.
• Why it matters: Required for organizations with physical infrastructure or complex third-party SaaS reliance. These sources are often highly specific and require specialized parsers and inference logic.
• Priority: Month 4-12.

The 80/20 Insight: Tier 1 and Tier 2 telemetry combined cover approximately 60-70% of commonly used ATT&CK techniques. Most organizations already generate this data. By focusing exclusively on Tiers 1 and 2 during the initial rollout, you can build a highly effective inference engine without procuring a single new sensor. This is the essence of MVI.

The Art of Telemetry Filtering (Data Dropping)

To optimize ROI within Tiers 1 and 2, you must ruthlessly drop low-value events before they ever reach your SIEM. Do not pay to ingest noise. This requires inserting a telemetry pipeline tool, such as Cribl Stream, Vector, or Logstash, between your endpoints and your SIEM.

Consider Windows Event ID 4688 (Process Creation). It is a vital log source, but if ingested raw, it is catastrophically expensive. A single domain controller might generate 50 GB of 4688 logs a day. Instead of sending it all to the SIEM, use your pipeline tool to apply explicit filters at the edge:

1. Drop High-Volume Benign Processes: Filter out process creations where Image equals C:\Windows\System32\conhost.exe or C:\Program Files\SplunkUniversalForwarder\bin\splunkd.exe.
2. Drop Known Scheduled Tasks: Filter out execution of specific software updaters that you have baselined.
3. Route for Retention: Send the heavily filtered, high-signal 4688 logs to the SIEM for real-time alerting. Send the raw, unfiltered 4688 firehose directly to your cheap S3 Data Lake (as outlined in the RUN phase) for compliance and retroactive threat hunting.

This edge-filtering strategy often reduces SIEM ingestion volumes by 30-50%, instantly freeing up budget.

SIEM Contract Negotiation Strategies

Once you adopt the MVI mindset and deploy edge filtering, your relationship with your SIEM vendor fundamentally changes. You are no longer held hostage by uncontrolled log growth. When negotiating your next SIEM renewal, leverage this architecture:

• Shift to Compute-Based Pricing: Demand to move away from ingest-based pricing (per GB/day) to compute-based pricing (vCPU/hour) if possible. If you filter heavily and search efficiently, compute pricing is drastically cheaper.
• The Data Lake Threat: Openly communicate to the vendor that you have an S3/Iceberg data lake architecture in place. Show them that if they raise ingest prices, you can effortlessly route Tier 2 telemetry away from the SIEM and into the data lake using your pipeline tool (Cribl/Vector). The threat of immediate data diversion is the strongest negotiating leverage a CISO possesses.

---

Chapter 3: Your First Coverage Map

You cannot secure what you cannot measure. The foundational metric of the Assumed Breach Doctrine is your Coverage Bound, the percentage of known attack techniques your telemetry can observe. If your coverage is 40%, you have a permanent 60% probability floor of undetected breach. No amount of threat hunting or AI can close a gap where telemetry simply doesn't exist.

To measure this mathematically, we use the open-source DeTT&CT (Detect Tactics, Techniques & Combat Threats) framework. DeTT&CT forces you to score your data quality and your detection quality honestly. It removes the illusion of security and replaces it with a quantifiable metric.

Step-by-Step Guide to Your First Map

1. Environment Setup: Ensure you have Python 3 installed. This framework will parse your YAML configurations and map them to the MITRE ATT&CK framework.

git clone https://github.com/rabobank-cdc/DeTTECT.git
cd DeTTECT
pip install -r requirements.txt

1. Define Data Sources (data-sources.yaml): You must document what telemetry you actually have, not what you think you have. Rate the data quality in terms of completeness, retention, and timeliness.

data_sources:
  - name: Sysmon Event ID 1 (Process Creation)
    provider: Windows
    quality:
      device_completeness: 4 # Applied via GPO to 95% of fleet
      data_field_completeness: 5 # Includes command line and hashes
      timeliness: 4 # Near real-time
      retention: 3 # 30 days in SIEM
  - name: Active Directory Auth (4624/4625)
    provider: Domain Controllers
    quality:
      device_completeness: 5 # All DCs forwarding
      data_field_completeness: 5
      timeliness: 5 # Real-time
      retention: 4 # 90 days

1. Map Existing Detections (detections.yaml): Document your existing detection rules against ATT&CK techniques. This requires absolute intellectual honesty. The most common pitfall in this phase is the "Watermelon Effect", a coverage map that looks beautifully green on the outside to executives, but is completely red and broken on the inside.

The Watermelon Effect occurs when an engineer maps a rule to an ATT&CK technique simply because the rule exists, without validating if the rule actually works against modern variations of the technique. A rule designed to catch Mimikatz by strictly alerting on the string "mimikatz.exe" in the command line does not mean you have coverage for OS Credential Dumping (T1003). It means you have coverage for lazy attackers. A rule with a 90% false-positive rate that analysts automatically ignore also has an effective coverage of zero.

Be ruthless in your scoring. We recommend using a strict 1-5 confidence scoring system for your rules:

• Score 1: The rule exists, but is disabled, universally ignored, or entirely trivial to bypass.
• Score 2: The rule detects a specific, rigid indicator (like a known bad hash or a hardcoded file path). Easily bypassed.
• Score 3: The rule detects the behavioral outcome (e.g., lsass.exe memory access), but suffers from high false-positive rates that mask true positives.
• Score 4: The rule detects the underlying capability via robust behavioral analysis, is actively tuned, and has a low false-positive rate.
• Score 5: The rule detects the capability, is mathematically resilient to evasion (e.g., process invariant monitoring), and is continuously validated via automated BAS testing.

detections:
  - name: Suspicious Encoded PowerShell
    technique_id: T1059.001
    score: 3 # Good detection, but requires ongoing FP tuning for SCCM
    data_sources:
      - Sysmon Event ID 1 (Process Creation)
  - name: LSASS Memory Access
    technique_id: T1003.001
    score: 4 # High fidelity behavioral detection
    data_sources:
      - Sysmon Event ID 10
  - name: Unsigned Binary Execution in Temp
    technique_id: T1036.005
    score: 1 # Watermelon rule - disabled due to extreme noise
    data_sources:
      - Windows Event ID 4688

1. Generate the Heatmap: Use DeTT&CT to parse your YAML files and output a MITRE ATT&CK Navigator JSON layer. This process translates your raw configuration into a visual representation of your coverage. The python script mathematically aggregates the scores of individual rules mapped to a technique to provide a composite coverage score.

python dettect.py d -f detections.yaml -l json

1. Visualize and Report: Import the JSON into the ATT&CK Navigator (https://mitre-attack.github.io/attack-navigator/). The resulting heat map will visually display your coverage gaps. Red means blind (no data sources or no rules). Yellow means partial (Score 2 or 3 rules). Green means covered (Score 4 or 5 rules).

The visual map is not a vanity metric; it is an engineering roadmap. If your organization is heavily targeted by ransomware, you immediately cross-reference your green blocks against the standard ransomware playbook (e.g., T1078 Valid Accounts, T1486 Data Encrypted for Impact, T1490 Inhibit System Recovery). If those specific squares are red, your EDR investment is failing you, regardless of how many other squares are green.

Success Criterion for Part I: You can present a single-page report to leadership that says: "We cover 42% of known ATT&CK techniques with a confidence score of 3 or higher. Our top unmitigated blind spots are T1055, T1071, and T1562. Closing these requires deploying Sysmon to the Linux fleet and ingesting proxy logs, which will cost X investment." This report forms the mathematically sound basis of your engineering roadmap and justifies future telemetry investments.

---

Part II: The Adoption Path

The doctrine is a direction of travel. We structure this journey in four phases. Do not attempt to skip phases. The failure mode of most detection engineering programs is attempting to jump straight to machine-learning anomaly detection before they have mastered basic visibility and alerting hygiene.

Chapter 4: CRAWL, Baseline Visibility (Months 1–3)

Objective: Know what you can see. Deploy initial high-fidelity detections. Establish documentation standards.

In the Crawl phase, you operate exclusively on Tier 1 and Tier 2 telemetry. You will manually deploy rules to your existing SIEM or EDR, but you will do so systematically. The goal here is not to build a complex automated pipeline (that comes later), but to establish a culture of engineering discipline around your alerts. You must treat detection rules as code, even if you are currently deploying them manually.

The Palantir Alerting and Detection Strategy (ADS) Standard

Every rule deployed must have rigorous documentation. We adopt the Palantir ADS framework. A rule without an ADS document is technical debt. The ADS requires you to define the Goal, Categorization, Technical Context, Blind Spots, and False Positives for every rule. This ensures that when a rule fires at 3 AM, the SOC analyst knows exactly why it fired, what it means, and what it misses.

A well-written ADS document prevents the "tribal knowledge" problem, where only the author of the rule knows how to interpret the alert. It also forces the detection engineer to honestly confront the limitations of the rule before it is deployed.

Quick Wins (The Top 5 Techniques)

Instead of writing custom rules from scratch, rely on the open-source Sigma community. Sigma is the generic signature format for SIEM systems. Start by deploying detections for the top 5 techniques (per Red Canary's Threat Detection Report). These techniques are consistently used by adversaries year after year, and covering them provides immediate ROI.

1. Command & Scripting Interpreter (T1059): Catch encoded PowerShell. Adversaries use encoded PowerShell to obfuscate their commands and bypass simple string matching. By encoding payloads in Base64 (using the -enc or -EncodedCommand flags), attackers can hide malicious scripts from static analysis engines and easily deliver complex commands directly via the command line without writing secondary files to disk.

This technique matters because PowerShell is ubiquitous in modern Windows environments and provides deep access to the .NET framework and Windows API. When an adversary establishes initial access, they rarely bring their own tools immediately; instead, they "live off the land" by utilizing PowerShell to download secondary payloads, enumerate Active Directory, or execute fileless malware directly in memory.

title: Suspicious Encoded PowerShell Command
id: 3d304fda-78aa-43ed-975c-d740798a49c1
status: stable
description: Detects the execution of PowerShell with suspicious encoding flags.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains|all:
            - 'powershell'
            - '-enc'
    condition: selection
falsepositives:
    - SCCM or management scripts
    - Legacy IT administration tasks
level: high

Tuning Guidance: SCCM, Tanium, and other endpoint management tools often use encoded PowerShell for benign tasks. You must baseline your environment and create exclusions for the specific service accounts and parent processes associated with these tools. For example, if you see Tanium running -enc, add an explicit filter where ParentImage equals TaniumClient.exe. Do not blanket-allow all encoded commands.

Validation: You can validate this rule using Atomic Red Team. Execute the command Invoke-AtomicTest T1059.001 -TestNumbers 1. This will simulate an adversary running a benign Base64-encoded PowerShell command, which should immediately trigger your detection rule in the SIEM without causing any harm to the host.

1. Signed Binary Proxy Execution (T1218): Catch LOLBin abuse like rundll32 executing malicious payloads. Adversaries use legitimate Windows binaries (Living-off-the-Land Binaries, or LOLBins) to execute their code, bypassing application allowlisting (like AppLocker) and evading endpoint controls. Since rundll32.exe is a Microsoft-signed binary natively designed to execute code within DLL files, executing malicious payloads through it masks the adversary's actions.

This technique is critical to monitor because it breaks the fundamental assumption of naive EDR controls, that only "unsigned" or "unknown" executables are dangerous. By loading an attacker-controlled DLL via rundll32.exe, the malicious code runs within the context of a trusted Microsoft process, rendering simple hash-based blocking entirely useless.

title: Suspicious Rundll32 Execution Without DLL File
id: cdc8cbde-c5aa-4dfa-8bb7-e03a95d7eb80
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\rundll32.exe'
    filter:
        CommandLine|contains: '.dll'
    condition: selection and not filter
falsepositives:
    - Rare third-party installers or legacy applications
    - Control Panel applet execution (.cpl files)
level: high

Tuning Guidance: This rule looks for rundll32.exe executing without a .dll extension in the command line. While rare, false positives may occur with certain legacy software or Control Panel applets (.cpl files). To tune, add filters for known .cpl files executing out of C:\Windows\System32\ if they generate noise.

Validation: Validate this rule with Atomic Red Team using Invoke-AtomicTest T1218.011 -TestNumbers 1. This test will use rundll32.exe to execute a JavaScript payload (like a popup dialog) without a .dll extension, which should successfully trigger the detection logic in your pipeline.

1. Windows Management Instrumentation (T1047): Detect remote WMI execution. Windows Management Instrumentation (WMI) is a powerful, built-in administrative framework that allows for deep system introspection and remote management. Adversaries abuse WMI for lateral movement, execution of payloads, and gathering system information without needing to drop custom RATs (Remote Access Trojans) onto the target machine.

Monitoring WMI is vital because it often blends seamlessly with legitimate administrative traffic. When an adversary uses WMI to spawn a process on a remote machine (like cmd.exe or powershell.exe), the process parent is the WMI Provider Host (WmiPrvSE.exe). This breaks the expected process lineage and is a strong indicator of remote execution.

title: Suspicious WMI Process Creation
id: a24c7f1f-4b05-4c07-8df2-a3c9f28d8ed4
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith: '\WmiPrvSE.exe'
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
    condition: selection
falsepositives:
    - IT admin remote administration scripts via WMI
    - Automated vulnerability scanners
level: high

Tuning Guidance: IT administrators often use WMI for legitimate remote management, which will trigger this rule. You must identify the source IPs (e.g., admin jump boxes) or user accounts associated with these admin activities and filter them out. Similarly, internal vulnerability scanners (like Nessus or Qualys) may spawn shells via WMI to gather patch levels. Add explicit exclusions for their service accounts.

Validation: Use Atomic Red Team to test this by running Invoke-AtomicTest T1047 -TestNumbers 2. This will simulate using wmic.exe to spawn a cmd.exe process, accurately replicating the remote execution behavior and confirming your logging pipeline captures WmiPrvSE.exe as the parent.

1. OS Credential Dumping (T1003): Monitor LSASS memory access. Adversaries target the Local Security Authority Subsystem Service (LSASS) memory to extract plaintext credentials, NTLM hashes, and Kerberos tickets. Tools like Mimikatz, procdump, and even the native Task Manager can be used to read or dump the memory of this critical process, providing the attacker with the keys needed for lateral movement.

This technique is arguably the most critical junction in an attack path. If an adversary successfully dumps LSASS on a machine where a Domain Admin has recently logged in, they can escalate privileges to compromise the entire Active Directory environment. Detecting unusual access requests to the lsass.exe process is an incredibly high-fidelity indicator of credential theft.

title: Suspicious LSASS Process Access
id: 32d0d3e2-e58d-4d41-926b-18b520b2b32d
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess: '0x1010'
    filter:
        SourceImage|endswith:
            - '\taskmgr.exe'
            - '\csrss.exe'
            - '\svchost.exe'
    condition: selection and not filter
falsepositives:
    - Antivirus engines performing legitimate memory scans
    - EDR agents
    - Specific system monitoring tools
level: critical

Tuning Guidance: You must rigorously exclude your EDR and Antivirus processes from this rule, as they legitimately access LSASS to monitor for malicious hooks. Only exclude specific, signed binaries from known paths (e.g., C:\Program Files\YourAV\av.exe). Do not exclude based on process name alone, as attackers will simply rename their dumping tool.

Validation: Trigger this detection via Atomic Red Team using Invoke-AtomicTest T1003.001 -TestNumbers 1. This test will utilize the Sysinternals tool procdump.exe to create a minidump of the LSASS process, perfectly mimicking how an adversary extracts memory for offline parsing.

1. Scheduled Task/Job (T1053): Detect persistence mechanisms via schtasks.exe. Adversaries create scheduled tasks to maintain persistence across reboots and to execute payloads repeatedly over time. By using the native Windows schtasks.exe utility, attackers ensure their malicious implants or beaconing scripts start automatically whenever the system turns on or a specific user logs in, without needing to modify the registry or drop binaries in startup folders.

Detecting anomalous scheduled tasks is vital because it is one of the most common and reliable persistence techniques observed in ransomware and APT campaigns. When an attacker specifies the SYSTEM user for the task, they also achieve privilege escalation, allowing their payload to run with the highest local privileges.

title: Suspicious Scheduled Task Creation
id: 92626ddd-662c-49e3-ac59-f6535f12d189
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\schtasks.exe'
        CommandLine|contains:
            - '/create'
            - 'SYSTEM'
            - 'VBScript'
    condition: selection
falsepositives:
    - Patch management systems
    - Automated software updaters (e.g., Google Chrome update tasks)
level: high

Tuning Guidance: Benign software updaters (like browser updates or Adobe updaters) frequently create scheduled tasks. Tune this by excluding the specific parent processes of your approved software inventory. For instance, if an approved enterprise application creates a task on installation, create a specific exception linking the installer's hash or signed path to the schtasks.exe child process.

Validation: Run Invoke-AtomicTest T1053.005 -TestNumbers 1 with Atomic Red Team. This test will create a scheduled task named "Atomic Red Team" that is set to execute a basic command. Verify that the task creation event (process creation of schtasks.exe with the /create flag) is captured and triggers the alert.

Deliverable: Your first Coverage Report demonstrating your current baseline and the explicit gaps you intend to close. This marks the end of the Crawl phase. You now know what you can detect, and your detections are documented.

---

Chapter 5: WALK, Detection as Code (Months 3–9)

Objective: Automate rule lifecycle. Eliminate ad-hoc SIEM queries. Transition to engineering.

Writing a query in a SIEM GUI and clicking "Save as Alert" is an anti-pattern. It lacks version control, peer review, and automated testing. In the Walk phase, we implement Detection-as-Code (DaC). We move the source of truth for detections out of the SIEM and into a version-controlled repository.

CI/CD Pipeline Architecture

Your detection rules live in a Git repository. A push to the repository triggers an automated pipeline. This pipeline ensures that no broken or syntactically invalid rule ever reaches production.

Git Push → Validate → Translate → Test → Shadow Mode → Deploy

GitHub Actions Workflow YAML: Below is a complete, production-ready GitHub Actions workflow. It validates the Sigma syntax, translates the rules into Splunk SPL, tests them against log fixtures, and automatically deploys them to Splunk via the REST API if all tests pass.

name: Detection-as-Code Pipeline
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

env:
  SPLUNK_URL: ${{ secrets.SPLUNK_URL }}
  SPLUNK_TOKEN: ${{ secrets.SPLUNK_TOKEN }}

jobs:
  validate-and-translate:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Repository
      uses: actions/checkout@v3
    
    - name: Set up Python 3.10
      uses: actions/setup-python@v4
      with:
        python-version: '3.10'
        
    - name: Install Sigma CLI and Backends
      run: |
        python -m pip install --upgrade pip
        pip install sigma-cli pysigma-backend-splunk
      
    - name: Validate Sigma Rules Syntax
      run: |
        echo "Validating YAML structure and Sigma spec..."
        sigma check rules/
      
    - name: Translate to Splunk SPL
      run: |
        echo "Translating rules to SPL using the windows-sysmon pipeline..."
        mkdir -p output/
        sigma convert -t splunk -p sysmon rules/ -o output/splunk_rules.json -f json
        
    - name: Upload Artifacts
      uses: actions/upload-artifact@v3
      with:
        name: splunk-rules
        path: output/splunk_rules.json

  test-fixtures:
    needs: validate-and-translate
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    - name: Download Translated Rules
      uses: actions/download-artifact@v3
      with:
        name: splunk-rules
        path: output/
        
    - name: Run Pytest against Log Fixtures
      run: |
        pip install pytest
        # This script runs the SPL against local JSON log fixtures to ensure the rule fires.
        pytest scripts/test_rules.py --rules output/splunk_rules.json --fixtures tests/fixtures/

  deploy-to-splunk:
    needs: test-fixtures
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    - name: Download Translated Rules
      uses: actions/download-artifact@v3
      with:
        name: splunk-rules
        path: output/
        
    - name: Deploy to Splunk API
      run: |
        pip install requests
        # Script pushes the JSON definitions to Splunk's /services/saved/searches endpoint
        python scripts/deploy_splunk.py --rules output/splunk_rules.json --shadow-mode true

Pipeline Stages Explained:

1. Validate: The sigma check command ensures the YAML is perfectly formed and adheres to the Sigma specification. If an engineer makes a typo in a field name, the build fails here.
2. Translate: The sigma convert command uses the pysigma-backend-splunk to translate generic Sigma logic into Splunk SPL. We output this as JSON so it can be easily parsed by the deployment script.
3. Test: The test_rules.py script takes known-bad log events (fixtures) and evaluates the translated SPL against them locally. If the SPL doesn't match the fixture, the logic is flawed, and the build fails.
4. Deploy: Finally, a Python script makes POST requests to the Splunk REST API (/services/saved/searches), updating or creating the saved searches. Note the --shadow-mode true flag, which ensures new rules do not immediately trigger PagerDuty.

Shadow Mode Implementation

All new rules must run in a logging-only (shadow) mode for a minimum of 7 to 14 days. During this period, the rule tags events but does not generate an alert for the SOC. The detection engineer reviews the false-positive rate. Deploying an untested rule directly to the SOC is a failure of engineering discipline.

How to implement Shadow Mode technically:

• In Splunk: When creating the saved search via the API, set the action.notable flag to 0 (disabled) and instead write the results to a summary index (e.g., index=shadow_detections). The SOC dashboards ignore this index, but detection engineers can query it using index=shadow_detections source="Rule_Name" to measure the false positive volume over a week.
• In Elastic Security: Create the rule using the Detection Engine API but set the actions array to be empty (no Jira ticket or Slack message generated) and assign a specific tag like shadow_mode: true. SOC analysts filter their alert queues to NOT tags: "shadow_mode".

The 20% Debt Reduction Practice

Alert fatigue destroys security teams. You must dedicate 20% of your detection engineering capacity entirely to tuning and deprecation. If a rule generates too many false positives and cannot be tuned within a reasonable timeframe, it must be deprecated or returned to shadow mode. Do not let stale, noisy rules rot in your SIEM.

Worked Example of Debt Reduction: Suppose your "Suspicious WMI Process Creation" rule generated 150 alerts last week, and 148 were false positives.

1. Identify the Noise: The engineer analyzes the 148 false positives. 130 of them were caused by the internal vulnerability scanner (QualysGuard.exe) launching WMI queries across the subnet. 18 were caused by an automated IT patch script running from a specific jump box (10.0.5.50).
2. Author the Tune: The engineer updates the Sigma rule in Git, adding to the filter section:

   filter_scanners:
       SourceImage|endswith: '\QualysGuard.exe'
   filter_jumpbox:
       SourceIP: '10.0.5.50'
   condition: selection and not (filter_scanners or filter_jumpbox)
   

3. Commit and Test: The engineer commits the tune. The CI/CD pipeline runs, translating the new filters and deploying the updated rule to the SIEM.
4. Result: The next week, the rule generates 2 alerts. Both are true positives. The SOC's trust in the alert is restored. This is the ROI of the 20% debt practice.

Threat Hunting Integration

Threat hunting transforms from an ad-hoc exercise into a continuous validation loop. Every month, conduct a hypothesis-driven hunt targeting the red spots on your DeTT&CT map. A successful hunt must result in a new, tested Sigma rule added to the pipeline.

The cadence looks like this:

1. Identify Gap: The coverage map shows a gap in detecting T1071 (Application Layer Protocol).
2. Hypothesis: "If an attacker is using HTTP for C2, we will see anomalous User-Agent strings or beaconing behavior in our proxy logs."
3. Hunt: Query proxy logs for rare User-Agents or periodic timing patterns.
4. Result: Identify a gap in parsing. Fix the parsing, and write a new Sigma rule to detect the specific anomalous behavior.
5. Deploy: Push the rule through the CI/CD pipeline.

Schema Standardization

To prepare for cross-domain correlation in the RUN phase, begin adopting schema standardization now. We recommend beginning OCSF (Open Cybersecurity Schema Framework) normalization for Tier 1-2 sources. This ensures that a src_ip is always a src_ip, regardless of whether the log came from a firewall, an EDR, or a cloud provider.

Metrics to Track

Your dashboard should transition from tracking "alerts closed" to tracking engineering metrics:

• False Positive Rate: Target < 10% for production rules.
• MTTD (Mean Time to Detect): Measured via regular automated testing (e.g., using Atomic Red Team).
• Detection Coverage %: The core metric from your DeTT&CT map.
• Rule Lifecycle Time: Time from initial draft to production deployment.

Success Criterion for Phase II: Every detection is code-reviewed, tested, and deployed via CI/CD. The SOC is no longer overwhelmed by noise, because every rule has been vetted in shadow mode.

---

Chapter 6: RUN, Data Lake & Cross-Domain Inference (Months 9–18)

Objective: Break the SIEM cost ceiling. Implement schema normalization. Begin cross-domain correlation.

At this stage, SIEM ingestion costs become the primary bottleneck to expanding coverage. You cannot achieve full Assumed Breach inference if you cannot afford to store the telemetry required to prove you are clean. We solve this by decoupling storage from analytics.

Security Data Lake Architecture

We transition from a monolithic SIEM to a hybrid architecture:

• Hot Data: Tier 1-2 telemetry stays in the SIEM for real-time, low-latency alerting where immediate SOC action is required (e.g., EDR alerts, high-confidence behavioral rules).
• Cold/Warm Data: Tier 3-4 telemetry is routed directly to a highly scalable, low-cost security data lake.

The Data Stack:

• Storage: Amazon S3, Azure Blob, or Google Cloud Storage.
• Format: Apache Parquet. This columnar, compressed format drastically reduces storage costs and query times compared to raw JSON.
• Table Management: Apache Iceberg. Iceberg enables schema evolution, time-travel queries, and ACID transactions on top of object storage. It allows the data lake to behave like a SQL database.
• Query Engine: Amazon Athena, Snowflake, or Databricks. You pay only for the compute used during the query, not for continuous ingestion.

The Telemetry Economics Table: To illustrate the necessity of the data lake, consider the monthly economics of logging at scale. Traditional SIEM vendors often charge ingestion fees (e.g., ~$5.00/GB) on top of infrastructure costs. Data lakes utilize commodity object storage (e.g., S3 at ~$0.023/GB) and charge only for compute when queried.

Daily Volume	Traditional SIEM Est. ($5/GB/mo)	Security Data Lake Est. ($0.50/GB/mo)*	Monthly Savings	Annual Savings
100 GB / day	$15,000 / mo	$1,500 / mo	$13,500	$162,000
500 GB / day	$75,000 / mo	$7,500 / mo	$67,500	$810,000
1 TB / day	$150,000 / mo	$15,000 / mo	$135,000	$1,620,000
*Data Lake estimate includes object storage, Parquet compression ratios, and average monthly compute/query costs.

Cost Target: Organizations transitioning to this hybrid model routinely report a 40–70% reduction in total telemetry spend, unlocking the budget necessary to ingest the Tier 3 and 4 logs required for continuous inference without bankrupting the security program.

Schema Normalization (OCSF)

To perform cross-domain correlation, your logs must speak the same language. We adopt the Open Cybersecurity Schema Framework (OCSF). This normalizes disparate vendor logs (e.g., AWS CloudTrail and Palo Alto Firewall) into a unified structure, allowing detection rules to be vendor-agnostic.

Cross-Domain Correlation Example (Detecting Lateral Movement): This SQL query correlates an Entra ID impossible travel alert (Identity domain) with an AWS console login (Cloud domain) and a subsequent suspicious process execution via SSM (Endpoint domain). Without a unified data lake and OCSF, joining these three distinct vendor logs in real-time is nearly impossible.

WITH identity_risk AS (
    -- 1. Find users with high-risk identity alerts in the last 24 hours
    SELECT actor.user.email, time AS alert_time
    FROM ocsf_identity_alerts
    WHERE risk_score > 80 
      AND time >= current_date - interval '1 day'
),
cloud_access AS (
    -- 2. Find AWS console logins from those compromised users
    SELECT c.actor.user.email, c.src_endpoint.ip, c.time AS login_time
    FROM ocsf_cloud_api_activity c
    JOIN identity_risk i ON c.actor.user.email = i.actor.user.email
    WHERE c.api.operation = 'ConsoleLogin'
      AND c.time > i.alert_time
)
-- 3. Find if the compromised user IP spawned a suspicious shell via AWS SSM
SELECT 
    ca.email, 
    ca.ip, 
    p.device.hostname, 
    p.process.cmd_line
FROM ocsf_process_creation p
JOIN cloud_access ca ON p.src_endpoint.ip = ca.ip
WHERE p.process.parent_name = 'amazon-ssm-agent.exe'
  AND (p.process.name = 'cmd.exe' OR p.process.name = 'powershell.exe')
  AND p.time > ca.login_time;

This is the essence of continuous inference: fusing weak signals across distinct domains to build a high-confidence belief state. An impossible travel alert alone is often a false positive (a user turned on a VPN). An SSM agent spawning a shell happens occasionally during administration. But the sequence of Impossible Travel -> Console Login -> SSM Shell yields a P(Breach) approaching 1.0.

OCSF Adoption Status and Challenges

While the Open Cybersecurity Schema Framework (OCSF) is the industry's best path toward vendor-agnostic data lakes, adoption is not without friction. The primary challenge is that legacy log sources (like older on-premise firewalls or legacy EDRs) do not natively emit OCSF JSON. To bridge this gap, engineering teams must deploy a translation layer, often using tools like Vector, Cribl Stream, or Logstash, to map proprietary vendor fields (e.g., PanOS.source_address) to the OCSF standard (src_endpoint.ip) before the data is written to the Iceberg tables. While this requires upfront engineering effort, it permanently decouples your detection logic from your vendors, allowing you to swap out a firewall or EDR vendor in the future without rewriting hundreds of SQL queries.

Breach and Attack Simulation (BAS)

Integrate BAS tools like Atomic Red Team into your CI/CD pipeline. The pipeline automatically replays attacks against a test environment, ensuring that the SIEM receives the logs, the detection rules parse them correctly, and the alerts actually fire.

Maturity Assessment

Map your team against the Elastic Detection Engineering Behavior Maturity Model (DEBMM). By the end of the Run phase, you should target the Intermediate (Tier 3) level, characterized by standardized schemas, automated testing, and hybrid storage architectures.

Success Criterion for Phase III: Unified schema across all domains. Detections continuously validated against simulated attacks. Data lake architecture sustainably managing terabytes of Tier 3-4 telemetry.

---

Chapter 7: FLY, Continuous Inference (Months 18–36)

Objective: Full belief state operations. The Assumed Breach Doctrine fully operationalized.

In the Fly phase, we abandon binary alerts in favor of continuous inference. We shift from "did an alert fire?" to "what is our current mathematical belief that we are breached?"

Multi-Signal Fusion via Dempster-Shafer Theory

Traditional SIEMs rely on Boolean logic: if condition X is met, trigger an alert. In the Fly phase, we use Dempster-Shafer evidence theory, a generalization of Bayesian inference, to fuse multiple weak signals into a high-confidence belief state. Dempster-Shafer is particularly useful in cybersecurity because it allows us to explicitly model ignorance (epistemic uncertainty), the things we don't know because we lack telemetry.

Consider a sequence of events over 30 minutes on a single workstation, Host-Win10-04. In a traditional SIEM, none of these individual events would cross the threshold to generate an alert, as doing so would cause unacceptable false positive rates:

1. Event 1 (Identity): 3 failed logins followed by a success. This happens daily when users mistype passwords. We assign a low basic probability assignment (BPA), or mass, to the hypothesis of Breach: m1(Breach) = 0.05. The remaining mass 0.95 is assigned to ignorance.
2. Event 2 (Endpoint): Execution of an encoded PowerShell command. While suspicious, this is often caused by SCCM. m2(Breach) = 0.08.
3. Event 3 (Network): A new DNS domain query to a recently registered .xyz domain. m3(Breach) = 0.12.
4. Event 4 (Endpoint): A novel SMB connection to a sensitive file share the user hasn't accessed in 90 days. m4(Breach) = 0.15.
5. Event 5 (Endpoint): LSASS memory access by a non-standard process. m5(Breach) = 0.35.

No single event crosses a typical 0.80 alert threshold. However, we fuse these independent observations using Dempster's rule of combination. The rule calculates the orthogonal sum of the masses.

Let's combine just the first two events: m1,2(Breach) = 1 - [ (1 - m1(Breach)) * (1 - m2(Breach)) ] m1,2(Breach) = 1 - [ (1 - 0.05) * (1 - 0.08) ] = 1 - [ 0.95 * 0.92 ] = 1 - 0.874 = 0.126

As we iteratively combine all five events, the fused mass of belief for a Breach grows non-linearly:

• Fusion 1+2: 0.126
• Fusion 1+2+3: 1 - (0.874 * 0.88) = 0.231
• Fusion 1+2+3+4: 1 - (0.769 * 0.85) = 0.346
• Fusion 1+2+3+4+5: 1 - (0.654 * 0.65) = 0.575

With just five weak signals, the mathematical belief state that Host-Win10-04 is breached has reached 57.5%. The system infers the breach from the aggregate behavior, without requiring a single perfectly deterministic signature.

Distributional Shift Monitoring

Instead of looking for specific bad things (signatures), we look for mathematical shifts in the distribution of normal things. We detect aggregate behavioral shifts using statistical measures like Kullback-Leibler (KL) divergence or Wasserstein distance on telemetry streams.

KL divergence measures how one probability distribution diverges from a second, expected probability distribution. In the Fly phase, you run scheduled analytics across the data lake to compare a host's behavior over the last 24 hours (the observation) against its behavior over the previous 30 days (the baseline).

• Process Entropy: A drop in process creation entropy on a workstation indicates a repetitive C2 beacon replacing diverse user activity. Normal users spawn hundreds of varied processes; a beaconing implant spawns the exact same cmd.exe or powershell.exe process every 60 minutes.
• Auth Timing: A shift from a Gaussian distribution (human work hours centered around 9 AM and 1 PM) to a uniform distribution (automated credential spraying or lateral movement occurring constantly through the night).
• DNS Query Patterns: A shift in the power-law distribution of DNS queries indicates a new, high-frequency C2 domain rising to the top of the request charts.

Python Implementation Example (KL Divergence on Auth Logs):

import numpy as np
from scipy.special import rel_entr

def calculate_auth_shift(baseline_probs, observed_probs):
    # Ensure no zero probabilities to avoid infinity in log
    epsilon = 1e-10
    P = np.array(observed_probs) + epsilon
    Q = np.array(baseline_probs) + epsilon
    
    # Normalize arrays so they sum to 1
    P /= np.sum(P)
    Q /= np.sum(Q)
    
    # Calculate KL Divergence
    kl_divergence = sum(rel_entr(P, Q))
    
    if kl_divergence > 0.5:
        return f"ALERT: Significant distributional shift detected! KL = {kl_divergence:.3f}"
    return f"Normal behavior. KL = {kl_divergence:.3f}"

# Example: Hourly authentication distribution
# Baseline: Gaussian curve around 9 AM
baseline = [0.01, 0.01, 0.01, 0.02, 0.05, 0.15, 0.25, 0.30, 0.10, 0.05, 0.03, 0.02]
# Observed: Uniform distribution (automated script running all night)
observed = [0.08, 0.08, 0.08, 0.08, 0.09, 0.08, 0.08, 0.08, 0.08, 0.09, 0.09, 0.09]

print(calculate_auth_shift(baseline, observed))
# Output: ALERT: Significant distributional shift detected! KL = 0.531

Honest Limitation: Distributional shift struggles against low-and-slow APTs that perfectly mimic normal behavior. If an attacker only beacons once a day, the KL divergence will not trigger. It is a powerful tool for catching automated, machine-speed attacks and noisy lateral movement, but it is one signal among many and must be fused with other evidence using Dempster-Shafer.

Action Band Integration

Operational response is driven by the continuous belief state, mapped to explicit action bands:

• Green (0.00-0.15): Normal operations. Continuous monitoring. No human intervention required.
• Yellow (0.15-0.40): Targeted threat hunt on the affected segment. The system automatically increases telemetry collection (e.g., moving from Tier 1 to Tier 3 collection for that specific host).
• Orange (0.40-0.70): Active investigation. Segment isolation initiated via SOAR. Incident Commander assigned.
• Red (0.70-1.00): Full incident response. Immediate containment and forensics.

Board Reporting and the Risk Dashboard

Reporting to the board shifts from reactive metrics ("we blocked 40,000 malware attacks this month") to proactive, mathematically grounded risk metrics. We call this "Probabilistic Security Posture."

Your dashboard should present three key numbers to executive leadership:

1. The Coverage Bound: "Given our current telemetry ingestion, we can confidently detect 62% of known MITRE ATT&CK techniques. To reach 75%, we require $X investment to ingest proxy and firewall logs into the data lake." This frames security as a capital allocation problem rather than a binary state of "secure" or "insecure."
2. The Baseline P(Breach): "Across our 10,000 endpoints, the average continuous belief state of compromise is currently 0.04. This is within our acceptable risk tolerance band."
3. Action Band Dwell Time: "This quarter, 12 hosts crossed into the Orange (Active Investigation) action band. Our SOAR platform isolated them in an average of 4.2 minutes. Zero hosts crossed into the Red band."

Success Criterion for Phase IV: The CISO never again answers "Are we breached?" with "I think we are okay." They answer with a number, a confidence interval, and a primary driver. Continuous inference is fully operational, and the Assumed Breach Doctrine is realized.

---

Part III: Special Contexts

The Assumed Breach Doctrine is not a one-size-fits-all framework. Different organizational structures and regulatory environments require adaptations. This part explores how to tailor the doctrine to small teams, privacy-conscious regions, and operational technology (OT) environments.

Chapter 8: The 5-Person Team Edition

The most common pushback to the Assumed Breach Doctrine is that it requires a Netflix-sized engineering team to implement. This is a misconception. While a 5-person security team cannot build a custom Bayesian inference engine or manage a complex Iceberg data lake, they can implement the core principles of the doctrine. In fact, small teams benefit the most from shifting away from reactive alert triage.

Ruthless Prioritization: MVT Only

A 5-person team must focus exclusively on Minimum Viable Telemetry (MVT). This means deploying robust detections solely for EDR and Identity (Tier 1). Do not attempt to ingest or parse DNS, firewall, or proxy logs until Tier 1 is fully operationalized, automated, and generating high-confidence signals.

Leverage the Community

Do not write custom rules. Your team does not have the capacity to research zero-days and write novel behavioral signatures. Instead, leverage the community. There are over 3,500 Sigma rules available in public repositories. Your engineering effort should be spent on testing and tuning these existing rules to fit your environment, not authoring them from scratch.

The Weekly Schedule

A small team must aggressively protect its time. A suggested weekly cadence:

• Monday/Tuesday: Incident response, alert triage, and operational tasks.
• Wednesday: Threat hunting (validating existing detections against DeTT&CT gaps) and rule tuning.
• Thursday: CI/CD pipeline maintenance and Breach and Attack Simulation (BAS) testing.
• Friday: The 20% Debt Day. Exclusively tune noisy rules and deprecate legacy alerts. If an alert has a high false positive rate, turn it off.

The Metric That Matters

For a small team, do not attempt to calculate complex Bayesian probabilities. Focus entirely on one metric: Detection Coverage % against the MITRE ATT&CK framework. Measure it every quarter. If you are at 35% in Q1, your goal is 40% in Q2.

The key insight: A 5-person team with 60% coverage and a known blind spot map has stronger security posture than a 50-person SOC drowning in 10,000 daily alerts with no coverage analysis.

---

Chapter 9: Privacy, Legal, and Compliance Constraints

The doctrine requires comprehensive behavioral telemetry. In privacy-conscious jurisdictions (such as the European Union under GDPR), this creates tension with principles of data minimization and employee monitoring.

Navigating GDPR and Data Minimization

Data minimization requires collecting only the data strictly necessary for a specific purpose. Continuous inference requires broad behavioral data. To reconcile this:

1. Pseudonymization: Hash usernames, IP addresses, and hostnames during the initial ingestion and inference phases. The belief state calculation does not need to know that "Alice in Accounting" generated an anomaly; it only needs to know that "User-Hash-X" deviated from its baseline. Only de-anonymize the data (via a logged, audited "break-glass" procedure) when the belief state crosses into the Orange action band (Active Investigation).
2. Graduated Collection: Implement baseline telemetry for all users, but reserve deep identity-correlated telemetry for high-risk segments (e.g., domain admins, critical infrastructure operators) or when a host's belief state enters the Yellow band.

Works Council Approvals

In European contexts, deploying EDR or behavioral monitoring often requires approval from a Works Council, which will actively resist anything resembling employee productivity monitoring.

Position the Assumed Breach inference model not as "employee monitoring" but as "infrastructure behavioral analysis." Emphasize that the system looks for machine-speed anomalies (e.g., automated credential spraying, process injection) and distributional shifts, not human productivity metrics. The use of pseudonymization is critical in gaining this approval.

Compliance as a Derivative Output

The Assumed Breach Doctrine fundamentally improves compliance reporting. Instead of providing point-in-time audit checkboxes, the inference engine provides continuous evidence of security controls. A report stating, "Our continuous inference engine has maintained a P(Breach) below 0.15 for 90 days across all in-scope PCI segments, with a verified coverage bound of 75%," is far more defensible to auditors than traditional compliance artifacts.

---

Chapter 10: OT/ICS Environments

Operational Technology (OT) and Industrial Control Systems (ICS) present unique challenges for the Assumed Breach Doctrine. Traditional IT telemetry (process creation, authentication) is often unavailable or irrelevant in a network of PLCs, RTUs, and SCADA servers.

Unique Telemetry Challenges

OT protocols (Modbus, DNP3, IEC 61850) and Historian logs require specialized parsers. You cannot simply forward Modbus traffic to a standard SIEM and expect useful inference. OT environments are also highly sensitive to active scanning or heavy agent deployments.

Process Invariant Monitoring

The defining characteristic of OT is that it is bound by physics. This provides a massive advantage for inference. We use Process Invariant Monitoring as a high-confidence inference source.

If a boiler has a physical maximum pressure increase of 10 PSI per minute, any telemetry indicating a 50 PSI jump is either a sensor failure or a cyber-physical attack. Invariants act as absolute constraints on the Bayesian likelihood. If an invariant is violated, P(Breach) immediately approaches 1.0.

Conversely, if telemetry perfectly adheres to invariants with zero stochastic variance (i.e., it lacks the natural "noise" of physical systems), it strongly indicates a sensor replay attack. Real physics is noisy; perfect data is synthetic.

Integration with the IT Fabric

OT telemetry should not remain siloed. The most dangerous attacks (e.g., PIPEDREAM, TRITON) often traverse the IT network to reach the OT network. OT alerts and invariant violations must be integrated into the broader cross-domain data lake (established in the RUN phase) to provide full cross-domain inference. An anomalous login on the IT side (Yellow band) combined with a minor, sub-threshold anomaly in the OT Historian (Yellow band) should immediately escalate the fused belief state to Red.

---

Part IV: Reference

Chapter 11: Tooling Ecosystem Reference

Implementing the doctrine requires combining multiple tools across the visibility, detection, and data layers. This matrix details the recommended open-source and commercial tooling required to traverse from Crawl to Fly.

Tool	Purpose	Phase	Cost Profile	Description
DeTT&CT	ATT&CK mapping	Crawl	Free (Open Source)	Python-based framework to visualize MITRE ATT&CK coverage based on data sources and detection rules. Mandatory for measuring the Coverage Bound.
SigmaHQ	Generic detection	Crawl	Free (Open Source)	The industry standard repository for vendor-agnostic detection signatures. Contains over 3,500 community-vetted rules.
sigma-cli	Rule translation	Walk	Free (Open Source)	Converts Sigma YAML into SIEM-specific query languages (SPL, KQL, Lucene) and validates rule syntax.
GitHub Actions	CI/CD pipeline	Walk	Low / Free Tier	Automates rule testing, translation, and deployment via API to the SIEM. Establishes Detection-as-Code.
Atomic Red Team	BAS / Validation	Walk	Free (Open Source)	Library of simple, automated tests mapped to the MITRE ATT&CK framework used to validate detections.
Apache Parquet	Data storage	Run	Free (Infra costs apply)	Columnar storage format for the data lake. Drastically reduces AWS S3 / Azure Blob storage costs and query latency.
Apache Iceberg	Table management	Run	Free (Infra costs apply)	Open table format for huge analytic datasets. Enables schema evolution and time-travel querying on the data lake.
OCSF	Schema normalization	Run	Free (Standard)	Open Cybersecurity Schema Framework. Standardizes log structures across vendors to enable cross-domain correlation.
Panther / Anvilogic	Commercial DaC	Walk / Run	Commercial (High)	Turnkey commercial platforms for Detection-as-Code and data lake analytics. Accelerates the Walk/Run phases.

Chapter 12: Case Studies

The following organizations have successfully implemented aspects of the Assumed Breach Doctrine, demonstrating its practicality at scale.

Netflix (Snare) Netflix built the "Snare" platform to process millions of log records per minute, initially operating under the assumption that advanced stream-processing architectures were the key to catching adversaries in real-time. The initial iterations of Snare focused heavily on complex streaming analytics, attempting to join massive datasets in memory to detect subtle anomalies before they were ever written to disk. The engineering team spent considerable effort tuning Flink jobs to handle the sheer volume of AWS CloudTrail and VPC Flow Logs generated by Netflix's microservices architecture.

However, as the platform matured, the team discovered a counter-intuitive reality: raw processing speed was far less important than signal quality. The complex streaming analytics were incredibly brittle. A minor change in a microservice deployment pattern would trigger massive alert storms, overwhelming the security operations team. The false-positive rate of these "advanced" models was unsustainable, leading to the exact alert fatigue the Assumed Breach Doctrine seeks to eliminate.

Consequently, Netflix made a deliberate architectural tradeoff. They intentionally deprecated the highly complex, brittle streaming analytics in favor of high-fidelity, well-tuned rules that ran on a slight delay but minimized false positives. They shifted from trying to find the "unknown unknowns" in real-time to executing highly reliable, deterministic rules (like detecting specific IAM role assumption anomalies) with near-zero false positive rates.

Lesson: Minimum Viable Inference beats "collect everything." A few high-fidelity signals are worth exponentially more than petabytes of uncurated data processed in real-time. Speed without accuracy is just noise delivered faster.

Airbnb (Graph) Faced with complex, distributed attacks targeting both their infrastructure and their users, Airbnb rebuilt their risk system into a massive interconnected graph database. This architecture, known internally as Himeji, scaled to contain over 7 billion nodes and 11 billion edges. Nodes represented entities (users, IP addresses, devices, payment methods), and edges represented the relationships and actions between them. This graph structure allowed them to perform advanced behavioral detection across seemingly disconnected events that a traditional SIEM would miss.

For example, a traditional SIEM might alert if an IP address fails to log in 50 times. The Airbnb graph could detect if 50 different IP addresses, all using the same rare browser fingerprint, attempted to log into 50 different accounts within a 10-minute window. This capability to traverse relationships instantly enabled the "multi-signal fusion" required in the FLY phase of the doctrine. They could calculate the probabilistic risk of an entire sub-graph of activity rather than relying on binary, single-event alerts.

Crucially, the success of this 7-billion-node graph depended entirely on data normalization. To achieve this, Airbnb enforced strict data quality contracts (which they termed the "Wall") on all engineering teams emitting logs. The Wall was a rigid schema validation layer. If a microservice attempted to emit a log that did not perfectly match the predefined schema (analogous to OCSF), the log was outright rejected at the pipeline ingress. The security team refused to ingest garbage data.

Lesson: Data quality at the source is critical for inference. You cannot run advanced analytics, let alone 11-billion-edge graph traversals, on garbage data. Enforcing strict schema contracts on developers is a prerequisite for advanced detection.

Slack (AER) Slack developed the Anomaly Event Response (AER) system to solve a specific problem: human SOC analysts could not react fast enough to contain high-speed attacks (like credential stuffing or automated token abuse). Slack recognized that for certain classes of attacks, the MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond) needed to be measured in milliseconds, not minutes. AER was designed to autonomously mitigate high-confidence threats without human intervention.

The system works by establishing continuous inference baselines for user behavior. AER ingests a massive firehose of application request logs and evaluates them against historical baselines in real-time. It looks for impossible travel, sudden shifts in API endpoint usage (e.g., a user who normally only reads messages suddenly attempting to export the entire workspace), and known-bad infrastructure (Tor exit nodes, residential proxies).

To enable autonomous action without disrupting legitimate users, Slack implemented rigorous confidence thresholds. AER only takes autonomous action (such as instantly revoking a session token or forcing a password reset) when the fused belief state crosses a definitive mathematical threshold. If the probability of compromise is calculated at 0.95 or higher, the system fires. If it is 0.70, it routes to a human for investigation. This aligns perfectly with the "Action Band" concept outlined in the FLY phase of the doctrine.

Lesson: Continuous inference, when properly tuned and mathematically bounded, can confidently drive autonomous response. By trusting the math, organizations can free SOC analysts from manual containment tasks and block machine-speed attacks before data exfiltration occurs.

Bitstamp (Detection as Code) Bitstamp transitioned from writing ad-hoc SIEM rules to a Python-based Detection-as-Code workflow using Panther and Git. Every rule was subjected to peer review, CI/CD testing, and shadow mode deployment. This dramatically reduced their false positive rate and allowed the team to rapidly iterate on detections during active incidents. Lesson: Detection-as-Code is not theoretical; it is a highly effective, production-ready methodology for reducing alert debt and increasing engineering velocity.

SpecterOps (Capability Abstraction) SpecterOps pioneered the "Funnel of Fidelity" methodology. Instead of writing brittle rules targeting specific malware hashes or tool names (which attackers easily change), they advocated focusing on the underlying capabilities and OS primitives required to execute a technique (e.g., the specific API calls required for process injection). Lesson: Detect the underlying behavior, not the specific tool. This perfectly aligns with the doctrine's emphasis on distributional shift and capability inference.

---

Appendices

Appendix A: Palantir ADS Rule Documentation Template

Use this template in your Git repository for every detection rule.

# ADS: [Rule Name]
**Goal**: What specific adversary objective is this detection trying to identify?
**Categorization**: MITRE ATT&CK mapping (Tactic/Technique).
**Strategy Abstract**: A high-level, plain-English explanation of the detection logic.
**Technical Context**: Detailed explanation of the telemetry involved, the expected adversary behavior, and how the OS/application generates the logs.
**Blind Spots & Assumptions**: What variations of this technique will this rule miss? What implicit assumptions does the rule make?
**False Positives**: Known benign administrative or automated activities that will trigger this rule. How can analysts verify they are benign?
**Validation**: Specific steps (or Atomic Red Team commands) to safely trigger the rule for testing.
**Priority**: Default action band severity (Green/Yellow/Orange/Red).
**Response**: Playbook steps for analysts to follow when this alert is triggered.

Appendix B: DeTT&CT Coverage Report Template

Use this template to communicate coverage to leadership.

# Detection Coverage Report
**Date**: YYYY-MM-DD | **Framework**: MITRE ATT&CK v14

- **Overall Detection Coverage**: 48% (Defined as techniques with validated detections)
- **Trend**: +5% from previous quarter

**Top 5 Unmitigated Blind Spots (High Priority):**
1. T1055 - Process Injection (Requires advanced EDR memory scanning tuning and Sysmon Event 10)
2. T1071 - Application Layer Protocol (Requires TLS decryption for C2 visibility; currently blinded)
3. T1562 - Impair Defenses (Coverage gap in Linux segments; missing auditd logs)
4. T1027 - Obfuscated Files (Relying solely on static AV signatures; need behavioral de-obfuscation)
5. T1134 - Access Token Manipulation (Requires enhanced Sysmon configuration deployment)

*Action Plan*: Quarter 4 engineering sprints will focus on deploying Sysmon tuning to address T1134 and T1055, targeting a 3% overall coverage increase.

Appendix C: OCSF Field Mapping Cheat Sheet

Standardize on these OCSF fields for cross-domain detection rules.

• Source IP: src_endpoint.ip
• Destination IP: dst_endpoint.ip
• User Name: actor.user.name
• Process Name: process.name
• Command Line: process.cmd_line
• File Path: file.path
• File Hash (SHA256): file.hashes.sha256
• Action/Outcome: activity_id (e.g., 1 for Logon, 2 for Logoff)
• Time: time (Normalized to UTC)

Appendix D: Detection Engineering Hiring Rubric

When building a detection engineering team, evaluate candidates on the "triple-threat" model:

1. Security Analysis (40%): Deep understanding of attacker TTPs, Windows/Linux internals, network protocols, and forensic artifacts. Interview Question: "Explain exactly what happens in memory and in the event logs when Mimikatz dumps LSASS."
2. Software Engineering (40%): Proficiency in Python/Go, version control (Git), CI/CD concepts, and writing maintainable code. Interview Question: "Write a robust Python script to paginate through a REST API, extract specific JSON fields, and handle rate-limiting errors."
3. Data Science & Engineering (20%): Understanding of statistics, schema normalization, and query optimization (SQL, KQL, SPL). Interview Question: "How would you optimize a SQL query that needs to join a 5TB network flow table with a 50GB identity table?"