A SIEM alert is an event description: an event occurred, a rule matched, here is the raw log entry. It tells you that something happened. It does not tell you what the adversary is trying to do, whether this event is part of a larger campaign, which assets are at risk, or what you should do in the next 60 seconds. The gap between an alert and a useful threat narrative is the gap that determines whether your analysts catch real intrusions or chase noise. Closing that gap is what Sockindle was built to do.
What a Threat Narrative Is
A threat narrative is a structured account of adversarial activity that answers the questions an analyst needs answered to take action: Who is the adversary (or what adversary group does this TTP pattern resemble)? What have they done so far (chronological sequence of attacker actions)? What assets are affected or at risk? What is the adversary's likely objective based on observed behavior? What containment or investigation actions should happen next?
A threat narrative is not a long report. The most actionable ones are concise — a summary paragraph, a timeline, an asset list, a recommended action — but they synthesize context from multiple data sources and multiple time windows that no single alert can provide.
The difference between receiving an alert that says "suspicious PowerShell execution on host CORP-WS-0144" and receiving a narrative that says "Host CORP-WS-0144 has been compromised. Over the past 6 hours, the host has established persistence via a scheduled task, dumped credentials from LSASS memory, and made three outbound connections to 185.212.44.12 (flagged C2 infrastructure). Affected user account: [email protected]. Recommended immediate actions: isolate host, suspend account, review all systems accessed by jsmith in the past 48 hours" — is the difference between an alert that might be investigated and an escalation that will be acted on. Now.
How the Reconstruction Process Works
Attack narrative reconstruction starts with raw telemetry ingestion across all connected data sources: EDR events from CrowdStrike or SentinelOne, SIEM logs from Splunk or Microsoft Sentinel, identity provider events from Okta, cloud security alerts from AWS Security Hub or Azure Defender. These streams arrive in different formats, at different latencies, with different entity identification schemes.
Step 1 — Normalization and entity resolution
Before any correlation can happen, events must be normalized to a common schema and entities must be resolved to canonical identifiers. The user "jsmith" in Active Directory, "[email protected]" in Okta, and "CORP\jsmith" in Windows Security events must resolve to the same entity before events across these sources can be correlated into a unified timeline.
This normalization step is where most detection architectures fall short. Siloed tools each maintain their own entity model. Cross-source correlation requires a unified entity graph — an ongoing maintenance investment, not a one-time setup task.
Step 2 — Threat graph construction
Normalized events are ingested into a live threat graph: a structured representation of entities (users, hosts, IPs, files, processes) and the relationships between them over time. The threat graph is not a static snapshot — it is continuously updated as new telemetry arrives, with historical context retained for the retention window (typically 30 to 90 days).
The threat graph answers a question that event streams cannot: how are these entities connected, and what has changed about those connections? A new edge between a user and a host they have never accessed before. A process creating a child process that has no prior history on that host. A credential used from two different geographic locations within a 20-minute window. These patterns are visible in the graph structure; they are invisible in a linear event stream.
Step 3 — Kill-chain correlation
Autonomous hunt agents run continuously against the live threat graph, querying for adversarial patterns mapped to MITRE ATT&CK tactics and techniques. When a sequence of events across the graph matches a kill-chain pattern — initial access followed by execution, persistence, credential access, lateral movement — the system begins building a candidate campaign object: a structured account of the adversary's observed actions, linked to the underlying telemetry evidence.
Kill-chain correlation requires time-windowed pattern matching across multiple event types and multiple entities. An execution event on Day 1 and a lateral movement event on Day 3 are part of the same campaign if they share entity connections and the temporal gap is within the adversary dwell-time model. That linkage is what transforms isolated events into a campaign narrative.
Step 4 — Adversary profiling and enrichment
When a kill-chain pattern is identified, the system enriches the campaign object with external threat intelligence: IP reputation data, known-bad indicators from threat feeds, adversary group TTP signatures from MITRE ATT&CK group profiles. If the observed technique sequence matches the known behavioral profile of a specific threat actor group, that attribution context is attached to the narrative — not as a definitive identification, but as a probabilistic assessment ("TTP sequence consistent with FIN7 financially motivated campaigns").
Enrichment also includes asset context: what is the criticality of the affected hosts? What data is accessible from those systems? Is the affected user account privileged? This context directly informs the priority of the escalation — a compromised standard user workstation with no sensitive data access is a lower-priority escalation than a compromised domain admin account with access to crown-jewel systems.
Step 5 — Narrative generation and analyst escalation
The synthesized campaign object — normalized events, entity graph, kill-chain sequence, adversary enrichment, asset context — becomes the basis for the analyst-facing threat narrative. The narrative is generated in a structured format: summary, timeline, affected assets, recommended containment actions, supporting evidence links.
Every element of the narrative is linked to underlying evidence: the specific log events, the threat graph relationships, the threat intelligence references. Analysts can drill down from the narrative summary to the raw evidence for any assertion. The narrative is a synthesis, not a black box — the analyst can verify every claim.
What Gets Lost Without Narrative Reconstruction
When analysts receive raw alerts instead of reconstructed narratives, three things happen consistently. First, investigation depth per finding decreases — there is insufficient time to reconstruct context from scratch for every alert. Second, multi-stage campaigns that generate alerts across different tools are not correlated — the lateral movement alert is investigated separately from the credential dump alert that preceded it, and the campaign is never recognized as a unified operation. Third, the 60-second decision window for containment is missed — by the time context is assembled manually, the adversary has progressed.
The narrative reconstruction process is what the Sockindle platform performs continuously, before an analyst opens a ticket. By the time a finding reaches the analyst queue, the correlation has been done, the context has been assembled, and the recommended actions are ready. The analyst's job is judgment — is this a confirmed incident, does the containment recommendation fit the business context, are there elements of the narrative that require deeper investigation — not context assembly.
We designed the escalation format around a single question: what does an analyst need to know, right now, to make a good containment decision in under 60 seconds? Everything in the narrative answers that question. Nothing in it is filler.
— Mira Halevi, CEO & Co-Founder, Sockindle
The Immutable Evidence Chain
Every narrative Sockindle generates maintains an immutable evidence chain: the underlying events, their sources, the correlation logic applied, and the analyst actions taken in response. This chain is tamper-evident and timestamped, satisfying the audit trail requirements of SOC 2 Type II and NIST CSF incident documentation standards.
When an auditor asks for documentation of incident response activities, the narrative and its evidence chain provide a complete answer — not a manually reconstructed account, but a contemporaneous record of what was observed, when, and what was done about it.
The distance between a raw SIEM alert and an actionable threat narrative is the distance between a detection tool and a defense capability. Raw alerts tell you something happened. Threat narratives tell you what to do about it. Building the bridge between those two requires continuous correlation, behavioral context, kill-chain understanding, and adversary knowledge — work that cannot happen fast enough manually at enterprise alert volumes. That is the problem the reconstruction process solves, and why it sits at the center of how Sockindle approaches autonomous SOC operations.
