What a SIEM Does
Summary
This note explains what a SIEM is actually doing in day-to-day blue-team work. The goal is to build a realistic mental model instead of treating a SIEM as a magic dashboard.
Official Microsoft Sentinel dashboard view showing the kind of visibility layer a SIEM provides before investigation starts.
Why this matters
- a SIEM is central to many entry-level SOC workflows
- blue-team work becomes much easier once you understand what the platform is really doing
- tools like Wazuh, Sentinel, Splunk, or Elastic make more sense when you separate ingestion, detection, and investigation
Environment / Scope
| Item | Value |
|---|---|
| Topic | SIEM fundamentals |
| Best use for this note | building a blue-team platform mental model |
| Main focus | collection, correlation, alerting, investigation |
| Safe to practise? | yes |
Key concepts
- SIEM - security information and event management
- Ingestion - bringing logs and telemetry into the platform
- Correlation - connecting related events into something more meaningful
- Detection - logic that turns activity into an alert-worthy signal
- Investigation - the follow-up work after something is flagged
Mental model
Think about a SIEM as a pipeline:
log source -> collection -> normalisation -> detection -> alert -> investigationA SIEM does not “do security” by itself.
It helps collect evidence, apply logic, and make investigation easier.
Everyday examples
| Need | What the SIEM helps with |
|---|---|
| see failed logons across multiple systems | central log collection |
| spot suspicious PowerShell activity | detection rules on endpoint telemetry |
| review one alert in context | investigation and event history |
| reduce noise over time | tuning and rule improvement |
Common misunderstandings
| Misunderstanding | Better explanation |
|---|---|
| ”A SIEM blocks attacks” | a SIEM mainly provides visibility, alerting, and investigation support |
| ”More logs always means better security” | more data without useful detection and triage often just creates noise |
| ”An alert means confirmed malicious activity” | alerts are signals, not final conclusions |
| ”The SIEM is the detection” | the SIEM hosts detections, but detection quality still depends on rules, telemetry, and tuning |
Verification
| Check | Expected result |
|---|---|
| Sources are onboarded | logs arrive from expected systems |
| Time is correct | timestamps are consistent enough for investigation |
| Alerts can be produced | test events trigger expected detections |
| Context exists | event fields support triage and explanation |
Pitfalls / Troubleshooting
| Problem | Likely cause | What to check |
|---|---|---|
| No alerts at all | no telemetry, broken parsing, or weak detection logic | ingestion, timestamps, rules |
| Too many alerts | noisy detections or poor filtering | rule quality, thresholds, source context |
| Alerts are hard to explain | weak event context | fields, enrichment, logging quality |
| Same issue appears across tools differently | inconsistent normalisation | source mapping and parser behaviour |
Key takeaways
- a SIEM is a platform for visibility, detection, and investigation support
- alerts only matter if the underlying telemetry and logic are trustworthy
- good SIEM work is as much about signal quality as it is about collecting logs