The Center for Internet Security (CIS) has just released Version 8 of their popular security controls. With this version, the “Top 20” moniker has been lost and the list of controls reduced to 18. The Version 8 is a major update to the Safeguards, builds on some of the new features in Version 7.1 (Implementation Groups), and addresses and acknowledges the growing impact of the cloud-first and product-centric world that we live in. Praetorian was proud to participate in the Version 8 review process and offer our expertise to the development of this set of Safeguards.
From the Changelog, a few initial trends can easily be seen in the update.
Overview of Changes
[image id=”2978″ filter=”false”]
Source: Center for Internet Security Control Version 8 Changelog (https://www.cisecurity.org/white-papers/cis-controls-v8-change-log/)
Once of the most obvious changes is the addition of a wholly new Control; Control 15: Service Provider Management. This Control addresses the prevalence of SaaS platforms and the sensitivity of the data they store and process. Previously the Controls only required and inventory of these types of systems. This new Control goes further requiring policies, classification, assessment, and monitoring. Coupling service providers, their SaaS platforms, and cloud providers has created a recipe for risk that is now addressed in this control. Praetorian has done research in this space regarding both AWS Confused-Deputy Attacks and similar attacks in Alibaba Cloud. These types of attacks highlight the importance of this Control.
Usurping Continuous Vulnerability Management as Control 3 is Data Protection, moving up from the number 13 spot. This is in response to the modern threat landscape that has been dominated by data breaches and exposures. Data is often an organization’s most valuable asset and therefore affords this Control a higher spot on the list. Five new Safeguards were added to this Control that sound very similar to what we see in the NIST Cybersecurity Framework. The new five Safeguards are largely focused on managing and identifying data rather than technical implementations that must be put in place. The new Control 3 for Data Protection also encompasses elements of Access Control and Monitoring previously separated in Controls 14 and 16. Overall this seems like a smart move because without our data, most of the other aspects of a security program do not matter.
Next, a meteoric rise and split of Control 16: Account Monitoring and Control in the new Control 5: Account Management and Control 6: Access Control Management coupled with the absorption (and minor demotion) of Control 4: Controlled Use of Administrative Privileges. With the advent of SSO platforms, third-party account management tools, and privileged access management (PAM) platforms, this split makes sense while the absorption of Control 4 is completely logical in the new Controls. Often, the functions of account management and access control are assigned to different teams and implemented in different platforms. Human Relations (HR) systems may drive account provisioning, de-provisioning, and disablement while IT teams may manage access controls and group permissions via IT systems. This also allows for a greater focus on each of these areas to ensure processes do not become so cumbersome that nuance is lost (ie. granting all employees overly broad permissions because it is easier). This is also a nod to reducing the blast radius of any particular attack or compromise due to access snowballing.
A more minor change, the old Controls for the secure configuration of devices (Control 5 for endpoints and Control 11 for network devices) have been consolidated and bumped up to Control 4: Secure Configuration of Enterprise Assets and Software. While this is not a monumental shift, it does acknowledge that there is parity in the priority and risk for security configurations of all devices and their included software. The prior split between endpoints, network devices, and software was unnecessary and added complication where it was not needed. In many organizations (especially smaller organizations) the tools and processes for ensuring configuration control is the same across the entire enterprise, while larger organizations may split those functions. In our experience as penetration testers and Red Teamers, insecure configurations and deployment errors account for large portions of attack chains and often make exploitation of vulnerabilities unnecessary. The newly minted Control 14: Network Infrastructure Management, while related, speaks much more to the architecture, design, and management of networks rather than the system and device configurations.
The final few shifts are minor and in relation to the reduction of the total Controls from 20 to 18. Minor title updates have also occurred. Control 14: Security Awareness and Skills Training has moved from 17 to 14, Control 16: Application Security has moved from 18 to 16, Control 17: Incident Response Management from 19 to 17, and Control 18: Penetration Testing has moving from 20 to 18, still occupying the final Control spot on the list.
Summary Changes
While these changes at the Control level may be fairly easy to digest, there are over 200 changes to individual Safeguards that organizations who make heavy use of the CIS Controls should review in full. As a summary:
- 98 instances of re-ordering in the same Control
- 71 instances of re-ordering in a different Control
- 53 instances of new Controls
- 100 instances of content merging
- 36 instances of expanding Implementation Groups
- 17 instances of reducing Implementation Groups
- 14 deprecated Safeguards
The high number of Safeguard and Controls that were merged is a driver for the reduction from 20 to 18 total Controls but should also make implementation easier for security professionals as the Safeguards now feel more realistic, risk-informed, and appropriately flexible. To use CIS terminology, the Safeguards are now organized by Activity rather than by “ownership.”
The end result is a reduction from 171 total Safeguards down to 153. For organizations seeking to adjust the workload of implementing the Controls, the shifts in Implementation Groups now stands as:
- 55 Controls in IG1 (up from 43)
- 130 Controls in IG2 (down from 142)
- 153 Controls in IG3 (down from 171)
Deprecated Safeguards
The update to Version 8 deprecates 14 Safeguards. Ensuring that the CIS Controls apply to “most” organizations is a critical factor in assessing which controls are appropriate. Below is Praetorian’s analysis why these controls are no longer needed:
- 2.5 Integrate Software and Hardware Asset Inventories
- This was either largely impractical or handled by modern EDR (or other) endpoint monitoring agents in most organizations. . The effort to integrate inventories was not commensurate with the value it provided. Organizations largely have access to device software inventories via other tools.
- 5.2 Maintain Secure Images
- While a supply chain attacks via compromised “gold images” is possible, most organizations have departed from imaging machines and are largely leveraging configuration tools to bootstrap machines that are running known good operating systems (generally installed by manufacturers). As such, this should not be a common Safeguard for most organizations. That being said, the broader definition of “images” to include container images or firmware for OT devices could make this a valid safeguard, though that was never the intent of Control 5 in Version 7.1.
- 5.3 Securely Store Master Images
- See 5.2
- 5.5 Implement Automated Configuration Monitoring Systems
- Many organizations may not be able to automate Configuration Monitoring. While automation is an ideal state, there are other ways to achieve this outcome, such as routine and frequent configuration pushes. Additionally, limiting the ways that configuration changes can be made and implementing a strong configuration/change management process can mitigate a large portion of the risk.
- 12.5 Configure Monitoring Systems to Record Network Packets
- Recording all network packets is a tall order for small organizations and the data storage requirements in large organizations may be cost or resource prohibitive. Many network security tools (called out in the Safeguards of Control 13) support the capture of packets related to an event. Additionally, other log sources can provide the same information with a smaller data footprint. It is also important to note that collection of network flow logs is still present in Safeguard 13.6.
- 12.10 Decrypt Network Traffic at Proxy
- The double-edged sword of balancing user privacy and complicated deployments with improved security. Most attackers are using encrypted communications for C2, so failing to decrypt network traffic can be a boon to security analysts. That being said, the prevalence of endpoint agent-based security tooling significantly mitigates this risk and can provide security analysts appropriate visibility without having to decrypt network traffic.
- 13.5 Monitor and Detect Any Unauthorized Use of Encryption
- We are not sure that anyone was ever able to figure out what this control meant or how to safeguard against it. Presumably this was a Safeguard intended to prevent or detect attackers encrypting C2 channels or perhaps performing ransomware operations. Either way, assessing this control was near impossible.
- 13.8 Manage System’s External Removable Media’s Read/Write Configurations
- In our estimation, this control should not have been removed as the effort of implementation can be low while the impact is high. In a cloud-first world, the use of removable media is quickly becoming a thing of the past, therefore, restricting use of removable media should continue to have diminishing impact on business operations. Exceptions to removable media restrictions should be limited and easy to manage. Organizations also have a much easier time managing access control to data stored on enterprise platforms rather than on unmanaged storage devices.
- 15.5 Limit Wireless Access on Client Devices
- This is simply not realistic in today’s remote-centric and mobile environment. Other Safeguards exist to protect devices that connect to untrusted wireless networks.
- 16.13 Alert on Account Login Behavior Deviation
- This control was ill-defined as there was no guidance on what types of deviation to alert on making implementation fairly ambiguous. With the rise of WFH and remote work, logon behavior is no longer as static as it used to be. Aside from country-based geographic logon rules, most organizations will be unsuccessful in implementing this Control.
- 17.1 Perform a Skills Gap Analysis
- While nice in theory, most organizations simply do not have the resources, expertise, or tools to perform a useful skills gap analysis. Training is much better when based on best practices and provided to everyone (and to role specific populations) in a standardized fashion.
- 20.5 Create Test Bed for Elements Not Typically Tested in Production
- Penetration testing and Red Teaming should happen on Production systems periodically and on test systems frequently. Attackers do not differentiate between prod and test systems. Neither should security practitioners.
- 20.6 Use Vulnerability Scanning and Penetration Testing Tools in Concert
- This control was a no-brainer to any penetration tester but also was overly prescriptive and penetration testers should be the ones defining test plans for an environment. On top of that, many organizations simply do not have vulnerability scanning results with which to drive penetration testing efforts. That made this control a bit of a double-dip.
- 20.7 Ensure Results from Penetration Test are Documented Using Open, Machine-readable Standards
- Similar to 13.5, most practitioners were not entirely sure how to meet this Control. Additionally, most organizations are more concerned with being able to import data into a ticketing system (JIRA, ServiceNow, etc) via something like a CSV rather than an open finding standard format.
Summary
The release of Version 8 of the CIS Controls renews their commitment to helping secure modern organizations. Having participated in their review process, it was clear that they took input seriously and sought to incorporate as much feedback as possible. The shifts in Control priorities, the depreciation of Safeguards, and the merging of Safeguards all were done with security and the end-user in mind.
While Praetorian prioritizes the NIST Cyber Security Framework for our maturity analysis, this update to the CIS Controls has boosted that benchmark and made it a strong contender for any organization’s security benchmarking efforts.
