◇ OpenCyber Academy
Technical · Chapter 3 · English

Chapter 3 — The SIEM and alerting

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 3 — The SIEM and alerting

Lesson map

Lesson 03 published. Map, example, EX009.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 What a SIEM does"]
  N2["3.2 Rules"]
  N3["3.3 Events, alerts, incidents"]
  N4["3.4 Severity"]
  N5["3.5 Alert queue"]
  N6["3.6 Noise"]
  N7["Correlation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX009"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 What a SIEM does"]
  N2["3.2 Rules"]
  N3["3.3 Events, alerts, incidents"]
  N4["3.4 Severity"]
  N5["3.5 Alert queue"]
  N6["3.6 Noise"]
  N7["Correlation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX009"]

[Learning outcomes]
    |
    v
[3.1 What a SIEM does]
    |
    v
[3.2 Rules]
    |
    v
[3.3 Events, alerts, incidents]
    |
    v
[3.4 Severity]
    |
    v
[3.5 Alert queue]
    |
    v
[3.6 Noise]
    |
    v
[Correlation]
    |
    v
[Worked example] --> [Exercise EX009]

Learning outcomes

You will (1) explain what a SIEM does; (2) describe how rules produce alerts; (3) distinguish events, alerts and incidents; (4) explain alert severity.

3.1 What a SIEM does

A SIEM collects logs, normalises their fields, stores them for search and runs rules that raise alerts. Northgate's SIEM receives about four million events a day. Four million events a day is far beyond what analysts can read, so rules decide which few deserve a person's attention. On the Monday of the parks01 case, two of those millions became alerts, at 09:04 and 09:09, and both reached Carlos's queue within minutes of the activity. The rest stay searchable, which is how Carlos later checks the domain controller and share logs for parks01.

3.2 Rules

A rule describes a pattern, such as "20 or more failed logons from one source in 10 minutes". When the pattern matches, the SIEM raises an alert. Sigma (SigmaHQ) is an open, vendor-neutral format for sharing such rules. At 09:04 the 46 failures from 203.0.113.80 crossed this threshold of 20 within ten minutes, so the rule fired. Writing the idea in Sigma's format makes it easier to share with other councils or move to a different SIEM later. The detection engineering chapter uses the same structure for Carlos's new rule.

3.3 Events, alerts, incidents

An event is anything logged. An alert is an event or group that a rule flagged. An incident is a confirmed situation that harms or threatens security, as defined in NIST SP 800-61r3 (Nelson et al., 2025). Most alerts are not incidents. The parks01 case passes through all three stages in a single Monday morning. Every failed logon was an event; the 09:04 and 09:09 rule matches were alerts; only after Carlos confirmed the tablet was idle did the case become INC-0417, an incident. Keeping the terms apart stops every alert being reported as an incident to managers.

3.4 Severity

Each rule has a severity. The failed-logon rule is medium; a success after guessing raises it to high. Severity tells the analyst how much harm the matched pattern could mean if it is real. Failures alone are an attempt, while a success after them suggests a compromised account, which is why the 09:09 alert outranked the 09:04 one. Triage later combines this severity with how important the affected system is. Severity is set when the rule is written and reviewed during tuning, so it reflects what the SOC has learned from real alerts.

3.5 Alert queue

Alerts wait in a queue sorted by severity and time. Analysts take the top one, investigate and record a decision. Taking the top alert rather than the most interesting one keeps the most serious work first. Recording a decision for each alert means nothing is left half-handled when a shift ends. In the parks01 case, the linked 09:04 and 09:09 alerts sat together in one case, so the next analyst saw the whole story. The queue also shows how long each alert has waited, which feeds the acknowledge times measured later in the metrics chapter.

3.6 Noise

Rules that fire often without real problems create noise that hides important alerts. Alahmadi et al. (2022) found analysts widely frustrated by false positives. At Northgate, the 'admin tool used' rule shows the cost: it fired 220 times in a month with only two real cases. Analysts who see hundreds of harmless alerts begin to skim, and a real case can slip past. Tuning that rule is one of Carlos's tasks later in the book. Every noisy rule therefore has a cost in attention as well as in time.

Correlation

Some rules look across sources. A correlation rule might link a portal logon with a domain controller authentication and a file-share access in the same minutes. Correlation turns separate small signals into one meaningful alert, but it only works when time and user fields agree across systems, which is why chapter 2 stressed them.

Worked example

The SIEM raised two alerts at 09:04 and 09:09. Carlos sees they share a source address and links them in one case, so the next analyst sees the whole story.

Synthetic case. Volumes and alerts are invented.

Errors and limits

SIEM rules only see what is logged; gaps in collection are blind spots.

Exercises

Synthesis

The SIEM turns logs into alerts through rules; analysts turn alerts into decisions.

Continue studying — chapter 03 of 18

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →