Four Audiences, One Intrusion, Four Hours
At 09:00 you confirm an intrusion: a malicious OAuth application has been consented to by 14 users, granting read access to mailboxes, including the CFO's. The initial lead came from a TLP:RED report shared by a peer bank under an NDA; that report names the actor only as an unverified cluster designation and is single-source. Legal says you cannot name the affected users or the peer bank externally. At 13:00 you must brief the board, push a detection package to the SOC, file a regulatory notification, and send an advisory to 30 partner organizations. The CEO's chief of staff asks you to "just tell the board who did it and whether we're safe." A board member has read about a named APT in the news and asks whether it is that one.
1. Tailor the core message for each of the four audiences.
Read the worked answer
Same facts, different decisions.
Board (5 minutes, no TTP detail). What happened: a third-party application was granted read access to 14 mailboxes, including the CFO's, for a period you are still scoping. Impact: potential exposure of email content, not of core banking systems. Actions taken: consents revoked, tokens invalidated, mailboxes preserved for review. Ask: approval for an org-wide third-party consent review and a budget line for mailbox forensics. Residual risk and what would change the assessment. "Are we safe" gets an honest answer - safe from this technique now, not yet able to say what else was touched.
SOC (operational). Detection content: OAuth consent queries, application ID and publisher indicators, the specific scopes abused, KQL/SPL logic, known false positives, validation steps, escalation path, and a 72-hour watch instruction. Include the handling marking.
Regulator. Factual timeline, data categories, number of accounts, containment date, and next update date, on their template. No speculation, no attribution, no adjectives.
Partners (30 organizations). The technique and detection content in sanitized form, marked TLP:AMBER, stripped of victim names, the CFO, the peer bank, and any cluster naming. Before sending, check whether the NDA permits onward sharing of anything derived from the TLP:RED report - often it does not, in which case the advisory goes out on your own observations only.
2. How do you handle confidence and attribution with the board and with partners?
Read the worked answer
Separate the three claims and give each its own confidence statement.
- What happened: high confidence. Fourteen consents and mailbox access are directly observed.
- How it was done: high confidence. The technique is visible in audit logs.
- Who did it: low confidence, and not needed for any of the four outgoing decisions.
Telling the chief of staff "we are not going to name the actor, and here is why" is a legitimate answer. Attribution from a single unverified peer report would be borrowed confidence; if it is wrong, the board has been misled and your partner relationship damaged. Use estimative language consistently: "we assess with low confidence that this is related to the cluster described in a peer report, because the report is single-source and unverified."
On the board member's APT question, answer directly: "We cannot confirm a link. Naming a group would not change any of the four actions we are taking today, and a wrong name would be worse than no name." Then offer what would raise confidence - corroborating infrastructure from a second source, or matching tooling - and when you expect to know.
Partners get the same discipline: state the technique with high confidence, and either omit attribution or mark it explicitly as low confidence and single-source, which tells them how much weight to put on it.
3. What goes into each written product, and what do you deliberately leave out?
Read the worked answer
Board one-pager. Five bullets: event, exposure, containment, residual risk, decision requested. One confidence line. One named owner and a next-update date. Leave out TTP detail, actor names, tool names, and the peer bank.
SOC detection package. Application IDs and publisher names, scopes abused, queries with comments, false-positive notes, backtest results, escalation path, watch duration, TLP marking, and an intelligence-gaps line. Leave out victim identities and anything that identifies the peer.
Regulatory filing. Timeline, categories, counts, containment, notification status, contact. Leave out speculation, attribution, and adjectives. Answer exactly what is asked; extra narrative creates obligations.
Partner advisory. Technique, detection content, mitigations, TLP:AMBER, and a clear statement of what you have not observed. Leave out the TLP:RED source material unless the agreement allows derived sharing, and leave out any cluster name you cannot corroborate.
Two things belong in every product: an explicit confidence statement and an intelligence-gaps line saying what would change the assessment. That is what makes the product usable by someone who has to decide before you know everything. Keep a source-handling log for the TLP:RED item so that, if challenged, you can show exactly what was shared with whom and under which marking - dissemination discipline is the control that lets you keep receiving sensitive peer reporting.