Mount Hood - Oregon, USA (July 2019)

Mapping CIS Controls to Cloud

AWS , CloudSecurity , Technology

Building a public cloud security program from scratch is a lot of work. There are a ton of things you need to do and figuring out what you need to do and the priority is critical. CIS publishes a list of 20 Critical Security Controls. While primarily focused at traditional IT data-center centric organizations, the concepts and the order of the 20 Controls provides a reasonably good road map for anyone looking to start their cloud security journey.

Overview of the Controls

CIS has 20 base controls they break down into three categories: Basic, Foundational, and Organizational. To further group the effort they categorize specific sub-controls based on the type of organization:

Implementation Group 1: An organization with limited resources and cybersecurity expertise available to implement Sub-Controls Implementation Group 2: An organization with moderate resources and cybersecurity expertise to implement Sub-Controls Implementation Group 3: A mature organization with significant resources and cybersecurity experience to allocate to Sub-Controls

Basic Controls

  1. Inventory and Control of Hardware Assets
  2. Inventory and Control of Software Assets
  3. Continuous Vulnerability Management
  4. Controlled Use of Administrative Privileges
  5. Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers
  6. Maintenance, Monitoring and Analysis of Audit Logs

Foundational Controls

  1. Email and Web Browser Protections
  2. Malware Defenses
  3. Limitation and Control of Network Ports, Protocols, and Services
  4. Data Recovery Capabilities
  5. Secure Configuration for Network Devices, such as Firewalls, Routers and Switches
  6. Boundary Defense
  7. Data Protection
  8. Controlled Access Based on the Need to Know
  9. Wireless Access Control
  10. Account Monitoring and Control

Organizational Controls

  1. Implement a Security Awareness and Training Program
  2. Application Software Security
  3. Incident Response and Management
  4. Penetration Tests and Red Team Exercises

Mapping Basic Controls to the Cloud

For the basic and foundational controls, we will outline what CIS provides as the appropriate sub-controls for the specific control, then provide a prioritized list of cloud-specific sub-controls. Where possible we map the cloud-specific sub-control the the CIS provided sub-control.

Control 1 - Inventory and Control of Hardware Assets

The CIS provided sub-controls for this control are:

  • 1.1 Utilize an Active Discovery Tool (Group 2)
  • 1.2 Use a Passive Asset Discovery Tool (Group 3)
  • 1.3 Use DHCP Logging to Update Asset Inventory (Group 2)
  • 1.4 Maintain Detailed Asset Inventory (Group 1)
  • 1.5 Maintain Asset Inventory Information (Group 2)
  • 1.6 Address Unauthorized Assets (Group 1)
  • 1.7 Deploy Port Level Access Control (Group 2)
  • 1.8 Utilize Client Certificates to Authenticate Hardware Assets (Group 3)

The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Maintain a detailed inventory of cloud accounts (1.4 & 1.5)
  2. Maintain a detailed inventory of cloud resources by account (1.1).
  3. Monitor the cloud bill for every cloud account for anomalies (1.6)

Control 2 - Inventory and Control of Software Assets

The CIS provided sub-controls for this control are:

  • 2.1 Maintain Inventory of Authorized Software (Group 1)
  • 2.2 Ensure Software is Supported by Vendor (Group 1)
  • 2.3 Utilize Software Inventory Tools (Group 2)
  • 2.4 Track Software Inventory Information (Group 2)
  • 2.5 Integrate Software and Hardware Asset Inventories (Group 2)
  • 2.6 Address unapproved software (Group 1)
  • 2.7 Utilize Application Whitelisting (Group 3)
  • 2.8 Implement Application Whitelisting of Libraries (Group 3)
  • 2.9 Implement Application Whitelisting of Scripts (Group 3)
  • 2.10 Physically or Logically Segregate High Risk Applications (Group 3)

The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Maintain a detailed inventory of applications (2.4).
  2. Link the application inventory to cloud account inventory from Control 1 (2.5)
  3. Maintain detailed risk profile of each application (i.e. regulated data, trade secrets, etc) (2.4, 2.10)
  4. Link (via tagging) cloud resources to application (2.5)
  5. Place high-value or high-risk applications into their own cloud account (2.10)

Control 3 - Continuous Vulnerability Management

For cloud, Continuous Vulnerability Management really means Cloud Security Posture Management (CSPM), and CSPM is critical to establish once inventories are in place.

The CIS provided sub-controls reflect on-prem thinking. For this control they are:

  • 3.1 Run Automated Vulnerability Scanning Tools (Group 2)
  • 3.2 Perform Authenticated Vulnerability Scanning (Group 2)
  • 3.3 Protect Dedicated Assessment Accounts (Group 2)
  • 3.4 Deploy Automated Operating System Patch Management Tools (Group 1)
  • 3.5 Deploy Automated Software Patch Management Tools (Group 1)
  • 3.6 Compare Back-to-Back Vulnerability Scans (Group 2)
  • 3.7 Utilize a Risk-Rating Process (Group 2)

While any company should implement the above controls for their cloud Instances/VMs, additional cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Run Automated CSPM Scanning (3.1).
  2. Risk-Rate the CSPM findings for your organization (3.7).
    • This is critical. Most tools throw in all sorts of best practices and often tie them to specific severities. These may not be appropriate for your organization and will generate bad-will between security and development communities if security’s stance is “Tool say bad, you must fix”.
    • If I were to add “Write a Cloud Security Standard” into the CIS Controls, it would be here.
  3. For the cloud-hosted operating systems, leverage CSP provided tools like Security Center (Azure), AWS SSM, and AWS Inspector (3.2, 3.4, 3.5)

Control 4 - Controlled Use of Administrative Privileges

The CIS provided sub-controls for this control are:

  • 4.1 Maintain Inventory of Administrative Accounts (Group 2)
  • 4.2 Change Default Passwords (Group 1)
  • 4.3 Ensure the Use of Dedicated Administrative Accounts (Group 1)
  • 4.4 Use Unique Passwords (Group 2)
  • 4.5 Use Multi-Factor Authentication for All Administrative Access (Group 2)
  • 4.6 Use Dedicated Workstations For All Administrative Tasks (Group 2)
  • 4.7 Limit Access to Script Tools (Group 2)
  • 4.8 Log and Alert on Changes to Administrative Group Membership (Group 2)
  • 4.9 Log and Alert on Unsuccessful Administrative Account Login (Group 2)

Controlling access to the cloud provider’s APIs is a critical aspect of any cloud security program, and this control’s placement in the number four slot makes complete sense. The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Multi-Factor for all cloud access is vital (4.5)
  2. Enable CloudTrail or similar (4.8 & 4.9)
  3. Approval process and workflow for cloud account access (4.1)

Slightly more advanced organizations would want to:

  1. Create alerts around the usage of AWS Root login, and invalid IAM Logins (4.8 & 4.9)
  2. Detect & Alert on IAM Logins w/o MFA, and IAM Logins that don’t come from known IP Addresses
  3. Leverage of SSO and Federation for console and API Access

Control 5 - Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers

The CIS provided sub-controls for this control are:

  • 5.1 Establish Secure Configurations (Group 1)
  • 5.2 Maintain Secure Images (Group 2)
  • 5.3 Securely Store Master Images (Group 2)
  • 5.4 Deploy System Configuration Management Tools (Group 2)
  • 5.5 Implement Automated Configuration Monitoring Systems (Group 2)

The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Adopt secure configuration for your public cloud provider via a standard or baseline (5.1)
  2. Implement an “account factory” where newly created accounts and deployed consistently (5.2)
  3. Adopt Golden AMIs/Images (5.2)
  4. Adopt Guard Rails via tools like DivvyCloud or DisruptOps (5.5)

Control 6 - Maintenance, Monitoring and Analysis of Audit Logs

The CIS provided sub-controls for this control are:

  • 6.1 Utilize Three Synchronized Time Sources (Group 2)
  • 6.2 Activate Audit Logging (Group 1)
  • 6.3 Enable Detailed Logging (Group 2)
  • 6.4 Ensure Adequate Storage for Logs (Group 2)
  • 6.5 Central Log Management (Group 2)
  • 6.6 Deploy SIEM or Log Analytic Tools (Group 2)
  • 6.7 Regularly Review Logs (Group 2)
  • 6.8 Regularly Tune SIEM (Group 3)

The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Enable CloudTrail!!!! (6.2)
    • Seriously. I told you to do that back in Control #4.
  2. Enable Organizational CloudTrail (6.5)
  3. Send your CloudTrail logs to a SIEM or Splunk (6.6)
  4. Establish pushing OS-level logs to an external logging infrastructure to preserve otherwise ephemeral log data (6.4)
  5. Invest in building Cloud Security Detections for your cloud-plane audit logs (6.7 & 6.8)

Mapping Foundational Controls to the Cloud

The foundational controls tend to diverge and be less relevant to the cloud. For example “Email and Web Browser Protections” and “Wireless Access Control” have minimal applicability to public cloud. Others like “Malware Defense”, “Data Recovery Capabilities”, and “Controlled Access Based on the Need to Know” are as applicable on-prem as in the cloud. Where the foundational controls have minimal applicability to cloud we will omit them or make brief notes on some cloud tooling that can help achieve the goals.

Control 8 - Malware Defenses

One of the Sub-Controls here is “Enable DNS Query Logging” which is a function of AWS GuardDuty, and is now a feature available in AWS. Otherwise leverage these controls in your cloud environment as you would leverage them in your legacy infrastructure.

Control 9 - Limitation and Control of Network Ports, Protocols, and Services

The CIS provided sub-controls for this control are:

  • 9.1 Associate Active Ports, Services, and Protocols to Asset Inventory (Group 2)
  • 9.2 Ensure Only Approved Ports, Protocols, and Services Are Running (Group 2)
  • 9.3 Perform Regular Automated Port Scans (Group 2)
  • 9.4 Apply Host-Based Firewalls or Port-Filtering (Group 1)
  • 9.5 Implement Application Firewalls (Group 3)

The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Leveraging Security Groups to limit access to hosts and resources (9.2 & 9.4)
  2. Establish and alert on mis-configured security groups in your CSPM tool (9.2 & 9.3)
    • Feed the findings from your CSPM tool into your vulnerability management program.
  3. Leverage your CSP’s native WAF functionality where necessary to limit access to non-public APIs & resources (9.5)

Control 11 - Secure Configuration for Network Devices, such as Firewalls, Routers and Switches

With public cloud, most of the network infrastructure is managed by the provider. There is little here of applicability, but I included the CIS sub-controls for completeness.

  • 11.1 Maintain Standard Security Configurations for Network Devices (Group 2)
  • 11.2 Document Traffic Configuration Rules (Group 2)
  • 11.3 Use Automated Tools to Verify Standard Device Configurations and Detect Changes (Group 2)
  • 11.4 Install the Latest Stable Version of Any Security-Related Updates on All Network Devices (Group 1)
  • 11.5 Manage Network Devices Using Multi-Factor Authentication and Encrypted Sessions (Group 2)
  • 11.6 Use Dedicated Machines For All Network Administrative Tasks (Group 2)
  • 11.7 Manage Network Infrastructure Through a Dedicated Network (Group 2)

Most of the interesting aspects fall into the next section.

Control 12 - Boundary Defense

The CIS provided sub-controls for this control are:

  • 12.1 Maintain an Inventory of Network Boundaries (Group 1)
  • 12.2 Scan for Unauthorized Connections Across Trusted Network Boundaries (Group 2)
  • 12.3 Deny Communications With Known Malicious IP Addresses (Group 2)
  • 12.4 Deny Communication Over Unauthorized Ports (Group 1)
  • 12.5 Configure Monitoring Systems to Record Network Packets (Group 2)
  • 12.6 Deploy Network-Based IDS Sensors (Group 2)
  • 12.7 Deploy Network-Based Intrusion Prevention Systems (Group 3)
  • 12.8 Deploy NetFlow Collection on Networking Boundary Devices (Group 2)
  • 12.9 Deploy Application Layer Filtering Proxy Server (Group 3)
  • 12.10 Decrypt Network Traffic at Proxy (Group 3)
  • 12.11 Require All Remote Login to Use Multi-Factor Authentication (Group 2)
  • 12.12 Manage All Devices Remotely Logging into Internal Network (Group 3)

The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Maintain an inventory of all public endpoints (12.1).
    • This includes API Gateways, Load-balancers, Directly attached instances, CloudFront Distributions, and provider hosted DNS.
  2. Strictly control how security groups are leveraged (12.4)
    • Larger organizations can consider limiting access to security group permissions to specific network or security engineering teams, removing the ability for developers to expose resources to the internet. This is important in networks where broad lateral movement is a possibility due to the extensive use of Transit Gateways or Direct Connects.
  3. Enable GuardDuty and other CSP provided network anomaly detection (12.3)
    • GuardDuty will process the VPC Flowlog data to look for known bad IP addresses in the AWS-sourced threat lists.
  4. Leverage WAFs (12.2, 12.3, 12.7) in addition to security groups.
    • WAFs provide a layer of protection on specific cloud-managed resources like CloudFront and API Gateway where traditional network layer-3 controls are not available.
  5. Require MFA on VPN and Bastion hosts (12.11)
  6. Enable VPC Flow Logging (12.8)

Many of the controls in this group (12.9 & 12.10) relate to monitoring & managing egress traffic. If necessary for your organization (or application) this needs to be carefully architected, as the patterns traditionally used in your on-premises data-centers introduce availability risk in public cloud.

Control 13 - Data Protection

Given my stance on cloud encryption, I’m somewhat glad to see this control further down the list. The CIS provided sub-controls for this control are:

  • 13.1 Maintain an Inventory of Sensitive Information (Group 1)
  • 13.2 Remove Sensitive Data or Systems Not Regularly Accessed by Organization (Group 1)
  • 13.3 Monitor and Block Unauthorized Network Traffic (Group 2)
  • 13.4 Only Allow Access to Authorized Cloud Storage or Email Providers (Group 2)
  • 13.5 Monitor and Detect Any Unauthorized Use of Encryption (Group 3)
  • 13.6 Encrypt Mobile Device Data (Group 1)
  • 13.7 Manage USB Devices (Group 2)
  • 13.8 Manage System’s External Removable Media’s Read/Write Configurations (Group 3)
  • 13.9 Encrypt Data on USB Storage Devices (Group 3)

The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Attach the data classification to your cloud account or application inventory as described in Controls 1 & 2 (13.1)
  2. Monitor and manage the shadow clouds and edge clouds (13.4)
    • Don’t just focus on what you know about and pretend the rest doesn’t exist
  3. Monitor how snapshots and images are shared (13.8)
    • Your CSPM tool can assist here.
    • Consider turning public snapshots or images into security events rather than just common misconfigurations.
  4. Encrypt all EC2 Volumes, RDS Databases, and everything else! (13.6 & 13.7)
  5. Monitor for the deletion of KMS Keys (13.5)
    • Deletion of keys will render your data inaccessible.
  6. Consider the use of provider VDI tools (like AWS Workspaces) to limit movement of sensitive data out of the cloud provider (13.8)

Control 14 - Controlled Access Based on the Need to Know

The CIS provided sub-controls for this control are:

  • 14.1 Segment the Network Based on Sensitivity (Group 2)
  • 14.2 Enable Firewall Filtering Between VLANs (Group 2)
  • 14.3 Disable Workstation to Workstation Communication (Group 2)
  • 14.4 Encrypt All Sensitive Information in Transit (Group 2)
  • 14.5 Utilize an Active Discovery Tool to Identify Sensitive Data (Group 3)
  • 14.6 Protect Information Through Access Control Lists (Group 1)
  • 14.7 Enforce Access Control to Data Through Automated Tools (Group 3)
  • 14.8 Encrypt Sensitive Information at Rest (Group 3)
  • 14.9 Enforce Detail Logging for Access or Changes to Sensitive Data (Group 3)

The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Filter traffic from cloud back to on-prem via an IT Managed firewall (14.2).
  2. Segment applications in their own accounts (14.1)
    • While we’re way down in the list of controls, adopting a multi-account strategy is a core thing to consider as you begin your cloud journey. Migrating teams out of the multi-tenant swamps should start to occur when you reach this point.
  3. Segment environments (dev, test, prod) into their own accounts, or at least their own VPCs (14.1)
  4. Leverage VPC Peering & Transit Gateways judiciously (14.2)
    • A key component of controlling access and therefore lateral movement is avoiding the creation of a totally flat cloud network. While these cloud networking constructs have their place, make sure that threat modeling occurs when they’re proposed.
  5. Enable & enforce least privilege in IAM policies via tools like CloudSplaining and Parliament (14.6)
  6. Limit direct ingress to cloud resources by leveraging your CSP’s native loadbalancer capability. This also allows your to offload TLS and certificate management to the CSP (14.4)
  7. Leverage Bucket Policies & VPC Endpoints to restrict who/how sensitive data can be accessed (14.7)
  8. Enable S3 Data Events, and establish monitoring for S3 Data Events in CloudTrail (14.9)
    • You might consider collection of the data events earlier in your program and establish the monitoring and anomaly detection here in number 14
  9. Enable Macie if your risk profile calls for that (14.5)
    • While pricing has improved, it is very expensive. Additionally, GuardDuty has some S3 access anomaly detection now. Macie is primarily good for finding sensitive data.

Control 16 - Account Monitoring and Control

The CIS provided sub-controls for this control are:

  • 16.1 Maintain an Inventory of Authentication Systems (Group 2)
  • 16.2 Configure Centralized Point of Authentication (Group 2)
  • 16.3 Require Multi-Factor Authentication (Group 2)
  • 16.4 Encrypt or Hash all Authentication Credentials (Group 2)
  • 16.5 Encrypt Transmittal of Username and Authentication Credentials (Group 2)
  • 16.6 Maintain an Inventory of Accounts (Group 2)
  • 16.7 Establish Process for Revoking Access (Group 2)
  • 16.8 Disable Any Unassociated Accounts (Group 1)
  • 16.9 Disable Dormant Accounts (Group 1)
  • 16.10 Ensure All Accounts Have An Expiration Date (Group 2)
  • 16.11 Lock Workstation Sessions After Inactivity (Group 1)
  • 16.12 Monitor Attempts to Access Deactivated Accounts (Group 2)
  • 16.13 Alert on Account Login Behavior Deviation (Group 3)

We revisit here some recommendations from Control 4. The cloud-specific sub-controls you would want to enable are (in order of priority):

  1. Leverage SSO for all Console and API access (16.2)
    • This recommendation was part of Control 4 for larger organizations. At this point in the program, all organizations should be leveraging some form of SSO and removing IAM Users from the mix.
  2. MFA. Really this time. (16.3)
  3. Disable any IAM User that hasn’t used their API Key or LoginProfile in 90 days (16.8 & 16.9)
  4. Require key rotation on service accounts (16.10)
  5. Ensure a process exists to revoke non-SSO access when someone leaves (16.7)
    • This is specific to IAM Users which exist outside the SSO/Federation you’ve already established. Expect there will always be one or two IAM Users that exist for break-glass purposes.
  6. Generate SIEM Alerts on invalid login and Access Denied in CloudTrail (16.12)
  7. Generate SIEM Alerts on anomalous CloudTrail behavior. Enable GuardDuty for the same purpose. (16.13)
  8. Vault Root Credentials and Root MFA tokens in an audit-able tool like CyberArk (16.2)
  9. Tag any IAM users that are used for service accounts, or establish a database of IAM Users and why they exist (16.6)
    • Knowing where they API Keys are deployed and who is responsible for rotation will make the process of key rotation easier
  10. Enable InfoSec to revoke users during an incident (16.7)

Organizational

The organizational controls are mostly cloud agnostic. They apply to an organization whether they are entirely on-prem, 100% cloud-native or some hybrid. For these last four controls, I won’t dive into the sub-controls, but only highlight a few things cloud-specific to add to the organization’s existing programs.

Control 17 - Implement a Security Awareness and Training Program

Make sure new cloud users are aware of the rules. Provide training to developers who are building IaC.

Control 18 - Application Software Security

This control really discusses moving beyond just the infrastructure to build a proper AppSec program. This should include SAST & DAST, CI/CD, etc. CIS discusses WAF in this control, however it is more fitting in a cloud environment to consider that as part of the boundary defense control.

Control 19 - Incident Response and Management

There are quite a few things involved in cloud IR, but they should fit into an existing organizations IR process. Key here is for InfoSec to establish a relationship with your provider’s account team. Set the Security Contacts for all accounts. The other cloud specific sub controls from the first 16 controls will help set the stage for a successful Cloud IR sub-program.

Control 20 - Penetration Tests and Red Team Exercises

There is a reason this control is #20. It requires a level of organizational maturity to gain actual security benefit from Pen-testings and Red Teaming. Without all the previous 19 controls, a Pen Test is an expensive trophy and Red Teaming provides minimal value if not doing continuous testing of the already in place security people process and technology. Now might be a good time to visit the idea of Canary Tokens