Defender
A starting point for defenders, analysts, and responders handling suspicious activity, phishing, and account-risk investigations.
This page defines the defender lane for analysts and responders who triage suspicious activity, contain active risk, preserve evidence, and escalate when incident criteria are met.
1. Problem this page solves
Defender work fails when triage, containment, and escalation happen without clear decision ownership and evidence thresholds.
This page gives the first-pass path so defender decisions stay fast, auditable, and proportional under uncertainty.
2. What you should understand after reading
After this page, you should understand:
- the defender role boundary: validate signals, contain risk, preserve evidence, escalate at decision gates
- what to read first before acting on alerts or reports
- which incident decisions you own and which you hand off
- how to separate observed facts from inferred conclusions
- what to defer until the active case loop is complete
3. Mechanism-first role path
Read first (in order)
- Evidence
- Operations
- Do I Need to Escalate?
- What Evidence Is Required?
- Authorization Model
- Investigating a Phishing Report
Decisions you own in this role
| Decision | What you own | Primary pages |
|---|---|---|
| Triage classification | Decide whether signals are informational, suspicious, or confirmed malicious based on available artifacts | Evidence, Operations |
| Containment selection | Apply the least disruptive containment that reduces live risk while preserving future investigation value | Operations, Runbooks |
| Escalation trigger | Escalate when compromise indicators, privileged exposure, spread potential, or boundary uncertainty exceed defender authority | Do I Need to Escalate?, Authorization Model |
| Evidence sufficiency | Make sure case artifacts support later approval, incident review, and post-incident decisions | What Evidence Is Required?, Evidence |
Defer initially
Defer these until the current case is triaged and either contained or escalated:
- integration authoring and connector implementation detail in Integration Author
- field-level receipt internals in Receipt Spec
- scenario catalog pages that do not match the active incident type
4. Observed vs inferred
| Layer | What is observed | What is inferred |
|---|---|---|
| Alert and artifact review | message and header artifacts, sender infrastructure data, auth results, linked indicators, timeline events | attacker intent, campaign attribution, full blast radius |
| Containment and response | account disable or reset actions, mail-flow blocks, endpoint or network controls, timestamps, case notes | certainty that all persistence paths are removed |
| Escalation readiness | explicit evidence gaps, policy boundary breaches, privileged impact signals | business impact severity beyond currently observed evidence |
Treat inferred conclusions as hypotheses until more evidence confirms them.
5. Role-specific trust assumptions
Operate with these assumptions kept explicit:
- Incoming signals are imperfect: user reports, alerts, and artifacts may be incomplete, delayed, or intentionally deceptive.
- Evidence timing lags risk: containment may begin before evidence is complete; record what was known at each decision point.
- Escalation timing is a control: delaying escalation can increase impact, while premature escalation can disrupt operations without added safety.
- Scope and approval boundaries are configuration-backed: defender actions still depend on accurate policy and workflow configuration.
- Runtime integrity is assumed: host or key compromise breaks workflow and evidence guarantees.
- Receipts attest recorded execution, not correctness: when verified against trusted keys they prove what was recorded as run and captured, not whether the analytic conclusion is true.
See Threat Model for the full trust-boundary map.
6. Next-page handoff
Next, read Investigating a Phishing Report to apply this defender lane to a governed case flow with explicit triage, containment, and escalation gates.