Hardly a day goes by without news of another hack making the headlines and the hours and days following a security breach can make or break the affected company’s reputation. Having a detailed incident response plan in place allows you to react in a smart and structured way. Put simply, an incident response plan is insurance; hopefully, you will never have to use it, but it is absolutely essential.
Why do I need an incident response plan?
Does the thought of your business getting hacked make you feel a little queasy? Nobody likes to think about worst-case scenarios. However, understanding risks and preparing for different types of incident is the best way to stay on top of threats.
Every organisation should have an incident response plan and review it on a regular basis. Anyone can become the victim of hackers, regardless of company size or industry. Even if you don’t consider your business an attractive target for hackers or haven’t experienced a security breach, safe is better than sorry.
Preparing an incident response plan will benefit your business in (at least) two ways. First of all, you will be able to tackle security incidents with confidence and react quickly and effectively. On top of that, creating an incident response plan will also raise security awareness within your organisation and that is always a good thing!
Incident response plan basics
Organisation and roles
Most incident response plans follow the same structure, but the content of each individual plan varies based on the type and size of the organisation and the technology used.
Larger organisations often have a dedicated security incident response team (SIRT) that works exclusively with analysing threats and handling security incidents. This is often not an option for smaller businesses, which is why developing an incident response plan is an excellent opportunity to plan and assign temporary incident response roles and responsibilities.
Preparing the organisation for incident response includes deciding who is on call, how an incident should be escalated, and how information should flow between tech, PR, and legal. When it comes to incident response and communication, it is important to note that transparency is extremely important and, if you are processing the data of EU citizens, required by the GDPR. It might be tempting to conceal a security incident to avoid badwill, but unsurprisingly, this has a tendency to backfire and have a negative effect on brand reputation and trustworthiness. (We wrote about some examples of successful incident response PR and a well-known cautionary tale in our article on Four IT security role models)
The phases of incident response
It is a good idea to start developing your incident response plan by mapping out different threats in order to get a clear picture of what needs to be included in your plan. A stolen computer is a completely different situation than a DDoS attack, but both are security incidents!
An incident response plan typically consists of a sequence of steps leading from incident detection to recovery and lessons learned. Keep in mind that an incident response plan is never complete. As the threat landscape changes, so will the ways to approach and respond to incidents.
1. Prevention
A proactive approach to security goes hand in hand with an incident response plan. Nobody is 100% secure, but good security routines, comprehensive logging and monitoring, and a risk-aware mindset across all teams can go a long way to prevent incidents and minimize damage.
Incident prevention is a broad topic that covers everything from educating staff and performing regular risk assessments to using penetration tests and services like Detectify to monitor your web application’s security status.
2. Detection
Detection is a crucial step in incident response. It’s simple – you can’t tackle an incident if you don’t know you are under attack. The first indication that something is wrong can often be seen in logs.
Once you know something is going on, you need to establish what type of attack you are experiencing and how serious it is. You can categorize the incident and its severity based on the following criteria:
- Functional impact (To what extent does the incident affects your ability to provide services to users?)
- Information impact (Was information compromised in any way and to what extent?)
- Recoverability (What kind of resources do you need to recover from the incident?)
The criteria above will help you determine what needs to be done next and who should be involved. For example, if user information is compromised in a privacy breach, affected users need to be informed and a PR statement issued. On the other hand, a low severity incident with no functional, information or recoverability impact still requires appropriate steps to be taken, but stakeholders like the board of directors and the authorities will most likely not be involved.
3. Containment
You have identified the incident and it’s time to take action. Containment is all about taking control of the incident and isolating it in order to minimize damage. As such, containment often involves decisions that need to strike a balance between successfully containing an incident and retaining evidence with minimal impact on your business.
Making important decisions in a stressful situation is far from easy, which is why having clear guidelines in place is crucial. Map out different types of incidents and set containment criteria that clearly indicate the right course of action. For example, how severe does an attack need to be to warrant shutting down a specific service? Such decisions are much easier when you do not have an ongoing incident on your hands!
4. Eradication and recovery
Once you have successfully contained the incident, you can focus on getting things back to normal. The next step depends on the type of incident.
If the incident was the result of a security flaw in your web application, you might, for example, remediate the vulnerability during eradication. If a system was shut down in the containment phase, recovery is when you restore it and make sure everything’s functioning as it should.
5. Lessons learned
Every incident is a learning experience and an opportunity to improve your existing incident response plan. Within a few days after the incident has been resolved, gather your team and reflect on lessons learned.
Discuss what happened and what was done as well as what worked well and what didn’t. Could anything have been done differently? What additional tools or routines could help tackle future incidents? What could be added to your prevention workflow to avoid similar incidents?
6. Report
Writing a detailed report to document the incident from detection to recovery is a crucial part of incident response. You can use the incident report internally as well as a foundation for external communication about the incident.
The report should include incident details (what happened and when, how the incident was prioritized, what action was taken) as well as relevant investigation results, such as the cause of the incident and its business impact.
What next?
Once designed, an incident response plan is not set in stone. It’s like a fire drill – it needs to be reviewed on a regular basis and updated when needed. Like all security, incident response is a long-term committment that is never truly “finished”.
Getting started with a structured approach to incident response may seem intimidating and time-consuming at first, but it is an worthwhile investment that can save you a lot of headache later on. When faced with a security incident, nobody regrets having spent time developing an incident response plan!