The 7 Red Flags When Creating an Incident Response Plan

A well-thought-out incident response plan (IRP) can prepare your organization for an emergency and enable you to respond to incidents in a more structured, efficient and comprehensive manner. An incident response plan provides a structured approach to handling cyber incidents and serves as a guide for each phase of the incident response process. This increases your incident response readiness.

The quality of such incident response plans varies from company to company. The scope ranges from 2 short pages to extensive 50-page concepts. Oneconsult has already seen, reviewed and revised many of these emergency plans. We have compiled a list of the 7 “Red Flags” that you should pay attention to when developing your own IRP and which you should address in order to be optimally and sustainably prepared for incidents.

Red Flag 1: No Definition, Classification and Prioritization of Incidents

The first “Red Flag” we come across when reviewing incident response plans is that incidents are not defined, classified and prioritized. This leads to a considerable loss of time in an emergency.

Defining, classifying, or differentiating between different incident levels and prioritizing them helps to avoid both underreactions and overreactions. Typical severity levels of incidents are:

• Event
• Security Incident
• Crisis

The severity classification can be defined, for example, based on the impact, urgency, financial damage, extent (number of systems affected), reputational damage and the effort required to deal with the incident. In this way, incidents can be quickly assessed and prioritized accordingly. This can save time in the decision-making process (see Red Flag 2) and escalation (see Red Flag 3), which has a direct impact on the response time to the various incidents. Depending on the categorization, for example, a warning message from an antivirus program would be an event, the compromise of a business email would be a security incident and the encryption of systems by ransomware would be a crisis. The response and management differ greatly between these three scenarios. The scenarios pertinent to a company should be defined depending on what is business-critical and included in the incident response plan.

Red Flag 2: No Definition of Roles Within the Emergency Organization

The second problem is a missing or unclear definition of individual roles in an emergency organization. This includes decision-makers, competencies, responsibilities, and areas of competence. Each role should therefore define a responsible person and list at least one deputy, in order to still be able to react appropriately if an employee happens to be on vacation, sick or unavailable.

In the event of a cyber incident, the incident response team or emergency organization comes into play. Cyber incidents often not only affect IT, but also other departments, e.g. in the event of a crisis, the following departments will also be involved:

• Executive Management
• Legal Department
• Communication
• HR
• Data Protection Officer
• etc.

All of these involved parties should be included in the incident response plan, at least optionally or as required. Everyone should understand their role and be clear about the associated tasks. Knowing who will take on which tasks in the event of an incident saves time, creates clarity and avoids unnecessary stress.

There are also external parties such as providers of cyber insurances, service providers and incident response providers. It is important to determine in advance which partners need to be informed or involved. Also pay attention to the contractual conditions regarding how quickly you will receive support.

In addition, a contact list (see DFIR, Simple: Who to Call in a Cyber Emergency?) with internal and external contacts and deputies should be provided. This should include the various communication channels, ideally with a private number to ensure reachability.

The contact list could be added to the IRP as an annex to simplify changes, additions and deletions. In this way, the annex can be used as the “living part”, which does not need to be approved. The contact list should be reviewed regularly, e.g. annually, revised and adapted if necessary. This also applies to the IRP itself.

Red Flag 3: No Reporting Procedures and Escalation Channels

Another “Red Flag” is the lack of reporting procedures and escalation paths within the emergency response organization. A lack of proactive incident response and escalation can cause delays and potentially buy attackers valuable time to successfully carry out their actions. In the cases we handle as the CSIRT (Computer Security and Incident Response Team), we are often notified far too late, and the damage is already extensive. It is therefore often the case that the damage could have been significantly reduced if we had been informed at an earlier stage.

Identifying the order and urgency with which individuals should be contacted is important. A distinction should be made according to the severity of the incident (see Red Flag 1). This influences which stakeholders should and must be involved. If there is also an obligation to provide information, for example as part of a cyber insurance policy, the reporting deadline should be documented. The same applies to other reporting obligations such as the requirements of a data protection regulation.

The reporting procedures and escalation channels should be presented clearly and concisely, for example in the form of a matrix or a list. This provides a quick overview of the people who need to be informed and ensures that everyone can easily understand how to report or escalate an incident at a glance. The format could be as follows:

In this context, it is also important to define the means of communication (telephone, email, SMS, etc.) via which the escalation should take place. In the event that these are no longer available, an emergency means of communication must be defined as well.

Red Flag 4: No Crisis Communication

As soon as the incident and its extent have been identified, and depending on the severity of the incident, this must be communicated to the employees and all those affected. It is advisable to clearly define the primary communication channel and its backup options in case the primary channel becomes inaccessible.

It is particularly important to define the following:

• Who is responsible for the task of communication.
• Who needs to be informed and when.
• How the information is to be provided.
• What should be communicated.

For the last point, it is advisable to create templates depending on the scenario and contact person in order to be able to communicate effectively with:

• Employees
• Customers/suppliers/partners
• Press/media

The communication should include in particular what type of incident it is, whether the incident is still ongoing, what measures have been taken to contain or resolve the incident and whether other organizations (e.g. authorities) are involved in dealing with it. Further recommendations on this topic can be found in the blog post by CERT NZ (New Zealand’s Computer Emergency Response Team).

Our experience and the incidents published in the media have shown this: Proper, timely and transparent communication helps to reassure those involved, protect your organization’s reputation, and maintain or even rebuild the trust of stakeholders. However, do not disclose too much information, as this could attract the attention of attackers. Especially at the beginning of incident management, remember that it is best to communicate as much as necessary, but as little as possible. It is therefore essential that a company defines how to communicate in the event of a cyber incident, specifically as part of an IRP.

Red Flag 5: No Defined Measures

Many complications can arise if the procedure, especially the actions to be taken at each phase of the incident response process, are not clearly outlined. The situation can even worsen if the measures are not appropriate or are not introduced at the right time.

Clearly defined and comprehensible processes help to initiate suitable measures for containment, management and recovery. They should show exactly what needs to be done in which phase and who is to be responsible. The measures to be taken depend on the severity and nature of the incident. Examples include isolating affected files, systems or network segments, deactivating user accounts, and resetting all passwords.

As useful additions to the IRP, playbooks or checklists can be developed that contain general immediate actions or steps to be taken to improve and speed up the incident response process. Documents such as an asset inventory, a network plan, a data backup policy, and a disaster recovery plan are also very useful and should be linked to the IRP.

Red Flag 6: No Physical Copy of the IRP

Among the incidents that the Oneconsult CSIRT has dealt with, it has occurred that the IRP was neither printed out nor available in an offline version, so that it was no longer available at the time of the attack and a lot of time was lost before the key points for further action were compiled.

It is recommended that a printed copy of the plan is made and stored securely. This ensures that the IRP is available even if central IT components should fail.

In addition to the IRP, other documents/information are also often forgotten to be stored in a crisis-proof manner, for example:

• All necessary referenced documents such as recovery plans
• A crisis communication plan
• Licenses and keys
• Important passwords

 One effective method is to store these files on an “emergency USB stick” to guarantee continued access to this critical data during emergencies. It is important to securely store this USB stick as well.

Red Flag 7: Lack of Practice

A perfect emergency response plan is only half as good if it is not practiced regularly. This is the seventh and final “Red Flag”.

Frequently, we encounter meticulously crafted incident response plans that address and alleviate the obstacles mentioned earlier. Yet, when an exercise is conducted and the plan is put into action, it often reveals that the process, as outlined in theory, either fails entirely or only partially succeeds. In some instances, the process may have worked, but the members of the defined emergency organization are unaware of the plan and thus lack clarity on their roles and responsibilities.

Regular practice and training of an incident response plan are therefore essential to overcome final obstacles and internalize the plan effectively. Ultimately, the plan can only be executed efficiently if it is well understood and adhered to in an emergency.

Conclusion

The incident response plan is one of the fundamental elements of incident response readiness. It clarifies roles and responsibilities and describes processes and procedures. It should also contain a list of the key persons who need to be involved in the event of a crisis. The plan is therefore particularly important in order to be able to react correctly and in good time in the event of an incident. Typical red flags are the lack of such information. Crisis communication and measures are also often forgotten. The IRP should also be printed out and tested regularly so that it is always available and updated in the event of an incident.

If you need support in creating or reviewing your incident response plan, require additional playbooks or would like to test your incident response plan using tabletop exercises (see Incident Response), do not hesitate to contact us. We will be happy to help you with these and all other cyber security topics.

We look forward to hearing from you: