Every alert in the demo is worked through these steps. The triage panel shows the reasoning at each one.
What it shows
A tier 1 analyst’s day is mostly a queue: read the alert, decide whether it’s real, decide what happens next, and write down why. This demo recreates that queue with eighteen synthetic alerts, written to resemble what Sysmon, Windows Security logging, a web proxy and an identity provider would produce.
What fired? The rule name and the raw event that triggered it.
Is it plausible? Compare against what is normal for that host and user.
What technique does it map to? A MITRE ATT&CK technique gives a shared vocabulary for the behavior.
Disposition. True positive, benign true positive, false positive, or escalate.
Next steps. What a responder should do now, in order.
How it’s built
The alerts live in one data file, src/data/alerts.ts. Every IP address comes from the ranges reserved for documentation (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) and every domain uses example names, so nothing points at a real system.
Filtering and sorting are plain functions in src/lib/alerts.ts, covered by unit tests in tests/alerts.test.ts.
The search box trims input, removes control characters and caps the length before it’s used. Results are written into the page as text, never as HTML.
exportfunctionsanitizeQuery(raw:unknown, maxLength =100):string{if(typeof raw !=='string')return'';return raw
.replace(/[\u0000-\u001f\u007f]/g,'').trim().slice(0, maxLength).toLowerCase();}
Limits
The data is invented. The dispositions are written as teaching notes, not as output from a real detection engine. The value here is the triage reasoning, which is mine to explain in an interview.