While a lot of energy is put it into avoiding security breaches, they still happen. A solid incident response plan can limit damage, reduce recovery time and contain the associated costs.

Most IT Departments are firmly focused on prevention. We build systems and adopt tools to help safeguard against phishing attacks and ransomware and all the other myriad threats that businesses face on a daily basis. But what we often end up with is a mix of technologies that have not been integrated or configured properly.

The potential cost of a data breach drives rapid adoption of new software, but the frenzied firefighting approach has drawbacks. Before we can fully leverage the systems at our disposal, we must accept that incidents will occur and build a clear incident response plan that can be relied upon to guide us out of danger.

An incident response plan can provide a solid foundation for your future security efforts. Here’s how to get started.

  1. Assign clear responsibilities

Start with who should oversee the development of the incident response plan itself. Whether it’s the CIO or someone else, they’re going to need to inform all the relevant stakeholders, gather input, and assign roles. Central to this is the drafting of a security incident response team that will be responsible for detection, identification, notification, analysis, containment, eradication, documentation, and post incident recovery activities.

As the incident response plan is developed you may also need the participation of senior management, legal counsel, human resources, regulatory bodies, law enforcement, cyber consultants, and a public relations expert. There are many moving parts to coordinate if you want to ensure that incidents are dealt with swiftly and efficiently.

  1. Define your risk tolerance

Your IR plan is tailored to your organization. You must discover what is critical data, what key functionality your company requires to do business, and prioritize your efforts to focus them in the right places. False positives and alerts that are perceived as unimportant can lead to alert fatigue and that’s when things start getting ignored and slip through the cracks.

It’s important to be pragmatic here and identify, with the help of stakeholders, where the greatest risks for your business lie. Map out your critical functions and operations in full, including dependencies.

  1. Identify events

With roles and risks defined, you can move on to incident classification. When an incident develops, you need to be able to classify it, so that you know precisely what action to take.

A high-risk incident could result in critical systems becoming unusable or the loss of control over confidential information. A medium risk might denote the installation of malware that could lead to compromise. A low risk might be a prerequisite to a medium risk, such as someone failing to adhere to policy.

Classifying risks allows you to prioritize them. Each incident should also be fully documented, so you have a basis for investigation and audit should it be required in the future.

  1. Set explicit instructions

With a system in place to uncover and classify incidents, you can set clear procedures that enumerate in detail what every person involved in an incident should do. This starts with the rules on reporting, and includes everything from fixed time scales for investigation to the steps needed to remediate the problem. Having clear procedures in place removes room for confusion, doubt, or bad decision making.

Your procedures should spell out what needs to happen when a suspected incident is uncovered. After it is reported to the right people, the IR team can investigate and analyze the potential scope, including which accounts, devices, and systems have been compromised. Before it can be effectively contained, you must know how far it has spread. During this phase, it is vital to preserve potential evidence that might reveal the root cause of the incident and help you prevent a reoccurrence.

View the explicit instructions that you draft as part of your standard operating procedures as living documents. They are simply your best guess right now at how to uncover and contain an incident.

  1. Prioritize eradication and recovery

As part of working out your risk tolerance, you’ve identified critical systems. These critical systems that enable your business to run should be fully backed up, so you can get them up and running again swiftly. For the rest of your business functions, you need to perform a kind of triage to work out the right order for eradication and recovery.

It’s also very important to isolate the infected business units and make sure that stakeholders are kept in the loop on realistic recovery time. When it comes to restoring normal operations, bear in mind that you must know what a normal state looks like. If you haven’t documented that beforehand, then you may struggle at this stage.

  1. Learn from every incident

The incident response plan is not written in stone and every incident is a learning opportunity. Once it has been dealt with, confirm the root cause, analyze, document, measure, and retest. Assess the incident response procedure used and how it was carried out. This process enables you to make recommendations for better future response and prevention of a reoccurrence.

If you use incident analysis to find flaws or deficiencies in your detection, notification procedure, containment, eradication, or any other part of the process, then you can use that information to strengthen your incident response plan. It is a system for continuous improvement that will significantly boost your security over time.

Ultimately, security incidents are inevitable and beyond your control to an extent, but how you react to them is entirely up to you. Get started (248) 357 – 3980.