An Incident Response Plan of an organization is a set of proven methodologies and protocols to follow at the occurrence of an incident to bring the affected systems back to function. In the digital world today, every website is prone to the incident, an undesirable disruption which causes malfunctioning of your site in delivering its primary function. The incident response plan (IRP) is a systematic, documented approach that an organization adopts to counter an incident and recover from it in minimum possible time.
Increasingly services are getting on to cloud which improves work efficiency which means they are also vulnerable to incidents. Incidents need not be caused only by cyber attacks. Errors as innocuous as a simple coding error could cause downtime and subsequently major havoc and given the network of how systems are connected today, one small incident could trigger a series of incidents due to Domino effect. So it is a mandate for every IT enterprise to have a well crafted IRP in place.
An IRP should define three major components of response mechanism i.e people, processes, and tools that are to be deployed to handle the mishap, prevent damages and to study the aftermath and learn from it. People refer to the incident management team who should be informed first and be put in charge of handling incident, their roles and expected outcomes from each. Processes define the set of actions to be carried out from the occurrence of the incident until it is resolved. Tools is a compilation the set of tools that should be used to identify, mitigate and communicate the incident.
Here are the six major phases of dealing with any incident and creating an Incident response plan :
As the title implies, this stage of planning focuses on preparing the organization, the Incident management team to be specific, to be ready to counter an incident any moment. This stage involves designing incident handling mechanism covers every type of incident ranging from power failure to a disastrous cyber attack. It includes framing policies, defining practices and rules, response strategy on how to handle incidents. This stage objectively defines the severity of the incident and recommends corresponding actions to be taken. Guidelines to the response team on whom to contact and when to improve response efficiency is also done in this stage. The other key actions in the preparation stages are documentation of the incident, a deputing team with proper roles and responsibilities assigned with all required accesses granted. This stage also should actually prepare the team by conducting mock drills for the team to have real, hands-on experience in handling incidents.
In this stage, an abnormality found in the usual functioning of the system is inspected for its eligibility to qualify as an incident. Here the IR team collects past events from sources like error messages and log files to check if the malfunction can be labeled as an incident or not. Once an incident is identified, immediately it is communicated to the team and the whole process is documented as evidence. Creating and maintaining such documents is necessary for future references and sometimes, it plays a vital role in mitigating or recovering from the current live incident.
The goal of this stage is to control the impact of the incident and prevent it from affecting the system further. It is done in three sequential steps. One,short time containment in which the affected component of the system is isolated from the rest to control the magnitude of the damage and substitute them with backup components. The next step is system backup in which the data from the isolated component is backed up for immediate or future use. The last step is long term containment strategy which involves studying the root cause and investing in disaster proof components and systems to withstand such outages in the future.
This stage of the process deals with the eradication of the cause of the incident. Here the root cause of the issue is analyzed and cost of eradicating it is calculated. All the steps that are necessary to remove malicious content off of the affected systems and ensuring they are free from are carried out. This may require replacing vulnerable software or hardware or both, recruiting the personnel with the right skills to the team,training the current team and sometimes taking appropriate actions on the team member as per the organizational policy, if they are found to be the reason behind the incident. The learnings from this stage is documented and imparted to the company’s incident response training program.
The purpose of this stage is to bring the affected system back to the production environment after the root cause is identified and resolved. It is very important that the components are carefully tested and validated before putting them back to production. An organization should target to reach this phase as quickly as possible since it means less downtime and services are back to availability for the users faster than expected. Important decisions like when to call the system as normal again, how to ensure the restored component is clean, how long to keep it in observation etc are made in this stage. Sometimes third party resources are hired to monitor the system to ensure the system is no more vulnerable.
Every incident should be a lesson for the organization to learn from. After resolving the incident, the organization should have a document that reads clearly the cause of the incident,actions taken and every minute detail related to the prior steps. This will help in avoiding recurring patterns of incidents which will cost a lot of time and other resources and also it will question the capability of the team to keep the system up and running for its users. The overall objective of this stage is to prevent a similar incident from happening again. The team meets with the incident report and discusses and listens to the views of all the members of Incident Response team and any valuable learning or a good example case can be included in the training module of the new members.