How to Keep Your Cool and Write Powerful Incident Response Reports

How to Keep Your Cool and Write Powerful Incident Response Reports

Speakers: [Speaker's name not provided in transcript or metadata], Axonius

Conference: RSAC 2024

YouTube: https://www.youtube.com/watch?v=fMWUDZOkRR4

Overview

In the high-stakes world of cybersecurity, effective incident response is paramount, but its impact is often diminished by poorly communicated outcomes. This talk, "How to Keep Your Cool and Write Powerful Incident Response Reports," addresses a critical, yet frequently overlooked, aspect of incident management: the art and science of crafting impactful incident reports. The speaker draws an analogy to "The Wolf" from Pulp Fiction—a character brought in to clean up messy situations with confidence and clarity—to inspire incident responders to approach their reporting with similar composure and effectiveness.

The presentation emphasizes that an incident report is more than a mere record of events; it is a strategic communication tool. Its primary goals are to inform stakeholders, address concerns about underlying risks, build confidence in the response team's capabilities, and, crucially, highlight opportunities for improvement. The speaker argues that the success of these objectives hinges on presenting information "on your readers' terms," a principle that underpins all subsequent recommendations regarding content, tone, structure, word choice, and visual presentation.

This talk is particularly relevant for any cybersecurity professional involved in incident response, security operations, or risk management. It provides practical, actionable advice that transcends purely technical skills, focusing on the communication prowess necessary to translate complex security events into clear, actionable intelligence for diverse audiences, from technical teams to executive leadership. By mastering these reporting techniques, organizations can ensure that valuable lessons are learned, necessary changes are implemented, and the overall security posture is continuously strengthened in the wake of an incident.

Background

▶ Watch: Introduction and 'The Wolf' analogy for incident response (0:00)

The necessity for clear and effective incident reporting stems from several inherent challenges in cybersecurity. Firstly, security incidents are inherently chaotic and stressful. Responders operate under immense pressure, often dealing with incomplete information, multiple stakeholders, and rapidly evolving situations. This environment makes it difficult to synthesize information coherently for post-incident analysis. Secondly, the audience for an incident report is typically diverse, ranging from highly technical security engineers to non-technical business executives, legal counsel, and even affected customers. Each group has different information needs and levels of technical understanding, making a one-size-fits-all approach to reporting ineffective.

Historically, many incident reports have suffered from common pitfalls: being overly technical, lacking clear conclusions, failing to address business impact, or being excessively long and convoluted. The speaker highlights a common consumer experience—receiving vague data breach notifications that leave recipients "deeply unsatisfied." These notifications often use generic phrases like "we take your security seriously" without providing critical details such as what data was compromised, how it happened, or what measures are being taken to prevent recurrence. This consumer dissatisfaction mirrors the frustration often experienced by internal stakeholders when incident reports fail to deliver the necessary insights.

To address these challenges, the speaker references a survey conducted at a SANS conference, where security professionals articulated their core expectations for incident reports. These expectations, while seemingly simple, form the bedrock of effective reporting:

1. What happened and when? (Timeline, affected resources, business impact)
2. Why did it happen? (Root cause, control failures, confidence level in analysis)
3. What was done and what remains to be done? (Response actions, future steps)
4. What lessons were learned? (Actionable improvements, ownership, timelines)

The talk's "Background" effectively establishes the common problems in incident reporting and sets the stage for the proposed solutions, emphasizing that understanding the reader's perspective is paramount to creating reports that truly serve their intended purpose.

Key Findings

▶ Watch: Key to success: Write on your readers' terms (2:09)

The core findings of this talk revolve around five critical elements that contribute to a successful incident report, which the speaker metaphorically refers to as "five wolves that all need to be fed." These elements extend beyond mere factual accuracy to encompass the entire communication process:

1. The Right Information (What): Reports must answer fundamental questions: what happened, when, which IT resources and business processes were affected, and what the significance of the event is. Crucially, the speaker emphasizes the need to explicitly state when information is unknown (e.g., "the business purpose of the server is currently unknown, we're researching it"). For root cause analysis, it's not enough to state what caused it (e.g., a vulnerability); reports must specify which vulnerability (e.g., a CVE number), why it was present, how the root cause was determined (e.g., "analyzed logs on the affected server"), and the confidence level of the analysis. Connections to past incidents should also be noted. Response actions should be framed using a structured approach, such as the NIST framework phases: Identification, Containment, Eradication, and Recovery.

1. The Right Tone: The tone of a report significantly influences its reception. An accusatory tone (e.g., "IT failed to patch the server") is counterproductive, fostering animosity rather than collaboration. The speaker advocates for a neutral, situation-focused tone (e.g., "The server was vulnerable because it wasn't patched. IT should review and automate the patch management process"), which encourages cooperation and joint problem-solving. The tone should convey control and competence, without undue urgency or alarm.

1. The Right Words: Effective reports are succinct, precise, and audience-appropriate. The speaker highlights common issues like unnecessary words (e.g., "source host IPs addresses"), overly long sentences, and the use of passive voice (e.g., "it is estimated" instead of "we engaged the vendor and they estimated"). Jargon must be used judiciously; technical terms like SYN packets or PCAP are appropriate for technical audiences but alienating for management, suggesting the need to segment information or simplify language based on the reader. The speaker challenges writers to cut paragraphs by at least 20% to achieve brevity.

1. The Right Structure: Modern business communication demands that the most important information be presented first. This "bottom line up front" approach contrasts with traditional academic writing. This principle applies to the entire report:

• Title: Should be informative and convey a key takeaway (e.g., "Data loss prevention tools worked at containing an incident" rather than "Incident Report May 2024").
• Section Headings: Should summarize the key finding of the section.
• Paragraphs: The first sentence of each paragraph should serve as its summary, conveying the main idea. Each paragraph should ideally contain only one key idea. This structure allows readers to quickly scan and grasp essential information.

1. The Right Look: The visual presentation of a report significantly impacts its readability and perceived utility. A "wall of text" or poorly formatted document is uninviting and less likely to be read. Reports should be broken into small, digestible sections with clear headings, consistent formatting, and ample white space. This makes the content appear less daunting and more accessible, encouraging engagement.

These five findings collectively form a holistic framework for transforming incident reports from mere documentation into powerful tools for organizational learning and security improvement.

Technical Deep Dive

▶ Watch: Example of an unsatisfying data breach notice (3:30)

While the talk focuses on communication, its "technical deep dive" lies in the technical rigor and structure applied to the act of writing itself, and the specific technical details that must be included in an incident report to make it effective for a technical audience. The speaker outlines how to technically construct a report that satisfies both technical and non-technical stakeholders.

The core of the technical deep dive begins with the demand for specific, verifiable data in the "What happened and when" section. Instead of vague statements, reports should include:

• Exact Timestamps and Time Zones: Crucial for correlating events across different systems and geographies.
• Specific IT Resources: Not just "a server," but "server XYZ," including identifying details like hostnames, IP addresses, or data center locations.
• Business Process Impact: While not strictly "technical" in the traditional sense, understanding which CI/CD pipeline or R&D unit tests were affected bridges the gap between technical compromise and business consequence, which is a key technical requirement for risk assessment.

For the "Why did it happen" or root cause analysis, the technical depth becomes even more critical:

• Specific Vulnerabilities: Reports must move beyond "a vulnerability" to identify the precise flaw, ideally with a CVE number (e.g., "a specific vulnerability in OpenSSH, CVE-202X-XXXX"). This allows technical teams to understand the exact weakness exploited and prioritize patching.
• Evidence-Based Analysis: The report must detail how the root cause was determined. This involves referencing specific technical artifacts: "analyzed logs on the affected server" or "reviewed PCAP files." The speaker explicitly mentions the value of appendices for housing raw data, such as log excerpts or network captures, allowing technically inclined readers to validate findings without cluttering the main report.
• Confidence Level: Acknowledging the certainty of the analysis (e.g., "we're pretty certain") is a technical honesty that builds trust. It reflects the often-incomplete nature of forensic data.

The "What was done and what yet remains to be done" section is framed using the NIST Incident Response Framework, which provides a universally recognized technical structure:

• Identification: Technical details of detection mechanisms, alerts, and initial forensic findings.
• Containment: Specific actions taken to limit the incident's scope, such as isolating compromised systems, blocking malicious IP addresses, or disabling user accounts.
• Eradication: Technical steps to remove the threat, like malware cleanup, system rebuilding, or patching the exploited vulnerability (e.g., applying the patch for the OpenSSH CVE).
• Recovery: Technical procedures to restore affected systems and services to normal operation, including validation and monitoring.

Finally, the "Lessons Learned" section technically translates insights into actionable improvements. Instead of vague statements like "better vulnerability management," the report should specify:

• Concrete Actions: "Implement automated patch management for critical servers."
• Assigned Ownership: "IT Operations Team."
• Start Date: "Within one week of report approval."

This level of detail transforms a philosophical lesson into a project management task, ensuring technical accountability and follow-through. The speaker's emphasis on using a template (available in Microsoft Word and PDF formats) further underscores the technical approach to consistent and thorough reporting, acting as a checklist for responders under stress. This template guides the capture of all necessary technical and contextual information, ensuring no critical detail is missed.

Demo / Proof of Concept

▶ Watch: SANS survey results: What readers want to know (4:38)

The talk effectively uses several "proofs of concept" in the form of real-world (or simulated real-world) report excerpts to demonstrate both ineffective and effective communication strategies. These examples serve as practical demonstrations of the principles discussed.

1. Consumer Data Breach Notification (Negative Example): The speaker presents an excerpt from a generic data breach notification that includes the common, unsatisfying phrase, "We take your security seriously." This serves as a proof of concept for what not to do. It lacks specificity regarding what data was at risk, why the breach occurred, and what preventative measures are being implemented. This demonstration highlights the reader's frustration when critical information is withheld, proving the point that vague language erodes confidence.

1. Effective "What Happened and When" (Positive Example): A subsequent excerpt demonstrates good practice. It clearly states the date ("May 4th"), the affected resource ("server name meaningful to technical readers"), and the business impact ("CI/CD pipeline," "R&D could not run unit tests"). This example visually proves how to provide concrete details that inform both technical and business audiences, although the speaker notes it could still be improved by explicitly stating the significance of the R&D impact.

1. Effective "Root Cause" Explanation (Positive Example): Another excerpt showcases a strong root cause analysis. It specifies "a specific vulnerability in OpenSSH with a CVE number." Crucially, it demonstrates how to explain how this was known ("analyzed logs on the affected server") and how confident the team is in their findings. The mention of an appendix for raw data (e.g., logs) is also highlighted as a best practice for technical transparency. This serves as a proof of concept for building trust through evidence and transparency.

1. Tone Comparison (Negative vs. Positive): The speaker provides a direct comparison of tone:

• Ineffective: "IT failed to patch the server." (Accusatory)
• Effective: "The server was vulnerable because it wasn't patched. IT should review and automate the patch management process." (Situation-focused, collaborative)

This side-by-side demonstration visually and textually proves how word choice impacts inter-team relations and the likelihood of successful remediation.

1. Wordiness and Jargon (Negative Example): An extended excerpt is shown to illustrate multiple issues: unnecessary words ("source host IPs addresses"), overly long sentences, passive voice ("it is estimated"), and inappropriate jargon (e.g., SYN packets, PCAP) mixed with financial details ($3,500). This comprehensive proof of concept visually underlines how these elements combine to alienate readers and obscure meaning.

1. Visual Structure and Look (Negative vs. Positive): The talk concludes with a powerful visual demonstration of how formatting impacts readability. An "uninviting" wall of text from a real-world report is contrasted with the same content reformatted with clear headings, smaller sections, and better visual appeal. This side-by-side comparison clearly shows how a clean, consistent look makes a document more inviting and likely to be read, even before its content is processed.

Beyond these specific textual and visual examples, the speaker also offers two tangible tools as proofs of concept for improving reporting:

• Incident Report Template: A Microsoft Word and PDF template (used at the speaker's organization, Axonius) that incorporates all the discussed principles. This serves as a practical, ready-to-use framework.
• Cheat Sheet: A downloadable resource summarizing the key writing principles.

These demonstrations, ranging from abstract principles illustrated by text excerpts to concrete templates, provide compelling evidence for the efficacy of the speaker's recommendations.

Defensive Implications

▶ Watch: Detailing 'What Happened and When' in reports (6:00)

The defensive implications of writing powerful incident response reports are profound and far-reaching, extending beyond immediate incident containment to long-term organizational resilience. This talk provides a blueprint for how organizations can leverage effective reporting to strengthen their security posture.

Firstly, accelerated and informed decision-making is a direct defensive benefit. When reports clearly articulate what happened, why, and what the business impact is, executive leadership can quickly grasp the severity and allocate resources appropriately. Instead of debating technical minutiae, they can focus on strategic responses, such as initiating crisis communications, engaging legal counsel, or approving emergency funding for security enhancements.

Secondly, proactive vulnerability management and risk reduction are significantly enhanced. By explicitly detailing the root cause—including specific CVE numbers and the reasons for their presence (e.g., "unpatched OpenSSH")—reports provide actionable intelligence for security teams. This allows them to prioritize patching efforts, update configuration baselines, and review vulnerability scanning processes. When reports connect current incidents to past events, defenders gain insights into persistent weaknesses or recurring attack vectors, enabling more strategic, long-term defensive planning.

Thirdly, improved cross-functional collaboration is a critical defensive outcome. The speaker's emphasis on a constructive, non-accusatory tone fosters better relationships between security teams, IT operations, development, and other departments. When reports focus on situational analysis and process improvements rather than blame, teams are more willing to cooperate on remediation efforts and implement preventative measures. This collaborative spirit is essential for effective defense, as security is a shared responsibility across the organization.

Fourthly, enhanced organizational learning and continuous improvement become systemic. The "Lessons Learned" section, structured with specific actions, assigned ownership, and start dates, transforms post-incident analysis into a tangible improvement program. This ensures that the organization not only recovers from an incident but actively learns from it, preventing similar incidents in the future. For example, if a report identifies that a lack of automated patch management led to a compromise, the "Lessons Learned" section would mandate the implementation of such a system, thereby strengthening the overall defensive infrastructure.

Finally, building trust and confidence among internal stakeholders, customers, and regulators is a crucial defensive measure. Transparent, well-structured, and clear reports demonstrate competence and accountability. This can mitigate reputational damage, reduce legal exposure, and reassure customers that their data and services are handled by a responsible organization. In a world where trust is a key differentiator, effective incident reporting serves as a powerful tool for maintaining stakeholder confidence.

In essence, by implementing the recommendations from this talk, defenders can move beyond merely reacting to incidents to proactively strengthening their defenses, fostering a culture of continuous security improvement, and enhancing their overall resilience against future threats.

Key Takeaways

• Prioritize the Reader's Needs: Always frame your report's content, structure, and language around what your diverse audience (technical, management, legal) needs to know, rather than what you, as the responder, want to convey.
• Be Specific and Evidence-Based: Clearly state what happened (time, affected assets, business impact), why (specific vulnerabilities like CVE numbers, how root cause was determined via logs or PCAP), and how confident you are in your findings. Use appendices for raw technical data.
• Adopt a Constructive Tone: Focus on the situation and processes rather than blaming individuals or teams. A collaborative tone (e.g., "The server was vulnerable because it wasn't patched. IT should review...") fosters cooperation and effective remediation.
• Structure for Clarity and Impact: Employ a "bottom line up front" approach, starting with key takeaways in titles, section headings, and the first sentence of each paragraph. Utilize frameworks like NIST (Identification, Containment, Eradication, Recovery) to organize response actions.
• Ensure Actionable Lessons Learned: Translate post-incident insights into concrete actions, assign clear ownership, and establish start dates. This transforms abstract lessons into tangible security improvements.
• Master Conciseness and Visual Appeal: Eliminate unnecessary words, keep sentences concise, and avoid jargon inappropriate for the audience. Format reports with clear headings, bullet points, and white space to make them inviting and easy to read.

About the Speaker(s)

The speaker for this presentation shared valuable insights into crafting effective incident response reports, drawing on practical experience and research. While the specific name and title of the speaker were not provided in the transcript or metadata, they did mention that the report template discussed in the talk is used at "my organization, at Axonius." This indicates that the speaker is a cybersecurity professional affiliated with Axonius, a company known for its cybersecurity asset management platform. Their expertise clearly lies in incident response, security operations, and the critical skill of communicating complex technical information to diverse audiences within an organizational context. The speaker's ability to simplify complex communication principles and provide actionable advice highlights a background rooted in practical incident handling and a deep understanding of organizational dynamics in security.