CIS Benchmarks Explained: Levels + Steps for Quick CIS Benchmark Compliance

CIS Benchmarks are important for security and compliance. In this blog, you'll get an overview, plus learn how to enforce CIS Benchmarks with Puppet.

Table of Contents:

• What are CIS Benchmarks?
• CIS Benchmark Categories
• What's the Difference Between Level 1 and Level 2 CIS Benchmarks?
• Why Use CIS Benchmarks?
• CIS Benchmark Tool: Puppet Comply
• How to Enforce CIS Benchmarks With Puppet

What are CIS Benchmarks?

CIS Benchmarks are a set of best practices and guidelines for securing IT systems, apps, networks, and infrastructure. CIS Benchmarks are developed by the Center for Internet Security (CIS), a global non-profit organization, and are offered free to the public.

There are more than 140 CIS Benchmarks to date, and they’re all created by industry consensus. That means that instead of being handed down by a small group, each benchmark is created by a community of cybersecurity experts, compliance and security practitioners, and organizations dedicated to improving global cybersecurity. It also means each CIS Benchmark can be applied to multiple technologies and they aren’t specific to any one vendor or platform.

See how CIS Benchmarks support security for technology in government >>

While many compliance frameworks are broad, CIS Benchmark recommendations are known for providing specific action steps and changes to implement to improve security at the system and app levels. CIS Benchmarks are flexible and can be implemented at different levels (Level 1 and Level 2), which allows different organizations to define the level of security that’s right for them. CIS regularly updates CIS Benchmarks so they address the changing cybersecurity threat landscape.

CIS Benchmark Categories

CIS Benchmarks are categorized by the area of IT they help secure. The seven main categories of CIS Benchmark are:

• CIS Benchmarks for Operating Systems (OS) cover securing configurations for Windows, Linux, and macOS.
• CIS Benchmarks for Servers include security configurations for server software like WIndows Server, SQL, VMWare, Kubernetes configuration, and more.
• CIS Benchmarks for Cloud Providers secure cloud infrastructure from AWS, Azure, and GCP.
• CIS Benchmarks for Network Devices provide security configuration guidelines for network devices, including hardware vendor-specific guidelines for CISCO, Palo Alto Networks, and Juniper.
• CIS Benchmarks for Desktop Software cover configurations to ensure security for common desktop applications like Microsoft Office, Microsoft Exchange Server, Chrome, Safari, and Firefox.
• CIS Benchmarks for Mobile Devices like iOS and Android address OS privacy configurations, settings, permissions, and dev options on mobile devices.
• CIS Benchmarks for Multi-Function Print Devices include configuration recommendations for multi-function printers in an office setting. Recommendations from CIS include firmware updates, TCP/IP config, file sharing, wireless access, and user management.

What's the Difference Between Level 1 and Level 2 CIS Benchmarks?

Level 1 CIS Benchmarks cover basic security requirements that are quicker to implement and have a smaller impact on service and functionality. Level 2 CIS Benchmarks go deeper and can actually hinder your business functionality if they’re not implemented correctly.

One of the benefits of using CIS Benchmarks is that you can select which level of CIS Benchmark compliance applies to your organization.

Who Should Use Level 1 CIS Benchmarks?

Organizations who only need to achieve a basic level of cybersecurity often find value in implementing Level 1 CIS Benchmarks. Those often include:

• Small and medium-sized businesses with limited cybersecurity resources and few compliance requirements
• Organizations without critical systems like personally identifiable information (PII) or other sensitive data storage or processing

Who Should Use Level 2 CIS Benchmarks?

Level 2 CIS Benchmarks are more comprehensive than Level 1, and implementing them often requires more testing and operational changes. Organizations that handle more sensitive data or are at a greater risk for cybersecurity threats often opt to implement Level 2 CIS Benchmarks. That can include:

• Enterprise organizations with vast, complex IT environments that span data centers and multi-cloud deployment or hybrid cloud IT
• Organizations that host critical infrastructure for services like energy, communications, healthcare, and transportation
• Regulated industries like healthcare and financial services organizations
• Organizations with high cybersecurity risk like government and banking

Some small organizations may be subject to a high degree of regulatory oversight and may opt for Level 2 CIS Benchmark compliance. Certain large organizations may find that Level 1 CIS Benchmark compliance is satisfactory for their cybersecurity needs. Each organization’s compliance needs are different, and there are no hard-and-fast lines defining which organizations need which kind of compliance.

Why Use CIS Benchmarks?

Using the CIS Benchmark framework helps ensure systems, apps, networks, and infrastructure are secured. CIS Benchmarks are globally recognized, free to use, and can be customized to the needs of almost any organization.

CIS uses a consensus-driven approach to develop its benchmarks. This two-step process starts with cybersecurity and system experts, who define, review and test the recommendations. Once consensus is reached, feedback is accepted from a wider range of cybersecurity professionals from around the world.

This process ensures that the benchmark is truly a best practice that has been well-refined and tested to ensure security and compliance.

Comply With Regulations

Both CIS Level 1 benchmarks and CIS Level 2 benchmarks align with many of the major regulations that are required for various industries.

With so many different regulations to keep up with, it’s no wonder that companies fall behind in compliance. CIS has aligned its benchmarks against many regulatory frameworks, enabling companies to utilize the benchmarks to gain best practices from CIS that help them achieve CIS compliance against the regulations that apply to them.

Globally Recognized

CIS Benchmarks are globally recognized and accepted.

The CIS Benchmarks are accepted by government, business, industry, and academia globally. According to Dilligent Insights, “CIS draws members from a range of backgrounds including private companies, government, and research institutions” and “provides a range of tools, resources and programs to enable best-practice IT governance within organizations and government.” With over 140 benchmarks, organizations can be sure their security and compliance needs are covered!

CIS Benchmark Tool: Puppet Comply

Puppet Comply can be your CIS Benchmark tool. It utilizes the CIS-CAT® Pro scanner to assess your IT infrastructure against CIS Benchmarks so you can get a clear view of your overall compliance. Puppet recognizes that CIS is the gold standard and when developing our continuous compliance solution, partnering with CIS was the right move for our customers.

Demo Puppet Comply Now

When it comes to compliance, knowledge really is power. See automated compliance scanning in action on your systems with a free demo.

SCHEDULE A DEMO

Pairing CIS Benchmarks with Puppet’s powerful automation capabilities goes a long way towards a more compliant and secure infrastructure.

How to Enforce CIS Benchmarks with Puppet

If you were to go away and start writing Puppet code to apply all those rules, your colleagues would not see you for a long time! Fortunately a lot of the work has already been done in the Puppet Forge module fervid/secure_linux_cis. We're going to take a look at how you can quickly apply the server Level 1 CIS Benchmark.

What Does the secure_linux_cis Module Actually Give Us?

1. The first thing the Secure Linux CIS Module gives us is the CIS Benchmarks as rule sets, so if we want to apply the server Level 1 Benchmark we can just use that rule set to get all the CIS rule numbers.
2. The Secure Linux CIS Module maps each CIS rule number to a rule name via a class.
3. The Secure Linux CIS Module provides a class that implements all those individual rule classes.

How Are We Going to Apply the secure_linux_cis Module?

We could just add the class to a node's classification and we'd get the full CIS Benchmark applied, but what happens if you're running an online business? Shutting down our Squid Proxy (rule 2.2.13) on your web servers might be a bit of a disaster.

What if your developers like to access their systems via a desktop interface? If we disable X11 forwarding (rule 5.2.4) in development we could cause them a problem, but we don't want it enabled in production.

And what if the company standard for file sharing is Samba (rule 2.2.12)?

How Are We Going to Apply the secure_linux_cis module Without Breaking Everything?

We're going to need to apply some customizations. It might be tempting to copy the module and start customizing the code directly, but that'll give us a headache when a new version is released. We'll leave the module intact and add an abstraction layer, a profile.

The module already uses Hiera as a parameter lookup so it makes sense for us to do the same. We could put everything into our control-repo Hiera and leverage our current hierarchy, but we're going to do something different (reasons explained later). Instead, we're going to create a profile module (as opposed to a component module). We’ll call our new module cis_profile; it’s a catchy name that tells us exactly what it does. This module is going to be the location for all our Hiera data. You can only do this with version Hiera 5 or later.

DevOps & Security: Sworn Enemies? Not anymore. Read our free eBook to turn your DevOps into a security advantage. DOWNLOAD EBOOK

The CIS module uses its own Hiera lookup to get the CIS rule set for any given operating system and passes it as a parameter to the class that implements the rules. We could copy that rule set and customize it for each application or environment, but that would give us a few problems.

1. If we modify that rule set, we can't continue to call it a CIS rule set; it's now our own customized rule set.
2. It's not a very layered approach. In our original example, we want a set of rules for our web server in production and a few less rules in development. We're not really taking advantage of Hiera.
3. How do we track what rules we've removed? The security team is going to be asking not what CIS rules are we applying, but what rules we're not applying -- and more importantly, why.

fervid/secure_linux_cis helps us out here because it has exclude rules. This means we can apply the CIS Benchmark to everything as defined in the module, then our implementation of the module can provide the exclude rules. We can exclude the HTTP proxy rule on our web servers and exclude the X11 rule in development. Instead of a big list of rules we're applying, we should have a very short list of rules we're not applying.

Let's take our original example of Squid, X11 and Samba. How might that look as a set of exclude rules in hiera?

First we need to configure the Hiera strategy our module is going to use. Unlike looking up an NTP server IP address, we don't want it to stop looking at the first positive result. We want to collect all the rules we want to exclude. We also don't want any duplicates so a unique merge is going to be the strategy for us; we can specify that in cis_profile/data/common.yaml. We also have that company-wide requirement to enable Samba, so we can put that in common.yaml too so everything gets that exclusion.

---
lookup_options:
  cis_profile::exclude_rules:
    merge: unique
# 2.2.12 Ensure Samba is not enabled (Scored)
# Excluded to allow company wide file share system.
cis_profile::exclude_rules:
  - secure_linux_cis::distribution::centos7::cis_2_2_12

Next we want to add an exclusion for X11 forwarding in development so we'll put that in cis_profile/data/environment/development.yaml.

# 5.2.4 Ensure SSH X11 forwarding is disabled (Scored)
# Enabled in development for debugging.
cis_profile::exclude_rules:
  - secure_linux_cis::distribution::centos7::cis_5_2_4

Finally, we want to allow HTTP proxy on our web server cis_profile/data/nodes/apache01.example.com.yaml.

# 2.2.13 Ensure HTTP Proxy Server is not enabled (Scored)
# See Security exception number:1234
cis_profile::exclude_rules:
  - secure_linux_cis::distribution::centos7::cis_2_2_13

We'll need to create a hierarchy that'll use facts on our machines to collect all those exclusions, starting with our common ones, the ones for our environment, and finally the ones for a specific node so our cis_profile/hiera.yaml will look something like this.

---
version: 5
defaults:
  datadir: 'data'
  data_hash: 'yaml_data'
hierarchy:
  - name: 'Node'
    path: "nodes/%{::trusted.certname}.yaml"
  - name: 'environment'
    path: "environment/%{::environment}.yaml"
  - name: 'common'
    path: 'common.yaml'

Finally, we're going to need a class, cis_profile/manifests/init.pp; it'll get all the exclude rules Hiera found for us and pass them into fervid/secure_linux_cis via $exclude_rules.

class cis_profile (
  Enum['firewall', 'firewalld']           $firewall_package        = 'firewalld',
  Enum['1', '2']                          $enforcement_level       = '1',
  Array[String]                           $exclude_rules           = [],
){
  class {'::secure_linux_cis':
    time_servers      => ['time1.google.com', 'time1.google.com'],
    profile_type      => 'server',
    allow_users       => ['centos'],
    firewall_package  => $firewall_package,
    enforcement_level => $enforcement_level,
    exclude_rules     => $exclude_rules,
  }
}

Apply It to a Node

I have a node which passes all the server_level_1 checks so I'll go in and make the following changes:

• Enable Squid
• Enable Samba
• Make /etc/crontab world read/write and make it owned by the centos user.
• Edit /etc/ssh/sshd_config and set X11Forwarding to yes

Then I'll run Puppet; here's what we get:

[root@apache01 ~]# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for apache01.example.com.yaml
Info: Applying configuration version 'peserver-production-b96c97c9a3b'
Notice: /Stage[main]/Secure_linux_cis::Rules::Ensure_permissions_on_etc_crontab_are_configured/File[/etc/crontab]/owner: owner changed 'centos' to 'root' (corrective)
Notice: /Stage[main]/Secure_linux_cis::Rules::Ensure_permissions_on_etc_crontab_are_configured/File[/etc/crontab]/group: group changed 'centos' to 'root' (corrective)
Notice: /Stage[main]/Secure_linux_cis::Rules::Ensure_permissions_on_etc_crontab_are_configured/File[/etc/crontab]/mode: mode changed '0777' to '0600' (corrective)
Notice: Applied catalog in 0.08 seconds

This is my development web server so we've got the exceptions above in place, we can see Samba, Squid and the sshd configuration were not touched, but there is no exception for the crontab rules so the CIS module has corrected its permissions and ownership.

So, That Good Reason for Using a Profile Module...

Because of the way we've implemented the exclude rules, Hiera now only contains our exceptions. It also tells us exactly where those exceptions are, what server they are on, which environment they are in, etc. Our Hiera data has become our CIS audit document and it's not hidden amongst any other data like NTP server IP addresses or public ssh keys.

This is all related to security. A standard change control board may not be appropriate. Pulling this data out of the control-repo allows us to have a very specific set of approvers for changes. We don't even need to use Hiera, we could use a different backend such as a CMDB to provide our exclude rules. In fact, we could hand this entire profile to our security team to maintain.

Getting Started

As I said at the start, there are 186 server_level_1 tests for a CentOS 7 machine. Some of those tests have dependencies; for example, the contab test requires puppetlabs/cron. You may be using a different cron module or even have written your own. You're also likely to find some things are already managed in your own baseline and that's going to give a duplicate resource declaration error. This can add up to a screen full of errors that can be overwhelming but a simple strategy to get started can help you out. Copy the entire server_level_1 test list into your exclude list. It sounds a bit excessive, but there is some logic in there.

You're now applying the CIS standard and you now have a list of all the standards you're not enforcing. It's not a bad place to be on day 1 of CIS enforcement.

Now you have your exclude list that you can work through, removing the tests you want to enforce.

Careful, There Is a Little Gotcha

If you find yourself scratching your head after modifying the exclude list, running

puppet agent -t

and not seeing any changes, don't worry. Some of the tests eat up a not insignificant amount of CPU during the enforcement, so there is a scheduler that by default only applies the module once every hour. For testing you may want to add the following to your Hiera lookup with some more suitable values:

secure_linux_cis::hardening_schedule:
  period: hourly
  repeat: 2

These parameters are passed to the Resource Type: schedule.

Learn more

• My cis_profile
• Watch the webinar on 5 Simple Ways to Manage Endpoints with Puppet Enterprise
• Check out this podcast episode with insights from a Puppet debugger
• Read about the importance of Governance, Risk, and Compliance (GRC)
• CentOS 8 is end-of-life (EOL): What now?

Not Using Puppet Yet?

Get started with your free trial of Puppet Enterprise today.

START MY TRIAL

This blog was originally published in two parts on March 9, 2021 and July 23, 2021. It has since been consolidated and updated for relevance. 

Learn More

• Learn about using tools to secure and optimize processes at scale with Perforce's enterprise automation 101