Risk working example
The first scenario: the finance-team intrusion verdict
Turning evidence into a defensible priority
Uncover delivered: phishing-driven intrusion, two confirmed hosts compromised, federated SSO into a cloud finance platform from a stolen identity. Likely PCI and GDPR exposure was flagged during Scope for compliance to confirm. Risk now sets the priority.
Step 1. Score impact
High. Two hosts compromised. A federated SSO session reached a payment-processing platform. PCI and GDPR notification duties are likely triggered, with confirmation owned by compliance and counsel (GDPR’s 72-hour clock starts at awareness of a confirmed breach). If the adversary moves further, financial and regulatory consequences are direct. Even at the current evidence level, impact is high.
Step 2. Score likelihood
High. Multiple independent sources confirm: EDR process tree, network connection to a domain registered 4 days ago, federated identity SSO, mailbox audit on three users. The chain maps cleanly to a known phishing-with-macros pattern. No legitimate explanation has survived investigation. Likelihood is high.
Step 3. Combine via the matrix
High impact × high likelihood = Escalate immediately. The matrix says P1. The decision is automatic; the work is to produce the handoff package for incident response.
The RATM record behind the two axes
The two axes reduce from the four RATM dimensions (framework). The record as written in the case:
Asset criticality: High. laptop-finance-09 is a user-class endpoint, but the compromised identity federates into the PCI-scoped payment platform, a regulated-data store. Threat actor intent: Medium. Spear-phish with a finance-role lure and a four-day-old C2 domain; the dropper hash matches a known campaign at medium confidence. Attribution is unconfirmed, so per the calibration note the score stays Medium with the upgrade path recorded. Exploitation & scope: High. Execution confirmed on two hosts, credential theft with observed reuse (the federated SSO session), lateral reach into the SaaS platform. Business impact: High. Possible PCI exposure and a plausible GDPR clock. Confirmation is owned by compliance, but the possibility alone anchors High.
Reduction: asset criticality + business impact make the impact axis: High. Threat actor intent + exploitation & scope, weighted by the multi-source evidence quality, make the likelihood axis: High. The Medium intent score does not drag likelihood down, because likelihood measures confidence that the activity is real and malicious, and the confirmed exploitation carries that question.
Step 4. Document the verdict
The Risk verdict records:
- Impact: High. Two hosts compromised; potential reach into PCI-scoped payment platform.
- Likelihood: High. Multi-source evidence; clean ATT&CK mapping.
- Priority: P1. Escalate immediately.
- Open questions: vendor-side activity on the cloud platform pending; mobile device activity may be unmonitored.
- Recommended response: contain the two confirmed hosts, rotate dlin’s credentials, revoke the federated SSO session, notify compliance. The host isolations and session revocation sit on the SOC’s pre-authorized immediate-actions list, so they execute at handoff without waiting for IR; the rest of the containment strategy is IR’s call.
Step 5. Hand off to Escalation
Risk’s deliverable is a one-page verdict the Escalation phase can act on. Impact and likelihood justified separately, the matrix decision shown, open questions named, recommended response sketched. The next analyst (Tier 2 / incident responder) has everything they need to start.
Key Takeaway
Risk turned a morning of detection and a few hours of investigation into a one-page verdict. The verdict is what travels to Escalation. The reasoning behind it is what defends the case six months later.A second scenario: the Cursor IDE benign-true-positive verdict
The first walkthrough produced a P1 escalation. The Cursor case from Uncover went the other way. Risk’s job there is to record a defensible low residual risk verdict so the closure is durable.
Producing a defensible low-risk closure
Uncover concluded that the Cursor Helper alert was consistent with legitimate developer workflows on a hardened macOS endpoint. Two telemetry gaps (no full PCAP, no USB monitoring) were named but uncorroborated by any other signal. Risk now records the verdict.
Step 1. Score impact
Medium-High. Impact is scored on the premise that the activity is real: this device holds source code, dev secrets, and SSH access to CI infrastructure, so a genuine Empire-style agent here would be a medium-high-impact compromise. The benign-looking evidence does not discount this score, that belongs entirely to likelihood. Scoring impact honestly is what keeps the closure defensible: the case closes because the likelihood collapsed, not because the asset stopped mattering.
Step 2. Score likelihood
Low. Multiple corroborating sources point to legitimate IDE plugin behavior: signed vendor binary, expected install path, peer baseline match, no persistence created, no credential access, no privilege escalation. The Empire-style superficial similarity is the only signal in the other direction, and it is explained by the rule’s over-broad pattern.
Step 3. Weigh residual risk
The methodology requires Risk to name what could change the verdict.
- Technical alignment. Behavior aligns with known, approved developer tooling. Activity is likely part of normal operations.
- Process integrity. No tampering, no code injection, no unauthorized privilege escalation observed.
- User role. Activity executed by a developer within the scope of normal job duties using approved tools.
- Endpoint health. Security agents active, unmodified, reporting clean telemetry.
- Residual risk remains low. The two coverage gaps (PCAP, USB) are real but uncorroborated by any independent signal.
What a less experienced analyst could miss: that “I cannot prove a negative” is not a reason to keep the case open. The two gaps are permanent; no additional hours of querying will fill them. The defensible move is exactly what this step does: name the gaps, note that nothing corroborates them, and record what new signal would reopen the case. Holding a case open to avoid signing an uncertain close is not rigor, it is the queue quietly absorbing the analyst’s discomfort.
Step 4. Document the closure
The risk statement for the closure record
Risk statement: there is a low residual risk that the observed behavior may overlap with known adversary techniques, particularly those used by the Empire framework. This means there is a possibility the activity could be associated with malicious actors, which warrants the documentation produced during Uncover.
However, given the presence of strong contextual indicators of legitimate developer activity (signed vendor binary, expected install path, peer baseline match, no Persistence Mechanisms an adversary installs so their access survives reboots, password resets, and partial cleanups: Run keys, scheduled tasks, services, WMI subscriptions, browser extensions. Mature operators plant several anchors so removing one is not enough. , clean Endpoint A device that initiates network connections and runs user-facing software: laptop, desktop, server, phone, tablet. Endpoints are where most adversary tradecraft eventually shows up, which is why EDR exists. Telemetry Collection and transmission of security-relevant data from remote sources for monitoring and analysis. ), this risk is assessed as low.
The developer was operating within the scope of their normal job duties using approved tools. The endpoint configuration was hardened and the supporting telemetry was clean, further reducing the likelihood of malicious intent.
Based on the totality of the evidence, the behavior is assessed as non-malicious and attributable to approved operational tooling. The low residual risk does not warrant escalation or further investigation at this time.
This is what a defensible Benign True Positive An alert that fired on exactly the activity its detection logic describes, where that activity turns out to be authorized or expected in the local context: a red-team exercise, an admin's sanctioned use of a dual-use tool, a scanner doing its job. The detection worked; the context clears it. Distinct from a false positive, where the logic matched something it should not have. The close still feeds tuning, because the record is what teaches the detection about the local context. closure reads like. Not “dismissed.” Structured, evidenced, signed.
Step 5. Hand off to Escalation
Escalation receives a “no escalation required” handoff from Risk. The methodology still treats this as a formal handoff because Documentation will draw from it and because the closure becomes the artifact that defends the case if the same alert fires again.
- Verdict: benign true positive (detection correct, activity benign), low residual risk.
- Open questions for the program: are the macOS PCAP / USB monitoring gaps acceptable for the developer-workstation population? This is a program-level question, not an investigation-level one.
- Detection-engineering feedback: rule is over-broad for macOS developer workstations running Electron-based IDEs. Tuned variant requested.
Two shapes of Risk verdict
The two scenarios show the two main shapes Risk produces. A high-impact, high-likelihood verdict drives immediate escalation and resource mobilization. A medium-high-impact, low-likelihood verdict still produces a defensible closure, the likelihood is where the benign evidence belongs, with documented residual risk and program-level feedback. Both are correct outputs; both deserve the same rigor in their documentation.
A third scenario: the token-theft verdict under time pressure
Case C arrives at Risk differently: Uncover ended on an escalation trigger, not on evidence exhaustion. The session and the OAuth grant are live persistence, so the escalation decision is effectively made. Risk still runs, in minutes, because the verdict record is what tells incident response how hard to pull and what to pull first.
Scoring a live identity compromise
Uncover delivered: confirmed AiTM session theft on rvega's account, an active inbox-hiding rule, a consented OAuth app with standing mailbox access, roughly 1,800 messages synced including billing threads, no outbound mail sent, blast radius one account with recorded negative sweeps. The compromise is live. Risk sets the priority.
Step 1. Score impact
High. Customer personal data has already been read at volume (the sync is a completed data access, not a hypothetical), the mailbox feeds live payment conversations that make wire fraud the natural next move, and a GDPR assessment is open with compliance. Impact does not wait on whether the attacker gets further; the collection that already happened carries the score.
What a less experienced analyst could miss: the pull of “no wire went out, we caught it in time” toward a downgraded score. Interrupting the fraud is a containment win, not an impact discount: 1,800 messages of customer data were read by an unauthorized party, which is a completed breach event with its own regulatory clock, whether or not the attacker ever got to spend it.
Step 2. Score likelihood
High, effectively confirmed. The session join is structurally unambiguous (one session ID, two irreconcilable presentations, no authentication ceremony), the tenant audit corroborates with attacker tradecraft (hiding rule, consent grant, bulk sync), and no benign explanation survived Uncover. This is as close to certainty as triage gets.
Step 3. Combine via the matrix
High impact × high likelihood = Escalate immediately. P1. The matrix confirms what Uncover’s trigger already decided; the value Risk adds here is the ordering of the response actions, because identity containment has a sequencing trap.
Why the response ordering matters more than the score
A password reset alone contains nothing in this case. The attacker holds a session token and an application grant, and neither checks the password again. The pre-authorized immediate actions execute in this order at handoff:
- Revoke all sessions for rvega at the IdP (kills the replayed token).
- Revoke the OAuth grant for “Mail Backup Sync” (kills the app’s standing access; a separate action in a separate admin surface, which is why it gets its own line).
- Disable the inbox rule and preserve it as evidence.
- Then reset credentials and re-enroll MFA, with the reset treated as hygiene rather than containment.
Reversing 1 and 4, the instinctive order, leaves the attacker connected while everyone relaxes because “the password was changed.”
Step 4. Document the verdict
- Impact: High. Bulk read of customer data confirmed; payment-fraud staging interrupted before any outbound message.
- Likelihood: High. Session-join evidence plus corroborating tenant artifacts; no surviving benign hypothesis.
- Priority: P1. Live persistence in two forms.
- Open questions: item-level read detail pending vendor; GDPR determination owned by compliance; the AiTM proxy’s capture scope permanently unknowable.
- Recommended response: the four ordered identity actions above, then a tenant-wide block of the app publisher and a hunt rule for the ASN.
Step 5. Hand off to Escalation
Same one-page shape as the finance case, with one addition: the verdict names the time-sensitivity explicitly. Every minute before session revocation is a minute of live mailbox access. Escalation inherits a P1 with a pre-sequenced containment list and a warning about the order.
Key Takeaway
The token-theft verdict took minutes because Uncover’s evidence made it automatic, and that is the point: when the trigger has already fired, Risk’s contribution is not the score, it is the ordered, identity-aware response plan that keeps the containment from being theater.