Advanced Security #SIEM #detection-rules #UEBA #log-analysis

SIEM Vocabulary

5 exercises — master SIEM vocabulary for SOC analysts: SIEM architecture and core functions vs. log aggregation, detection vs. correlation rules with MITRE ATT&CK mapping, true/false positive/negative classification and the alert fatigue problem, log source onboarding steps, and UEBA behavioural analytics.

0 / 5 completed

SIEM quick reference

SIEM — collects + normalises + correlates + alerts; turns raw logs into actionable security detections.
Detection rule — fires on a single known-bad event or indicator. Correlation rule — fires when a pattern of events across sources/time is suspicious.
MITRE ATT&CK — framework of adversary TTPs; mapping rules to techniques enables detection coverage gap analysis.
TP: alert fired, real threat. FP: alert fired, benign event (alert fatigue). FN: no alert, real threat (worst outcome — missed breach). TN: no alert, no threat (normal operation).
Log source onboarding — connectivity + parsing + normalisation + event coverage validation + rule activation + coverage matrix update.
UEBA — ML baselines normal user/entity behaviour; alerts on deviations like impossible travel, off-hours access, data volume anomalies, peer group outliers.
Alert fatigue — too many FPs cause analysts to stop trusting alerts; base-rate error is the root cause; solved by rule tuning and UEBA calibration.

1 / 5

A SOC manager explains the team's tooling: "Everything flows into the SIEM. It's not just a log storage system — it aggregates, normalises, and correlates events from across our environment so we can detect threats we'd never see by looking at any single source."

What is a SIEM, what are its core functions, and what distinguishes it from a simple log aggregator?

The SIEM's value is the intelligence layer on top of log collection. Raw logs are evidence; the SIEM's correlation engine turns evidence into alerts.

SIEM data flow:

Stage	What happens	Why it matters
Ingestion	Logs arrive via syslog, API, agent, or cloud integration	Coverage: every source you don't log is a blind spot
Normalisation / parsing	Log fields extracted and mapped to common schema (src_ip, user, action, outcome)	Cross-source correlation requires consistent field names
Enrichment	Adds context: IP geolocation, threat intel feed match, asset inventory lookup	Turns raw IP into "known malicious C2 server in Russia"
Correlation	Detection rules evaluate enriched events; statistical models identify anomalies	Connects events across sources into a detectable pattern
Alerting	Alert fires; routed to analyst queue, SOAR, or ticketing system	Analyst focuses on prioritised, enriched alerts — not raw logs

Common SIEM use cases:
• Detect credential stuffing: >100 failed logins from single IP in 60s → alert
• Detect lateral movement: user authenticates from office IP, then 5 minutes later from overseas IP → impossible travel alert
• Detect privilege escalation: standard user account added to admin group outside business hours → alert
• Detect data exfiltration: unusual volume of data egress from a database server to external IP → alert

Key vocabulary:
• SIEM (Security Information and Event Management) — centralised security platform that aggregates, normalises, correlates, and alerts across log sources from the entire environment
• Log normalisation — parsing raw log formats into a common schema; enables cross-source event correlation regardless of vendor or log format
• Correlation rule — a SIEM logic rule that fires an alert when a specific pattern of events is detected across one or more sources within a time window
• Log source coverage — the completeness of log ingestion; any system not feeding the SIEM is a potential undetected attacker path

2 / 5

A SOC team debates their detection rules. A senior analyst says: "We need to distinguish between detection rules and correlation rules, map our rules to MITRE ATT&CK, and be careful about base-rate error — not everything should fire an alert."

What is the difference between detection rules and correlation rules, what does mapping to MITRE ATT&CK add, and what is base-rate error in a SOC context?

Both rule types are needed. Detection rules catch known-bad indicators instantly; correlation rules catch subtle patterns across time and sources. MITRE ATT&CK mapping enables gap analysis. Base-rate error is the alert fatigue root cause.

Detection rule vs correlation rule examples:

Type	Example rule	MITRE ATT&CK mapping
Detection rule	Alert if any DNS query resolves to a known C2 IP from the threat intel feed	T1071.004 — C2 over DNS
Detection rule	Alert if a privileged group (Domain Admins) membership changes	T1098 — Account Manipulation
Correlation rule	Alert if: >20 failed logins from one IP within 2 min AND the account then succeeds	T1110.001 — Password Guessing / Credential Access
Correlation rule	Alert if: same user authenticates from two different countries within 2 hours (impossible travel)	T1078 — Valid Accounts / Lateral Movement

Base-rate error in SOC context:
Imagine a rule that triggers on any failed login. A company with 10,000 users will have thousands of failed logins per day (typos, locked keyboards, forgotten passwords). 99.9% are benign. Alerting on each creates thousands of tickets that overwhelm analysts — most are false positives. A well-calibrated rule adds conditions: >50 failures from ONE IP within 5 minutes — a much rarer event, with a higher proportion of true threats.

Signal-to-noise ratio — the ratio of true positive alerts to total alerts. Poor signal-to-noise → alert fatigue → analysts start ignoring alerts → real threats are missed.

Key vocabulary:
• Detection rule — fires on a single event or condition matching a known-bad indicator; fast; good for known threats
• Correlation rule — fires when a combination of events across sources/time forms a suspicious pattern; catches subtler threats
• MITRE ATT&CK — a framework of adversary tactics, techniques, and procedures (TTPs); used to map detections to specific attack behaviors and identify coverage gaps
• Base-rate error — when a rule fires too frequently due to the high base rate of benign events that match the condition; produces mostly false positives; root cause of alert fatigue

3 / 5

A SOC analyst reviews the day's alert queue. In the debrief, the team uses four terms: true positive, false positive, true negative, false negative. The lead analyst says: "False negatives are our worst outcome — we'd rather tune too sensitive than miss a real attack."

What does each classification mean, why is a false negative the worst outcome, and how does the SOC manage this tension?

The TP/FP/TN/FN framework is core to evaluating detection quality. Good SOC teams track these metrics to continuously improve detection coverage and precision.

Classification matrix:

	Alert fired	No alert fired
Real threat	✓ True Positive (TP) — detection worked	✗ False Negative (FN) — missed detection; attacker undetected
No threat (benign)	⚠ False Positive (FP) — false alarm; analyst time wasted	✓ True Negative (TN) — correct silence; normal operation

Why FNs are worst:
• An undetected breach has a "dwell time" — the period between initial compromise and discovery
• Median enterprise breach dwell time: 16–24 days (IBM/Mandiant reports)
• Every day of dwell time = more data exfiltrated, more lateral movement, deeper persistence
• FNs represent unknown unknowns — the team cannot respond to what it cannot see

Managing FP vs FN trade-off:
• For critical assets (domain controllers, production DBs, payment systems): optimise for low FN rate; accept more FPs; every missed detection is unacceptable
• For lower-risk assets: tune for lower FP rate to reduce analyst noise
• Rule tuning — updating rules to exclude known-benign patterns (e.g., exclude scheduled task logins from admin service accounts from "after-hours admin login" alert)

Key vocabulary:
• True positive (TP) — alert fires; threat is real; correct detection
• False positive (FP) — alert fires; event is benign; false alarm; source of alert fatigue
• False negative (FN) — alert does not fire; threat is real; missed detection; worst outcome
• True negative (TN) — alert does not fire; no threat; correct silence
• Dwell time — the period between initial network compromise and detection; longer dwell time = more damage; FNs increase dwell time

4 / 5

A SOC engineer is tasked with onboarding a new log source — the company's new cloud WAF. A colleague asks: "What does log source onboarding actually involve? I thought you just point it at the SIEM."

What does proper log source onboarding entail?

Log source onboarding is a multi-step engineering task. "Just pointing" a source at a SIEM without verifying parsing, normalisation, and coverage creates a false sense of security — you think you're covered but the alerts won't fire correctly.

Log source onboarding checklist:

Step	Verify	Common failure mode
Connectivity	Events arriving in SIEM at expected volume	Firewall blocking syslog port; misconfigured API key
Parsing	Key fields correctly extracted: timestamp, src_ip, user, action, severity	Vendor changed log format in firmware update; parser breaks silently
Normalisation	Fields mapped to SIEM common schema	Cross-source correlation rules can't match if source_ip field name differs
Event coverage	Expected event types present: auth events, errors, admin actions	Logging only INFO level; WARN/ERROR/SECURITY events not enabled
Detection activation	Relevant rules using this new source are enabled and tuned	Rules exist in library but not activated for new source type
Coverage matrix	Inventory updated; stakeholders notified of new visibility	Asset not in inventory; blind spots unknown

Key vocabulary:
• Log source onboarding — the full process of integrating a new system into the SIEM: connectivity, parsing, normalisation, coverage validation, and rule activation
• Parser — the SIEM component (or configuration) that extracts structured fields from a vendor's raw log format
• Log source coverage matrix — an inventory mapping every system in the environment to its SIEM log source status: monitored / not monitored / partial
• False sense of coverage — believing a source is monitored when connectivity exists but parsing, event selection, or rules are misconfigured; common audit finding

5 / 5

A threat analyst proposes adding UEBA to the SIEM stack. She says: "Rule-based detection only catches known patterns. UEBA detects when a user or entity deviates from their own baseline — which is how we catch insider threats and compromised accounts that don't match any known IOC."

What is UEBA, how does it work, and when is it most valuable?

UEBA fills the gap that rule-based SIEM detection leaves: it catches "known-good credential used in unusual way" — which is how most insider threats and sophisticated breach investigations look.

UEBA key detection signals:

Signal	What it detects	Typical threat
Impossible travel	Login from London, then 2 hours later from Seoul — physically impossible	Credential theft; account sharing
Data volume anomaly	User uploads 50x normal data to external storage	Insider exfiltration; departing employee
Off-hours access	User accesses payroll system at 3am on a weekend; baseline is Mon-Fri 9-6	Compromised account; malicious insider
Peer group deviation	Sales rep accesses engineering source code repos; no peers do this	IP theft; account compromise
Privilege escalation pattern	Standard user queries admin-only APIs repeatedly, all returning 403	Reconnaissance; privilege probing

UEBA limitations to acknowledge in discussion:
• Baseline requires 30-90 days of training data before alerts are reliable
• New employees have no baseline — high FP rate initially
• Anomaly ≠ threat: legitimate business travel triggers impossible travel; UEBA needs analyst interpretation
• Costly: ML-based UEBA at scale requires significant storage and compute

Key vocabulary:
• UEBA (User and Entity Behaviour Analytics) — ML-based analysis that baselines normal behaviour per user/entity and fires alerts on significant deviation; detects insider threats and compromised credentials
• Baseline — the model of normal behaviour for a specific user or entity, built from historical data; the reference against which current behaviour is compared
• Anomaly score — a numerical risk score reflecting how far a user's current behaviour deviates from their baseline; high score → alert to analyst
• Peer group analysis — comparing a user's behaviour to a cohort of similar users (same role, department); identifying outliers within a peer group