For most employees, the incident is over. The threat has been contained and neutralized, the technical staff has gone home, and management has handled the damage control as best they can. If you are a CISO, however, your work is far from over. To prevent the incident from happening again, you have to understand how it happened, and to understand how it happened, the best method is to launch a post-mortem review. In fact, a post-mortem analysis should be part of your incident response plan. An effective post-mortem will delve into the how, what, who, when and why to give you insight into ways you can improve your tools, training and processes. Here are the top seven tips for conducting a post-mortem after an incident occurs.
Completing an Incident Report Should Be Your First Step
Document any information that you can use to prevent similar incidents in the future. Although not all of the information applies to all organizations or all incidents, a good incident report typically includes much of the following information.
- The date and time of the incident
- Location of the compromised system or device
- Function of the compromised system or device, such as web server or desktop computer
- How the incident was identified
- Steps taken to neutralize and contain the incident
- The impact of the incident
- Team that was involved in solving the incident and all the evidence collected.
Schedule a Meeting
Schedule a post-mortem meeting as soon as possible. You may have to allow people a little time for recovery, especially those who sacrificed their sleep to respond to the incident. Ideally, you can have everyone at the meeting who was involved in responding to the incident, but try to at least get a representative from each department or work group involved.
Ensure participants bring any notes they made during the incident response. Make copies of any trouble tickets or timelines and distribute them to participants, but warn them that these documents are confidential and must be returned at the end of the meeting or secured in a locked drawer. Shred any returned documents to keep them safe from "dumpster divers."
Evaluate Your Incident Response
Between what you learned in your meeting and other documentation such as logs, you can begin to analyze your response. Look for answers to the following questions.
How much time passed between recognizing a security incident and its resolution?
Could the identification of the incident have occurred sooner?
Were your resources sufficient to handle the type of incident?
How could the response have been handled better, faster or more effectively?
Are there processes that you could automate that would provide greater protection or more efficient responses?
Monitor Activities After the Incident
Additional threats are often launched soon after the initial threat has been contained. Continue to monitor activities closely. Pay particular attention to indicators associated with the previous incident that may appear in a security log.
Determine Whether the Incident Was Random or Targeted
The method of attack can often reveal whether you were targeted or suffered a random attack. For example, if the incident was the result of an employee responding to a phishing attempt, it was probably random. If your website was targeted, it was likely a company-specific attack. Once you know the most likely cause of the incident, update your company's threat intelligence feeds. Make sure that everyone with a "need to know" is informed about potential triggers, system vulnerabilities and policies that need improvement.
Identify Preventive Initiatives
Scorecards can help you assess your security, identify new initiatives and secure buy-in across departmental lines. The metrics you select will vary, but here are some you might want to consider.
- Percentage or number of vulnerabilities that are unpatched
- Volume of alerts
- Number of false alarms
- Volume of incident tickets that were opened and closed
- Time elapsed between the detection of incidents and closure
- Average time between initial infection and detection or quarantine
- Inventory of unauthorized devices and software
- Metrics from fully deployed security tools, including threats detected or blocked
Follow Up
Based on your findings, you may need to plan on some additional activities. For example, if your post-mortem revealed that your response team needs additional training, you will need to make sure that they receive it. If an employee who was circumventing security contributed to the incident, you may need to decide the best way to convey the importance of following company cybersecurity policies. If an excessive period passed between the discovery of the threat and the time it was reported to the incident response team, you may need an initiative to educate employees on how to identify a suspicious activity and to whom they should report their concerns. If your team members were so overwhelmed by false positives that they overlooked a real threat, you may need to automate some of your response processes.
A security incident is no one's idea of a pleasant experience. However, every incident is a learning opportunity. By analyzing what happened and how it happened, you are in a much better position to prevent another incident by shoring up your defenses. Although the improvements you make may not prevent every possible future attack, you will be better prepared when the next incident occurs. A security incident can be a galvanizing event that provides the momentum to improve incident response plans, fix flaws in your processes and harden your defenses against a community of cybercriminals who are constantly refining their skills and techniques.
Download our Top Security Orchestration Use Cases Whitepaper
To see Cortex XSOAR in action, sign up for our free Community Edition.