logo

CIS Control 17. Incident Response Management

The Center for Internet Security (CIS) offers Critical Security Controls (CSCs) that help organizations improve cybersecurity. CIS CSC 17 covers incident response and management. (In earlier versions of the CIS controls, handling of security incidents was covered in Control 19.)

CIS CSC 17 focuses on how to develop a plan for responding to attacks and other security incidents, including the importance of defining clear roles for those responsible for the various tasks involved.

The recommendations help improve response capability. However, enterprises can also use the Council of Registered Security Testers (CREST) Cybersecurity Incident Response Guide for a better security plan and incident response.

Before delving into the safeguards of incident response and management control, it’s essential to understand what may qualify as an incident.

Security events and security incidents: What is the difference?

A security event and a security incident are two different things in the language of information security. Security incidents typically result from security events that have not been handled in time. For instance, an improper change to the configuration of an access control, such as a GPO or a security group, is a security event. When a hacker exploits that configuration change to steal data from information systems, that is a security incident. Incidents occur far less frequently than events and can be far more damaging. Simplistically, an incident is an event with damaging consequences.

For effective incident response management, a designated team should create a detailed response plan for all known security incidents, including designated personnel and recovery capabilities, Having a solid plan helps address security issues like data integrity as well as compliance with data protection mandates and other regulations.

Here are the nine safeguards of the CIS incident response control:

17.1. Designate Personnel to Manage Incident Handling

This safeguard suggests designating a primary contact and a backup to manage the incident-handling process, including coordinating and documenting incident response and recovery efforts. This designation should be reviewed annually and whenever significant changes impact security.

The key contact may be an employee within the company or a third-party vendor. Both approaches have their pros and cons. Having an employee as the key manager ensures that response management stays within the organization, but, depending on the size of the organization, the undertaking can be too much for one employee. A third party specializing in security management may better handle a security incident. If a third party is designated for risk assessment and incident response, the safeguard recommends having at least one person within the organization to provide oversight.

17.2. Establish and Maintain Contact Information for Reporting Security Incidents

It’s important to maintain accurate contact information for all parties who should receive information about security incidents. The contact details of these parties should be easy and quickly accessible. The list can be ordered based on priority.

The list generally includes those accountable for response management and those with the power to make significant decisions. An incident response team may also need to inform law enforcement, partner vendors, cyber insurance providers or the public.

There should be mechanisms in place to contact and inform relevant parties about an incident promptly. Automating the incident notification process can help.

The contact information should be updated once a year or more frequently to ensure the notifications reach all relevant parties.

17.3. Establish and Maintain an Enterprise Process for Reporting Incidents

The previous safeguard concerns who should be informed about incidents. This safeguard addresses how incidents should be reported, including the reporting timeframe, mechanisms for reporting and the information to be reported (such as the incident type, time, level of threat, system or software impacted, audit logs, etc.)

Having a documented reporting workflow makes it easier for anyone learning about an incident to inform the right personnel in a timely and effective manner. This process should be available to the entire workforce and be reviewed annually and whenever significant changes occur that may impact security.

17.4. Establish and Maintain an Incident Response Process

This safeguard requires the creation of a roadmap for incident response by defining roles and responsibilities, communication and security plans, and compliance requirements. Without assigned tasks and clear instructions, parties may think someone else is handling a particular task when actually no one is.

The response process should broadly outline steps, including monitoring and identifying the cyber threat associated with the incident, defining the objectives for handling the incident, and acting to prevent damage or recover assets. Many incident response teams use  jump kits that contain resources needed to investigate and respond to incidents, such as computers, backup devices, cameras, portable printers, and digital forensic software such as protocol analyzers.

Usually, the first step is to ascertain the nature of the incident so that appropriate response procedures can be implemented. With clear objectives in mind, teams can make efforts to slow down the threat. Then they can take the proper steps based on their documented action plan to handle the incident and reverse any damage.

This process should be reviewed once a year and whenever significant changes can impact security.

17.5. Assign Key Roles and Responsibilities

As outlined in the previous safeguard, incident responders must know their role in response procedures. Assign key roles and responsibilities to different individuals or teams as applicable. This may include the security team (incident responders), system administrators, legal staff, public relations (PR) and human resources (HR) team members, and analysts. Of course, the security and IT teams will have the lion’s share of the responsibilities in case of a cybersecurity incident. However, other essential personnel, like those in legal or HR departments, should also know their functions.

The roster of roles and corresponding responsibilities should be reviewed and revised annually and whenever a significant change occurs.

17.6. Define Mechanisms for Communicating During Incident Response

Communication is vital when it comes to incident reporting and assessment. While the other safeguards outline what to communicate and who to communicate to, this safeguard outlines how to communicate. There should be pre-defined communication channels like email or phone.

Contingency plans should also be defined. For example, a serious incident can make email communication impossible. Therefore, there should be another communication mechanism to inform the necessary parties and give updates on the incident response.

17.7. Conduct Routine Incident Response Exercises

It’s also important to prepare for real-world incidents by conducting routine incident response exercises and scenarios for key personnel. These exercises will test and audit the different aspects of the incident response plan and procedures, like communication channels, workflows  and investigations. For example, practice responding to network incidents that disrupt the critical flow of information in the organization. Conduct these exercises at least once a year.

The teams can use the NIST Technical Guide to Security Testing and Assessment to formulate exercise drills.

17.8. Conduct Post-Incident Reviews

After every incident, organizations need to investigate both the incident and their response. They should designate the personnel responsible for performing this analysis and creating a post-incident report to identify follow-up actions and mistakes.

The post-incident report should answer questions like:

  • Exactly what happened?
  • What caused it?
  • How did the responsible personnel respond?
  • How long did the response take?
  • Was the response procedure adequate?
  • What could have been done better?
  • Was the information in the incident report sufficient?
  • What could have been done differently?
  • What measures can prevent such incidents in the future?

17.9. Establish and Maintain Security Incident Thresholds

This safeguard helps organizations distinguish security incidents from security events. By defining different incidents and their impact, organizations can ensure that their resources go to critical incidents and not just minor anomalous events. In addition, it helps create a priority system for incidents so that responders know when to react and how to respond.

Identifying and classifying incidents can standardize the response procedures moving forward. The organization should update their thresholds to include new internal and external threats that qualify as incidents.

Summary

The nine safeguards of CIS CSC 17 help organizations implement sound incident response management, including role assignment, contact management, scenario practice, and incident analysis and documentation.

Dirk Schrader is a Resident CISO (EMEA) and VP of Security Research at Netwrix. A 25-year veteran in IT security with certifications as CISSP (ISC²) and CISM (ISACA), he works to advance cyber resilience as a modern approach to tackling cyber threats. Dirk has worked on cybersecurity projects around the globe, starting in technical and support roles at the beginning of his career and then moving into sales, marketing and product management positions at both large multinational corporations and small startups. He has published numerous articles about the need to address change and vulnerability management to achieve cyber resilience.