Security threats continue to escalate. From advanced hacks engineered by nation-state actors to more prosaic attacks using “as-a-service” malware, organizations face a constant barrage of threats to their IT infrastructure and data. 

Hackers continue to shift their strategies as they find new vulnerabilities.

Most organizations recognize that they can’t just wait for a security incident to happen. They’re taking a proactive approach by implementing a suite of security controls throughout the IT environment. Given the immense cost and business disruption of a data breach, organizations continue to make significant security investments to reduce the risk of zero-day exploits, ransomware and other threats.

It's simply not enough.

There’s no way to block every threat or predict what the next attack will look like. Even with state-of-the-art security tools, organizations should assume that a breach is a matter of “when” not “if.” And they need to be prepared to respond to that breach as quickly as possible to protect systems and data and maintain business continuity.

That’s why an incident response plan is a critical part of any security strategy. Organizations with higher levels of security maturity have a written and tested plan to help guide their response efforts.

Laying the Foundation

An incident response plan outlines the steps the organization will take to minimize the damage and disruption of a security breach. More than an IT discipline, it will require input and buy-in from executive management, human resources, public relations and legal teams.

The first step is to make someone the owner of the plan. That person will assign roles and responsibilities, delegate specific tasks and facilitate communication among everyone involved.

One of the most important tasks is to define the level of risk that’s acceptable to the business. This will be based on financial, legal, compliance and other considerations. Then the incident response team should identify and prioritize business functions to focus efforts on systems and processes critical to operations. How much downtime and data loss are acceptable for each function? If multiple systems and processes are affected, in what order should they be restored?

Organizations should also classify incidents based upon the level of risk. That will depend, in part, on the business function involved and the potential threat posed by the incident. A user clicking on a malicious link that is blocked might be considered a low-risk incident, with additional security training as an appropriate response. An insider threat involving mission-critical systems would be a high-risk incident.

Developing Procedures

Once the foundation has been laid, the incident response team can begin determining the steps that need to be taken for each type of incident. There should be a protocol for reporting the incident to the individuals assigned to investigate it. Those individuals should take action based upon the established procedures and timeline. Detailed procedures help ensure that appropriate decisions are made with less confusion.

Threats should be isolated quickly to minimize spread to other systems and devices. Log files, alerts and other data should be analyzed to determine the origin, intent and scope of the threat. If data is lost or corrupted, the incident response team should know how to restore from backups quickly.

An incident response plan is a critical part of any security strategy.

One of the most important steps is assessment of the response after the incident has been remediated. Every incident should be treated as a learning experience. If the response did not go as quickly or as well as planned, the strategy should be revised and optimized.

GDS follows well-established incident response procedures when we help customers identify and contain threats. We also help organizations establish their own in-house procedures. Contact us today to get a plan in place before the inevitable happens.