Although we have seen the significant benefits that Ansible can bring to CIS Benchmark implementation, I'm sure it is apparent at this stage that development and maintenance of these policies could turn into a full-time job, especially when coupled with the need to run them against the infrastructure and manage the results of each run.

Fortunately, the spirit of open source development brings a solution to this dilemma. Imagine if someone had already spent a great deal of time and effort developing a high-quality set of Ansible roles for implementing CIS Benchmarks, and that this was available as open source code so that you could audit it, ensure it was fit for your environment, and tailor it easily if required. Further, imagine that they had put a great deal of time and effort into tagging each task, and adding appropriate variable structure to allow you to easily specify your choices such as which time synchronization service your enterprise uses.

Thankfully, this work has already been completed by MindPoint Group, and their code has been made freely available on GitHub at https://github.com/MindPointGroup/RHEL7-CIS.

In addition to this, just as users of Ubuntu may choose paid support or to use the free open source operating system, and EL7 users may choose between Red Hat Enterprise Linux 7 or CentOS 7, MindPoint Group also offers a commercially supported version of their Ansible hardening code, available via https://www.lockdownenterprise.com/. Thus, they offer support for both ends of the spectrum, respecting that some enterprises will absolutely require an enterprise support contract, while others will prefer to use freely available open source software.

Let's explore how we might use the open source code against our CentOS 7 server:

1. First of all, we need to clone the GitHub repository:

$ cd roles
$ git clone https://github.com/MindPointGroup/RHEL7-CIS.git
$ cd ..

2. Once this is complete, we can then proceed to use the code exactly as we would use any other role. Where appropriate, we should set variables, which can be set either in the inventory or in the main playbook (more on this in a second).

Thus, the purest and simplest possible implementation of the MindPoint Group CIS Benchmark in Ansible once the role has been cloned from GitHub is a playbook that looks like this:

---
- name: Implement EL7 CIS benchmark
  hosts: all
  become: yes

  roles:
    - RHEL7-CIS

3. With these steps complete, you can literally begin implementing the EL7 benchmark and its near 400 recommendations on your Linux servers in a matter of minutes – the playbook is run in the normal manner, and will produce many pages of output as all the checks are performed and recommendations implemented (if/when required). The following screenshot shows the playbook being run and the initial page of output:

Now, a word on variables. As we established in the previous section (Writing Ansible security policies), there will be occasions where you need to vary your playbook run. The variables and tags are all documented in the README.md file that accompanies the GitHub repository we cloned earlier, and for purposes of illustration, let's consider a few examples.

First off, suppose we only want to implement the level 1 recommendations (those that are less risky to day-to-day operations). This can be achieved by running the playbook and using the level1 tag:

$ ansible-playbook -i hosts site.yml --tags=level1

Alternatively, you might be running the hardening playbooks against a set of servers that act as routers. In this instance, we would need to set the rhel7cis_is_router variable to false to ensure that kernel parameters that disable router functionality are not set.

This could be done on the command line as follows:

$ ansible-playbook -i hosts site.yml -e rhel7cis_is_router=true

However, this is very manual, and it would be far too easy for someone to accidentally run the playbook without setting this variable, suddenly disabling the router.

It would be far better to set this variable at the inventory level, thus ensuring that it is always set correctly whenever the playbook is run. Thus, we might create an inventory such as this:

[routers]
router-testhost

[routers:vars]
rhel7cis_is_router=true

With this inventory in place, running the playbook against the routers is performed using a command such as the following:

$ ansible-playbook -i routers site.yml

As long as this inventory file is used, there is no danger of someone forgetting to set the rhel7cis_is_router variable to true.

Of course, this discussion does not mean that you must download and use these playbooks – it is still entirely possible to develop and maintain your own playbooks to your own requirements. Indeed, there may be situations in which this strategy is actually preferable.

What is important is that you choose the strategy that is best for your enterprise. When selecting your strategy for implementing security policy at scale, you should take the following into account:

• Whether you want to own your own code (with all the advantages and disadvantages that brings)
• Whether you want to be responsible for the maintenance of your code base going forward
• That you should standardize on one code base as far as possible to ensure your code structure remains maintainable
• Whether you need third-party support on implementing these benchmarks or whether you are happy that you have the skills and resources in-house

Once you have made your evaluation, you will be well placed to define your path forward with creating Ansible playbooks to implement your chosen security standards. It is intended that the information provided to you in this chapter so far will be sufficient to support you in whichever path you choose. Although we have focused on EL7 (Red Hat Enterprise Linux 7 and CentOS 7) in this chapter, everything we have discussed will scale well to other operating systems for which there exist security benchmarks (for example, Ubuntu Server 18.04). In fact, if you run through the processes we have discussed within this chapter using the CIS Benchmark for Ubuntu Server 18.04, you will find a great deal of similarity can be achieved.

So far, we have dealt almost exclusively with the implementation of CIS Benchmarks. This chapter would not be complete, however, without providing a method to check levels of enforcement without the need to make changes. After all, auditing is an important part of most enterprise policies, especially where security is concerned, yet changes must be made under an authorized change request window.