SIEM: getting events in, parsing them, and keeping them

Why this matters

Domain 4 is security operations, and this lesson covers the foundation that every other detection capability sits on. Threat hunting queries this data. Incident response reconstructs from it. Behavioural baselines are computed over it. Correlation joins across it.

That dependency is the reason to take the unglamorous parts seriously. A detection programme with excellent rules over incomplete, badly parsed or insufficiently retained data is a programme that finds a subset of what it believes it finds, and — as with every coverage problem in this course — nothing in its output says so.

The examinable material divides into four practical questions: what to ingest given that you cannot afford everything, how to make events comparable across sources, how to handle time, and how long to keep it. The fifth section is the one most often skipped and most often the cause of a missed incident: how you know ingest is still working.

The lesson

Sources worth ingesting, and the cost model that decides what you cannot

Most platforms charge by volume, so ingestion is a budget allocation, and allocating it by "collect everything" produces a bill that forces indiscriminate cuts later. Allocating it deliberately is the skill.

The sources that repay their cost most reliably, roughly in order:

• Identity and authentication. Sign-ins, failures, multi-factor events, privilege changes, consent grants, directory modifications. Almost every attack path crosses identity, and the volume is modest relative to the value.
• Endpoint detection telemetry. Process creation with command lines, parent relationships, network connections from processes, and script block content. This is the highest-value host data by a wide margin and also the highest volume, which makes it the main budget decision.
• Cloud control plane audit logs. Every API call in every account. Modest volume, and it is the only record of what happened to the estate's configuration.
• Network metadata — flow records, DNS queries, proxy logs. DNS in particular is unusually informative per byte.
• Application and database audit logs for the systems holding classification that warrants it.
• Security control output: firewall denies, email security verdicts, web gateway blocks, data loss prevention events.

What to think carefully about rather than ingest reflexively: high-volume low-signal sources such as verbose debug logging, full packet capture beyond a short rolling window, and successful-connection records from busy internal services. These are the ones that consume a budget and rarely change a decision.

The allocation method that works: start from the detections you intend to build and the investigations you expect to run, and ingest what those need. That is the ATT&CK-driven coverage approach from lesson nine, used as a purchasing argument — it tells you which sources buy which techniques, and it converts a budget conversation into a coverage conversation.

Two architectural notes. Tiering lets you keep high-value data hot and searchable while archiving bulk data cheaply, which resolves much of the cost tension — provided the archive is genuinely retrievable within an investigation's timescale rather than in theory. And filtering at the collector reduces volume before it is charged, but every filter is a decision to be blind to something, so filters need the same review as detection rules.

Parsing and normalisation, and the field mapping that makes correlation possible

Raw events arrive in many formats. Parsing extracts fields from each; normalisation maps those fields onto a common schema so that a username is in the same field regardless of source.

This matters because correlation is a join, and a join requires the same value in the same field. If one source records user, another account_name and a third principal, a rule joining authentication to process creation cannot be written once — it must be written per source, which does not scale and silently misses sources nobody remembered.

What to normalise, at minimum: identity (user, account, principal), host (name, address, unique identifier), process, network endpoints, action, outcome and time. Getting those right covers most detection logic.

The failure modes are specific and quiet:

• A parser that silently drops unmatched events. A format change upstream and the events vanish — no error, just an absence.
• A parser that misassigns fields. Source and destination transposed produces rules that fire on exactly the wrong traffic, and it looks like a tuning problem for months.
• Inconsistent representation. Hostnames sometimes qualified and sometimes not, addresses sometimes as names, usernames sometimes with a domain prefix. Joins then match a subset and the shortfall is invisible.
• Enrichment treated as fact. Geolocation, asset ownership and threat intelligence attached at ingest are point-in-time and can be wrong; carrying the enrichment's age matters for the same reason lesson nineteen required evidence to have one.

The control is testing: for each source, a set of known events with known expected parsed output, run when a parser changes and when a source's version changes. This is the same discipline the rest of this course applies to every control — a parser nobody has proven can fail is a parser nobody has evidence about.

Time: clock skew, time zones and the ordering problem it creates in an investigation

Time is the axis every investigation is built on, and it is unreliable by default.

The problems:

• Clock skew. Hosts drift. A host minutes ahead or behind places its events wrongly relative to everything else, which breaks causal reasoning — the effect appears before the cause.
• Time zones. Events recorded in local time without an offset are ambiguous, and a globally distributed estate produces an unorderable mixture.
• Two timestamps per event, at least — when it happened and when it was received — which can differ by a lot if a forwarder buffered during an outage. Rules evaluating on receipt time will mis-handle a backlog, and a detection window measured on the wrong one can miss an entire replayed batch.
• Resolution. Second-granularity timestamps cannot order events within a second, which matters for process lineage.
• Daylight saving transitions, which produce an hour that occurs twice.

The controls are standard and worth stating because their absence appears in scenarios: synchronised time across the estate from a trusted source, with monitoring for drift; store and query in UTC with local presentation only; preserve both event and ingest timestamps; and prefer higher resolution where the source supplies it.

One operational point worth carrying: an incident timeline built from unsynchronised sources is evidence that can be challenged. Where the output may be used in a legal or disciplinary process, demonstrable time synchronisation is part of the evidential quality, alongside the chain of custody material in lesson forty-nine.

Retention tiers driven by the obligations from domain 1, not by disk price alone

Retention is a decision with three inputs, and cost is only one.

Obligation. Sector rules and contracts frequently specify minimum retention for audit data, sometimes years. This is the floor and it is not negotiable, so it is the first input — lesson eleven's work consumed here.

Investigation need. The critical figure is dwell time: attackers are frequently present for months before detection, so retention shorter than plausible dwell time means that when you finally detect an intrusion, the data covering how it began has already expired. Retaining ninety days and discovering an eight-month-old compromise means the origin is unknowable. This is the argument that most often justifies extending retention, and it is the one to make.

Cost, which is real and is why tiering exists.

A workable structure:

Two practical requirements. The archive must be genuinely retrievable, tested, within a time that is useful during an incident — an archive that takes three weeks to restore is a compliance artefact, not an investigative resource. And retention must survive the incident: an attacker with access to the logging platform can delete evidence, which is why logs go somewhere the monitored systems' administrators cannot alter, per lesson twenty-three, and why write-once storage is used for the audit tier.

The connection worth making explicit: retention interacts with the deletion obligations of lesson seven. Logs contain personal data, and a retention period set for security purposes must be justifiable against a data minimisation requirement. That is a documented decision rather than a default.

Proving ingest is still working, because a silent source looks exactly like a quiet one

The closing discipline, and the one most likely to be missing in a scenario describing a missed detection.

When a log source stops sending, the platform shows nothing from it. That is visually identical to a source with nothing to report. No alert fires, because alerts fire on events and there are none. Every rule over that source silently stops working, and every dashboard looks healthy — arguably healthier, since there are fewer findings.

This happens constantly for mundane reasons: an agent fails after an upgrade, a forwarder's disk fills, a credential expires, a network rule changes, a firewall policy is rebuilt, a new subscription is created outside the collection configuration, or a licence limit is reached and the platform starts dropping.

The control is monitoring the pipeline itself, with four measures:

• Expected sources versus reporting sources, derived from the asset inventory of lesson five rather than from a list maintained by hand, so a new host that never started reporting is visible.
• Volume per source against its own baseline, alerting on an implausible drop as well as on zero. A source at 10% of normal is usually a partial failure, which is harder to notice and just as damaging.
• Latency, because a source arriving hours late is effectively absent for real-time detection.
• Parse failure rate, since events arriving and failing to parse are events that do not exist for any rule.

And the recurring principle that this course keeps arriving at from different directions, stated here in its operational form: absence of evidence is not evidence of absence, and a monitoring system must be able to distinguish "no events" from "no answer". A detection programme that cannot tell those apart will, sooner or later, report a clean estate while blind.