After this lesson, you will be able to: Use Splunk Free (or the Splunk Boss of the SOC dataset) to query logs, write a detection, and build a basic alert.
SIEM is the central nervous system of every SOC. Splunk is the most-used SIEM in the world and the lingua franca of detection engineering interviews. This lesson gets you running queries in a real Splunk instance and writing your first detection.
A SIEM (Security Information and Event Management) collects logs from every system that matters (endpoints, servers, firewalls, cloud, identity), normalises them, and lets analysts search across the whole environment. On top of search, it provides alerting (a saved query that runs on a schedule and fires when results appear), dashboards, and case-management workflows. Splunk dominates the enterprise market. Microsoft Sentinel, Elastic Security, Sumo Logic, and Chronicle (Google) are the other big names you'll see on job postings.
The Free tier indexes up to 500MB of data per day and is enough for serious learning.
Sign up at splunk.com (free) and download Splunk Enterprise (the free tier flag activates after 60 days, plenty of time to learn)
Install on your host OS or in a small Linux VM (Splunk has 1-click installers for Windows, macOS, Linux)
Start Splunk and log in to http://localhost:8000 with the admin account you set during install
Download the Splunk Boss of the SOC v1 dataset (https://github.com/splunk/botsv1-attack-only) and follow its README to import data
Go to Search & Reporting and run a first query: index=botsv1 | stats count by sourcetype
Splunk Processing Language (SPL) is its own dialect. These five queries cover most day-to-day work.
# 1. Top user-agents in HTTP logs (find suspicious automation)index=botsv1 sourcetype=stream:http| stats count by http_user_agent| sort -count# 2. Failed logins clustered by source IP (brute force candidates)index=botsv1 sourcetype=WinEventLog:Security EventCode=4625| stats count by src_ip, user| where count > 5# 3. Outbound traffic to rare destinations (potential exfil)index=botsv1 sourcetype=stream:tcp dest_ip!=10.0.0.0/8| stats count by dest_ip| sort count# 4. PowerShell encoded commands (often malicious)index=botsv1 sourcetype=WinEventLog:* CommandLine="*-enc*"| table _time, host, user, CommandLine# 5. New process executions by parent (look for cmd.exe spawned from word.exe)index=botsv1 sourcetype=WinEventLog:* EventCode=4688| stats values(NewProcessName) by ParentProcessName
Saved searches become alerts. This is the basic loop of detection engineering.
Pick a query above that looks for malicious behavior (e.g., #2: clustered failed logins)
In the Search bar, run it and adjust until it returns true positives in the BOTS dataset
Save As > Alert. Give it a name and a schedule (every 5 minutes)
Set trigger conditions: 'Number of Results' > 5 within 5 min
Set action: Add to Triggered Alerts (for the lab), in production you'd send to email / Slack / case-management
Leave it running; check Triggered Alerts after another search cycle confirms it fires
Document the alert: title, query, false-positive rate, response steps. This becomes the alert runbook.
Alerting on raw signals (every 4625 event) instead of correlated patterns (5+ failures from one IP across 5+ accounts in 5 min). Forgetting time-based context, the same activity is suspicious at 3am and benign at 10am. Not testing detections against the BOTS dataset (or similar) before pushing to prod, false positives ship by default. Not measuring alert volume after deployment, alerts that fire too often or too rarely both die in the queue. Skipping the runbook, the alert is the question, the runbook is the answer.
Pick the one that minimises false positives.
Sign in and purchase access to unlock this lesson.