What should you do after a cyber security incident?
Once you have contained and eradicated a security incident, there is still more vital work to be done. In this blog, we’ll set out the steps you should take after a cyber security incident to improve your security posture and better respond to future incidents. Of course, it’s best to prevent cyber attacks from happening in the first place, which is why we strongly advise creating a Cyber Incident Response Plan or if the incident is cloud-based, then look at implementing your Cloud Incident Response Plan.
Incident response is a cyclical activity centred around a five-stage process: planning, preparation, detection and analysis, containment and recovery, and post-incident analysis. The last step within this process – post-incident activity – is often overlooked, despite its criticality to an effective incident response capability.
In the high-stress environment of incident handling, restoring services to normal is an obvious priority for the incident response team. However, your organisation must understand that incident response does not end with the eradication stage.
Even after restoring your services to normal, best practice guidance – such as that from NIST SP 800-61 and ISO 27035 – recommends further steps to close an incident properly. This phase is known as commonly known as post-incident activity or lessons learned.
For detailed advice on creating your incident response plan, please refer to our guide to incident response.
Why do I need to carry out post-incident activity after responding to a security incident?
The post-incident phase of the incident response lifecycle is an opportunity to review and improve your incident response capability with an eye to preventing similar incidents from occurring.
During this phase, your team will conduct a root cause analysis to determine why and how the incident happened and what needs to be done to prevent a similar incident from happening again. This analysis typically features two facets: a ‘lessons learned’ meeting and a written report.
Post-incident activity is about more than just reviewing technical policies and infrastructure. You should also consider the human element of security, looking at factors such as how effectively your incident response team enacted the plan and the role that your employee(s) – whether intentionally or accidentally – played in enabling the incident to occur. For example, if an employee clicked on a phishing email that led to a successful ransomware attack, you may want to reconsider your approach to employee phishing training.
When looking at the human element of any incident, it’s important to note that this phase should not turn into a blame game. Root cause analysis is ultimately about learning from what happened and making improvements to prevent similar incidents from happening in future.
This phase also helps to create a culture of continuous improvement, so your incident response team views every incident as an opportunity to learn and optimise their approach.
What are ‘lessons learned’ meetings in incident response?
Lessons learned meeting is one term to describe the face-to-face meeting that you should hold with the incident response team and other parties involved in an incident in the days after the event. Other names to describe this session include a “debrief” or “wash up” session.
For significant security incidents, we advise holding a formal lessons-learned meeting to go through the incident. For minor events, you may choose to discuss several incidents in one session. This is because lessons-learned meetings can be resource-intensive – especially for organisations where incident response team members hold other roles within the business.
The goal of the lessons learned meeting is to understand why the incident happened, how the response occurred and how well this intervention worked. During the planning phase of your incident response lifecycle, it would be best if you put together a template or discussion guide to bring structure and uniformity to these meetings. This will help ensure you capture the necessary information and keep the meeting within the correct parameters.
As well as having these guidelines, it’s also advisable to share expectations and rules with your attendees prior to the meeting. You should emphasise that the meeting is an opportunity to improve, rather than point fingers. This can go a long way toward preventing any discord between participants.
It might also be wise if resources allow it, to appoint a moderator for the meeting who feels confident to mediate the discussion and bring the group towards closure and agreement. Lastly, make sure to take detailed notes from the meeting, focused on critical takeaways about the incident and action items moving forward.
Below are some questions to consider including to guide your discussion:
- What happened during this event and when?
- How well did the organisation’s team members perform in handling the incident?
- Did the incident response team follow documented procedures, and were these procedures sufficient to guide the response?
- Did the incident response team perform any actions that inhibited the eradication of the incident?
- What could the incident response team have done better?
- What processes/technologies could have prevented this incident from occurring if any?
- What indicators should we look for in future to detect similar incidents?
What reporting should I undertake after a cyber security incident?
Another essential aspect of the post-incident analysis is the creation of a follow-up report for the incident. This report can be used as a reference point for the incident response team to assist them with handling similar incidents in future. You should put the following data points in your report:
- A timestamped chronology of events using log data and personal statements
- A concise summary of the incident, giving an overview of what happened and the remediation steps taken
- An objective assessment of the response, which can be used in conjunction with other incident data for justifying additional incident response funding, implementing new security controls and the efficacy of the incident response team (for more information on this, please see section 3.4.2 of NIST’s incident response guidance or speak to our team.)
- Recommendations for improvement, spanning people, processes and technologies as needed.
You should share your report with management for their review so that they can then evaluate, discuss and approve your suggested recommendations. You may also need – or choose – to share these incident details with other stakeholders, such as the National Cyber Security Centre, who may use the data for pattern analysis.
Need help with cyber incident response?
If you need help preparing your incident response plan or simply want to chat with us about ways in which you could approach it, then we’d love to hear from you – and we promise no hard sell. You may also find this article useful on how to choose a good incident response supplier.
