The postmortem is one of the most important parts of incident response and is also the part that is most often omitted. As mentioned in the previous chapter, documenting events that occurred during the previous phases (identification, classification, traceback, and reaction) is important to effectively create a good postmortem following a security incident. The collection of this data is important because it can be used for future improvement in the process, policies, and device configuration. This data can also be used to calculate the cost and the total hours of involvement and may help you justify additional funding of the incident response team.
This also can help you to understand changes in new security threats and trends. You can use the data and lessons learned from the postmortem as input to improve security policies, processes, and system configurations. This is illustrated in Figure 6-1.
Figure 6-1 Postmortem Looped Feedback
Try to address the “who, what, how, when, why” questions in your postmortem. Table 6-1 demonstrates this approach.
Table 6-1 Typical Questions Answered in a Postmortem
Type Question
Who Who was affected by this incident? Who reported the incident? Were the right people engaged? Were customers impacted? Were partners impacted?
Was communication between staff and other teams appropriate? What What systems were affected by this incident?
What processes were affected by this incident?
What tools were used to identify, classify, trace back, and mitigate the incident?
What worked well? What did not work well?
What were the key lessons learned from the incident?
What other contingency plans in the organization could be applied? Preparation Identification Classification Traceback Reaction Postmortem
The answers to questions like those included in Table 6-1 should be collected in a collaborative effort between the team members who help on the identification,
classification, traceback, and reaction phases. Keep in mind that if you ask questions that are too broad, you may have different perspectives within your staff. This is not necessarily a problem; however, you want to collect clear and concrete facts. If you ask questions that are too narrow, you may end up limiting the input and information that you can collect and analyze from your team experience during the incident. On the other hand, you should collect data that is clear and concrete, rather than collecting data simply because it is available and may be incorrect.
The analysis of the data collected in the postmortem will also help you to measure the success of the incident response team. However, the postmortem process will fail miserably if the problem review board is used as a forum to point fingers at specific staff members or organizational divisions. The most important thing is to understand that the data collected in the initial stage of the postmortem helps you organize a list of lessons learned during the incident.
Figure 6-2 shows the first part of a basic incident response report and postmortem. In this example, Joe Doe from a fictitious company called SecureMe is the author of the report.
How How was the incident first identified?
How could the recovery process have been shortened after a fix was identified?
How effective was the incident diagnosis and response? How effective was the communication process? When When was the incident first identified?
When was the incident first reported? When was the incident mitigated? Why Why did a procedure fail?
Why was a procedure difficult to implement? Why was your methodology successful?
Table 6-1 Typical Questions Answered in a Postmortem (Continued)
Figure 6-2 Incident Response Report and Postmortem Example
SecureMe, Inc. Incident Response Report and Postmortem
Reported by: Joe Doe Phone: (555) 123-1234 Date of Incident: 07/04/2009 Incident ID (if applicable): CSIR
T
-987654321
Date: 07/05/2009 Email: [email protected] Time of Incident: 9:30 a.m. EST External Service Request (If applicable): 601234569
Incident Summary: Numerous ICMP
packets were sent by an unauthorized system to a sales e-commerce web-server farm.
How was it discovered? Abnormal behavior was noticed from CS-MARS incident using Netflow data. An automatic e-mail notification from the system was received at 9:30 a.m. What actions and technical mitigation have been taken? The source of attack was confirmed by using Netflow data and CS-MARS reports. An access control list was deployed at the Internet edge router to mitigate the attack.
Select the type of incident:
Denial of Service Attack
List all the systems that were af
fected:
Sales e-Commerce web servers Where any of the af
fected systems mission critical?
[X] Y
es [ ] No
What was the source?
X
External unauthorized user
W
as law enforcement contacted? [ ] Y
e
s [x] No
If yes, what department (i.e., local enforcement, FBI, etc):
Unauthorized Application Access We
bsite Defacement
Identity Theft
List all departments or business units that were af
fected:
Sales Department Was the source of the attack/incident spoofed? [ ] Y
es [x] No
Former employee Internal guest Unknown
Other
Other (please specify): (please specify):
X
W
orm or V
irus
In Figure 6-2, a member of the SecureMe incident response team reports that numerous ICMP packets were sent to a web server farm that is part of an e-commerce solution that belongs to its sales department. The fields on the form include most of the questions listed in Table 6-1. Figure 6-2 is merely a basic example. You can expand this form by
incorporating more detailed information that is appropriate for your environment and organization, such as the following: