Improving your Organization’s Incident Response Plan Using CIS Control 17 Safeguards

Cybersecurity incidents continue to increase in number and sophistication, which means the need for effective incident response management keeps ratcheting up. By October 2021, the number of data-compromise incidents driven by ransomware, phishing, and other attacks was already running 27% ahead of the total for all of 2020.
As ransomware attacks persist—and go after larger and more disruptive targets like pipelines, food processors, and government agencies—the U.S. Transportation Security Administration is planning new cybersecurity incident reporting and response planning requirements for major airport and rail operators. Organizations of all sizes should review their incident response plans now, and use the most current version of CIS Control 17 to find and fill any gaps in their plans.

CIS Controls Version 8 Rethinks Incident Response in Cybersecurity

Until mid-2021, security teams could use CIS Control 17 to help stop phishing emails, while incident response and management steps were listed under Control 19. However, CIS revamped the Controls in May 2021 and consolidated the total number of Controls from 20 to 18.

Now in v8, CIS Control 17 addresses incident response with three basic Safeguards that every organization should implement. Control 17 also includes half a dozen more Safeguards for enterprises, regardless of whether the enterprise works with sensitive or confidential data.

These Safeguards replace Sub-Controls, and they’re sorted into Implementation Groups (IGs) that apply to organizations of different sizes and complexity, and those with different data protection needs. Let’s look at each Safeguard in CIS 17:

CIS Controls v8 implementation handout

Plan, Communicate, Test: Key Safeguards of CIS Control 17

Security assessment plans will vary depending on which IGs apply to an organization.

IG1 addresses basic cyber hygiene steps that every organization should take—even small organizations and those that think they’re too obscure to be found by ransomware attackers. Control 17’s IG1 Safeguards are:

• 17.1: Organizations need to designate one incident response lead and one backup person. The CIS IoT Companion guide recommends that organizations also pick a response lead and a backup for IoT incidents, because the threats to unmanaged devices and the appropriate responses differ from IT and managed devices.
• 17.2: Organizations need to write and continuously update their incident-reporting contact list. It should include anyone who needs to know, such as law enforcement and regulatory agencies, insurers, employees, and vendors. Other relevant stakeholders may include shareholders and investors, patients, students, or customers. The list may also include PR contacts for crisis management and media contacts.
• 17.3: Employees need a written process they can follow to report incidents, including those involving IoT devices. That process should explain clearly what types of incidents or issues to report, who to send the report to, when to report incidents, and how to share the information (for example, via email, phone, instant message, or another channel).

Beyond those basics, enterprises and any organization handling sensitive or restricted data should implement steps 17.4 through 17.8, which CIS includes in IG2 and IG3:

• 17.4: Organizations must define all the roles, responsibilities, compliance issues, and communication requirements for incident response. Without clear action steps, a team can waste valuable time duplicating efforts and untangling communication threads during an incident response. Unclear roles and requirements also raise the likelihood that critical response steps may be overlooked.
• 17.5: The right people need to be appointed to the right incident response roles. At the enterprise level, this step requires bringing in people beyond IT and SOC from legal, PR, HR, facilities, and other relevant departments.
• 17.6: Enterprises need to pre-designate approved communication channels for people involved in the response to use during an incident. They should also choose backup channels, in case the primary channels are compromised. For example, the NotPetya attack took down email systems across enterprise targets, complicating the response for impacted companies.
• 17.7: Organizations should thoroughly test incident response plans at least once a year using a variety of scenarios, including current IT threats. This step requires identifying the security testing tools your team will need well in advance of planned tests.
• 17.8: Response teams should follow cybersecurity testing and incident response drills with reviews to see what worked and what needs improvement next time.

There’s one more IG3 Safeguard that CIS recommends for organizations that work with sensitive data:

• 17.9: Organizations should set thresholds for incidents, “including, at a minimum, differentiating between an incident and an event.” Setting thresholds enables your response team to prioritize its work and allows your security team to automate alerts at those thresholds for more efficient responses.

What Are the Organizational Risks When Incident Response Plans Fall Short?

When security teams lack comprehensive data about their devices and what those devices are doing—or when that data is scattered across different security solutions—it’s virtually impossible to launch a fast, effective response to an incident.

To respond properly, security teams need real-time answers to these questions:

• Which devices are affected? For example, is the incident unfolding on your organization’s connected printers, or is it targeting a wider range of devices that share the same IoT operating system?
• What do the devices control and what do they communicate with? Devices that control critical infrastructure operations, patient safety, security monitoring, and other sensitive tasks require a more urgent response than, say, a Rickroll breach of connected televisions.
• What networks are the devices on? When security teams can see which networks and segments the devices have access to, and whether those limits have been breached, they can more quickly assess risks to other parts of the organization’s environment and operations.

Where are the affected devices? Connected devices are everywhere, from the production lines and classrooms to operating theaters and executive suites. Understanding where compromised devices are located can help the team prioritize its response.

Untested or incompletely tested plans can fail during a crisis, complicating and slowing down the response. Response delays can worsen the scope of the incident by allowing intruders more time in the system, so the longer it takes to identify an attack and isolate the devices and networks involved, the bigger the disruption can be. For example, SolarWinds “saw signs of hackers invading their networks as early as January of 2019, about eight months earlier than the previously publicly disclosed timeline,” but delays in identification and response allowed attackers to stay almost two more years within their system.

Delayed or disorganized responses can also lead to steep compliance penalties. For example, under GDPR, the EU requires enterprises to report known data exposures within 72 hours of discovery. Slow incident response has led to costly fines for some organizations, including one travel booking site that was fined $560K for reporting a breach 22 days after discovery.

Miscommunication during incident response can also undermine organizations’ relationships with investors and customers. The resulting brand damage can lead to a decline in stock value, customer churn, and increases in the average cost to acquire new customers.

Optimize Your Organization’s Incident Response Management Plan With the Armis Platform

The Armis Unified Asset Intelligence Platform gives organizations the tools and information to achieve faster, more focused incident response, remediation, and recovery. The platform provides complete device visibility of un-agentable devices across the environment. Armis also delivers continuous monitoring of device activity based on risk intelligence from the Armis Collective Asset Intelligence Engine, our threat intelligence platform that includes information on more than two billion devices and counting. With these insights and AI-powered anomaly detection, the Armis platform can quickly alert security teams to anomalous device behavior that can signal an attack. After incident response, security teams can access the platform’s logs for review and forensics.

Learn more about how the Armis platform’s threat detection and response capabilities can help you see every device, identify malicious behavior faster, and respond more effectively to protect your organization’s assets, relationships, and reputation.