Security Information and Event Management (SIEM)

CyBOK Knowledge Area 8.4 · Level N2 (all Cyber Security students, both studios) · depth: know, use & apply

How you can use this topic (learning outcomes)

This topic supports the following learning outcomes, with example products you could deliver in your project:

Analysing & Advising — an advice note on what your project would need from a SIEM: which sources to feed in, and which correlations would actually catch a threat that matters to your client.
Designing & Realising — a small working setup in a SIEM-style tool (for example the ELK stack or Splunk) that ingests your project's logs and raises a meaningful alert.
Managing & Collaborating — a set of correlation and alerting rules your team agrees on, tuned so the alerts are worth acting on.

This topic builds on the SOIM overview (8) and the monitoring & analysis topic (8.2-3); the MAPE-K loop and the base-rate fallacy should already be familiar.

What is a SIEM and why should you care?

Individual sensors each see a sliver of what happens. A SIEM is the control room where all those feeds come together on one wall of screens: it collects logs and alerts from across the whole network, brings them to one place and one format, connects the dots between them, and raises alerts a human can act on. In the MAPE-K loop it sits at the Plan step — the point where a mass of raw events becomes a manageable set of decisions. Modern systems generate far more event data than any human can read, so without something doing this consolidation, a SOC simply cannot function.

Bringing the data together: normalisation

Sensors and log sources come from many vendors and "speak different languages". Before you can compare them, a SIEM has to normalise them into a common form. Conceptually this happens at three layers: the schema (what the fields mean), the encoding (how they are written down — text like Syslog, JSON or XML, or binary), and the transport (the protocol that moves them from sensor to SIEM). You will meet a handful of formats in practice — Syslog as the widespread default, and vendor formats such as CEF and LEEF that became de-facto standards through the tools that use them. The detail of each format belongs in the knowledgebase; what matters here is why normalisation exists: without it, data from a firewall and a web server cannot be read side by side.

Finding meaning: alert correlation

Consolidating data is only step one; the value is in correlation — combining separate events into one meaningful signal. This is the direct answer to the base-rate fallacy from the monitoring & analysis topic: correlation is the filter that keeps analysts from drowning in false positives. CyBOK distinguishes four kinds: correlation between alerts (many alerts that are really one phenomenon — a worm spreading), correlation with the environment (is this alert even relevant to the target's OS and services?), correlation with external sources (threat intelligence about attacker paths and motives), and incident exchange (information shared by CERTs and ISACs about threats seen in your sector). Through these, a SIEM turns raw events into alerts, and groups of alerts into incidents that need human attention.

Starting points

Read — CyBOK KA 8, section 4 (SIEM) — the authoritative treatment of collection, normalisation and correlation.
Do — Elastic (ELK) stack — ingest logs and build queries and dashboards; a hands-on way to feel what a SIEM does.
Do — Splunk — a widely used commercial SIEM; useful to compare with the open ELK approach.
Study material in the knowledgebase — [TODO — !!!! Hier knowledgebase links neerzetten !!!] (Domain II → 8 SOIM → SIEM: normalisation layers, the four correlation types, event → alert → incident.)

Points of attention (check your own work)

Time synchronisation — Are all your sources and the SIEM synced to a reliable clock? Without correct time order, correlation is impossible.
The right sources in — Are you feeding the SIEM the logs that actually contain the threats you care about, rather than everything indiscriminately?
Correlation over raw volume — Are your rules combining events into meaningful signals, or just forwarding a flood of individual alerts?
Tuned to your environment — Have you removed correlations and signatures irrelevant to your systems (the base-rate fallacy again)?
Business impact — Would acting on an alert (blocking, disabling) risk breaking a service your client depends on? Have you weighed that?

Going deeper (advanced)

From SIEM to SOAR — the shift from Plan to Execute: automating mitigation, using attack graphs to model an attacker's likely next move, and why automated countermeasures demand a rigorous impact assessment before they run.
SIEM generations — why first-generation, SQL-based platforms struggled with modern data volumes, and how "big data"/NoSQL approaches changed the trade-offs.
Format expressiveness vs practicality — the story of IDMEF (technically rich, barely adopted) versus flatter formats that won on ingestion speed.

Sources and attribution

Debar, H. (2021). Security Operations & Incident Management. CyBOK Knowledge Area v1.0.2.