The Analyst Who Was Right Too Early
You are the duty intelligence officer for a corporate security team. At 14:00 a junior analyst flags an unusual pattern: three separate phishing emails in 48 hours, each targeting the accounts-payable team, each referencing a real internal project name, and each sent from a lookalike domain registered 11 days ago. The analyst assesses this as 'likely precursor to a business email compromise attempt' and wants to push an advisory to finance. Your team lead says the sample is too small, the emails were all blocked by the gateway, and pushing an advisory will 'cry wolf' and annoy the finance director, who has already complained about security noise twice this quarter. The analyst is visibly frustrated. You have to decide what gets sent, to whom, and how it is framed before end of shift.
1. How do you handle the disagreement between the analyst's assessment and the team lead's objection, and what do you actually send?
Read the worked answer
The core issue is not who wins the argument; it is that a low-cost, low-disruption action is being rejected on reputational grounds rather than analytic grounds. The team lead's objections are about political cost, not about the assessment being wrong.
Reasoning steps:
- Separate the two claims. Is the pattern real? Three targeted, project-aware, newly registered lookalike domains in 48 hours is a meaningful signal even if blocked. Is the response proportionate? A full advisory may be overkill; a targeted heads-up is not.
- Do not suppress. The failure mode here is the classic one: the warning gets buried because it is inconvenient, and the later incident review finds the signal was known. Document the assessment and the decision either way.
- Right-size the action. Send a short, specific note to the AP team lead (not a broadcast advisory): what the emails look like, that they were blocked, what to do if one gets through, and a request to report anything similar. No alarm language, no implication finance did anything wrong.
- Manage the relationship. Tell the team lead what you are doing and why, framed as protecting them: 'if this develops, we want to show we flagged it early and quietly.' That addresses the 'crying wolf' concern directly.
- Set a tripwire. Define what would escalate to a full advisory (e.g., a fourth attempt, a successful delivery, any reply from a finance mailbox).
Model answer: send the narrow note, log the dissent, agree escalation criteria, and keep the analyst's assessment on record with credit.
2. The team lead later argues that because all three emails were blocked, the 'likelihood' component of the risk should be rated low. How do you respond analytically?
Read the worked answer
This conflates attempt frequency with control effectiveness, and it treats a blocked attempt as if it never happened.
Key points:
- Likelihood of attempt is high and rising - the adversary is actively probing, learning internal project names, and iterating. Blocking three emails does not reduce the probability of a fourth; it may increase it as the attacker changes technique.
- Likelihood of impact depends on control durability. A single gateway is one layer. If the attacker pivots to a channel the gateway does not cover (phone, personal email, a supplier's compromised mailbox), the control that produced the 'low' rating no longer applies.
- Risk = f(likelihood, impact, control reliability). The correct move is to rate the threat as elevated and note that current impact is mitigated by a specific control, with an explicit assumption: 'rating holds only while gateway coverage is intact.'
- Beware the base-rate trap in reverse - 'nothing happened three times' is not evidence of safety; it is evidence the control worked three times.
Model answer: keep likelihood of attempt high, document the control dependency, and flag the residual risk if the attack shifts channel.