SOC alert triage with a small SIEM and a written playbook

Meridian is a small managed security provider watching the networks of a dozen client companies. Their monitoring throws about 3,000 raw alerts a day, almost all noise, so their two analysts miss the few that matter. Last quarter a real brute-force login against a client went unnoticed for six days, buried under failed-login alerts that were mostly normal.

They want a saner way to triage. You will stand up a small SIEM on a single machine, feed it sample logs, write detection rules that turn raw events into meaningful alerts, and write a triage playbook so an analyst handles each alert type the same way every time. The aim is not more alerts; it is fewer and better ones, ranked so the analyst works the top of the list first.

You will use public or synthetic sample logs, such as authentication logs, web server logs and firewall logs, loaded into an open SIEM like Wazuh or an ELK stack you run locally. You will write rules for a handful of real patterns: brute-force login attempts, a login from an impossible travel distance, a spike in server errors, and a known bad file hash. Each rule has a severity and a reason. Then you write the playbook: for each alert type, what the analyst checks, what counts as a true or false positive, and when to escalate. Done looks like the 3,000-event sample reduced to a ranked queue of tens of alerts, a documented rule set, and a playbook an analyst who has never seen the system could follow. Meridian signs off when the planted brute-force attack shows up near the top of the queue, not buried.