Measuring Your Incident Response Program
Measuring Your Incident Response Program

Your company has done its homework and put a strong incident response plan in place. Great work. Time to move on until a crisis manifests and you need to “pull it off the shelf” right? 

Unfortunately, the real work has just begun. Your company must constantly improve and test the effectiveness of its incident response program from a people, process, and technology perspective.

Test Your Processes

The first way to measure your incident response plan's effectiveness is to perform tabletop exercises, which are designed to simulate a real-world cyberattack emergency situation. This is the best way to stress test your process in a simulated environment, and will give you confidence in your organization's ability to react to a security incident in a coordinated way.

Start simple. Gather select team members to talk through a simulated situation and then test the incident response plan. When creating the situation, begin with a realistic high-risk scenario. What really scares you as an organization? How would you respond to this threat if it became a reality? Let's say you're most concerned with email as an attack vector because of ransomware and phishing attacks. If an employee in accounting opens a phishing email, how would the organization respond? Could you contain and subsequently address the corresponding threat?

•     Expand the scope. Your second test should extend beyond your organization's technical teams to see how information is flowing. Remember that security is a component of IT, which is a facet of the organization as a whole. It's how these components work together in the moment of truth that matters. Any roadblocks encountered as you move through the process should be noted. Once the tabletop exercise is over, you can then return to your team to update your processes to remove these roadblocks. The desired outcome is to quickly determine the right course of action. One example of preparation from other departments would be communications creating a message ready for fast dissemination on corporate social media. This message would inform the public of the risk to them, the business impact, and the remediation steps being taken to ensure the least damage. This way, no one is developing content while a security incident is unraveling, thus costing the organization unnecessary time.

•     Implement a red team vs. blue team scenario. A well-trained red team can find weaknesses by actively exploiting vulnerabilities that may exist in your organization. A red team can also identify gaps in your team's visibility to events that may be happening across your systems. In short, they can show where the incident response plan can be more robust. The blue team are your defenders; they will be focused on identifying and then eradicating threats to the environment. Their goal during the exercise will be to measure how long it takes to detect an attack being performed by the red team, and then to take the appropriate next step. The blue team needs to actively work to stop the red team from wreaking more havoc. Both teams can be supplemented by internal team members or by a third-party vendor. A third-party vendor can also assess the maturity of the incident response plan and then advise on improving current documentation. Finally, repeat testing is necessary to verify that the issues identified have been remediated.

Test Your People

Every day, your IT and security team members are monitoring networks, reviewing firewalls, and keeping an eye on vulnerability management. They are responsible for ensuring the continuation of business operations, and obviously need to know what to do when they see that an event has happened or is happening.

But what about all of your other employees? How many of them can correctly answer who they should contact if they see questionable activity occurring on a network, etc.?

If you have a remarkably wide margin between total employees and those who can accurately indicate the right process to communicate security events, revisit your incident response plans and end-user IT policies to address undetected gaps in your administrative controls.

In most situations, people will contact their immediate supervisor. While this might be the policy in some organizations, it unfortunately delays remediation and could impact containment time. Having a standard and centralized point of contact for all users will ensure that your incident response is built on a process – and not people who may not react.

Test Your Technology

Don't be deceived into a false sense of confidence by service-level agreements (SLAs). They can often be misleading when related to security incidents. Some organizations typically have a set metric stating, “incidents will be resolved in X number of minutes,” but does that metric accurately reflect every variation of an incident? For example, there will likely be a different reaction to malware found on a recruiting employee's computer versus malware on the CEO's computer.

Creating a timeline of events is an effective tool for tracking response time for each incident. For example, pinpoint exactly when an employee from HR rep contacted IT. What was the timeline of that action being communicated with that person to another employee? Was proper action taken by the proper person? Work on constant improvement; the quicker your response becomes, the better.

Think of it like putting out a fire. You wouldn't want the fire to go on for hours before calling 911. Of course, a security fire is only metaphorical, but its effects can be just as devastating. According to the Aberdeen Group, the average cost for an hour of downtime is approximately $110,000. Failure to respond quickly isn't cheap, nor should it be an option.