Notes from the Field - CIS Control 17 - Incident Response Management

The client I was working with had a SaaS application hosted in AWS. When we discussed how they would respond if their data were compromised, they said that wasn’t a serious concern as the data the company collected was of little value. Nobody would want it. It didn’t have personally identifiable information (PII), such as social security numbers, license numbers or medical information. When I raised the prospect of a ransomware attack and the damage it could do to their operations and reputation, they began to realize the potential consequences of their lack of preparation. Most companies understand that they could be the target of an attack. Some don’t. But all need incident response processes in place for when an incident occurs.

Castillo San Felipe del Morro, San Juan, Puerto Rico

In this post I discuss the Center for Internet Security Control 17 - Incident Response Management. The Center for Internet Security Controls are 18 critical information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks and data. The document contains high level information that executives can understand and also has specific details about tools and procedures for technical staff to run with. I recommend it to all my clients for information security guidance. 

The Overview for Control 17 is - Establish a program to develop and maintain an incident response capability (e.g., policies, plans, procedures, defined roles, training, and communications) to prepare, detect, and quickly respond to an attack.

Why is this Control Critical? Companies often don't have incident response and recovery capabilities even when they have detection and prevention controls in place. If such a company does have a compromise or other incident, they may not have people with the appropriate skills and experience to contain the incident and keep it from spreading. Without a full understanding of such attacks, incident responders will be in a perpetual state of being a step behind attackers. Even with a good plan and people, it's important that that regular training be provided to staff that will respond to incidents. 

Control 17 has 9 safeguards in support of incident response. They are: 

17.1 Designate Personnel to Manage Incident Handling

17.2 Establish and Maintain Contact Information for Reporting Security Incidents

17.3 Establish and Maintain an Enterprise Process for Reporting Incidents

17.4 Establish and Maintain an Incident Response Process

17.5 Assign Key Role and Responsibilities 

17.6 Define Mechanisms for Communicating During Incident Response

17.7 Conduct Routine Incident Response Exercises

17.8 Conduct Post-Incident Reviews

17.9 Establish and Maintain Security Incident Thresholds

Let's take a look at a few of these starting with 17.1 Designate Personnel to Manage Incident Handling. Smaller and mid-size companies I've worked with often don't have a dedicated Security Operations Center (SOC). Incident response falls to the DevOps or IT teams. But the roles are not formally assigned. The individuals who must respond often don't know they are responsible until there is an incident. Their regular duties don't include responding to incidents. When one happens they are unprepared to take appropriate action.  

17.4 Establish and Maintain an Incident Response Process and 17.5 Assign Key Roles and Responsibilities - you can combine these two safeguards and potentially the first five safeguards. This is where you document an incident response policy and process. You identify the specific roles and responsibilities for responding to incidents. Establish processes for how individuals will report incidents and the activities to respond.    

17.7 Conduct Routine Incident Response Exercises is key for all companies, particularly those without a SOC or other personnel who routinely respond to incidents. It's important for teams to engage in monthly or quarterly training to run through attack scenarios and how they would respond. Each team member would become more and more familiar with their role in incident response processes and what action to take. While not a replacement for actual experience, the individuals involved will understand what to do rather than try to figure it out during an actual incident. 

17.8 Conduct Post-Incident Reviews is where teams use lessons learned from an incident to determine how to improve their response procedures in advance of the next incident. What could they have done differently or would the response have been better if the tasks were performed in a different order? Did any steps slow down the response process? What controls can they put in place now to prevent or mitigate this same type of attack from occurring in the future?  What tools do they need to better respond? Agree among the team on next steps going forward, such as updating the incident response checklist or playbook. 

CIS Control 17 is a good way to get started with incident response management. In the next post, I will cover the final control, Center for Internet Security Control 18 - Penetration Testing.