Why Every Organization Needs an Incident Response Plan

It's human nature to procrastinate, especially when people aren't quite sure of the right way to approach a task.

But when it comes to an incident response (IR) plan, the time to develop one is before a security breach occurs. Unfortunately, far too often it takes an incident to trigger planning.

And that, all security pros know, is far from ideal.

Why Do I Need an Incident Response Plan?
Having an IR plan in place is a critical part of a successful security program. Its purpose is to establish and test clear measures that an organization could and likely should take to reduce the impact of a breach from external and internal threats.

While not every attack can be prevented, an organization's IR stance should emphasize anticipation, agility, and adaptation, says Chris Morales, head of security analytics at Vectra.

"With a successful incident response program, damage can be mitigated or avoided altogether," Morales says. "Enterprise architecture and systems engineering must be based on the assumption that systems or components have either been compromised or contain undiscovered vulnerabilities that could lead to undetected compromises. Additionally, missions and business functions must continue to operate in the presence of compromise."

The capabilities of an IR program are often measured on the level of an organization's maturity, which defines how proactive an organization is. Companies that are able to map policies to the level of risk appropriate to the business are better prepared in the event of a security incident.

By way of example, Morales explains that the goal for a small business should be to reach a level of repeatable process, which includes having a maintained plan, concrete roles and responsibilities, lines of communication, and established response procedures. These are the necessary stepping stones that would allow it to appropriately address the bulk of incidents it would likely see.

"However, for organizations with highly valuable information with a high-risk level, a formal plan is not enough, and they need to be much more intelligence-driven and proactive in threat-hunting capabilities," Morales says.

Starting from Scratch
Many companies find themselves in the position of having to start writing their IR plans from scratch, as was once the case for Trish Dixon, vice president of IronNet's Cyber Operations Center (CyOC).

"It was an interesting dynamic to think that you can just jump right in and start writing an incident response plan when you haven't really taken into account the rest of your company's policies," Dixon says.

Without knowing a company's continuity plan, failovers, or its most critical systems, it's impossible to write an IR plan that understands the impact an incident will have.

If, for example, the most critical part of the business is its infrastructure, you can't have an effective IR plan without knowing how long it can be down before it starts costing the company money, Dixon says.

"From doing a business-impact analysis, it's a lot easier to start mapping out and designing your incident response framework around that," she says.

While there is no "right way" to design a plan, there are best practices, such as those set forth in the NIST framework, for creating and testing an optimal IR plan that will allow organizations to be more resilient in the event of a cyberattack.

At the very least, every organization should have a framework or concept down to understand the critical steps to take in the event of an incident.

"As you continue to evaluate your policies when you audit them, make sure the IR plan and policy are updated as well," Dixon advises. Reviewing a policy once annually is absolutely not enough.

Auditing the IR policy quarterly is in line with best practices, but Dixon says organizations have to test it almost on a daily basis.

"You may have an event come in that's not necessarily categorized as an incident," she says, "but you should always refer back to your incident response plan to be able to say, ‘Had this event been this type of incident, what would we have done?'"

Measuring IR Success
Testing IR daily creates a necessary and inquisitive mindset that habitually asks "if this had been X" in order to determine whether an incident is escalated and/or who to contact. Companies need to gain as much information as possible so as to act on the presence of attackers.

Being proactive allows organizations to better react with a deeper understanding of the threat actor's intentions and how the organization's defenses relate to potential threats. That's why threat awareness is one of the core metrics used to assess an organization's maturity and capabilities for IR success, Morales says.

Every detail and every event that happens can help defenders decide what to do in response to an incident so they are better positioned to quickly and sufficiently isolate, adapt, and return to normal business operations should they ever encounter a worst-case scenario.

A lot of organizations begin with an incident response framework, such as NIST's "Computer Security Incident Handling Guide," and use that as a guide for developing a unique IR plan specific to the company. But understanding who all of the players are is one of the most critical starting points when developing or updating an IR plan.

Indeed, people can get tunnel vision within their operations centers and forget they may need to involve the business section, sales, and IT, so those people are not written into the plan, Dixon says.

What's most important for organizations to keep in mind is that the IR plan needs to be applicable to their business.

"A framework is a framework. It's a recommendation for best practices. It's not meant to suggest that every situation is applicable to all organizations across the world," Dixon says. "People need to be comfortable with adjusting the frameworks to apply to their organization."

Related Content:

Image Source: TeraVector via Adobe Stock