SIEM fundamentals — correlation rules and alert tuning

A Security Information and Event Management system, or SIEM, builds on centralised logging by adding correlation: the ability to connect related events across different sources into a single meaningful alert. A single failed login means little on its own, but a hundred failed logins across ten accounts followed by one success from an unusual country tells a story no individual log line could tell alone. This lesson covers how SIEM correlation rules construct that story automatically.

Analogy🏏Cricket

💪 Think of it like fitness: one slightly elevated heart-rate reading during a workout means nothing on its own. But a trainer who correlates a climbing resting pulse, dropping sleep quality, and stalling lifts over two weeks reads a clear story of overtraining that no single measurement could reveal. SIEM correlation works the same way: a lone failed login is noise, yet a hundred failures across ten accounts followed by one success from an unfamiliar country is a signal only visible when the readings are connected. Correlation is the coach that watches the whole pattern instead of reacting to any single number.

A correlation rule defines a pattern across events, typically expressed as a condition over a time window: this event type occurring this many times, from this many distinct sources, within this many minutes, optionally followed by a second event type. When the pattern matches, the SIEM raises an alert bundling the contributing events together, giving an analyst the full context of what happened rather than a single isolated line stripped of its surroundings.

Analogy🏏Cricket

♟️ Think of it like chess: a strong player rarely reacts to a single move, but recognises a known attacking pattern — a knight advanced here, a bishop lined up there, a pawn pushed within a few moves — as one coordinated threat. A correlation rule encodes exactly that kind of pattern: this event type, this many times, from this many sources, within this many minutes, optionally followed by a second move. When the sequence matches, the SIEM bundles the contributing events into one alert, handing the analyst the whole combination rather than a lone piece stripped of the position that gives it meaning.

Under the hood, alert quality depends entirely on tuning. A rule set too loosely fires constantly on benign activity, burying real threats in noise until analysts start ignoring alerts altogether, a failure mode known as alert fatigue. A rule set too tightly misses genuine attacks that vary slightly from the exact pattern anticipated. Effective tuning iterates continuously, adjusting thresholds and conditions against real traffic until the signal-to-noise ratio actually supports timely human response.

Analogy🏏Cricket

🍳 Think of it like cooking: seasoning a dish is a balance. Too little salt and every plate tastes flat, so the kitchen stops trusting the seasoning entirely; too much and you drown the real flavours and miss when something is genuinely off. Alert tuning is that same balance. A rule set too loosely fires constantly on benign activity until analysts ignore every alert — the flat, over-salted fatigue that hides real threats — while a rule set too tightly misses attacks that vary slightly from the recipe. Effective tuning means tasting against real traffic and adjusting continuously until the signal is exactly strong enough to act on.

text

# Simplified correlation rule: brute-force followed by success
rule brute_force_then_success {
  window: 10m
  condition:
    count(event.action == "login_failed", by user.name) >= 5
    followed_by event.action == "login_success" (same user.name)
  severity: high
  action: alert("Possible credential stuffing success")
}

Analogy🏏Cricket

💰 Think of it like finance: a single small transaction on your card means nothing, and a bank that froze the account over every coffee purchase would be useless. But a fraud engine that correlates several declined attempts, then a sudden successful charge from a new country, sees a pattern worth freezing the card over. SIEM correlation is that fraud engine for logins: five failed authentications are unremarkable alone, yet the same sequence suddenly ending in success is exactly the combination that warrants review. Neither event trips an alarm by itself, but stitched together in order they reveal an account being taken over.

Best practice starts new rules in a monitoring-only mode, measuring how often they would have fired against historical traffic before ever paging anyone. Group related alerts to avoid duplicate notifications for the same underlying incident, assign each rule a severity that reflects real business impact, and review rules regularly as the environment changes, since a threshold tuned for last year's traffic volume may be far too sensitive or far too lax today.

Analogy🏏Cricket

💼 Think of it like business: a sensible company pilots a new policy quietly before enforcing it, measuring how it would have played out against last quarter's data before it affects anyone. New correlation rules deserve the same discipline — run them in monitoring-only mode first to see how often they would have fired, group related alerts so one incident does not spam the whole team, rank each rule's severity by real business impact, and revisit the rules on a schedule. A threshold calibrated for last year's transaction volume can be dangerously wrong for this year's, so a rule set is a policy to maintain, not to set and forget.

In the real world, a team without correlation might see a thousand individual failed-login log lines scroll past unnoticed in a busy dashboard. The same environment with a tuned SIEM rule raises exactly one high-severity alert summarising the whole credential-stuffing attempt, complete with every contributing event attached. That single, well-formed alert is what actually gets investigated, while the thousand raw lines never would have been read by anyone.

Analogy🏏Cricket

⚽ Think of it like sports: a coach who watches all ninety minutes of raw footage sees a thousand touches blur past and notices nothing, but an analyst who tags the sequence — the repeated probing down one wing that finally breaks through — hands the coach a single clip that actually gets studied. A SIEM without correlation is that unwatched raw footage: a thousand failed-login lines scroll by unread. A tuned rule is the edited clip, raising exactly one high-severity alert that summarises the whole credential-stuffing move with every contributing event attached. Only the well-formed alert ever gets investigated.

SIEM correlation connects related events across sources into one meaningful alert.
Rules define patterns over time windows, such as repeated events followed by a specific outcome.
Poorly tuned rules cause alert fatigue; well-tuned rules surface real signal.
Start new rules in monitoring-only mode before enabling live paging.
Review and retune rules regularly as traffic patterns and the environment evolve.