The most critical phase of an incident response process is recovery. Every minute business is disrupted by a cybersecurity incident, there is signifcant cost placed on the organization. A quick recovery response can help limit costs making recovery the absolute goal of responding to an incident.

Organizations cannot skip critical steps in the investigation and response process, so where do you start? How can your team get to recovery and get back to business as fast as possible? Read on!

Cyber Security Best Practices and Preventing Future Incidents

If an ounce of prevention is worth a pound of cure, an incident response (IR) plan is worth a metric ton of value. As you focus on protections to prevent attempted attacks and limit the damage of successful attacks, prepare for what happens when they fail. Hyper-focusing on prevention puts your team at the risk of leaving your business unprepared when a cybersecurity incident occurs. Prevention will inevitably fail, and the cure is to have a get-well plan to get back to business. A get-well plan is an important piece of your company’s incident response strategy.

Having an IR plan does not mean that solid practices such as strong authentication and multi-factor authentication are no longer important for protecting against unauthorized access and initial access break-ins. Do not ignore vulnerabilities nor neglect aging systems because vulnerability management can reduce your attack surface and limit the exposures attackers seek to exploit. Segmentation and increased friction to make lateral movement within the organization networks difficult for attackers can likewise be key in limiting attacks and data breaches. Lastly, you should ensure your users are wary of all messaging attacks and scams. Protect privileged access and work to create an aware staff, who is prepared and trained to avoid attacks. This preparation is vital, as phishing attacks are utilized at a high rate in cybersecurity attacks and often involves law enforcement.

Your list of valuable protections that can specifically and directly address aspects of threats and tactics commonly used in the most prevalent attacks could be best practices. The list is not exhaustive and should be considered a priority within the implementation of capabilities in a comprehensive cybersecurity program. Capabilities that enable the identification of threats against key assets and valuable data while overall seeking to manage ongoing technology risks are cornerstones of all cybersecurity programs. Backstops to protection and prevention are capabilities that enable the detection of attacks and rapid response to contain and reduce harm if attackers succeed in targeting the organization’s systems or users. Along with all these capabilities, the safety net for ensuring the organization can survive a cybersecurity attack is the incident response plan. A high-performing response capability can be the real difference maker.

Incident Response and Getting Back to Business

In our previous article Incident Response Preparation: Fortune Favors the Prepared, we covered the fundamental aspects of the incident response plan using 5 phases that include preparation, identification, containment, eradication and recovery. Much of that article focused on the importance of preparations with tips on improvements that should be considered in all the phases. To draw a focus on several key objectives of a successful response effort, let’s consider desired outcomes that make up the goals of incident response.

Containment goals after a cyber threat

At its core, containment is about cutting off the attackers. Old school virus infection attacks looked at containment as isolation of infected computers. By labelling encryption and extortion attacks as “ransomware,” we have overly narrowed the attack to the effects of the encryption software and the view that ransomware might be treated similarly to viruses and other malware. Do not fall victim to this viewpoint when considering how to respond to and contain the most prevalent attacks.

The most significant incidents are the equivalent of detonation events with a catastrophic blast radius that leave the organization’s technology environment destroyed. At a minimum, the network and systems will be tainted or damaged to a degree that rebuilding may be the best option.

At times, incidents are an investigation of something that has happened in the past after many days or months have elapsed since the attackers entered and did harm, and often include law enforcement. Containment in these cases will not be as urgent and in other cases may have been achieved through changes or updates made to the environment already. Stealthy data theft attacks and other attacks that may involve corporate or state espionage can fall into this state as well and require quick actions to eject the attackers from your systems. Containment actions may include taking the organization offline from the internet or blocking off the attackers using aggressive and disruptive measures.

Initial detection and forensic analysis go hand-in-hand with containment so that you can determine what will effectively cut off the attackers and allow you to regain control of your environment. The clock is ticking, and your ability to fully investigate and understand how the attackers gained initial entry, and continue to have ongoing access, may be limited to the information that led to detection. The desire to preserve evidence and retain normal business operations must be weighed against the benefits of limiting the damage. Gaming these types of decisions can be an important aspect of tabletop exercises and is always better before you are under the proverbial gun. In some incidents, the early detection stages are a struggle to regain or retain control of administrator credentials and maintain the confidentiality and privacy of data. Quick actions can be the difference between winning or losing the fight for control. At times, this can be the difference between an outage lasting a few hours, to an incident event that costs millions of dollars with months of business disruption, lost customer trust, and for some, even more catastrophic results.

The goals of containment are to stop the bleeding and stabilize the environment so that a proper investigation can be conducted within the security incident response process. Containment can be measured in terms of effectiveness and the time it takes to accomplish. Ultimately, containment must occur before you can begin trying to achieve investigation goals.

Investigation goals for your security incident response

Fundamental to the investigation are several outcomes that are necessary to consider the response effort successful. During the identification phase, it is very important to understand how attackers achieved success in their attack and defeated or otherwise circumvented protections. If the entry point or hole used to gain access is not found, then attackers can reenter, or new adversaries can pile on with additional attacks. Gathering evidence and evaluating the trail left by attackers to learn about the initial attack activities is vital and can be complicated exponentially when the attackers remain active within the network. This process can be time-consuming and requires forensic expertise and a deep understanding of the attackers’ tactics.

Confirm you have access to extensive forensic capacity to analyze systems at scale. Consider that a priority of your time be reserved for evaluating systems showing the clearest indications of being part of the initial or recurring entry to the environment. Utilize resources that are part of your cybersecurity insurance coverage to perform the investigation. These resources have closely aligned goals associated with determining how the attackers gained access or the root cause, however, the urgency they exhibit may not be aligned with your business needs and the pace you need for your overall response efforts. You may consider employing multiple teams or making sure that the firm that you are using can go at your speed. These steps may seem duplicative or expensive, but these costs may be small compared to lost revenue and damage caused by the attack.

Similar to the, “know how they got in” goal is the, “What did they do once they were in?” goal. Knowing what systems were used to traverse the environment, potentially exploited to gain access to data, and then used to exfiltrate data all contribute to understanding the impact of the incident. An incident investigation is crucial to answer these questions. The true scope of the damage is needed to determine what was harmed and what will need to be done to repair and regain the trust of tainted systems. It is imperative to know if confidential data has been accessed, privacy violated, or if valuable trade secrets have been stolen. These factors are considerations for notifications and disclosures associated with regulated data or potential harm to partners, stakeholders and customers.

Steps cannot be skipped and shortcuts in the investigation process cannot be taken if there is a trade-off between thoroughness and completeness. Answers to the questions, “How did they get in?” and “What did they do?” are needed to achieve success in your response efforts. So, it’s important to consider how we can meet the investigation goals while also moving forward on recovery efforts.

Recovery goals after a cyber attack

The goal of recovery is to securely get back to business. If you’ve been involved with any incident that has caused disruption, you will be very familiar with the “When can we get back to business?” question. This applies to just about any IT event or incident, not just cybersecurity attacks and. The “Are we there yet?” question is always tricky. It is ultimately what incident response must achieve and is the million-dollar question.

I’m not able to tell you what the answer to this question is, as each situation is unique. I can help you put things in place to provide a better answer than, “We don’t know yet.”

Let’s start with the premise that a significant incident may likely be the most intense, in-depth IT project you will ever participate in. And while intense, and loaded with unknowns and uncertainty, there is a silver lining. You work on IT projects throughout your career and have successfully led some pretty big ones, so you’ve got this. Let’s put incident response recovery into project mode and get back to business. Here’s how!

List and track what needs to be completed by your incident responders. The list will grow, and the project plan will evolve quickly. Start tracking these as a project. Begin thinking about parallel paths – lots of them. Make sure you are working to resource all of them, prioritizing many as the most important. This is not the time to think about limitations. It is time to think about how to work the problem and identify what you need to overcome any, and all obstacles. Add whatever resources are needed, or anything that can lead to more resources, to your playbook. Partners, providers, suppliers, and vendors have much to offer, and you may need it all.

Do not overlook the investigation functions and security operations. I am not advocating you skip or even rush the investigation while you jump to recovery. Treat the investigation as a high-priority, parallel project path. Resource it to the level it does not delay the critical path, and then do not delay getting recovery functions underway while the investigation continues.

More on how to get back to normal operations faster and smarter:

• Concurrent IR phases – Get the investigation and recovery tracks onto parallel, not serial paths, as soon as possible. This action may mean getting multiple response commanders deputized; establish the command structure for each function of the project plan.
• COOPs – Make sure business can function when plan A is no longer available using Continuity of Operations Plans. These plans are not Disaster Recovery functions that rely on IT to rebuild. They are the potentially manual methods of doing business when the primary technologies are not available. It is best to have these plans assembled before an event, but when all else fails, COOPs can be put back together by the business while the IT and security teams do their response work.
• Containment must hold – Safe and secure recovery means that you cannot bring any part of the business back up on tainted, damaged or unclean/affected systems. The goals of containment are important parts of ensuring that incident response can be aligned with business goals without jeopardizing security during the recovery process. Containment does not have to hold up movement on recovery tasks.
• Prioritize by business process – Some recovery may need to be completed on new systems in new environments. Architecting a completely new environment is a huge undertaking, but it may be the quicker path for some functions. You will need to game this out as part of your Disaster Recovery Plan with your incident management team before you experience an incident. Recovery may sound expensive, it is. Balance what is recovered in a new environment by business impact. The associated costs may be worth it.

All of these tips and steps will not help you answer the question of when business will be back to normal. They will help you communicate what remains to be done, what you need to do to get there, and how to complete tasks right away in order to speak directly to distinct business functions in real-time. The recovery project plan will help ensure resources are prioritized, maximized and utilized to the fullest extent possible in order to accomplish the goal of getting back to business.

Building on the fundamentals and making improvements to your security posture

Any incident response plan would not be complete without taking advantage of every opportunity to improve. Evaluating areas where the incident response team was effective, the positives of your risk management, plus where it can be better, will always help the response process go faster. The lessons learned at every stage of the response can provide an advantage for the team in future events.

Additionally, evaluating what security controls or security tools failed and how those controls need to be improved for different types of incidents should be baked into the recovery plan. This action has the benefit of taking advantage of the momentum that the effective incident response provides as well as defeating any of the arguments that changes to security may impact the business poorly. The business has already been negatively impacted and may still be at a standstill.

Be prudent, and wise and focus on the controls that will directly prevent future incidents/future attacks or provide benefits to detection of security threats or slowing down the attackers and malicious activity. Implementing security improvements may be necessary to fully eradicate the threats and security breaches that were part of the attack. Putting vulnerable systems back in place will certainly lead to future successful attacks. There are few things worse than a significant cybersecurity incident, but one is dealing with multiple additional attacks while you are trying to recover from the initial incident. Another is restoring the environment just to put the vulnerabilities back in place to get hit again.

Pay particular attention to details like how the attack was first detected, by whom, and by which method. Consider if there were preludes to the attack that were missed and what, if anything, could have raised the alarm earlier. When you are reliant only on your security protection technologies to provide your detections then the attacks that those technologies don’t prevent are only detected when damage is done.

Improvements to detections may be difficult to identify, so consider having a thorough post-mortem review by an independent party with an assessment of your potential blind spots and a review of your risk communication plan. Having a Monday morning quarterback critique of not only the response process but also the early-stage detections is something that many mature industries do. Reviews of response after natural disasters by the Federal Emergency Management Agency, transportation incidents by the National Transportation Safety Board, and similar review boards are part of a process that seeks to make sure that bad things such as data loss only happen once and if they can be avoided in the future.

How can GDT help prevent cybersecurity incidents in your company?

Using this article and the previous article on incident response preparation, there are a lot of suggested activities and steps to take to move forward. If you feel overwhelmed about where to start, the team here at GDT can help you and your team prepare for an incident or make sure you are on track for success.

Our team of expert consultants has worked on the preparations, response engagements, and recovery projects and are here to help. Contact us before an incident happens to prepare. Do not hesitate to reach out if you have a cybersecurity attack or experience a computer security incident. That is why we are here!