You will now do the Tier 1 job for real: generate a mix of activity — some benign, some hostile — then triage each alert as an analyst would, at speed, and write it up. Snapshot all three machines first.
1. Generate a realistic mix (20 minutes)
An analyst's queue is mostly noise with occasional signal. Produce that mix so your triage is realistic, not a series of obvious attacks.
On Ubuntu, some benign activity and some hostile:
# benign: normal logins and sudo
sudo apt update
sudo systemctl status ssh
ssh student@localhost # correct password — a normal login
# hostile: a brute force
for i in $(seq 1 8); do ssh admin@localhost 2>/dev/null; done
# ambiguous: a single failed login (typo? or probe?)
ssh student@localhost # one wrong password, then correct
On Windows:
# benign
Get-Service | Out-Null
# hostile: account creation
New-LocalUser -Name "svc_backup" -NoPassword
Add-LocalGroupMember -Group "Administrators" -Member "svc_backup"
# ambiguous: a couple of failed logons
# (lock and mistype twice, then log in)
2. Work the queue (25 minutes)
In the dashboard, look at everything from the last hour across both agents, sorted by level. This is your alert queue. Now triage every alert, spending no more than a minute or two on each — Tier 1 pace.
For each alert, record in a triage table:
| Time | Source | Alert | Level | Verdict | Severity | Action |
|---|
- Verdict: true positive, false positive, or needs-investigation.
- Severity: your judgement, not just the rule level — consider what system and what account.
- Action: close, investigate, or escalate.
Force yourself to decide quickly. Triage is not investigation; it is the rapid sort. You will be wrong occasionally, and that is expected — the skill is being mostly right, fast, and knowing which ones you are unsure about.
3. Handle the ambiguous ones (15 minutes)
The single failed login, the two failed logons — these are the real test. They are not obviously benign and not obviously hostile. This is where triage judgement lives.
For each ambiguous alert, ask:
- What else was happening around the same time from the same source? (Pivot and search.)
- Does a single failure sit alone, or is it the edge of a pattern?
- Would this alarm you on a critical system, even if not on a test box?
Write your reasoning. "I judged this benign because it was a single failure immediately followed by a successful login from the same user — consistent with a typo, not an attack" is exactly the kind of documented reasoning a SOC runs on. The verdict matters less than that your reasoning is sound and written down.
4. Escalate properly (10 minutes)
Take the one or two alerts you judged serious — the brute force, the account creation — and write an escalation as you would hand to Tier 2:
- What triggered it and when.
- Why you believe it is real — the evidence.
- Initial scope — what you already know.
- Why it needs Tier 2 — what you cannot determine at triage.
A good escalation saves the next analyst time; a bad one makes them start from nothing. Write it so someone who has not seen your screen can pick it up and run.
5. Clean up (5 minutes)
# Windows
Remove-LocalUser -Name "svc_backup"
Confirm the removal appears in your monitoring — and note that a real attacker's cleanup would appear the same way, which is why deletion events are worth watching too.
Extension, if you finish early
- Time yourself: how long per alert? Tier 1 handles a large queue, so pace is real. But watch that speed does not cost accuracy — the metrics lecture warned exactly about this trade-off.
- Re-triage one alert you closed as false positive. Are you certain? What would change your mind? This self-doubt is healthy and is how missed attacks get caught on a second look.
Done?
Show your instructor:
- Your triage table for the full queue, verdicts and reasoning included.
- Your documented reasoning on the ambiguous alerts.
- A written escalation for a serious alert, usable by someone who did not see your screen.