CIS Control 17: Incident Response Management

We all know that it is a question of when you will be compromised and not if you will be compromised. It is unavoidable. The goal of CIS Control 17 is to ensure that you are set up for success when that inevitable breach occurs. If an organization is neither equipped nor prepared for that potential data breach, they are not likely to succeed in responding to the threat.

Key Takeaways

One takeaway from Control 17 is that it is not a standalone guide. CIS recommends using the control as a high-level overview but digging deeper into the topic using other guides. They specifically reference the Council of Registered Security Testers (CREST) Cyber Security Incident Response Guide. Another takeaway is that a plan is key. Even if that plan is simply to call a third party to perform the investigation, have it documented. More mature organizations with internal teams should engage in Red Team and Blue Team exercises.

The biggest takeaway from CIS Control 17 is that planning and communication are critical when responding to an incident. The longer an intruder has access to your network, the more time they’ve had to embed themselves into your systems. Communicating with everyone involved can help limit the duration between attack and clean-up.

Safeguards for Control 17

17.1) Designate Personnel to Manage Incident Handling

Description: Designate one key person and at least one backup who will manage the enterprise’s incident handling process. Management personnel are responsible for the coordination and documentation of incident response and recovery efforts. They can consist of employees internal to the enterprise, third-party vendors, or a hybrid approach. If using a third-party vendor, designate at least one person internal to the enterprise to oversee any third-party work. Review annually, or when significant enterprise changes occur, that could impact this Safeguard.

Notes: The security function associated with this Safeguard is Respond. This is a balancing act that can go either way. In some organizations, there will be hesitancy in dedicating resources to ensure your process is robust and complete. In other organizations, there will be a desire to over-allocate resources, preventing a plan of action from being formed and acted upon when needed. Follow this guidance and have that one key individual and a backup (or two) to support them.

17.2) Establish and Maintain Contact Information for Reporting Security Incidents

Description: Establish and maintain contact information for parties that need to be informed of security incidents. Contacts may include internal staff, third-party vendors, law enforcement, cyber insurance providers, relevant government agencies, Information Sharing and Analysis Center (ISAC) partners, or other stakeholders. Verify contacts annually to ensure that information is up-to-date.

Notes: The security function associated with this Safeguard is Govern. The last thing you want to do is scramble in the middle of a security incident. Whatever your internal documentation system may be, ensure that it has a clear, easy-to-find page with all of the contact information that could be needed. Use proper keywords and test with internal resources to ensure that whatever search words they think of will return the desired result. There’s nothing worse than getting lost in internal documentation when you need that critical piece of information.

17.3) Establish and Maintain an Enterprise Process for Reporting Incidents

Description: Establish and maintain an enterprise process for the workforce to report security incidents. The process includes reporting timeframe, personnel to report to, mechanism for reporting, and the minimum information to be reported. Ensure the process is publicly available to all of the workforce. Review annually, or when significant enterprise changes occur, that could impact this Safeguard.

Notes: The security function associated with this Safeguard is Govern. It is critical that when an incident occurs, everyone knows the workflow for reporting it. Everyone in the organization should understand that workflow and know who will inform whom. You don’t want critical executives learning about incidents via the news. Instead, an enterprise-wide process should ensure that everyone knows what they need to know.

17.4) Establish and Maintain an Incident Response Process

Description: Establish and maintain an incident response process that addresses roles and responsibilities, compliance requirements, and a communication plan. Review annually, or when significant enterprise changes occur, that could impact this Safeguard.

Notes: The security function associated with this Safeguard is Govern. Just as you need to know who to report to and when to report details, you need to know who is responsible for each step of the process. If everyone thinks that someone else is handling it, you’ll be stuck. The process needs to keep moving forward, and that means that everyone needs to be aware of their role.

17.5) Assign Key Roles and Responsibilities

Description: Assign key roles and responsibilities for incident response, including staff from legal, IT, information security, facilities, public relations, human resources, incident responders, and analysts, as applicable. Review annually, or when significant enterprise changes occur, that could impact this Safeguard.

Notes: The security function associated with this Safeguard is Respond. As mentioned in Safeguard 4, it is critical that everyone knows their role. While the process will outline this, it is important that everyone involved in the process has read it and understands their role and responsibilities. Ensure that those who need to know the process understand their involvement.

17.6) Define Mechanisms for Communicating During Incident Response

Description: Determine which primary and secondary mechanisms will be used to communicate and report during a security incident. Mechanisms can include phone calls, emails, or letters. Keep in mind that certain mechanisms, such as emails, can be affected during a security incident. Review annually, or when significant enterprise changes occur, that could impact this Safeguard.

Notes: The security function associated with this Safeguard is Respond. Just as important as knowing when to communicate and with whom to communicate is knowing how to communicate. If the incident has disrupted email, how will you share data? Do you have a messaging platform and an up-to-date phone number list? As more and more employees transition to working from home, it is critical that companies have a means to communicate regardless of critical system outages.

17.7) Conduct Routine Incident Response Exercises

Description: Plan and conduct routine incident response exercises and scenarios for key personnel involved in the incident response process to prepare for responding to real-world incidents. Exercises need to test communication channels, decision-making, and workflows. Conduct testing on an annual basis at a minimum.

Notes: The security function associated with this Safeguard is Recover. Once you have figured out the roles and responsibilities, communication means, timeline, and other critical information from the previous Safeguards, it is important to practice your response process. Just like a fire drill, it is important to work through the entire process. Don’t let anyone miss out on these exercises.

17.8) Conduct Post-Incident Reviews

Description: Conduct post-incident reviews. Post-incident reviews help prevent incident recurrence by identifying lessons learned and follow-up action.

Notes: The security function associated with this Safeguard is Recover. Retrospectives are a critical aspect of software development, and they are just as critical in incident response. Ask yourself what went well, what went poorly, and what you would change. If everyone involved in the process comes to a conversation ready to discuss those questions, you’ll have an agile, ever-evolving incident response process that improves with each incident.

17.9) Establish and Maintain Security Incident Thresholds

Description: Establish and maintain security incident thresholds, including differentiating between an incident and an event. Examples can include abnormal activity, security vulnerability, security weakness, data breaches, privacy incidents, etc. Review annually, or when significant enterprise changes occur, that could impact this Safeguard.

Notes: The security function associated with this Safeguard is Recover. Think of this as a rating system. Different incidents will have different impacts, and with each individual impact comes a different level of responsiveness. You don’t want to burn out on every incident by treating minor problems the same as critical ones, but you also don’t want to minimize critical security incidents. Setting thresholds that are well-defined and easily understood will make it easier for everyone to respond appropriately.

See how simple and effective security controls can create a framework that helps you to protect your organization and data from known cyber-attack vectors by downloading this guide.

Read more about the 18 CIS Controls here:

CIS Control 1: Inventory and Control of Enterprise Assets

CIS Control 2: Inventory and Control of Software Assets

CIS Control 3: Data Protection

CIS Control 4: Secure Configuration of Enterprise Assets and Software

CIS Control 5: Account Management

CIS Control 6: Access Control Management

CIS Control 7: Continuous Vulnerability Management

CIS Control 8: Audit Log Management

CIS Control 9: Email and Web Browser Protections

CIS Control 10: Malware Defenses

CIS Control 11: Data Recovery

CIS Control 12: Network Infrastructure Management

CIS Control 13: Network Monitoring and Defense

CIS Control 14: Security Awareness and Skill Training

CIS Control 15: Service Provider Management

CIS Control 16: Application Software Security

CIS Control 17: Incident Response Management

CIS Control: 18 Penetration Testing