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:
flowchart TD
A["log source"]
B["collection"]
C["normalisation"]
D["detection"]
E["alert"]
F["investigation"]
A --> B
B --> C
C --> D
D --> E
E --> F
A 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