So you’ve found a cyberattack in your environment. The first step is to not panic. The second step is to pull out your cybersecurity response plan, which you’ve hopefully written down during a non-stressful time well before the incident. If you don’t have that plan documented yet, bookmark this page and go find a reputable incident response service provider to help you out. When you return, we’ll discuss what you should do to prepare yourself for a cyber security incident response.
Due to your efforts to protect yourself in the third phase of the NIST Cybersecurity Framework — “Detect” — you now know you have a cybersecurity incident on your hands. If you haven’t yet read our first three CyberSecurity Awareness Month posts, which highlight the functions of the NIST CyberSecurity Framework, you can find them here (Identify, Protect, and Detect). Today, we tackle the start of the fourth stage — “Respond” — perhaps the most panic-prone stage. The adrenaline involved in responding to a cyberattack is why planning is critical in this phase.
Time is of the essence when fighting back a cyberattack, so figuring out what to do during the attack is not ideal. The plan should be figured out ahead of time and practiced regularly so everyone knows their role during the event. Of course, no plan survives engagement with the enemy, but that is no reason to not have a plan; it’s a reason to have multiple flexible plans focused on what needs to happen. Ultimately, your reaction should be second-nature so your brain can concentrate on analyzing data, not deciding what needs to happen next.
Blue Team … Assemble
One of the most important parts of your incident response plan is to identify the team that needs to be involved. This team should include not only internal employees, but also any external support, including vendor support contacts and third-party incident response, legal, and/or cyber forensics teams. Beyond identifying individuals and teams, the plan should include how everyone will be contacted, which is commonly done via call sheets, notification trees, and group messaging. It should also identify how all the team members will get together and coordinate, which should include both in-person or virtual options.
Through all this planning, consider what technologies and systems you will be able to rely on during a security breach. For example, if your email server has been breached and you need to isolate it on the network, you will not be able to rely on it to send communications. Also, think of interdependencies that may be compromised. For example, if your Active Directory gets shut down with ransomware, collaboration tools like Teams may not be reliable for collaboration. Once the team is assembled, it’s time to start addressing the incident.
Stop the Spread
Ideally, while you’ve been assembling, the systems have automatically started the response. Your primary tool here is an endpoint detect and response (EDR) product, which likely also participated in the detection of the intruder and was able to immediately execute the first priority: Stop the spread. By running on endpoints in your environment, EDR is able to directly detect anomalous program executions and block them as soon as it determines something nefarious is going on.
If the EDR tool couldn’t detect the anomalous behavior before it executed, it may be able to cut the system off from the network so that it cannot spread, receive instructions from command and control systems, and participate in data exfiltration. Partnering an EDR tool with managed services (MDR) or extended with technologies like SIEM and SOAR (XDR), can improve the speed in which the breach can be contained.
Unfortunately, the spread cannot always be contained. This is where having an infrastructure based on zero-trust architecture in place before an attack can be a huge asset by limiting horizontal spread. In a worst-case scenario, you may have to disconnect the entire infrastructure from the internet or shut down the entire data center.
Cleaning Up
However drastic the containment efforts may need to be, you’ll then need to focus on cleaning out the infection. This may be a system-by-system hunt, but is ultimately highly dependent on the type of infection and is why flexibility in the plan is important. Consider having an incident response team contracted and on-call to help with this effort.
If it has already spread widely or it required a full data center shutdown, you may benefit from simply failing over the data center to your disaster recovery site. Cybersecurity incident response should closely align with, or simply be a special use case within, your business continuity and disaster recovery (BC/DR) plan. But we’re getting a bit ahead of ourselves, because this is part of the fifth phase. More on that in the next post in the series.
Incident Communications
In parallel with all of this, your organization will need to have a plan for communicating with your key stakeholders. You don’t want to leave key decisions around how and what you will communicate to employees, customers, partners, suppliers, legal counsel, law enforcement, and, possibly, the media until you’re in the heat of the moment. Understanding what different audiences need to hear and when may require coordinating with them during the planning phase. Understanding what legal reporting requirements you need to abide by will definitely need to be known ahead of time.
Decisions around how often and at what depth you need to communicate will need to be defined and differences based on the audience considered. The key is to communicate early so you don’t get caught letting someone else tell your customers and partners what’s going on. Finally, just like communications amongst the response team, don’t assume any given communications channel will be available. Have multiple ways to communicate to these groups.
Digital Forensics
To close out the Respond phase, you’ll need to address the analysis of the incident. Some of this happens as you go along, but every incident should end with an analysis of what happened, the timeline, ramifications, and what can be done to prevent it in the future. In order to preserve and gather as much data as possible, the identification of key data should be in your plan. This will allow the entire team to gather the data you need to satisfy contractual, legal, and self-improvement obligations. Even if this data isn’t collected along the way, your team needs to make sure it isn’t destroyed as part of the mitigation efforts. Many companies choose to rely on an external digital forensics team to help with this planning and data gathering.
As you can see, there is a lot to be dealt with in a very fast, fluid, and high-pressure situation. Having tools like EDR and response plans in place before an incident occurs are critical to successfully navigating these items.
