While cybersecurity teams are generally overwhelmed these days, the moments after a major incident can be especially hectic. That’s why it’s critical to have an incident response plan in place, including workflows that are tailored to common threats like malware, DDoS, and many others. A good plan will establish roles, collaboration and communication procedures, as well as guide team members through the phases of incident response. For those of you improving your incident response plan, here are five critical steps that should not be overlooked.
1. Be Prepared
Preparation is so important because the pace of a cyber incident is too fast for ad hoc response and decision making processes. Identify the steps, responsibilities, and resources ahead of time, so there are no procedural gaps when the action starts.
Things to consider during preparations include:
- Communications—Are redundant methods in place, in case systems are compromised or personnel are offsite? How will incidents be escalated, and to whom?
- Evidence handling—How will you gather, track, and store digital and physical evidence (such as hashes, interviews and hard drives)?
- Resources—Is everything in place that analysts will need, such as documentation of critical assets, network diagrams, and current baselines of activity?
- Risk assessment—Have you determined where your “crown jewels” are? Have you documented known vulnerabilities and external threats?
- Employee training—When your employees receive a phishing email, do they know what to do? How, and to whom do they report it?
2. Validate – Did an Incident Really Happen?
Large organizations receive thousands of security alerts per day, so it is crucial that they be able to distinguish false positives from real incidents. To determine if an incident really occurred, analysts must be able to cross-reference between different data sources, such as IDPS, anti-virus, and SIEM, while also leveraging threat intelligence and other publicly available information, such as IP reputation sources.
Once the incident is confirmed, determine the type of attack. Is the attack vector a web-based application, rogue wireless access point, or a malicious email attachment? You should have response plans in place for the general types of incident you are likely to face. At this stage, you should also assess the severity of the incident, and assign it a priority level for remediation.
After the incident has been validated and assessed, it’s time to set the incident response process in motion. Notify all parties that will be involved, including incident response analysts, the forensics team, and—when applicable—legal and compliance. Assign tasks based on your analysis of the incident type of and severity.
3. Track Response and Analysis Activity
During the hectic urgency of incident response, taking the time to make records of your response process is probably the last thing on your mind, but it’s crucial for improving your processes over time. Track the overall incident response time, the time spent on specific tasks, and document all the steps taken. During incident response, team members should also know the status of each incident, and what tasks are outstanding. A good incident response platform will make this much less of a hassle by creating a centralized record of the entire process. The data gathered in this process will drive the post-event review (step #5) .
4. Reduce Risk through Root Cause Resolution
Containing a threat is only part of a conclusive incident response. Once the immediate danger has passed, the next step is remediation, which should include root cause resolution. For a major incident, remediation and recovery can be a lengthy process, so be sure to identify what actions are the most urgent, and prioritize them accordingly.
The steps for remediation might include:
- Eradicating the problem from affected systems, or replacing components that cannot be repaired.
- Restoring systems and files from backups.
- Closing vulnerabilities to prevent similar incidents.
- Updating security controls, such as installing patches and changing passwords.
For a basic incident response program, this might be the end of the process. However, a sophisticated and proactive program will follow up with root cause analysis and resolution. This will lead to an overall reduction of incidents over time, as recurring vulnerabilities are conclusively addressed. Root cause resolution involves using logs, analytics, link analysis, digital forensics, and other evidence to truly understand how an incident happened, and what needs to be done to prevent it from happening again.
5. Review the Effectiveness of Your Response
If you effectively tracked your response process during step #3 , you should now have a strong data set with which to perform a post-incident review. Not all incidents merit a review, but it should be done for significant events. Compare response times to previous incidents, organizational goals, and the time spent on each stage of the process. Check your initial impact assessment to see how it compares to the final assessment. Look at the performance of teams and individuals. Are there weak points in the process, or procedural bottlenecks that are causing delays?
It is important to make a record of these lessons learned, so that processes can evolve over time. The knowledge gained from post-incident review will be used to refine the preparations made in step #1 , as the process begins over again.
