Risk working example
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. PCI and GDPR triggers were active during Scope. 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 triggers are already active. 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.
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, isolate the federated SSO session, notify compliance.
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.
A second scenario: the Cursor IDE false-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
Low (conditional). If the activity were malicious, the device’s access to source code and CI infrastructure would make impact medium-high. But the impact score in Risk is the floor assuming evidence is real. Here the evidence is consistent with legitimate developer activity; the asset’s potential exposure remains noted but is not realized.
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.
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 False-Positive (definition missing) 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: false-positive, 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.