Every company that builds or maintains software should have an incident response plan at hand. If you do not have one, it’s best to create it before an attacker compromises your system. A response plan is needed to fight incidents in the best possible way using a structured approach. It helps to make sure your business is up and running in a timely manner. Your core business requires it so it helps you with your business continuity efforts. Today we’ll present a detailed guide for your Incident Response Plan.
Introduction
First of all, you need to determine the format in which you will describe the incident response plan. Many companies prefer to write down a long Word document, other companies may decide to dedicate a Confluence space that is open to the public. Which method you prefer, it’s important to include the following topics in your introduction:
- The purpose of the Incident Response Plan. If you do not specify this, people won’t be able to position it beside their other activities and duties. If you omit to do so, it might not get the right priority from them.
- Position the Incident Response Plan as part of the bigger Incident Response Program.
- Write down the intent of the document (f.e. describe the processes to respond to an incident, build the awareness of the security requirements, and inform/educate employees).
It’s crucial to inform the reader of the actual purpose of the Incident Response Plan. This includes informing them about how to reduce the impact of a serious (security) incident, how to respond to a malicious code attack or a hoax message which intends to disrupt the services of the organization. Those goals should state clear objectives which are tangible and concrete and written in such a way that the various persons who are in charge understand what to do.
Authority & Terms and conditions
A document that does not reflect the right authority is a dead letter. Furthermore, the Incident Response Plan should be aligned with the organization-wide (security) policies that are already implemented. It’s important to position it alongside the existing policies, so it gains the same importance from the (senior) management.
These include at least the following policies:
- Information security policy.
- Employee security policy.
- How to handle and control removable storage devices.
- Information and asset classification (see our previous article).
- Transporting information assets.
Individual information security policies which apply to the department itself should also be included.
From all of these policies, the reference (a unique number) and the effective date should be mentioned and communicated.
Terms and conditions
In addition to this, the readers need to be informed about the Terms and Definitions which apply to this document. It’s vital that everyone has the same view on every aspect that is being described, otherwise, things will lead to misunderstandings and miscommunications along the way. This can be a factor of delay when executing the plan and also lead to (endless) discussions across different departments.
The following Terms and Conditions form the core of the plan: asset, incident, incident response plan and incident response policy, incident response procedure, incident response program as well as information security and information security event. Without a proper understanding of these terms, people are not aligned and their motivations and actions might conflict with each other. It’s about getting a solid baseline from which everyone can take action and act responsibly. This can only happen if everyone has a mutual understanding of the various terms and definitions.
Roles and responsibilities
Every plan that describes a specific topic should point out who are the key persons in charge. The Incident Response Plan is no different from that. The various roles and responsibilities break down to the following disciplines: preparation, planning, discovery, reporting, investigation, coordinating, recovery, follow-ups, and lessons learned. For each of the disciplines you need to identify a primary responsible person and a backup in case the primary person is not available (for whatever reason):
- Information owner: who holds the information that needs to be at hand
- Incident commander: the person who leads the incident on the highest level
- Incident response point of contact: the linking pin between the executors of the Incident Response Plan and the State Incident Response Team.
- The Incident Response Team members themselves: the persons who actually carry out the actions being described.
- Users: any (other) person that needs to comply with the provisioning of the policies, procedures, and practices.
It’s vital that everyone is involved understands the role and his/her responsibilities in accordance with the plan. Everyone needs to have a crystal clear view of it, these roles and the corresponding activities and concrete actions should be evaluated during all practice sessions of the program itself.
Compliance
Enterprises that require to always be “in control” also need to make sure they adhere to compliance rules, policies, regulations, and applicable laws. The Incident Response Plan is no different from this.
Make sure that you have a single person from one department responsible for it. That person should have the knowledge and mandate to enforce the rules and policies that apply here. Different branches require different policies, be sure that the right ones are applied.
The program itself
In the program itself, you need to outline the governance structure. This means: who is responsible for which aspect of the plan. At the core it answers the following questions:
- Who defines the policies that need to be followed?
- Who writes down the various procedures?
- Identify the key persons to raise awareness and communications.
- Who decides about (human) resources outside the formal workgroups.
Be very clear on the interval at which the plans are evaluated and tested and also mention whenever a significant change to the plans needs to be addressed and communicated. Everyone involved should have a solid authority that is not to be disputed during or after execution.
Besides these, the following topics are relevant in the program itself.
Identification
Identify the key person that is responsible for the incident and also describe examples of common incidents that might hit the organization. This gives the responsible person a good overview to which incident he must respond with the correct actions (the proposed actions that also need to be written out in the correct order).
Keeping the evidence
Any evidence which is present at the discovery of an incident should be preserved. This includes log files, forensic data about (leaked) information, or physical security-related information that reveal or exposes how the incident happened in the first place. This is crucial to learn from previous incidents and to build better protections.
Eradication
Whenever a serious incident occurs, it’s important to identify, remove and repair the vulnerability which is the cause of the incident in such a way that it is unlikely to be repeated in the future. Customers that are impacted by the incident need to be informed (in a secure way). This also applies to procedures for internal and external communications, defining the method to secure communications itself, key persons to discuss incidents.
Confirmation and resumption of the business
Once data is restored and operations are “back to normal”, it’s critical to confirm that the following aspects are confined:
- All threats and vulnerabilities have been eliminated or mitigated
- No new threats have been introduced
Continue the “business as usual” operations. This is a business-driven decision, not a technical one. So therefore it’s (again) crucial that you identify the one and only person that decides about his.
Postmortem
Just like Scrum events, the postmortem event is an important one to learn from the past. In addition to this fact, make one person responsible for this event that leads it. Every incident needs to be evaluated by all individuals that share their experience and bring in their views and documentation that helps to make better decisions in the future. Be sure to conduct these meetings within the following week of the incident.
Education and awareness
One of the most important purposes of the Incident and Response Plan is to train and educate all people that are involved. It should be embedded in the education and awareness program. In the education & awareness plan, the following should be outlined:
- Discuss the training cycle/schedule and identify the persons who will be trained.
- What will be the topics of the proposed training and how much training is needed?
- Decide about the actual ways that people will be trained: will it be a classroom setting, remote training through a (series of) web-based training modules? And how to keep the trained people up to date when the Incident Response Plan changes?
- How to raise more awareness for the Incident Response Plan. What is the impact of the people that are involved, also relate that to their job role and/or responsibilities.
- Make sure people can find the pieces of training, for example on the intranet. People should also be notified of the training and someone in the organization needs to “tick the box” when sufficient training is finished.
Communications
Communications around an incident should be effective and appropriate – it needs to be “just right”. The following aspects of incident-related communications are important:
- Define procedures about communicating with the media: who has the authority to speak and what will be communicated (and whatnot). Sensitive information about the incident should be limited or even avoided at all. Inform every employee to redirect any questions to the authorized persons.
- Setup and maintain procedures to securely communicate (both internally and externally) with employees, stakeholders, customers, and clients.
- In addition to the previous aspect, keep the contact information about all involved at hand. Remember: if core systems are not working properly anymore, you need to have a solid place (hard-copy) of this contact information.
- Identify common circumstances in which you know that certain people will and will not be informed about the issue. This should be absolutely clear to avoid confusion and misunderstandings within the Incident Response Team.
The above-mentioned aspects require proper procedures and also someone that guards those procedures, perhaps a task for the communication officer?
Implementation and approval
Shortly said, the implementation plan requires a set of tactical projects to implement it in the organization. Think of the following projects which need to be as concrete as possible:
- Give a summary of the individual components and their timelines to implement.
- Identify performance measures to keep an eye on what is going on.
- Define auditing/monitoring guidelines for regulations, external laws and policies, etc.
- Define key roles for the projects filled in by knowledgeable experts that are end responsible for them.
Approval
Whatever is defined in the Incident Response Plan needs to be approved. So approval of the plan and commitment to it is vital to make it a success.
Conclusion
Every self-respecting organization needs to have a thorough Incident Response Plan in case something severely goes wrong. Think of an earthquake that destroys your data center or a pandemic that puts a lot of people in quarantine. In this article, I outlined various aspects of this plan. It acts as a starting point for various topics such as the communications plan, the training and education section, roles and responsibilities, etc.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
