A record number of digital attacks occurred in 2020. The FBI’s Cyber Division received as many as 4,000 complaints about digital attacks in one day early last year. That’s 400% higher than what the Cyber Division received the previous year. This growth in the volume of digital attacks underscores why you need to have an incident response plan in place.

That’s a whole lot of incidents to respond to …

The enterprise can only do so much to prevent malicious actors from breaking into networks. They need be able to detect, respond to and shut down an attack chain that’s in progress.

The whole purpose behind incident response is to minimize dwell time. That’s the amount of time between when an attacker gains a foothold in a network and when they’re discovered. The higher the dwell time, the greater the chances for attackers to explore an affected network. From there, they can move through it to business-critical assets and exfiltrate sensitive data.

The issue is that many groups still don’t have a formal incident response plan in place. In fact, 77% of respondents to a 2019 study did not have an incident response plan consistently applied across the enterprise. Less than half (46%) of those respondents test those plans often. This leaves their employers unprepared in the event of an incident.

Acknowledging those findings, it’s no surprise that the Cost of a Data Breach Report 2020 put the average dwell time at 280 days.

Laying the foundation of an incident response plan

Organizations of all sizes would benefit from crafting an incident response policy. The first thing they need to realize is that they don’t need to write something by themselves. The National Institute of Standards and Technology (NIST) along with others have already come up with guides containing incident response recommendations. You don’t need to follow every one of those guidelines. Instead, use those best practices as a starting place from which you can create a custom plan.

Using those and other frameworks for guidance, the enterprise can focus on aligning human resources. They can’t expect to fix incidents in a timely manner if no one in their ranks knows what they’re doing. Instead, they should take a moment to assign roles and responsibilities. Select someone to lead the response and make decisions, someone to lead the technical investigation of what happened, someone to keep critical business systems running, someone to communicate with staff and someone to communicate with stakeholders.

Those responsible for managing communications don’t need to improvise as they go, either. They can follow CompTIA and develop a media package ahead of time. Have social media posts, customer emails, communication schedules and other elements ready to go. By doing this, they can cut down on (or even counteract) any damage to the organization’s name suffered as a result of the breach. This helps to streamline the speed and efficiency of their response.

Incident response plan template

Concrete roles/responsibilities and an orchestrated communications strategy lay the foundations for the four pillars of incident response:

• Planning: In this stage, organizations actually create the processes that they need to coordinate their incident response steps.
• Detection: Detect a threat by monitoring for anomalies and suspicious activity.
• Recovery: Organizations need to analyze what they observed in the previous step in order to come up with a sound containment strategy. As part of this step, they’ll need to name affected systems, gather evidence and launch a response procedure.
• Post-Incident: After they’ve gone through all of the above-mentioned steps, organizations can then analyze the flow of their incident response plans. The purpose is to tell what worked and what didn’t so that they can make changes for next time.

To make the most out of these steps, organizations also need to identify when they’ll test their incident response plans and sticking to that timetable. The only way everyone involved will ultimately feel comfortable with what they need to do is by carrying out the plan in a test. This experience will help to highlight important changes organizations can make before they suffer their next security incident.

The benefits of testing don’t end there. If organizations run enough response drills to ransomware attacks, for instance, they’ll soon find that certain parts of the plan are always the same. Someone needs to prepare the backups; someone needs to wipe the affected systems; and, someone needs to ensure a disaster recovery process that reduces system downtime. Using those observations, organizations can craft playbooks that can help to speed up their response flows.

Making incident response planning second nature

No one incident response plan will work for two use cases. Just like everyone’s business goals are their own, so, too, are their security needs. Using the steps above, organizations can craft an incident response plan that upholds their needs. Remember, this also helps them to minimize attacker dwell time in a way that works for them.

With this preparatory work and plenty of testing, you will one day arrive at a point where your people don’t need to consult their incident response plans — or don’t need to look to them very often, at the very least. They know the drill. They know what they need to do. So, things just fall into place. The incident response plan becomes less of a written guide and more of a reflection of the organization’s inherent security culture. Everyone seamlessly works together and fulfills their obligations to recover from what happened and quickly resume business as usual.