Defensive methodology
SOC and SIEM
The SOC monitors, triages and escalates. The SIEM centralises logs, makes them searchable and raises alerts. The analyst's job is to decide quickly and correctly: true or false positive, and what to do next.
DefensiveElastic / KibanaKQLSplunk SPL
How a SOC is organised
| Tier | Role |
|---|---|
| L1 – Triage | Monitors alerts, dismisses false positives, documents and escalates. |
| L2 – Investigation | In-depth analysis, correlation, scoping, starts containment. |
| L3 – Expertise | Threat hunting, forensics, reverse engineering, improving detections. |
| Detection engineering | Writes and tunes rules, manages log sources. |
Classifying an alert
| Verdict | Meaning |
|---|---|
| True positive | Alert raised and the activity really is malicious. |
| False positive | Alert raised on legitimate activity: the rule needs tuning. |
| True negative | No alert, and nothing malicious. |
| False negative | No alert although an attack happened: the most dangerous case. |
Triage process
- Read the alertRule, host, user, time, severity.
- ContextMachine role, privileged account? Usual activity?
- WidenWhat happened before and after, on this host and account?
- CorrelateDo other sources confirm it (network, EDR, proxy)?
- DecideVerdict, real severity, escalate or close.
- DocumentWhat was seen, checked, concluded, and why.
The 5 questionsWho? What? Where? When? How? A triage note that answers them is almost always enough.
Searching the SIEM
- Always set the time range before searching.
- Start broad, then add filters one at a time.
- Show the useful columns (host, user, command) in Discover.
- Use visualisations to spot spikes.
Cheat sheetSIEM queries: KQL, SPL and ECS fields →
Reducing false positives
- Exclude precisely (one host, one service account), never broadly.
- Prefer thresholds and time windows over simple matches.
- Combine several weak signals rather than a single strong but noisy one.
- Document every exception: who added it, why, until when.
- Write rules in Sigma to make them portable across SIEMs.
Ticket checklist
- Summary of the alert and the rule that fired
- Hosts, accounts and IPs involved
- Timeline of the relevant events
- Queries used to check
- Reasoned verdict (true / false positive)
- Actions taken or recommended, and any escalation
- MITRE ATT&CK mapping where relevant