An Incident Response Plan (IRP) is exactly what it sounds like. A plan for how to respond to incidents. The key word here is respond. Without a plan, it will be an incident reaction instead of an incident response.
This post is covering IRPs that are specific to cyber security, but an IRP can cover any number of incidents. Sometimes it is included in a Business Continuity Plan (BCP) or a Disaster Recovery Plan (DRP). Other times it is its own plan.
The IRP can be generalized and simply cover “cyber-attacks”, or it can be broken down into different types of threat events such as ransomware, denial of service (DoS) attacks, and data breaches.
Regardless of the scope of the plan, it is important to make one.
All incidents will be different, and it is likely that your plan will not exactly fit your needs in the moment. However, planning offers many benefits.
Think Through Likely Scenarios
Even if the actual situation is different from the plan, the process of planning will help you adapt your plan to the incident. If you need ideas for incidents or threats to include in your IRP, you can refer to your information security risk assessment findings.
Limit the amount of things you will have to “figure out” when responding to an incident.
Who do we need to contact? What is their contact number? Who makes the response decisions? How do we restore from a backup?
These are questions you can answer beforehand.
Limit Required Decisions
You want to limit the number of decisions or fact finding that needs to be done in the event of a cyber-attack. If any decisions can be made beforehand, include them in the plan. For those decisions that cannot be planned ahead of time, you can at least prepare by identifying the decision points and decision-making criteria in the event of a cyber-attack.
Under what circumstances will you disconnect or shut down devices or services?
What to Put in Your Plan
This depends on what incident response resources you have. If you have your own incident response team, then this plan may go into a very deep level of detail covering many scenarios.
Most organizations do not. You may have a system administrator or a managed service provider who may need to be involved in the response, but no dedicated incident response team. For these organizations, here are important pieces of information to include and questions to answer:
Roles and Responsibilities
Assign a primary incident response coordinator to be responsible for making decisions, prompting action, and coordinating with external organizations? Unless absolutely necessary, this should not be a consultant, MSP, or insurance representative.
Assign any additional incident response roles.
Determine how you will communicate while responding to an incident. Keep in mind that some communication methods could be compromised or unavailable. Include primary and alternative means of communication.
Document contact information for the following individuals or organizations.
- Legal representative
- Insurance provider
- System administrator and/or MSP
- Public Relations representative
- Incident response experts or resources
- Digital forensics experts or resources
- Primary incident response point of contact
- Primary individual responsible for information security
- Internet Service Provider
- Any other required contacts
You may not need to contact all of these individuals, but if you do, it is beneficial to already have the contact information on hand.
Legal, Regulatory, Contractual Requirements
This can include requirements to notify affected individuals of a data breach, following certain procedures to ensure any evidence collected is admissible in court, or requirements set by your insurance provider. Seek legal advice to help determine these requirements.
Steps to Document
Reporting: Write instructions for end users to report incidents and any other reporting that is required wither it is internal or external to your organization.
Response: The steps that will be taken to analyze the event to determine if it is, in fact, an incident and to discover the extent of the incident.
Recover: The steps that will be taken to recover from the incident to include eliminating attacker access, mitigating the exploited vulnerability, restoring systems to a secure state, and learning from the experience through a documented after-action report or a root cause analysis.
A few more words of advice
Cooler heads prevail. Not every “event” is a cyber-attack that needs an “all-hands-on-deck” response. This will do damage to your organization and become a “boy who cried wolf” situation. That doesn’t mean you should ignore possible incidents, but you should look at what you know and try to limit any speculation until you are able to look into it more.
Exercise your IRP. It takes minimal effort to get everyone together and do a tabletop exercise of your plan once or twice per year. This is a great time to update information, requirements, and think of new scenarios you want to consider.
Communicate this plan. This plan may include sensitive information that you do not want to share with others. For those who do need to know, make sure to communicate the plan so everyone is on the same page. End users do not need to be aware of every detail in the plan, but they do need to know what to look for to identify potential incidents and report them to the proper individual(s).
Involve organization leadership. This one is fairly self-explanatory. All plans and policies need proper leadership support to be successful.
Involve other business sections. Don’t write this plan in a vacuum only considering IT or information security requirements. Include representatives from different sections of your organization. Incidents impact the entire organization and so will the response actions.
IRPs will look different for every organization. If you don’t have one, start writing one. Something is better than nothing. If you already have one, improve it over time and practice it.
If you need help along the way or want to learn more, schedule a free consultation with Agler Security Consulting!