SECURITYATLAS✳

✳ The reference desk / In practice

SIEM

A capability that collects, parses, stores, and searches security telemetry and often fires alerts.

Security information and event management

What it means

A SIEM brings security information from multiple systems into a place where people can search and correlate it. Common functions include collection, parsing, retention, detection rules, and investigation queries. Its usefulness depends on the sources, their quality, and the questions the team can answer. Installing the platform does not automatically produce relevant detections. In practice, a small set of reliable, well-understood sources is often a better starting point than collecting every available event without a plan for cost, privacy, or use.

See the idea / Detection

Join the account and time, not just nearby events.

Compare a rule over two collected logs when their account IDs match or differ.

Fictional SignalDesk retains I110: U110 gained an admin role at 08:00 UTC, and E110: a file export at 08:04. Both sources use the Chronos Hub account namespace. R110 looks for the same account exporting after that role addition, within ten minutes. Change only E110’s account from U110 to U220. Source accuracy, clock alignment and canonical ID mapping are controlled assumptions.

SIEM: Compare a rule over two collected logs when their account IDs match or differ. The chapter text below describes every state.SignalDesk · rule R110Two source logs; one defined joinOriginal sources · I110 / E110I110: U110 · admin added 08:00E110: U110 · export 08:04Selected normalized copiesNot ingestedSource event references stay attachedR110 · same account and timeQuery not runExport after addition · within 10 minStored alert · AL110No alert storedNo human or incident conclusionSOURCE RECORDS ≠ A JOIN

01 / 04

Source rows

I110 records an admin addition for U110. E110 records an export by U110 four minutes later. Nothing has been ingested or queried yet.

More about this step

I110 contains principalId U110, occurredAt 2026-09-30T08:00:00Z and AdminAdded. E110 contains actorId U110, recordedAt 2026-09-30T08:04:00Z and Export of F110. Both are entirely synthetic, in one Chronos Hub namespace. The comparison changes only the export account; close timestamps alone are insufficient. Source records remain independent and unchanged.

Keep in mindOnly these two synthetic logs and this configured rule are covered. A match supports a lead, not human attribution or an incident declaration. No match is not a safety verdict: other actions, accounts, missing logs and parsing errors need separate checks. Originals remain; no response action or analyst receipt is implied.

Read the visual, step by step

U110 · same account

  1. Source rows. I110 records an admin addition for U110. E110 records an export by U110 four minutes later. Nothing has been ingested or queried yet. I110 contains principalId U110, occurredAt 2026-09-30T08:00:00Z and AdminAdded. E110 contains actorId U110, recordedAt 2026-09-30T08:04:00Z and Export of F110. Both are entirely synthetic, in one Chronos Hub namespace. The comparison changes only the export account; close timestamps alone are insufficient. Source records remain independent and unchanged.
  2. Ingest. SignalDesk creates selected copies, maps the account and event-time fields, and retains both original event references. The collector stores independent copies and maps principalId or actorId to accountId, and occurredAt or recordedAt to eventTime. Event IDs and Chronos Hub namespace stay attached. The exercise assumes valid source records, aligned UTC clocks and correct canonical IDs. Collection time does not replace event time. Ingestion and parsing complete together in this simplified batch; no universal product pipeline is claimed.
  3. Correlate. R110 returns one pair: the same U110 account exported 240 seconds after its admin role was added. The actual query requires matching namespace and account ID, an AdminAdded event, an Export event, and an export more than zero and at most 600 seconds after the role event. It uses source event time, not arrival order. A match returns I110 and E110 as evidence references, not a person or attacker verdict. Missing IDs, a different namespace or an out-of-window export cannot satisfy this join.
  4. Store result. The configured rule stores AL110 with I110 and E110. This alert needs business context; it does not declare an incident. The rule writes an alert only when the completed query has a matched pair. AL110 carries the rule and original event references without the file payload. The comparison does not synthesize a same-account alert from merely nearby events. Stored creation is distinct from delivery to an analyst; no acknowledgement or response occurs here. Absence of this alert says only that R110 did not match these selected inputs.

U220 · different account

  1. Source rows. I110 records an admin addition for U110. E110 records an export by U220 four minutes later. Nothing has been ingested or queried yet. I110 contains principalId U110, occurredAt 2026-09-30T08:00:00Z and AdminAdded. E110 contains actorId U220, recordedAt 2026-09-30T08:04:00Z and Export of F110. Both are entirely synthetic, in one Chronos Hub namespace. The comparison changes only the export account; close timestamps alone are insufficient. Source records remain independent and unchanged.
  2. Ingest. SignalDesk creates selected copies, maps the account and event-time fields, and retains both original event references. The collector stores independent copies and maps principalId or actorId to accountId, and occurredAt or recordedAt to eventTime. Event IDs and Chronos Hub namespace stay attached. The exercise assumes valid source records, aligned UTC clocks and correct canonical IDs. Collection time does not replace event time. Ingestion and parsing complete together in this simplified batch; no universal product pipeline is claimed.
  3. Correlate. R110 returns no pair: U110’s admin addition and U220’s export have different account IDs. The actual query requires matching namespace and account ID, an AdminAdded event, an Export event, and an export more than zero and at most 600 seconds after the role event. It uses source event time, not arrival order. A match returns I110 and E110 as evidence references, not a person or attacker verdict. Missing IDs, a different namespace or an out-of-window export cannot satisfy this join.
  4. Store result. No AL110 is created because this query found no pair. The two source events remain available for other questions. The rule writes an alert only when the completed query has a matched pair. AL110 carries the rule and original event references without the file payload. The comparison does not synthesize a same-account alert from merely nearby events. Stored creation is distinct from delivery to an analyst; no acknowledgement or response occurs here. Absence of this alert says only that R110 did not match these selected inputs.

Only these two synthetic logs and this configured rule are covered. A match supports a lead, not human attribution or an incident declaration. No match is not a safety verdict: other actions, accounts, missing logs and parsing errors need separate checks. Originals remain; no response action or analyst receipt is implied.

Flow references: ASD: SIEM collection, normalization and correlation · NIST SP 800-61 Rev. 3: incident criteria and triage

AN ILLUSTRATIVE SCENARIO

A join that needs the same account

Synthetic I110 records U110’s admin addition at 08:00 and E110 an export at 08:04. SignalDesk retains the originals, maps the two sources into comparable account/time fields and runs R110. With U110 in both records it stores AL110 citing the pair. Changing only the export account to U220 returns no pair and creates no AL110. Neither result supplies human attribution, complete visibility or an incident declaration.

Put it to work

  1. Choose a few priority questions and onboard the sources that answer them. Assign source owners and verify timestamps, account identifiers, and important parsed fields.
  2. Develop a detection with both suspicious and legitimate test cases. Document required data, response steps, exceptions, and the person responsible for maintaining it.
  3. Monitor delivery delays, parsing failures, retention, and ingestion cost. Apply role-based access and avoid collecting sensitive fields that have no justified operational use.

How to check your work

Run an approved scenario across the connected systems. Confirm that the raw records arrive, a query joins the intended identities, and the resulting alert gives an analyst enough evidence to act.

Connect the ideas

  • Log

    A record emitted by a system that something happened, which may later be used as evidence.

  • Alert

    A notification that a rule or model wants a human to look at one or more records.

  • SOAR

    Tooling that runs playbooks across security systems, which still needs scoped authority and verification.

  • SOC

    The people and process that detect, investigate, and respond to security events. Distinct from System and Organization Controls reporting.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.