Security Operations

For Both Executive and Technical Readers

A SOC does what a clinician does: assemble weak signals over time into a judgment about a hidden state. That is a causal-inference problem, and it is the same architecture, pointed at the kill chain.

01 The Gap

Detection asks “is this alert malicious?” The real question is “what is the attacker doing?”

Most detection asks a local question, is this alert malicious?, one event at a time. The question a defender has is global and temporal: given everything seen across logins, endpoints, network, and threat intel, is an attack progressing right now, and how confident is the answer? Signature-based detection cannot answer that question. It was not designed to.

Signatures detect the known. Attackers change the moment you watch for them. The moment a new technique is signed, it is retired. The causal structure of an intrusion, phishing enables credential theft which enables privilege escalation which enables lateral movement which enables exfiltration, changes far more slowly than the individual techniques. That structure is what the model encodes.

02 The component

The full EARA stack applied to the kill chain, no new components needed.

Security Operations is a Cross-Cutting domain application of EARA, not a new architectural component, but the full EARA stack applied end-to-end to security operations. The domain model encodes the kill chain as a dynamic causal model. The LLM normalises raw telemetry into EvidenceBindings. The Cognitive Primitives answer: what is the current compromise probability, what evidence would most change the assessment, and what action most reduces risk?

// The kill-chain domain model, elicited from security experts
Phishing → CredentialTheft → PrivilegeEscalation → LateralMovement → Exfiltration
            ↓                      ↓
      AccountCompromise            DataExfiltration

// Evidence enters as soft bindings from the LLM
SoftEvidence("VPNAnomaly", p=0.71)      # LLM read of the log
HardEvidence("PrivilegeEscalation", "confirmed")  # EDR alert

The structure is elicited from your security experts, not mined from breach data you hope resembles the next breach. The same elicit-don’t-learn stance as every other EARA model.

03 How it works

Evidence lands. The posterior climbs. Policy acts on probability, not log lines.

Reading the evidence. The LLM normalises raw telemetry, log lines, alerts, threat intel, into typed EvidenceBindings, preserving confidence as soft evidence. It does not classify events; it translates them. The classification is the model’s job.

Running the posterior. As evidence lands, P(AccountCompromise) updates continuously. It climbs because the kill chain is advancing, not because one suspicious command tripped one rule. No single event is the verdict. The model carries a probability that rises as the chain advances, and policy acts on the probability, not on any one log line.

The counterfactual. When an incident is confirmed, the Rung 3 query runs: given everything that happened, would isolating the host at step 4 have prevented exfiltration? Probability of necessity: 0.78. That is the post-incident answer, not “we should have isolated earlier” but a specific probability with explicit assumptions.

Mechanism drift monitoring is especially valuable in security: when adversary tactics change, the log-likelihood of incoming observations under the current model drops. That is the signal to re-elicit the kill chain before the model diverges from the current threat landscape.

04 The Brains

The LLM reads the logs. The model assembles the kill chain.

In security, the LLM reads the logs and explains the verdict; the kill-chain model assembles the signals and computes the probability. The SOC analyst operates on the posterior, not on any individual log line.

The domain model for Security Operations is a domain-specific dynamic Bayesian network encoding the kill chain. It is built via the standard EARA elicitation workflow (02 Discovery, 03 Evidence) from the organisation’s own security experts and threat intel. Optionally open it in your inference tool of choice. The model is the thing; the software that runs it is a commodity.

# Kill-chain posterior, updating as evidence lands
net = Network.load("kill-chain-v2.bayes")

bindings = [
  SoftEvidence("VPNAnomaly", p=0.71),
  HardEvidence("PowerShellExecution", "observed"),
  SoftEvidence("CloudUploadAnomaly", p=0.58),
]
result = Inference(net).query(CausalQuery(evidence=bindings, target="AccountCompromise", rung=1))
result.posterior["AccountCompromise"]  # 0.87, above escalation threshold

The model across four states

Kill-chain model at baseline: all observables at prior N(0,1), AccountCompromise mean 0.136 — State A, Baseline. No evidence. All observables at prior N(0,1). AccountCompromise mean 0.136 ± 1.32, low background probability of compromise.

Kill-chain model with observational evidence: VPNAnomaly=0.71, PowerShellExecution=0.85, CloudUploadAnomaly=0.58, AccountCompromise mean 0.683 — State B, Observational (Rung 1). VPNAnomaly=0.71, PowerShellExecution=0.85, CloudUploadAnomaly=0.58. AccountCompromise posterior rises to mean 0.683 ± 1.24. The kill chain is assembling from observed signals.

Kill-chain model with interventional query: do(Reconnaissance=1.2) plus observational evidence, AccountCompromise mean 0.976 — State C, Interventional (Rung 2). Same observational evidence plus do(Reconnaissance=1.2), forcing recon as confirmed rather than inferred. AccountCompromise rises to mean 0.976 ± 1.15. Intervention lifts the posterior above the observational baseline.

Kill-chain model counterfactual: do(LateralMovement=-1.0) in counterfactual world, AccountCompromise mean -0.357 — State D, Counterfactual (Rung 3). Given the observed evidence from State B, do(LateralMovement=−1.0) in the counterfactual world. AccountCompromise counterfactual mean −0.357 ± 0.287, had lateral movement been blocked, the compromise probability would have been substantially lower than the factual 0.683.

05 Query in plain English

The same primitives, pointed at the kill chain.

The same architecture, the same primitives, pointed at the kill chain.

We’re seeing VPN anomalies on this account. Should we escalate?

AnyChatKill-chain posterior · current compromise probability

Running the kill-chain model with current evidence: VPN anomaly (soft, p=0.71), PowerShell execution (confirmed), cloud upload anomaly (soft, p=0.58). P(AccountCompromise) = 0.87: above the escalation threshold of 0.75. Recommend escalation. The chain appears to be at the lateral movement stage.

What evidence would most change our confidence?

AnyChatInquiry · value of information

Running VoI over available probes. A verified device fingerprint has the highest value (0.64), it would either confirm account linkage and push P(Compromise) above 0.95, or introduce ambiguity that drops it to 0.61. Memory image from the suspected host is second (0.41). Cloud audit logs have low value here, the exfiltration stage is not yet the binding uncertainty.

How do you know this is a real attack and not a false positive?

AnyChatProvenance

I don’t know, the model does. P(AccountCompromise) = 0.87 is not a rule firing. It is the posterior of a dynamic causal model over the kill-chain structure, given these specific EvidenceBindings. The model was elicited from your security experts. The AuditRecord records every binding, their confidence values, and the adjustment set the identification certificate used. The 0.87 is reproducible and contestable.

Couldn't our SOC analysts just use their SIEM rules and escalation playbooks?

AnyChatRung 3 · counterfactual triage

SIEM rules fire on signatures. Playbooks prescribe fixed escalation paths. Neither can fuse weak signals from multiple sensors into a joint posterior, or answer whether the alert is a genuine attack or a coincidence. The triage query running here combined VPN anomaly, authentication timing, and geolocation into a single P(Lateral Movement) estimate, then computed which additional evidence would most change that posterior. A playbook cannot do that computation. It also cannot answer “if we had blocked this account 48 hours ago, would the lateral movement have been prevented?”, that is a counterfactual requiring abduction over the incident timeline, which no SIEM rule produces.

The audit trail is the AuditRecord. The kill-chain model is the thing that made the assessment, not the individual alerts.

06 Where it sits

A cross-cutting domain application, outside the numbered sequence.

Security Operations sits outside the numbered EARA component sequence as a Cross-Cutting domain application. It uses every component in the stack: 01 Pipeline (the LLM boundary), 02–03 (domain model construction via kill-chain elicitation), 04–11 (the full suite of Cognitive Primitives), and 12 BPMN Integration (escalation and incident response workflows).

It is the clearest end-to-end worked example of the architecture in practice, a domain where the hidden-state inference problem, the temporal reasoning requirement, the explainability demand, and the counterfactual post-incident question are all present simultaneously. Every other domain application has a subset of these requirements. Security has them all.