Are You Prepared for a Security Incident? Here Are 6 Steps to Help You Be Ready

Responding to a cybersecurity incident, whether it’s a data breach, a ransomware event, or one of several types of cyberattacks, such as malware, denial of service, SQL injection, or zero-day exploit, can dramatically compromise an organization’s routine business operations. 

These incidents can shatter public confidence, erode brand value and take a big chunk out of top-line revenue. 

In this blog, I explain a framework that organizations can adopt to improve and fine-tune their incident response capabilities. 

It’s a six-step framework known as PICERL: Prepare, Identify, Contain, Eradicate, Recover and Lessons Learned.

Step 1. Prepare

Preparation ensures the right people from the right teams are involved and understand what their role is and what they need to do when an incident occurs. 

The prepare phase should generate a plan that incident response (IR) team members can practice against. Most organizations do this with their backup and data recovery (DR) procedures. IR plans should be rehearsed in the same way so that any weaknesses in the plan can be addressed. Mock IR drills give confidence to team members, so they can execute under the pressure of a real incident.

I like to ask customers if their IR team has participated in a mock drill and understood what their roles were. Other questions I ask are:

• Who notifies the public relations (PR) team?
• Who notifies legal?
• Who notifies finance?

The preparation phase is also where you determine whether you have the right tools. If not, do you have the funding you need to procure them and provide training for team members? These are the kinds of details that need to be ironed out. It’s also important that once an IR plan has been created that it’s reviewed and approved by senior leadership, including a budget to support the plan.

Gamification

There are gamified approaches to testing and practicing an IR plan that don’t require a full-bore test with all hands on deck. The companies I see that are really successful are the ones that have started to gamify testing and preparing their IR plan. For example, offering awards for the team that does the best job of finding the phishing email. Or follows through on their checklist plan in the quickest and clearest way. Gamification is particularly helpful for the entry-level security professional.

Making sure people know what to do reduces the chance of panic. It gives people a sense of purpose.

Step 2. Identify

Once you’ve determined you have an incident, the identify phase is where you start trying to answer questions like:

• When did it start, and how did it occur: stolen password or asset, phishing email, malicious code from a portable drive?
• What was the point of entry? Was it an unpatched vulnerability?
• Who found it, and how did we find it?
• Do we know the scope? Is it confined to one or two individuals or assets, or is it widespread?
• Can we continue to do business? Will whatever steps we take affect one of our lines of business?

Very often, compromised credentials are the point of entry. And from there, an incident escalates, and the bad actors take advantage of any opportunities they find in your environment.

I was once part of a team that did security assessments. One of the more common ways to launch a breach was to find out what brand of thumb drive the IT team handed out to their employees. 

You could create a drive with malicious code and drop it in the parking lot. Inevitably someone would pick it up and put it in their computer, usually trying to find out who’d lost it. That’s all it takes.

Often compromised credentials are the point of entry. And from there, bad actors take advantage of any opportunities they find in your environment.

Step 3. Contain

Once an incident has been declared, containment is about executing your plan to prevent the unwanted behavior from spreading. 

A short-term containment strategy could be something as simple as issuing a quarantine command to keep an asset, application, or system from communicating with anything except a security tool.

Long-term containment is a fix that is implemented enterprise-wide but could be considered short of complete remediation of a root cause of the incident. This would be a tactic for assisting law enforcement or regulatory agencies. 

It’s a good idea to have long-term containment strategies connected to your data backup and recovery systems.

Patches and updates are also part of containment. Do you have unpatched vulnerabilities that are related to an incident? If so, it’s time to accelerate the patch schedule for the software in question — application or operating system. 

This is also a good time to revisit which users have administrative access and to what systems. What is your attack surface relative to Active Directory? Have you enabled multi-factor authentication? These are all issues relevant to containment.

Long-term containment is a fix that is implemented enterprise-wide but could be considered short of complete remediation of a root cause of the incident.

Mean time to remediate

Mean time to remediate is how long it takes to move through the identification, containment and eradication phases of your IR plan. In 2018, the Verizon data breach report found a mean time to remediate in the range of 14 to 30 days for high-performing organizations. But there’s a strong trend among security professionals to lower that number as IR plans mature and teams become better at practicing their IR plans.

Step 4. Eradicate

Now you’re trying to eliminate the cause of the breach — root and branch, as they say. What does that mean? It means, for instance, in the case of malware that you’ve found and securely removed every instance of it you have been able to identify. You’ve hardened and patched systems where applicable. You’ve reimaged systems that you can’t harden. You’ve updated your threat intelligence to make sure you can identify artifacts related to the breach.

While the process unfolds, it may change the scope of your efforts. After a ransomware attack, for example, you may have a lot of systems that need to be reimaged and restored from their last known good backup. And if you don’t catch all the artifacts related to the attack or you haven’t addressed the vulnerability exploited to get in, you could be attacked again.

The key to eradication is thoroughness. Did you find it all — whatever “it” is — being the ultimate question. Often a partner or third party with specialized expertise can help with the cleanup.

Step 5. Recover

Moving from eradication to recovery reminds me of coming out of surgery. The damage has been done; now it’s time to focus on healing. From an incident response perspective, it’s time to be very honest with yourself. When can you return the affected systems to production? Have you patched, hardened and tested them? Have you used your internal red team to run a simulated attack against these systems using the same techniques as the attackers? You want to be able to say, “We addressed the vulnerabilities, and here’s our proof.”

Recovery also means defining how you will change the scope of your monitoring in the wake of the incident. How long will you monitor for the activity that caused the breach: 30 days, three months, six months? And precisely what are you looking for? The red team tests will help here, and so will the artifacts collected during containment.

Recovery is measured by how fast you are able to return impacted systems and processes back to a pre-breach state of functionality.

During recovery, you must be very honest with yourself.

Step 6. Lessons Learned

This step should begin with an after-action meeting that includes everyone who was part of the incident response team. That means everyone: IT, compliance, legal, PR, etc. This is where you have the opportunity to review and document what you learned about the breach.

• What part of your IR plan worked well? What didn’t?
• Were there gaps where additional people were needed? Did we need to reach out to a third party or an internal team, not on our list of resources?
• Based on the incident, do we need to change how we operate? Were we using the tools we had effectively? Were they configured properly?
• How was communication among teams? Could it be improved?
• Was there an employee aspect to the breach, such as a phishing attack or improper data handling? Can this be addressed with training?
• Was the vulnerability exploited unique to a line of business or endemic across the organization? Could we address the vulnerability with a different operational structure or process?

The more flexible the IR plan, the more you’ll learn from a breach when it occurs. And everything you learn should feed back into your preparation phase, which can always be refined and improved.

An after-action meeting should include everyone who was part of the incident response team.

For more information on the Tanium Incident Response solution, read my previous blog post 7 Ways Tanium Can Protect Your Organization From Evolving Cyberthreats and Data Breaches. 

If you’re ready to see it in action, sign up for a demo today.