Ransomware Reporting to Three Audiences in 24 Hours
At 02:00 a ransomware affiliate encrypts 40 of 3,000 endpoints at a manufacturing company. The CTI team supports incident response. At 09:00 the CISO asks for three products by 14:00: an executive brief for the board, a tactical IOC package for the SOC, and a peer-sharing report for an industry ISAC. Initial access is a phishing email with a malicious ZIP; the payload uses a signed but revoked driver. Customer order data may be exfiltrated, but forensics is incomplete. Legal has imposed a hold and counsel must review external sharing. The ISAC uses TLP:AMBER; the board is not technical. The SOC needs detections now. The company is publicly traded and disclosure rules apply. You have two analysts and no malware sandbox.
1. Design the three report products with audience-appropriate content.
Read the worked answer
The board brief should be one page: what happened in business terms, affected operations, containment status, customer and regulatory exposure, decisions needed, and next update time. Exclude raw IOCs and avoid definitive actor attribution. Use plain language and calibrated confidence. The SOC package should be technical and internally shareable: phishing sender and subject, ZIP filename, hashes, domains, registry keys, scheduled-task names, detection queries, and mitigation steps. Label it with TLP and confidence. The ISAC report should be anonymized: sector, victim profile, TTPs mapped to ATT&CK, provisional IOCs, and handling instructions. Exclude customer data, victim identity, and unpatched vulnerability details. State that forensics is ongoing and IOCs are provisional.
2. How would you handle TLP, legal review, and uncertainty in external sharing?
Read the worked answer
Label every product. Use TLP:RED or TLP:AMBER for the internal board brief depending on distribution, TLP:AMBER for the SOC package unless wider sharing is approved, and TLP:AMBER for the ISAC as required by its rules. Counsel must review the ISAC report before release because of the public-company disclosure and customer-data risk. Redact victim identity, customer identifiers, and any detail that could tip off the attacker or mislead peers. Share only indicators and TTPs the ISAC can act on. Use structured sharing such as STIX/TAXII if available. Do not share malware samples without handling controls. Explicitly mark uncertainty and say what would change the assessment.
3. How would you measure whether the reporting improved response?
Read the worked answer
Measure time from incident start to each product, number of SOC detections deployed from the package, blocks or hunts triggered by shared IOCs, board decisions recorded, and ISAC feedback or hit reports. Track false positives generated by shared indicators so peer trust is not damaged. Ask the SOC which IOCs fired and which were useless. After the incident, compare the intelligence requirements against what was delivered. Define a feedback loop so the next report is judged on decisions and detections, not page count.