PROBLEM
A SIEM dashboard without analyst discipline: alerts closed with no note or escalated with no facts.
PODEJŚCIE
A repeatable Security Analyst workshop: alert intake, telemetry checks, TP/FP classification, ATT&CK mapping and an escalation note.
ARCHITECTURE
- alert source (Wazuh / Event Log from the SOC lab)
- triage template (required fields)
- ATT&CK map only when the log covers the technique
- Outcome: escalate / watch / false positive / benign true positive
IMPLEMENTATION
- first-note field checklist
- TP vs FP drills on the same rules
- detection rule review after FP series
- hand-off to IR when the decision is escalate
RESULT
- portfolio evidence for SA skills (triage + detection)
- Linked resources: Event Log, IR, Wazuh rule review
- habit of a note before closing an alert
LESSONS
- an alert without host/account/time context is useless
- FP is a signal to fix the rule, not a shame metric
Goal
This project bundles skills expected of a Security Analyst (L1/L2): read the alert, check telemetry, classify, map a technique only when the log supports it, write a note worth escalating. It is not a LinkedIn title — it is a workshop with evidence from the lab.
Two problems I solved
1. Alerts closed with no decision trail
I knew “what to click in the SIEM”, but a week later nobody could reconstruct why an alert was FP or escalated. Required fields were missing.
What I gained: a first-note template (host, account, time with zone, rule source, artefacts, decision, gaps). I practise it on alerts from the SOC Home Lab and Wazuh. Same habit a SA queue demands.
2. Treating false positives as failure instead of a detection signal
When a rule was noisy I either disabled it or ignored alerts. Neither improves detection.
What I gained: an FP → rule review → hit/miss test loop with the Wazuh rule-review template. I separate false positive, benign true positive, true positive → escalate. ATT&CK is added only with telemetry coverage — not forced.
What signals Security Analyst fit
| SA skill | How I practise it in the lab |
|---|---|
| Time-boxed triage | Timed scenario: 10–15 min for the first note |
| Reading Windows/Linux telemetry | Event Log cheat sheet, syslog, Wazuh alert |
| TP/FP classification | Same rules, different stimuli (admin vs suspicious) |
| Detection hygiene | Rule review after FP series, replay test |
| Quality escalation | Note aligned with the IR checklist |
| ATT&CK context | Only when Event ID / log covers the technique |
One exercise flow
- Intake — alert ID, rule, host, user, timestamp.
- Context — lab host/account? Was the stimulus intentional?
- Verify — raw log / related Event IDs; can you replay the event?
- Classify — TP / BTP / FP / need more data.
- ATT&CK — optional, justified by telemetry.
- Decide — close with rationale, watch, or escalate to the IR path.
- Detect — if FP is repeatable → a rule ticket (not “ignore forever”).
Example lab scenarios
- failed Windows logons (4625) vs success from a new source (4624),
- new service / scheduled task as a persistence signal,
- Wazuh alert with an explicit positive test and a false trail,
- noisy rule → review and tighten (not a blind disable).
Related material
- SOC Home Lab
- Wazuh SIEM
- Incident Response Lab
- First note after an alert
- Windows event logs for SOC
- SOC L1 lab architecture
Boundaries
Own hosts only. No client data, no “ready SOC L2 with a certificate” claim, no monitoring someone else’s production. A company SA role still needs org playbooks, ticketing and mentoring — this shows the analytical foundation.
Status
active: the workshop grows with the SOC/Wazuh lab. This entry is the portfolio anchor for Security Analyst conversations.