Incident Response Plan Guideline: What is an Incident Response Plan?
Cybersecurity-related attacks have grown in number and variety, as well as in severity and disruption. Information technology (IT) programs now include computer security incident response as a key component.
New forms of security-related issues spring up on a regular basis. Although preventive actions based on risk assessments can reduce the frequency of occurrences, not all incidents can be avoided. As a result, an incident response capability is required for quickly recognizing occurrences, limiting damage and destruction, mitigating exploited flaws, and restoring IT services.
What is an Incident Response Plan?
An incident response plan is a set of tools and procedures that your security team can employ to detect, eradicate, and recover from cybersecurity threats. It's intended to assist your team in responding promptly and consistently to any external threat.
For all major occurrences, a proper incident response plan provides a course of action. Some accidents result in large network or data breaches, which can have a long-term impact on your business. When a major interruption happens, your company needs a comprehensive, detailed incident response strategy to help IT employees immediately stop, contain, and control the problem.
Why Do You Need an Incident Response Plan?
When an organization's reputation, income, and customer trust are on the line, the ability to detect and respond to security incidents and events is vital. Organizations must have an incident response strategy in place, whether the breach is small or large, to reduce the chance of becoming a victim of the current cyber-attack.
What defines a breach, the roles and responsibilities of the security team, tools for managing a breach, steps that must be taken to address a security incident, how the incident will be investigated and communicated, and the notification requirements following a data breach are all laid out in incident response strategies and plans.
The three most significant reasons why you need an incident response plan right now are listed below:
1. Safeguard Your Data: Data security is important for both personal and professional reasons. Your team may proactively protect your data by implementing an updated incident response plan. When a hacker uses ransomware (WannaCry, Petya, NotPetya, etc.) or private information is disclosed to the public, data in the wrong hands could be held for ransom.
2. Customer Trust: Protect Your Reputation: Consumers would transfer their business elsewhere if they were personally affected by a data leak, according to IDC (International Data Corporation). If a security breach is not addressed promptly, the company may lose some or all of its customers. Customers will lose trust in you if you have a data leak. You're probably aware that it can be a public relations disaster for businesses.
3. Protect Your Revenue: A thorough incident response procedure protects your company from a potential income loss. The average cost of a data breach, according to the Ponemon Institute's 2017 Cost of Data Breach Study, is $3.6 million.
The faster your company can identify and respond to a data breach or even a security event, the less likely it is to have a major impact on your data, customer confidence, reputation, and income. If your company doesn't have an incident response plan in place, consider partnering with a third-party managed security services provider to develop one.
How to Create an Incident Response (IR) Plan?
Some businesses create Incident Response (IR) plans because they are required by regulatory agencies. Others do so because they understand how important it is to respond quickly to an incident in order to minimize its damage. Security events will inevitably occur, and the goal of an incident response strategy is to minimize the negative impact on the company in the case of a cyberattack.
The five steps security professionals must take to build and implement an operational and effective IR plan are outlined below.
1. Create an IR Practice
The creation of the IR plan document itself, which begins with the development of an IR practice vision, is an excellent place to start. The following elements should be included in the document:
- IR mission statement: This clarifies why an IR plan is required in the first place.
- Roles and responsibilities: This section identifies who is involved in the IR plan and why they're there.
- The scope of an incident declaration specifies which conditions are eligible for a declaration and which are not.
2. Verify that incidents are detectable.
It is not the monitoring team's responsibility to declare an incident, but it is their responsibility to guarantee that all alerts of interest are thoroughly investigated and escalated. Whether monitoring is done internally or through a service provider, the IR Team lead plan should establish a process for managing, vetting, and elevating incidents of interest to ensure that alerts are sent to the IR in a timely and accurate manner. In the scope of your IR plan, only list dangers that your security team has the ability to detect.
3. Make the decision to formally begin the IR process.
Declaring an incident must be taken lightly since the IR process will entail extra labor and cost for the company. When a company decides that this level of risk is unacceptable and they are willing to invest in reducing the damage, an incident should be notified.
When an incident is escalated, a single individual must assume the role of IR lead. The incident declaration is the responsibility of the IR team head, in coordination with the broader cybersecurity team. The plan will outline the process for the IR team lead to do so.
First, the IR lead should double-check the incident by analyzing the data collected by the monitoring team and gathering additional information as appropriate. The lead can then convene a meeting with identified parties to declare an incident. Determine whether this meeting will be held in a virtual or physical war room, as well as fallback communication channels in the event that the primary ones are unavailable.If the decision to announce an incident is taken, the IR team lead must now carry out the rest of the IR plan as planned. Even if the team decides not to register an incident, the IR team head should write an after-action report and properly conclude the case.
4. Execute the IR Strategy
It's time to act after an incident has been proclaimed. Reduced impact requires concise, systematic actions that are clearly articulated and planned.
A process flow outline is required for an IR plan, which should cover both the plan's communication and the processes required to respond to an event. The escalation from the monitoring team and the formal incident declaration process begins the flow. The flow covers the measures to contain the threat and recover if an incident is declared.
Create a list of important stakeholders for each sort of event so the IR team can easily determine who is involved, when they are involved, and what measures should be taken. It is excellent practice to list actual names and current contacts, not simply jobs, to guarantee responsibility and keep the IR plan updated.
When an incident is announced, the IR lead and their team must take action. As the team works to isolate the impacted users, systems, applications, or other resources, containment should be a top concern. For creating the containment strategy, the IR plan should examine the stage and severity of the attack, as well as how to implement the strategy and who has authority.
It's time to start working on mitigation when the incident has been properly contained. Mitigation is the last set of steps in the process of returning a system or resource to normal operation. Depending on the type of occurrence and its intensity, different mitigation procedures will be taken. Mitigation could, for example, consist of simply reimaging a system to return it to its pre-attack state.
5. Make the Transition from Good to Great
A rigorous post-incident learning procedure should be included in an IR plan to limit the chance of recurrence. In addition to preventing the same incident from occurring again, the training provides monitoring for team preparation, allowing you to fine-tune coordination and decision-making for declaring or responding to an incident.
What Are The 6 Steps of an Incident Response Plan?
You may implement your incident response plan by following the six steps given below.
This will be the engine of your incident response planning and, in the end, the most important phase for safeguarding your company. This stage includes the following items:
- In the case of a data breach, make sure your personnel are appropriately trained in their incident response roles and duties.
- To evaluate your incident response plan, create incident response drill scenarios and conduct simulated data breaches on a regular basis.
- Ensure that every part of your incident response plan (training, execution, hardware and software resources, and so on) is approved and paid ahead of time.
Your response plan should be well-documented, with roles and duties for everyone clearly defined. The plan must then be put to the test to ensure that your personnel will perform as expected. The better your personnel are prepared, the less likely they are to make significant errors.
Subjects to be addressed are as follows:
- Has everyone received security policy training?
- Have relevant management approved your security policy and incident response plan?
- Is the Incident Response Team aware of their responsibilities and the mandatory notifications?
- Have all members of the Incident Response Team engaged in simulated training exercises?
This is the procedure for determining whether or not you've been hacked. A breach, also known as an incident, can occur in a variety of ways.
- Subjects to be addressed
- When did the incident take place?
- How did it come to be discovered?
- Who was the first to notice it?
- Are there any other regions that have been impacted?
- What is the compromise's scope?
- Does it have an impact on operations?
- Has the event's source (point of entry) been identified?
When a security compromise is first discovered, your first reaction may be to securely remove everything so you can go on. However, this will likely backfire in the long run because you'll be losing crucial evidence needed to figure out where the breach began and design a plan to prevent it from happening again.
Instead, restrict the breach to prevent it from spreading and causing more harm to your company. Disconnect impacted devices from the Internet if possible. Prepare both short-term and long-term containment plans. It's also beneficial to have a redundant system backup in case business operations are disrupted. That manner, any data that has been compromised will not be gone permanently.
This is also an excellent time to patch your systems, examine your remote access protocols (which should include required multi-factor authentication), replace all user and administrative access credentials, and harden all passwords.
Subjects to be addressed are as follows:
- What steps have been taken to contain the breach in the short term?
- What steps have been taken to keep the breach under control in the long run?
- Has any malware that has been found been isolated from the rest of the system?
- What kind of backups do you have in place?
- Is real multi-factor authentication required for remote access?
- Has the validity of all access credentials been checked, toughened, and changed?
- Have you installed all of the most recent security updates and patches?
After you've contained the problem, you'll need to locate and eliminate the breach's root cause. This means that all malware should be removed safely, systems should be hardened and patched anew, and updates should be installed.
Whether you do it yourself or hire someone to do it for you, you must be thorough.
If any traces of malware or security flaws remain in your systems, you risk losing important data and increasing your liabilities.
Subjects to be addressed are as follows:
- Have the attacker's artifacts/malware been securely removed?
- Has the system been patched, toughened, and updated?
- Is it possible to re-image the system?
This is the procedure for restoring and rebuilding damaged systems and devices in your company's environment. It's critical to get your systems and business activities back up and running without risk of another breach during this time.
Subjects to be addressed are as follows:
- When will the systems be ready to go back into production?
- Have you patched, hardened, and tested your systems?
- Is it possible to restore the system from a reliable backup?
- How long will you monitor the affected systems, and what will you check for throughout that time?
- What technologies will be used to ensure that similar attacks do not occur again? (Intrusion detection/protection, file integrity monitoring, etc.)
Hold an after-action meeting with all members of the Incident Response Team to share what you've learned from the data breach once the investigation is finished. This is where you will investigate and document the security violation. Determine what aspects of your reaction plan worked successfully and where there were flaws.
Subjects to be addressed are as follows:
- What security adjustments are required?
- What are the different ways that employees should be trained?
- What flaw did the hacker take advantage of?
- What steps will you take to guarantee that a similar incident does not occur again?
What to do After a Cyber Incident?
As previously mentioned, managers and organizations should take preemptive measures to reduce the danger of a data breach. What will happen if a case has occurred despite all the precautions taken? When a security breach is identified, the company should take the following urgent steps to contain the problem.
Step 1: Determine the extent of the damage.
After the incident is discovered, the selected members of the information security team must conduct an internal investigation to identify the impact on important business processes.
The organization will be able to identify the attacker, discover unknown security flaws, and determine what changes need to be made to the company's computer system as a result of this detailed study.
Step 2: Make every effort to prevent more damage.
The company should take precautions to prevent an attack from spreading.
Rerouting network traffic, filtering or restricting traffic, and isolating all or sections of the infiltrated network are some preventative techniques.
Step 3: Put together a list of the details.
The information security team should preserve a documented record of the steps taken to address the breach. The following information should be gathered:
- Affected systems
- Compromised accounts
- Services that have been disrupted
- Amount and type of damage done to the systems
- Data and network affected by the occurrence
Step 4: Collaborate with police enforcement
A major security breach should always be reported to the authorities. The following law enforcement agencies should be contacted for USA:
- The Federal Bureau of Investigation (FBI)
- The United States Secret Service (USSS)
- The United States Immigration and Customs Enforcement (USICE) (ICE)
- State and local law enforcement
- The District Attorney
Step 5: Inform those who are affected
If a data breach puts a person's personal information at danger, they must be notified. This fast response may enable them to adopt immediate protective measures. If law enforcement is involved, they should advise the company on whether or not the notice should be delayed to avoid jeopardizing the investigation.
Step 6: Apply what you've learned from the breach
Because cybersecurity breaches are becoming more common, it's critical to build organizational mechanisms for learning from them. Should a corporation be impacted by a breach in the future, this enables improved incident handling. The following are some learning issues:
- Keep track of all mistakes
Incident Response Plan Checklist
Below provided cyber incident response plan sample will be handy to be ready for an incident.
Checklist for Incident Responders
- Are all members aware of the organization's security policies?
- Do all members of the Computer Incident Response Team know who to contact in the event of a cyber incident?
- Do all incident responders have access to incident response toolkits and diaries in order to carry out the real incident response process?
- Have all members engaged in incident response drills on a regular basis to practice the incident response procedure and increase overall proficiency?
- Where did the incident happen?
- Who reported or discovered it?
- How was it discovered?
- Have any other areas been compromised as a result of the incident? If yes, what are they and when were they discovered?
- What is the impact's scope?
- What are the effects for business?
- Have the incident's source(s) been identified? If so, where are them, when are they, and what are they?
a. Containment for a short time
- Is it possible to isolate the issue?
- If that's the case, isolate the systems that are affected.
- If not, consult with system owners and/or managers to decide the next steps in resolving the issue.
- Are all affected and non-affected systems separated?
- If that's the case, move on to the following step.
- If not, isolate affected systems until a short-term containment solution is found to prevent the incident from escalating further.
- Have forensic copies of the systems in question been made for future investigation?
- Have all commands and other documentation been kept up to date after the incident occurred?
- If not, document all acts as soon as possible to ensure that all evidence is kept for prosecution and/or lessons learned.
- Are the forensic copies kept in a safe place?
- If that's the case, move on to the following step.
- If not, store the forensic images in a safe place to avoid accidental damage and/or tampering.
c. Containment for a long period of time
- Proceed to the Eradication step if the system can be shut down.
- if the system must remain in production, implement long-term containment by deleting all malware and other artifacts from affected systems and hardening them against future attacks until an ideal condition allows them to be reimaged.
- Can the system be reimaged and then hardened with patches and/or other countermeasures to prevent or lessen the risk of assaults, if that is possible?
- If not, could you perhaps explain why?
- Has the attackers' malware and other artifacts been removed, and have the affected systems been hardened against future attacks?
- If not, could you kindly explain why?
- Has the impacted system been patched and hardened against the recent attack, as well as any future ones?
- What day and time would it be possible to bring the affected systems back online?
- What tools will you use to test, monitor, and verify that the systems being restored to production are not vulnerable to the same threats that caused the initial incident?
- How long will you be monitoring the restored systems and what will you be looking for?
- Are there any previous benchmarks that can be used as a baseline against which the monitoring results of the recovered systems can be compared?
- Have you written all of the incident's relevant documentation?
- If this is the case, prepare an incident response report for the lessons learned meeting.
- If not, have documentation created as quickly as possible so that nothing is forgotten and the report is incomplete.
- Assuming the incident response report is complete, does it document and respond to the following questions for each phase of the incident response process: (Who? What? Where? Why? And How?)
- Is it possible to plan a lesson learned meeting within two weeks of the incident's resolution?
- If not, why not say why and when is the next available time to hold it?
- Meeting on Lessons Learned
- Have all CIRT members review the incident response protocol for the incident that happened.
- Was there any discussion of any errors or places where the response process may have been handled better during the meeting?
- Could you perhaps clarify why no such talks took place?
Incident Response Templates
It's much easier to start with a template, delete parts that aren't relevant to your business, and fill in your data and processes than it is to start from scratch. There are various free templates available below that can help you get started.
California Government Department of Technology Incident Response Plan
Created by: California Government Department of Technology
Contents: 17-step incident response procedure, referencing more detailed plans for specific incident types such as malware, system failure, active intrusion attempt.
Sysnet Security Incident Response Plan
Created by: Sysnet
- How to recognize a security incident
- Roles and responsibilities
- External contacts
- Payment cards—what to do if compromised
- Incident response steps
- Report, investigate, inform
- Maintain continuity
- Resolve and recover
- Specific incident response types
- Tampering with payment terminals
- Unauthorized wireless access points
- Loss of equipment
- Noncompliance with security policies
- Testing and periodic updates for IR plan
Get .DOC file (requires registration)
Cynet Incident Response Plan Template
Created by: Cynet
- Incident Response Team Responsibilities
- Testing and Updates
- Incident Response Process Overview
- Incident response checklists: Incident Discovery and Confirmation, Containment and Continuity, Eradication, Recovery, Lessons Learned