Create an Incident Response Report
Learning Objectives
After completing this unit, you’ll be able to:
- Write a sound incident response report.
- Integrate incident response actions into the report.
- Explain the importance of an after-action meeting.
Write an Incident Response Report
The next step of high-severity incident response is to document what transpired in a post-incident response report. In addition to this, you have certain reporting requirements during the incident that you need to fulfill.
Communication of incidents must transit through the organization's leadership structure. Depending on the organizational layout, communications of incidents often start with reporting through a service desk or a security operations center.
From here, notification of incidents may occur through unofficial or official processes such as email, verbal, or formal notification. Depending on the severity and type of incident, individuals that should receive notification may include the chief information officer (CIO), the head of information security, incident response teams (IRTs) either within the organization or through the organization’s managed service provider, and business system owners.
The report is a formal documentation of what transpired during the incident, and how it was identified, contained, removed, and recovered from. As an incident responder, you capture all actions taken throughout the response process by grabbing screenshots of anything that would be useful in the report. Take notes that document actions as they occur.
Sections of an Incident Response Report
The incident response report sections are for you to use as a guide for informational purposes only. You should follow whatever format your organization uses.
An incident response report typically consists of six sections.
- Executive Summary
- Incident Detail
- Detection and Response Activities
- Recommendations
- Conclusions
- Appendices
Executive Summary
The typical audience of the executive summary is executives and managers. This is the most important section of the report, and you should write this section last. Executives should be able to read this short section as a stand-alone report. In the report, it’s a good idea to do the following.
-
Summarize the incident including whether the incident is currently open or closed, the date/time when the incident occurred, the business units impacted, what happened, and immediate and planned action items.
-
Identify the incident’s root cause and actions you took to mitigate it.
-
List significant findings and their potential business impacts.
Incident Detail
System owners, incident responders, and systems operators typically read the incident detail. In this section, you discuss the scope of the incident, include a detailed account of the events leading up to the incident, and outline what actions you took to recover the impacted systems. You include information such as what assets the attacker compromised, scanned, or brought down, as well as the actors that were involved. This section may include a comprehensive incident timeline.
Detection and Response Activities
Incident responders, engineers, and system operators typically read the detection and response activities. In this section, you describe the detection, response, and recovery actions taken by all parties involved during incident response. In the section on detection, you summarize when the incident was detected, how it was reported, and to whom. You detail whether a human or automated tools detected the incident. You also walk through the decision process that led to deeming the event an incident, and describe who was involved.
In the response section of the report, you explain what parties responded to the incident and the actions they took to triage. You include screenshots, summaries of interviews, or notes taken by responders.
Finally, in the recovery section, you detail the response actions to return the impacted systems to production. This can include patching, reconfiguration, reimaging, or removing the system from production. You also list any tools used during the recovery.
Recommendations
System owners as well as engineers and administrators typically read the recommendations. In this section, you summarize incident findings and recommendations. You include enough details to explain the necessary actions to take. This is important so that the organization clearly understands what areas they need to improve upon in order to increase their security. You include web-linked resources and references to help the organization quickly identify remediation options and obtain the details they need. You also list all findings in a single chart with some basic information, including the vulnerability, host, and risk.
Conclusions
Everyone typically reads the report’s conclusions. In this section, you again summarize the incident response activities. You talk about what happened, and how the organization responded. Finally, you list significant incident findings and business impacts.
Appendices
Here you should include long lists like audit logs. You can also include copies of all time-stamped documents, such as chain of custody. Other documents you can include here are notes from incident handlers, screenshots, and reference diagrams.
Integrating Incident Response Actions into the Report
Now that you better understand the sections of an incident response report, let’s take a closer look at the type of information you should include. As soon as you suspect an incident, you should begin recording all relevant information. In doing so, avoid opinions and speculations (these are not evidence) and focus solely on the facts.
Document system events, conversations, and observed changes while conducting the response as opposed to at the end. By doing so, you efficiently track the incident time frame and all actions undertaken during the response phases. The IRT lead should document, time stamp, and sign every step taken from detection to conclusion of the incident.
You can use a computerized issue tracker to maintain records regarding the status of the incidents. The tracker should include:
- Current status of incident (to include incident type and severity)
- Indicators related to the incident
- Other incidents that may relate to the current incident
- Actions taken
- Chain of custody documents
- Impacted systems
- Contact information
- Incident handler notes
- Next steps
Be sure to keep this tracker’s access limited to only authorized personnel and encrypted if possible.
Summarizing Recommendations
When it comes to summarizing recommendations, describe what happened and why the incident occurred. Detail what systems were impacted, and explain actions that the organization should take to prevent reoccurrence. Think about:
- What should the senior executives do?
- What should the business owner do?
- What should the employees do?
- What do you want the public affairs team to say/do?
- How do these recommendations help the business, the customer, and the organization?
Note any systemic issues found during the incident investigation. For example, you may find in general that employees do not lock their screens, or that they write down passwords, or that access control is not technically enforced for system login. Recommend how the organization can address these systemic issues. Also detail the benefits of the recommendations so decision makers understand how implementing them limits exposure, prevents exploitation, improves the organization’s reputation, and increases security.
Hold an After-Action Meeting
In the after-action meeting, you review the incident response report, including the lessons learned, to provide a clear review of the entire incident. Attendees at the after-action meeting should include incident managers and support staff, the service owner of the impacted system, and representatives from the business function.
During the meeting, review the timeline of the incident. Explain when it started, how the incident response team was notified, and how long it took to determine it was an incident. Describe any challenges you encountered engaging support staff, and whether escalations were required. Go over what tools were available and if they were sufficient to diagnose the incident. Review the decisions made during the incident, who made them, and how they were reached to avoid any confusion on authority for future incidents. You can also use this time to complete any remaining documentation.
Knowledge Check
Ready to review what you’ve learned? The following knowledge check isn’t scored—it’s just an easy way to quiz yourself. To get started, drag the description in the left column next to the true/false category on the right. When you finish matching all the items, click Submit to check your work. If you’d like to start over, click Reset.
Great work!
Sum It Up
In this module, you’ve been introduced to preparing for and conducting a post-incident response. You've learned what steps are performed to triage an incident to prevent it from spreading further, and how to identify other hosts that may be affected by the incident. You've also learned what actions are necessary to remove the incident from your systems and restore everything back to normal operations.
Along with the information you reviewed in the Incident Response module, you should now have a better understanding of what it takes to be an incident responder. You can learn more about the in-demand cybersecurity skills necessary to get a job in incident response or another field, and learn more from real security practitioners by visiting the Cybersecurity Learning Hub on Trailhead.
Resources
