🔄 Topic

Understanding how SIEM tools collect logs and help analysts turn raw events into investigations.

🎯 Goal

Connect logs, dashboards, alerts, and evidence into a practical SOC triage workflow.

🛠 What I Did

Today I continued Course 2 — Play It Safe: Manage Security Risks and focused on SIEM tools.

A SIEM — Security Information and Event Management — collects and organizes logs from different systems so analysts can search, correlate, alert, and investigate.

The course introduced SIEM dashboards and how analysts use them during daily work. I focused on the practical point: a SIEM is not magic. It is only as useful as the logs, parsing, detection rules, and analyst questions behind it.

🔗 Key Cybersecurity Connections

A SOC alert is usually only the beginning.

Example flow:

firewall logs
endpoint logs
authentication logs
DNS logs
proxy logs
    ↓
SIEM ingestion
    ↓
detection rule or dashboard
    ↓
analyst triage
    ↓
escalation or closure

A good analyst must know which log source can answer which question. Authentication logs answer login questions. DNS logs answer domain lookup questions. Endpoint logs answer process execution questions.

🔍 Investigation Questions

  • What triggered the alert?
  • Which log source generated the event?
  • Is the field parsing correct?
  • Which user, host, IP, process, or domain is involved?
  • Is this activity normal for this asset?
  • What happened before and after the alert?
  • Is there corroborating evidence in another log source?
  • Can the alert be tuned to reduce false positives?

🚨 Detection Opportunities

Detection ideas:

  • many failed logins from one source IP
  • password spraying across many users
  • PowerShell launched by Office
  • DNS lookup to rare domain followed by outbound connection
  • VPN login from rare geography
  • new admin account created outside change window

Example SIEM-style event:

index=auth
user=m.rossi
src_ip=203.0.113.44
action=login_failure
count=34
window=10m
detection=possible_bruteforce

🧭 MITRE ATT&CK Techniques

Possible mappings:

  • T1110 — Brute Force
  • T1110.003 — Password Spraying
  • T1059 — Command and Scripting Interpreter
  • T1071 — Application Layer Protocol
  • T1078 — Valid Accounts

🗺 Visual Investigation Diagram

Raw logs
    ↓
SIEM ingestion
    ↓
Parsed fields
    ↓
Rule / dashboard
    ↓
Alert
    ↓
Analyst triage

⚠ Challenges

The challenge is avoiding blind trust in dashboards. A dashboard can summarize activity, but it can also hide context.

If the log source is missing, delayed, or parsed badly, the investigation may be wrong from the start.

📚 What I Learned

I learned that SIEM work is really evidence work. The analyst has to pivot across fields, validate assumptions, and build a timeline from multiple sources.

➡ Next Steps

  • Practice writing simple SIEM-style queries
  • List common log sources and what questions they answer
  • Create a false-positive notes section for each detection
  • Build fake logs for brute force and password spraying

🧠 Reflection

This connects directly to my detection engineering goals. The more I understand log sources and fields, the better I can write useful detections.

🧩 Lessons Learned

What worked

Thinking of SIEM as searchable evidence rather than an automatic answer machine.

What broke

Dashboards can create a false sense of certainty.

Why it broke

Summaries hide field quality, missing logs, and context.

Fix / takeaway

Always pivot from the dashboard back to raw events and related evidence.

📈 Skill Progression Context

This supports my SOC analyst and detection engineering progression because it turns course material into investigation habits: identifying assets, reading evidence, asking better questions, and explaining security risk clearly.

Instead of treating the certificate as passive study, I am using each topic to build practical analyst thinking that can later become lab notes, detections, diagrams, or portfolio writeups.

😄 TL;DR

A SIEM does not investigate. It gives the analyst a place to ask better questions.