1. An alert fires: suspicious sign-in for j.morrison from a Tor exit node. You check SigninLogs and find j.morrison also has an active legitimate session from the Bristol office at the same time. Using the triage scorecard, what does this dual-session finding contribute to your classification?
It scores Q1 (evidence of compromise beyond the alert) as YES (+3), because the simultaneous session from two locations with one being a Tor exit node is a corroborating indicator that the alert represents a genuine token replay attack — not a VPN or travel scenario.
It scores Q3 (active/historical) as ACTIVE, but does not affect Q1 because the dual session is explained by the alert itself, not additional evidence.
It reduces the score because the legitimate session proves the user's account is still functional, suggesting the Tor session may be a VPN connection.
Correct. The simultaneous session from Bristol + Tor exit node answers Q1 definitively: there IS evidence of compromise beyond the alert. The legitimate session DISPROVES the VPN explanation because VPN traffic would replace the user's IP, not create a parallel session. Two concurrent sessions from two countries = token replay confirmed.
2. Your triage scorecard produces a total of 10 (probable TP), but your confidence is low because the user is unreachable and you cannot verify the activity. What is the correct action per the scorecard methodology?
Close the alert as indeterminate and re-triage when the user is available to confirm.
Escalate immediately. Q8 (confidence override) requires that low confidence on a score of 8 or above triggers escalation regardless. Begin evidence preservation while awaiting user verification.
Reduce the score by 3 points to account for the uncertainty, producing a score of 7 (likely FP), and close with documentation.
Correct. Q8 is the confidence override: low confidence + score ≥ 8 = escalate. You do not reduce the score — the score reflects the data you DO have. Low confidence reflects data you do NOT have. The correct response: escalate with the documented uncertainty ("user unreachable — classification pending verification") and begin evidence preservation. Waiting for user verification delays the response while the attacker (if this is real) continues operating.
3. An attack at NE crosses from cloud (AiTM) to Windows (endpoint compromise via OneDrive) to Linux (SSH to database server). The cloud team triages the cloud alert and revokes the user's session. Is the incident contained?
Yes — revoking the cloud session removes the attacker's access to the M365 environment, which stops the attack chain.
No — the endpoint compromise operates independently of the cloud session. The malicious DLL on the workstation executes regardless of cloud session status. The SSH to Linux uses stolen credentials, not the cloud token. Cloud containment stops cloud access only. Endpoint isolation and Linux containment are also required.
Partially — the cloud containment stops new attacks, but the existing endpoint and Linux compromises need separate investigation (not separate containment).
Correct. Cloud containment stops cloud access. The endpoint DLL and the Linux SSH session operate independently — they use different credentials and different access paths. Containment must be executed in ALL THREE environments: cloud (session revocation — done), Windows (device isolation — needed), Linux (iptables block + account disable — needed). This is why cross-environment triage capability matters: the cloud team correctly triaged their environment but the attacker retained access in the other two.
4. What is the primary danger of "triage creep" — continuing into investigation activities instead of completing the triage handoff?
The triage responder may make incorrect forensic conclusions without proper investigation tools.
The investigation team may resent the triage responder for doing their job.
The investigation team cannot begin until they receive the triage handoff, and other alerts in the triage queue accumulate unclassified. Every minute spent investigating is a minute the investigation team waits AND a minute other alerts go untriaged.
Correct. Triage creep has two costs: the investigation team is blocked (they need the triage report to begin), and the alert queue grows (no one is triaging while you investigate). The discipline: complete the Triage Trinity, produce the report, hand off, return to the queue. If you are also the investigator, explicitly switch roles — close the triage phase before beginning investigation.
5. A penetration tester (a.patel) is running an authorised Kerberoasting attack during an approved testing window. The Defender for Identity alert fires correctly. What is the classification and what should the triage documentation include?
False positive — the detection rule incorrectly fired on legitimate activity. Document as FP and request a rule exclusion for a.patel.
Benign true positive (BTP). The detection correctly identified Kerberoasting (the rule is working). The activity is authorised (change ticket CHG-2026-0415). Close with BTP classification, reference the change ticket, and verify the timestamp falls within the approved window. Do NOT create a permanent exclusion — you want this rule to fire if someone other than a.patel Kerberoasts outside the testing window.
True positive — Kerberoasting was detected and should be escalated regardless of the testing authorisation.
Correct. BTP is the accurate classification: the rule detected real activity (not an FP), but the activity is authorised (not an incident). The key detail: reference the change ticket and verify the timing. If the same Kerberoasting occurs OUTSIDE the approved window or from a DIFFERENT user, the classification changes to TP. A permanent exclusion for a.patel would blind the SOC to genuine credential attacks from a.patel's compromised account.
6. Which category of evidence is MOST volatile and must be captured first during the triage preservation phase?
Memory contents and running processes — destroyed on reboot, overwritten by normal system operation, and actively modified as applications allocate and free memory. A reboot eliminates all evidence in this category.
Event logs — they persist on disk but rotate based on maximum size, potentially overwriting evidence within hours on busy systems.
Cloud sign-in logs — they have a 30-90 day retention period depending on licence tier.
Correct. Memory and running processes are the most volatile. A reboot destroys them entirely. Event logs persist on disk (semi-volatile — they rotate but survive reboots). Cloud logs persist in cloud storage (least volatile for triage purposes, though they have finite retention). The preservation hierarchy from TR1 formalises this: memory first, then processes and network state, then logs, then disk artifacts.
7. The triage scorecard asks 8 questions. Which three questions have the highest point values and why?
Q1 (evidence of compromise), Q2 (scope beyond single entity), and Q3 (active or historical) — each worth 3 points. These three questions most strongly differentiate true positives from false positives. Corroborating evidence, multi-entity scope, and active threat status are the strongest indicators that an alert represents a genuine incident.
Q5 (containment urgency), Q6 (business impact), and Q7 (regulatory trigger) — because these determine the response severity.
Q4 (sensitive data), Q6 (business impact), and Q8 (confidence) — because these determine whether the incident matters to the organisation.
Correct. Q1, Q2, and Q3 are the diagnostic core of the scorecard — they determine WHETHER the alert is an incident. Q4-Q7 determine HOW SEVERE the incident is. Q8 provides the confidence override. The diagnostic questions must score highest because the primary triage objective is classification accuracy. Severity assessment (Q4-Q7) matters only after the classification is established.
8. You are triaging an alert on a Saturday at 02:00. The alert scores 12 on the triage scorecard (probable TP). What is the correct approach?
Wait until Monday to investigate — a probable TP can wait for normal business hours.
Investigate fully yourself to avoid waking the IR team unnecessarily.
Begin evidence preservation immediately — volatile evidence degrades regardless of the day or time. Execute containment if Q5 scored high. Produce the triage report and escalate to the on-call IR contact. A score of 12 is above the probable TP threshold (8+) and triggers the preserve-and-escalate sequence regardless of when the alert fires.
Correct. Evidence does not wait for business hours. A probable TP at 02:00 Saturday requires the same response as a probable TP at 10:00 Monday: preserve volatile evidence, contain if urgent, produce the triage report, escalate to the on-call IR contact. Module TR12 covers after-hours triage specifically, including the 5-minute assessment that determines whether to wake the IR team or continue solo monitoring.
9. Your SOC processes 50 alerts per day with a 60% false positive rate. Each FP takes 8 minutes to triage. How much analyst time per day is consumed by false positives, and what is the primary action to reduce this?
240 minutes (4 hours) per day. 50 alerts times 60% equals 30 FPs. 30 FPs times 8 minutes equals 240 minutes. The primary action is detection rule tuning — identifying the 3-5 analytics rules that generate the most FPs and submitting tuning requests with the specific FP conditions documented from triage. Tuning the top 3 rules typically reduces FP volume by 40-60%, saving 96-144 minutes per day. This is more effective than adding analysts (which scales the waste) or auto-closing low-severity alerts (which hides real threats).
120 minutes per day. The solution is to hire another analyst.
240 minutes per day. The solution is to auto-close all low-severity alerts.
Correct. The FP cost calculation is fundamental to SOC capacity planning: FP count times triage time per FP equals analyst time consumed. The solution is always to reduce the FP count (detection tuning), not to process the FPs faster (alert fatigue risk) or ignore them (missed threat risk). The triage responder's FP documentation drives the tuning — without documented FP patterns, the detection engineering team does not know what to tune.
10. A triage responder classifies an alert as probable TP (scorecard 12) and executes containment. The investigation team later determines the alert was a false positive. Was the containment wrong?
No. The containment was correct based on the information available at triage time. Containment actions (session revocation, device isolation, password reset) are REVERSIBLE — the investigation team re-enables the account and releases the isolation once the FP is confirmed. The cost of unnecessary containment is brief business disruption. The cost of NOT containing a real TP (waiting for investigation to confirm) is potentially catastrophic. The triage responder is expected to contain on probable TP — that is the design intent of the classification system. A scorecard of 12 (probable TP range) warrants containment. The investigation team's subsequent FP determination does not retroactively make the containment decision wrong — it means the reversible safety net worked as intended.
Yes — containment should only be executed on confirmed TP (scorecard 15+).
It depends on the business impact of the containment.
Correct. This question tests a critical principle: containment is reversible, attacker actions are not. The triage system is DESIGNED to produce false containment (containing a probable TP that turns out to be FP) at a controlled rate. This is preferable to the alternative: not containing a probable TP that turns out to be a real breach. The cost asymmetry (reversible containment vs irreversible breach) makes the contain-on-probable-TP policy the rational default.
11. Rachel's SOC at NE processes 20 incidents per day. The average triage time is 12 minutes per incident. With 2 analysts per shift and 8 working hours per shift, what percentage of the shift is consumed by incident triage?
25%. Total triage time: 20 incidents times 12 minutes = 240 minutes (4 hours). Available analyst time: 2 analysts times 8 hours times 60 minutes = 960 minutes. Triage consumption: 240/960 = 25%. This means 75% of analyst time is available for proactive work — threat hunting, detection tuning, training, and process improvement. If the incident volume doubled to 40 per day (480 minutes of triage), consumption rises to 50% — still manageable but leaving less time for proactive work. At 80 incidents per day (960 minutes = 100% consumption), the SOC has zero capacity for anything except reactive triage and needs additional headcount or automation. This capacity calculation directly informs staffing and automation investment decisions.
50% — each analyst handles 10 incidents at 12 minutes each, consuming 2 hours of their 8-hour shift.
12.5% — 20 incidents split between 2 analysts is 10 each at 12 minutes = 120 minutes per analyst out of 480.
Correct. SOC capacity is calculated as total available analyst-minutes, not per-analyst minutes. Both analysts share the queue — the 20 incidents consume 240 minutes total regardless of how they are distributed between analysts. The 25% triage load is healthy — it leaves 75% capacity for proactive work. When triage load consistently exceeds 60%, the SOC is operating in reactive mode and needs capacity relief through either additional staffing or triage automation.
12. An alert fires at 14:00. The analyst starts triaging at 14:08 (8-minute queue wait). The scorecard is completed at 14:18 (10-minute triage). Containment is executed at 14:23 (5-minute containment). Documentation is completed at 14:28. What is the MTTR for this incident?
28 minutes. MTTR measures the total time from alert detection (14:00) to resolution (containment complete at 14:23, but documentation at 14:28 is the final step). The MTTR includes ALL phases: queue wait (8 min) + triage (10 min) + containment (5 min) + documentation (5 min) = 28 minutes. Some organisations define MTTR as time to containment (23 minutes) rather than time to full resolution (28 minutes) — the definition must be agreed upfront. At NE, Rachel defines MTTR as time to containment (23 minutes in this case) because containment is the action that stops the attacker. Documentation is essential but does not reduce risk. Either definition is valid as long as it is consistently applied across all incidents.
23 minutes — from alert to containment, excluding documentation.
20 minutes — from analyst start to documentation complete.
Correct. The MTTR definition varies by organisation. The critical point: the 8-minute queue wait is included in MTTR because the attacker was operating during those 8 minutes. Reducing the queue wait (through better prioritisation, SLA monitoring, or STAT auto-triage) directly reduces MTTR. In this example, if the queue wait were eliminated (analyst started at 14:00), MTTR drops to 20 minutes — a 29% improvement from a process change, not a skill improvement.
