From Cybersecurity to Cyber Resilience:

Building an incident response plan

Preparation, in the form of an incident response plan, is the difference between an immediate reaction that limits damage and indecision that gives attackers time to operate freely.

To be effective, an incident response plan should cover four main phases: 

1. Identification
2. Containment
3. Eradication
4. Recovery

*It is important to note here that although these are considered discrete steps, they don't necessarily happen in order. When responding to a breach, an organization will move forward and backward along the incident response plan as things develop and new information comes to light.

But long before that happens, you need to get everybody in one room to ask the right questions in preparation.

Prepare

Preparing an effective response plan starts with asking the right questions, both about your organization and how an attack may play out. The answers to these questions lay the foundation for your response plan.

But preparation isn't done once you've documented your plan.

Taking the time to test the plan is essential. This allows you to find holes or potential failure points in your cyber resilience strategies so you can increase the efficacy of your plan before it's tested by malicious actors under more stressful conditions.

While it's possible to prepare your plan without help from outside organizations, including a third-party (like iON) that has experience dealing with breaches in real-time, will give you valuable insight into how breaches usually play out and how even the best plans can fall apart.

Questions to ask

• What is the key data we have to protect in our supply chain governance?
• What are the key applications we need to protect?
• What critical business processes must keep functioning during a disaster or during a cyber attack as part of your risk management strategy?
• Who are the best people to have authority for key decisions during an incident?

Identification

Detecting an incident sets off the response plan.

Ideally, you'll have someone monitoring your system continuously as part of your cyber security framework, so as soon as a breach is detected, it can be validated, and your response can begin. If you don't have the budget to have a 24/7 team in-house, you can get managed detection from a third party like iON.

Questions to ask

• Are all employees aware of what a cyber threat looks like, and how to report one?
• How can I find out if a report is valid and worth responding to?
• How do we define an incident?
• When should we declare an incident?
• How do we classify and prioritize incidents?

Containment

The main goal of this step is to mitigate and limit the activities of the attacker in your network.

That requires finding out:

• What the attacker has access to
• How the attacker might elevate their privileges or move laterally to other systems
• What the specific indicators of compromise look like for this specific incident, and if any other systems or networks exhibit these same indicators
• What capabilities we have for containing an active attack

Then, once that's better understood, your team will take the needed actions to stop their progress. That could mean taking a system offline, a user offline, or disconnecting from the internet entirely.

Questions to ask

• Do we have centralized logging to facilitate the needed visibility?
• Do we have the ability to query our systems to figure out if the indicators have shown up on any other system, any other network, any other location?

Eradication

As you contain the attacker, the goal turns to mitigating any damage done and eradicating any malware that may have been installed. Depending on your organization, that may look like cleaning systems, restoring from backups, or completely rebuilding an ecosystem.

To properly plan for this step, you'll want to develop a comprehensive business continuity and disaster recovery (BC/DR) plan that defines how critical systems will be failed-over or restored during major disruptions.

Questions to ask

• How is the root cause identified and verified before eradication begins?
• Has malware been fully removed from affected systems?
• How is evidence preserved to support post-incident review or legal action?
• Are backups tested regularly, and how quickly can they be restored?
• Are our backups immutable so that an attacker cannot destroy them?
• Is there an alternate site or environment for running essential operations if the primary site is offline?
• Who is responsible for BD/DR procedures during an incident?
• Are third parties like cloud providers, MSPs, or critical vendors included in recovery planning?

Recovery

After the incident has been dealt with, you'll move into the recovery phase of the incident response plan. During this phase, the focus is to resume normal operations.

Beyond the technical aspect, recovery also involves communicating with your clients to let them know what happened and how you are increasing your security going forward. (While we're including communication as a part of recovery, it is important to communicate with all stakeholders throughout the breach.)

For most breaches, this step dictates how both regulators and the public react to the incident. Organizations that clearly communicate what happened and their next steps face lower fines and less impact on their brand.

Questions to ask

When documenting your recovery plan

• Which systems and services are prioritized for restoration?
• What are the recovery time objectives (RTOs) for each critical asset?
• What are the recovery point objectives (RPOs) for critical data?
• How are restored systems to be validated prior to putting them back in production?
• Are there dependencies between systems that must be restored in a specific order?
• How will you verify that vulnerabilities exploited in the incident have been remediated?

After an incident

• How could we have done this differently?
• How could we have done this better?
• How can we improve each phase of our plan?

Continually improving your incident response plan

In incident response, no plan is ever finished.

After recovery, there are post-recovery steps to go through. When there are significant changes in your organization, the plan should be revisited to make sure it still applies. And, even if your organization stays the same, attackers are always developing new methods, so you'll need to revisit your plan regularly to ensure it makes sense as the world of cybersecurity changes.

These continuous changes should be addressed through:

• Lessons-learned exercises
• Going through any notes taken during an incident
• Going through all the pain points
• Seeing if any improvements can be made
• Tabletop exercises to mimic future breaches

Find resilience with a cybersecurity partner

Fast recovery requires constant vigilance. From reworking response plans to detecting breaches as soon as possible, readiness is the difference between limiting damage and losing data.

But not every organization has the budget or bandwidth to stay constantly vigilant.

At iON, we work with companies to expand their ability to stay engaged and aware of everything happening in the networks.

We offer:

• Managed detection and response
• Endpoint monitoring
• Automatic threat detection and response
• Centralized endpoint management
• Automated incident response
• DR services

This allows you to leverage our 24-hour team to take care of those early stages of incident response. So, if you face an incident at two in the morning on a Sunday when your team is sleeping, you still have someone there to detect it and start the incident response process.

That means, you may get woken up in the middle of the night with bad news, instead of being contacted in the early morning with disastrous news. But, it also may mean we contact you on Monday at 8:30, telling you we took care of an incident for you.