Creating an incident response plan - a how to guide

An incident response program is an essential part of the overall information security management program. Being able to identify and respond to security incidents will help you prevent threats that originate from inside and outside of your network.

Below is a brief introduction to the concepts of Incident Response and some guidelines on implementing a formal Incident Response plan in your organisation. These plans should exist along side your Information Security Policy’s

What Is Incident Response?

Think of an incident response program like the digital 999 of your IT systems. When an emergency happens in the real world, you pick up the phone and trained professionals will follow a process for getting help to you. In the same way, an incident response program is the area of your security program that deals with security emergencies, both large and small.

A key component of the incident response plan is your incident response team (usually referred to as a CyberSecurity Incident Response Team, or CSIRT), who are your first responders when an incident happens.

The CyberSecurity Incident Response Team are nominated individuals or a managed service from your IT Support provider. They will quickly triage the situation and determine the right course of action according to the plans and processes you've laid out. If the CSIRT has the ability and access to resolve an incident, they will do so, or will escalate to someone who does. They will then log the incident for later review by management teams.

How should you determine who is on this response team? In smaller businesses, there may only be one or two people available such as a Director coupled with a Managed IT Support Service Provider. In medium-size businesses, the CSIRT may be comprised of a Director responsible for IT and Cyber Security together with an internal IT Cyber Security resource or a Managed Service provider. Regardless of who is assigned to the team, each person should be familiar with industry best practices together with subject matter experts for identifying and responding to security alerts. 

What Qualifies as an Incident?

The first step in forming an incident response program is determining exactly what counts as a security incident. Obviously a data breach or other large-scale event counts, but what about the everyday issues like a user getting locked out of their PC or accidentally sending an unencrypted email with confidential information?

As you configure your systems to generate alerts for specific types of incidents, you must find a balance between flagging important issues and overwhelming your security team with unnecessary alerts. You probably don't want to generate alerts for someone getting locked out of their PC once, or any time someone connects to the VPN. But what about someone that has gotten locked out 10 times in the past two days, or someone connecting to the VPN at 2 AM when you don’t have employees working from foreign countries? These could point to something more serious.

Utilising a SIEM (Security Information and event Management) you can add a layer of intelligence to the alerting, combine it with a SOC (Security Operations Center) you now get actionable insights to help you only focus and spend time on important alerts. Add in a Managed Service Provider, you can relax and simply review summary reports on the events in your environment, only having to get involved if there is a significant incident.

Determine the Sources of Incidents and How to Alert On Them

Where do security incidents come from in your environment? Or what devices in your network are able to generate alerts at these entry points? Incidents can originate from many different sources: your Microsoft 365 system knows when someone is trying to log in to your tenant; your email filter knows when someone is trying to send unwanted or phishing messages to your users; your intrusion detection/prevention systems know when suspicious traffic is happening on the network; your firewall knows when an incoming connection is trying to access your production systems, and so on.

All of these devices have the ability to generate logs and alerts. Instead of having your security team check each individual device, you can have the devices send their logs and alerts to one centralised logging system which automatically reads them and alerts you of anything unusual according to the criteria you set (SIEM). This way, your CSIRT and/or Managed Services Provider can get all of the alerts from one place in one standard format, allowing them to respond more quickly and accurately.

Develop an Incident Response Plan for Each Type of Incident

Once your logging system and alerts are in place, you need to formulate a plan for how your team should respond to each type of incident. There are hundreds of types of security incidents so we will not attempt to provide a suggested plan for each type here. Instead, ask the following questions for each type of event to help guide you to the proper response plan:

• What security risk does this incident represent?

• What is the severity of this incident, or how quickly should it be addressed?

• What system, application, device, personnel, or facility does this incident affect?

•  Does this incident affect business production, your clients, or the company's reputation?

•  Who has the ability or access to resolve this incident?

•  Could this incident happen again? If so, what measures can be put in place to prevent it next time?

Once your response plan has been decided, it's critically important to document it and obtain approval from senior management to enforce it. Then communicate the plan to your frontline teams and instruct them to follow it every time there is an incident.

Log and Review Every Incident

Logging is a key part of any good incident response program. Your CSIRT should be creating a log or record every time a qualified incident happens, and then tracking that ticket through to completion.

Management should review these logs on a regular basis to understand where incidents are coming from and how they're being handled. Significant events should be given a special evaluation, often called a "post-mortem," to understand what went wrong and how to fix it going forward.

If your ticketing system allows incidents to be categorised, this should be employed so that management can quickly understand where the most incidents are happening and delegate the necessary resources to those areas.

Implement Additional Security Controls to Prevent or Reduce Incidents

Management should be regularly reviewing the type and quantity of security incidents happening in the environment to determine if additional security controls are necessary.

For example,

• if users are consistently getting locked out of their account, perhaps it makes sense to implement a self-service account unlock function utilising multi-factor authentication.

• if confidential information is regularly leaving the environment via email (whether intentionally or not), a Data Loss Prevention system should probably be used for outgoing email.

When in doubt, a managed services provider can recommend the appropriate controls for the types of incidents present in your environment.

In today's digital world of constant threats and security breaches, having a proper incident response program is key in securing your company's data.

Incorporate the recommendations in this guide along with your regular practices to ensure that incidents in your environment are properly identified and resolved.

If you require assistance in creating an Incident response plan or the technologies to assist in the collection, reporting, alerting or the actionable insights then book a meeting with our experts.