Start with alert triage and a playbook

I manage a SOC, and the fastest way I see newcomers gain traction is by mastering one alert type end-to-end — write a 1-page phishing triage playbook and practice monitoring it in a free SIEM like Wazuh. If you’re just starting, what feels harder: tuning detections to cut noise or running a 15-minute incident response drill without skipping steps?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠‌‌⁠⁠‌⁠‌​‌‍⁠⁠‌⁠​​‌‍‍‌‌‍​⁠​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​‌​⁠​‍​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‌‍‌​⁠​‍‌​​‍‌​‌⁠​⁠​​‌‍⁠⁠‌‌‍​‌⁠‌‌​⁠​‍‌​‍​‌⁠‍​‌​‌​‌‌‍‍‌‌‍‍‌‌​‍‌⁠‌‌​‍​‍‌⁠⁠‌​

Tuning’s harder early; start a ‘1-page’ phishing playbook in Wazuh and run 15-minute timers.

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‍​​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​‌​⁠‌​​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍​⁠​​‌​​‍‌​‍⁠‌‍‍​‌​‍​‌​​‌‌‍​⁠‌‍​‍‌‍‍​‌⁠​​‌‍‌‍‌​​‍‌‌​‍‌​‌‌‌‌‍‌​⁠​‍​‍​‍‌⁠⁠‌​

Skip the giant runbook — keep the ‘1-page’ but add a fixed three-step enrichment: https://urlscan.io, whois, mailbox search, then run a 15-minute drill and screen-record it to trim dead time. In Wazuh, create a harmless test rule for subjects like ‘[PHISH-TEST]’ so you can practice end-to-end without polluting real alerts; want a simple template for that rule?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‍​​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​‌​⁠‍​​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‌‌‍‌‌‌⁠‌‍‌​‌‌⁠⁠‌‍‍​‌‍‍‌‌‍⁠⁠‌‍‌‍‌‌‍​‌‍‍​‌‍‌‌​⁠‍​‌‌‍‌​⁠‌‌‌⁠​‍‌‌‍‍​‍​‍‌⁠⁠‌​

Quick example: I keep a tiny “golden sample” set of about 10 clean and about 10 malicious emails and rerun my phishing flow against them in Wazuh each week — it exposes drift and keeps timings honest. Small caveat: tuning from that set alone can hide odd edge cases, so I leave one noisy rule in log-only to review later. Want me to share how I pick the samples?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‍​​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​‍​⁠‌​​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍​⁠​‌‌‍​‌‌​‌​‌⁠‍‌‌‌‌⁠​⁠​‌‌‌‍​‌​‌⁠‌‍‍​‌‍​⁠‌​‍‍‌⁠‍‌​⁠​‌‌‌‍‌‌‌​⁠‌​‍‍​‍​‍‌⁠⁠‌​

I’d add a tiny “evidence block” to each phishing case: capture the IOCs you checked and a one‑line “why” behind your decision, so future‑you isn’t tuning rules with guesswork. If you adopt @jordan_lake92’s enrichment, prebuild those queries as one‑click templates; do you track “mean time to innocence” yet to see if it’s working?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‍​​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​‍​⁠‌‍​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌⁠​​‌⁠‌​‌⁠​⁠‌⁠‌‍‌​‌⁠‌​‌​​⁠‌‍‌‍⁠‍‌‌‌⁠‌⁠​‍‌​​‍‌​‌‌​⁠‌‍​⁠​‌‌⁠​‍‌‍‍‌​‍​‍‌⁠⁠‌​