← Back to Defend

Detection and Logging

SIEM Basics

A SIEM brings logs together, parses them into consistent fields, adds context, and correlates behaviors across time. Start with a small set of high value detections, measure noise, and iterate.

Learning objectives

What you should be able to do after reading.
  • Explain ingestion, parsing, normalization, enrichment, and correlation in simple terms
  • Build detections that are testable, maintainable, and tied to clear response actions
  • Use dashboards and triage workflows to reduce time to investigate and contain incidents

At a glance

Fast mental model before you dive in.
🧠
Core capabilities
  • Collect and store logs centrally
  • Parse and normalize fields for search
  • Correlate events and trigger alerts
  • Support investigation and reporting
What good data looks like
  • Consistent timestamps and time zone handling
  • Stable fields like user, host, src_ip, action
  • Low parser error rates and clear source tagging
  • Enrichment for assets and identity context
A workable workflow
  • Detect, validate signal quality, add context
  • Decide: close, monitor, or escalate to incident
  • Document what you learned and tune rules
  • Review gaps and improve logging coverage

SIEM workflow

Stage What happens Why it matters Outputs
Ingest Collect events from endpoints, servers, network, and cloud services Without coverage you cannot detect or investigate reliably Connectors, forwarders, and ingestion pipelines
Normalize Parse logs and map fields into a consistent schema Makes searches portable and correlation predictable Unified fields such as user, host, source_ip, and outcome
Enrich Add asset, identity, and business context plus known bad indicators Improves prioritization and reduces false positives Entity context, risk scoring, and tagging
Detect Run rules and analytics that look for behaviors over time Turns raw events into actionable alerts Alerts with evidence, timelines, and links to raw logs
Respond Triage, contain, eradicate, and document lessons learned Reduces impact and improves future detections Cases, playbooks, and feedback into tuning

Make it sustainable

  • Start with a few high confidence use cases and add more only after tuning
  • Test detections with known good and known bad scenarios, then track false positives
  • Document ownership, severity, and response steps so alerts lead to consistent action

DEEP DIVE

▾

Ingestion and parsing: where quality is won

Ingestion is not complete until you can query reliably. Track which sources are onboarded, whether they arrive on time, and whether key fields parse correctly.

Parsing failures are silent risk. If a parser stops extracting user or src_ip, detections may still run but become far less useful. Monitor parsing health as a first class metric.

Keep source metadata. Always tag events with source system, environment, and collection path so you can troubleshoot and trust your searches.

Detection engineering for beginners

Start with a small set of detections you can explain and validate. Good starters map to clear attacker behaviors such as brute force, new admin creation, suspicious remote access, or unexpected outbound connections.

Write detections to be actionable: what happened, why it matters, what to check next, and what to do if confirmed.

Prefer stable fields and avoid brittle string matching when possible. If the data is messy, fix parsing first.

Triage flow that scales

A scalable triage flow is consistent. Verify signal quality, check context, then decide. Use a short checklist so different analysts reach similar conclusions.

Capture evidence and pivots: related events, time windows, affected assets, and user context. This reduces repeated work and improves handoffs.

If your SIEM supports cases, use them to link related alerts and document tuning decisions.

Continuous improvement loop

Treat detections as products. Each rule should have an owner, a purpose, test data, and a tuning history.

Review false positives and missed detections regularly. If an incident required data you did not have, that is a logging gap to close.

Use post incident reviews to update both logging requirements and detection logic, then validate the changes.

A simple data model makes everything easier

SIEMs work best when fields mean the same thing everywhere. Adopt a consistent schema for core fields like user, host, process, src_ip, dst_ip, action, and result.

Enrichment fits naturally into this model. Add asset tags, business owner, and criticality so detections can prioritize what matters.

Keep raw events alongside parsed fields so you can reprocess as your data model evolves.

Alert quality: signal, severity, and confidence

Not every suspicious event is an incident. Use severity to describe impact if true, and confidence to describe how likely it is true. This separation improves prioritization.

Prefer fewer high quality alerts over many low value ones. If you generate too many alerts, triage becomes random and real incidents get missed.

Include context in alerts: who, what, where, and why, plus suggested pivots.

Retention, access, and operational hygiene

Retention should match investigation needs and cost constraints. Keep fast searchable data for the period you most often investigate, then archive older data for longer lookbacks.

Protect the SIEM itself. Restrict who can delete data or disable sources. Log changes to ingestion settings and detection rules, because these are high value attacker targets.

Measure ingestion delay, dropped events, and storage health so you know when your visibility is degraded.

Starter roadmap

• Inventory log sources and onboard the highest value ones first

• Normalize key fields and monitor parsing health

• Build a small detection set and document triage steps

• Add enrichment for assets and identity

• Tune regularly, then expand coverage with measured scope