Scenario 3: SIEM Alert Triage

Field	Value
Internal ID	09
Type	Defensive (SOC analyst)
Difficulty	Medium (level 2); lab time limit 45 minutes
Tasks	An unscored preparation task (Task 0) and 3 auto-scored milestones, total 225 points
Lab surface	siem: Kali and meta terminal tabs, with the SIEM opened in a modal
Scored on	meta container (SCENARIO_TARGETS[9] = "meta"), 30-second check timeout
Guide	cyberrange/portal/public/scenarios/scenario_03_siem_alert_triage_and_log_analysis.md

ExplainerScenario 3: SIEM Alert Triage & Log Analysis1:09

Objectives

The student switches to the defender's seat. They generate some suspicious activity from Kali, watch it surface in the Wazuh SIEM, separate real threats from routine noise, and produce three analyst artifacts on the meta host: a structured triage record, an ordered incident timeline, and a supervisor-ready incident report.

Concepts

What a SIEM is and how detection rules raise alerts, the discipline of triage (true positive vs false positive), building an attack timeline from scattered events, and writing an incident report that drives a response. The guide contrasts the meaningful rows (failed SSH, rootcheck) with routine CIS/SCA configuration-scan noise.

Topology, roles and machines

Machine	Address	Role	Terminal user
Kali	10.0.(50+N).10	Generates the activity to triage	student
meta	10.0.(50+N).20	Monitored host; where triage files are written and scored	msfadmin
wazuh-manager	10.0.40.10	Shared SIEM manager, reached over the peered monitoring network	n/a

Files must be on meta

The checker reads the three artifact files on the meta host, not on Kali. Files written on Kali never score. This is the guide's most emphasized point.

Tools

The Wazuh SIEM (through the portal's Open SIEM button, which opens the auto-refreshing alert viewer in a modal), a shell on meta for writing files (cat, nano, vi), and Kali for generating noise. The Wazuh manager is shared across labs, so the student filters the alert table to their own pod-<student>-meta agent. Since pull requests 187 and 201 the viewer shows event times in UTC (…Z) and clicking an individual event copies its timestamp and rule ID, ready to paste into the files. Closing the modal returns keyboard focus to the terminal.

The guide (rewritten in pull requests 187, 201 and 230) opens with a Fast path and gives paste-in skeletons for the three files with PASTE… slots to replace. A short explainer says lab times are UTC and may differ from the student's own clock (for example by 8 hours in the Philippines), and that only the SIEM's Updated clock is local time.

What is detected

A failed SSH login as a non-existent user raises Wazuh rule 5710 (the guide's primary signal), read from /var/log/auth.log by the agent's default configuration. Recon scans usually raise no Wazuh row. CIS/SCA rows are routine configuration-scan noise the student is expected to classify as false positives.

Milestones, checks and evidence

Task 0, "Generate the alerts" (preparation, not scored): from Kali, try one SSH login to meta as a non-existent user, so rule 5710 fires and meta's auth.log holds a real event to triage, then click that rule 5710 event in the SIEM to copy its …Z timestamp. The portal shows it as Task 0 in the outline but never polls it (prepTask in useScenarios.ts).

The checks look for each artifact file in /home/msfadmin, /home/student or /tmp on meta. Since pull request 242 the guide's /home/msfadmin copy wins, so a stale /tmp copy cannot override the file the student just edited (previously /tmp was checked first; _s9_select_artifact()). Pull requests 187, 201, 206 and 221 tightened all three checks so that only the student's own observed alert scores (the catalog names the milestones "Open a triage record", "Build the timeline" and "Write the incident report"):

#	Milestone	Points	What the check verifies	Source
1	Start Triage	50	alert_triage.json mentions alert_id, severity or rule; contains no unfilled skeleton text (PASTE…, HH:MM, angle-bracket placeholders) or the guide's fictional example; names this lab's pod-…-meta agent in an agent field (compared with meta's own hostname, so another student's agent fails); mentions rule 5710; and contains an ISO …Z timestamp that matches a genuine invalid-user SSH event in meta's auth.log within ±5 minutes	check_scenario_9 case 1, _s9_m1_reason(), _s9_has_real_event_timestamp()
2	True Positive Classification	100	incident_timeline.md has no skeleton text or guide example, and a line naming rule 5710 carries a full ISO …Z timestamp that matches a genuine invalid-user SSH event in meta's auth.log within ±5 minutes. The planted flag-m1- log line is ignored so its timestamp cannot be copied.	check_scenario_9 case 2, _s9_timeline_time_is_real()
3	Incident Summary	75	incident_report.txt is over 200 bytes and mentions system, attack, alert or recommend; is not the guide's example lightly edited; has at least 120 non-space characters besides the five guide headings (Summary, Affected system, Evidence, Interpretation, Recommended response); mentions rule 5710; and names this lab's meta agent	check_scenario_9 case 3, _s9_m3_reason()

Timezone tolerance (pull request 221, _s9_claim_matches_event()): auth.log is read as UTC, with the year inferred from the container's clock. Besides the ±5-minute match, the first valid …Z timestamp in the file (for Task 2, the first one on a rule 5710 line) may also match an event shifted by a whole number of hours (−12 to +14) within ±60 seconds, which covers a local SIEM time mislabelled as Z. Only one timestamp gets this allowance, so a list of guesses cannot cover every hour. This replaces the earlier rule that matched any HH:MM on minutes past the hour.

Completion detection

Same poller as the other scenarios, with a 30-second per-check timeout (scenarios 9 and 11 get the longer timeout). The lab page shows no Manual Check button for these tasks; since pull request 187 an unfinished scored task shows Ask an instructor to check this task instead, so a student whose files are not credited can still reach review (ExercisePanel.tsx). Complete when all three scored milestones have a PASS; score 225. There is no flag task.

For Milestone 1, the check has an optional SIEM detection mapping: if Wazuh rule 5710 is seen on the student's meta agent during the lab's lifetime, the row records detection_score = 1 as supplementary evidence. This is the only detection mapping wired into a live scenario (DETECTION_RULES in wazuh_rule_map.py).

Logs and evidence

• The three artifact files on meta are the student's deliverables.
• milestone_verification rows, with detection_data recording the Wazuh rule and agent when detection fires.
• Per-student flags are planted on meta at provisioning (an auth.log line, an alerts.json entry and a summary flag file) as supplementary artifacts.
• Instructor diagnostics (pull request 242, the pilot; off unless SCORING_DIAGNOSTICS_SCENARIOS includes 9 or S3_DIAGNOSTICS_ENABLED=1): a failed check records which test failed first, for example ARTIFACT_MISSING, PLACEHOLDER_OR_EXAMPLE, AGENT_MISMATCH, RULE_MISSING, TIMESTAMP_NOT_MATCHED or REPORT_BODY_TOO_SHORT, plus which location held the file (HOME_MSFADMIN, HOME_STUDENT, TMP) and how many locations had a copy. File contents are never recorded. See Lifecycle & Scoring.

Standards mapping

Framework	Mapping	Note
MITRE ATT&CK (portal)	T1595 Active Scanning	Represents the activity being triaged
NIST (rubric seed)	Detection & Identification, Analysis, Documentation & Response	The nist_phase column per milestone
OWASP	Not applicable	This is a defensive monitoring scenario

Safety

The activity is generated inside the student's own lab. The Wazuh manager is shared, and enrollment is passwordless by design, which is noted as a risk in the threat model. Triage work is read-only file creation on meta.