Today we’ve released an initial version of audit-cis. This is an “audit mode only” cookbook that runs on a node to check for compliance with The Center for Internet Security (CIS) benchmark for a specific platform. This release targets CentOS 7, CIS Benchmark version 1.0.0.
CIS Benchmarks are consensus based security recommendations for various operating systems, platform distributions, or commonly used applications. They have a scoring system, and two levels. The cookbook implements control groups and controls for the various sections of the benchmark, using the “audit” steps implemented in Chef’s audit mode controls. For example, 1.2.2 in the CentOS 7 benchmark says “verify that gpgcheck is globally activated.” To audit that the system complies, the benchmark says:
% grep ^gpgcheck /etc/yum.conf gpgcheck=1
Implemented in audit mode, that is an it block within a control block, which is within a control_group block.
control_group '1 Install Updates, Patches and Additional Security Software' do
control '1.2 Configure Software Updates' do
it '1.2.2 Verify that gpgcheck is Globally Activated' do
expect(file('/etc/yum.conf').content).to match(/^gpgcheck=1/)
end
end
end
Chef Audit Mode is a feature of Chef introduced in version 12.1. It implements new Chef Recipe DSL methods, control_group and control for performing audit validations using Serverspec (and thus RSpec). Chef audit mode can be used with Chef Analytics for further analysis, or rules that send notifications.
Read more about audit mode in the Chef Documentation
* Chef Analytics and controls
* Chef Analytics and audit mode
* Chef Recipe DSL and controls
No. While audit mode is related to Chef Analytics, you do not need Chef Analytics to use it. In fact, the audit-cis cookbook itself has a test kitchen configuration that allows it to run in isolation for testing purposes.
However, to achieve the full benefits of Audit Mode, Chef Analytics is recommended. Users can implement analytics rules to ignore validations that fail, or send notifications on the ones that are of particular interest.
As of the initial release, CentOS 7 is supported by audit-cis, with its centos7-v100 recipe. We plan to add more popular platforms as recipes, such as older versions of CentOS, plus Ubuntu, and Windows.
You may notice a lot of repetition in reading these recipes. This is for two main reasons. First, each individual platform and version is different; they have their own separate benchmarks published by CIS. Second, auditing, in a security and compliance perspective, is very prescriptive, and requires careful wording, language, and serves as documentation that must be clear. While it may mean more work for ongoing maintenance, we feel that it will result in higher quality audit mode controls that will be more clear to read and understand.
Include the recipe for the platform and benchmark version you wish to validate on your nodes’ run lists. For example, recipe[audit-cis::centos7-100] to validate CIS Benchmark for CentOS 7, version 1.0.0.
Then, enable audit mode in your /etc/chef/client.rb. You can set it to :enabled, where Chef will converge the node and then run the controls, or to :audit_only where Chef will not attempt to converge any resources, but will run the controls.
audit_mode :enabled # or, audit_mode :audit_only
You can also use the --audit-mode argument to chef-client, for example: chef-client --audit-mode enabled or chef-client --audit-mode audit-only.
The test kitchen config, .kitchen.yml can also be used for reference.
Simply put, base OS image/installations are not compliant with the CIS benchmarks by default. For example, the CentOS 7 benchmark calls for mounting specific partitions for filesystems that are not part of the base CentOS 7 kickstart from installation media, such as /var, /var/log, or /var/log/audit. Some sites accept the risk of having certain failures for business reasons, such as running services that are recommended to be disabled. This is where Chef Analytics is useful, users can filter with rules against the controls that are relevant for their individual security policies.
Another reason for many of the failures is because “Level 2” profile applicability is enabled by default. This is one of the few (two as of this initial release) attributes to control behavior in the cookbook.
No.
The whole benchmark is implemented for audit mode. To filter out controls or tests, use Chef Analytics rules for the ones that are within local security policy (accepted risk).
You’ll need to implement your own recipes in cookbooks that perform the remediation steps. This cookbook’s recipes are “audit mode only” – that is, they do not converge any resources. Some cookbooks on Supermarket may be useful for remediation purposes, but local customization for individual site/organization security policy is almost certainly required.
It’s not feasible for us to account for every security policy exemption or implementation. While we could write a recipe that implements the remediation steps for every single check in the benchmark, many things fall in line with topics that could be handled by a task or topic specific cookbook. For example, section 6.2 “Configure SSH” could be handled by the openssh cookbook.
That said, in the future for testing purposes, we plan to implement a test cookbook that has platform/platform version and CIS Benchmark specific recipes to ensure a clean run using the base boxes in Test Kitchen.
If you encounter problems with the audit mode recipes in this cookbook, report them in this repository.
You can download it from Supermarket directly, or with your favorite dependency resolution tool. If you want to test it within test kitchen, ensure that you have test-kitchen 1.4.0 or higher.