Let's take a practical example to explore CIS Benchmarks in greater detail by looking at the one for RHEL 7. At the time of writing, this is on release version 2.2.0 and consists of 386 pages! Thus, immediately we can see that implementing this benchmark is unlikely to be a trivial activity.
As you explore the document, you will find that the section of most interest to us—the Recommendations section—is divided into subsections. Each of these focuses on a specific area of security within the operating system. At the time of writing, section 1 is all about the initial setup of the operating system; parameters and configuration likely to be applied at build time. Section 2 is all about securing common services that might be installed by default on a RHEL 7 server. Section 3 deals with network configuration, while section 4 goes into detail on your logging and audit logging setup to ensure you are capturing the requisite amount of data during daily use. This is to ensure you can audit your servers and find out what happened if you are unfortunate enough to suffer a breach or an outage. Section 5 considers access to your server and authentication (this is where you will find SSH server security mentioned—in fact, you will see that our example of disabling remote root logins is benchmark 5.2.8 in version 2.2.0 of the document). Finally, section 6 is entitled System Maintenance and is intended to be run not once, but regularly, to ensure the integrity of the system.
Of course, we have discussed previously in this book that it is possible for anyone with root privileges to change core system configuration, and thus it is recommended that all of the benchmarks be run (or at least checked) on a regular basis to ensure compliance with the original policy.
We will explore this across the next two chapters of this book; however, for now, let's return to furthering our understanding of the CIS Benchmark itself. As you look into each recommendation, you will notice that each has a level associated with it and is either Scored or Not Scored (this is stated in the title of each benchmark).
Each of these benchmarks are intended to contribute to a final report or scoring of a system as part of a compliance check—and recommendations that are scored quite literally contribute to the final score. Thus, if your system meets the check, then the final score is increased—however, if it is not met, the final score is decreased. Those marked as Not Scored have no bearing on the final score at all. In other words, you are not marked down for failing to implement them.
This, of course, does not mean they are any less important to consider. By way of example, let's consider benchmark 3.7 of the version 2.2.0 RHEL 7 benchmark, which is entitled Ensure wireless interfaces are disabled. The rationale between each benchmark is given in the details of the benchmark, and this one states the following:
This is a logical approach—we know that if your device has a wireless interface, it should be disabled unless it is in use. In addition, wireless security protocols have been historically broken, just as SSLv2 was, and thus, in the long term, wireless network communication might not be considered to be truly secure. Nonetheless, on a corporate laptop running RHEL 7, you cannot guarantee that it will be connected to a wired network connection. Wireless networking might be the only option and, in this instance, you would need to leave it turned on.
Of course, the CIS Benchmark cannot make this decision for you—only you can know whether your system needs to have its wireless network adapters enabled (if present), and so it is reasonable that this is a non-scorable item.
By contrast, our old friend benchmark 5.2.8 (disabling remote root SSH access) is scored as there should be no rational reason for enabling this in an enterprise environment. Thus, we would expect our system to be scored down if this benchmark could not be met.
Each benchmark has details on how to test for the presence of the condition or configuration mentioned, along with the details on how to apply the desired configuration.
In addition to these details, you will also note that each benchmark has a level associated with it that can be either 1 or 2. In each case, for RHEL 7, you will see that these levels are applied to two different scenarios—the use of RHEL 7 as a server and as a workstation. Again, this makes sense when we delve into the meaning of these levels.
Level 1 is intended to be a sensible security baseline for you to apply to your environment to reduce the attack surface. It is not intended to have an extensive impact on the day-to-day business usage of your Linux environment, and so level 1 benchmarks are the less intrusive ones to implement.
By contrast, level 2 benchmarks are offered to provide a much more rigorous level of security, and are highly likely to have an impact on the day-to-day usage of your environment.
If we look again at benchmark 3.7, we will see that it is categorized as level 1 for servers and level 2 for workstations. This makes sense—a server is unlikely to have a wireless network adapter, and even less likely to be using it, even if present, thus disabling it has little or no impact on the day-to-day usage of the server. However, a RHEL 7 laptop would become a lot less portable if benchmark 3.7 was implemented on it, and so the level 2 categorization warns us of this. Imagine having a laptop and not being able to use it on a wireless network—this is a concept that, to many, is unfeasible in this day and age!
Benchmark 5.2.8 is considered level 1 for both server and workstation because it is already considered good practice not to use the root account for day-to-day operations—thus, disabling access to it over SSH should not have any impact on a day-to-day basis.
In an ideal world, you should read and understand all benchmarks before you apply them in case they have an impact on your way of doing things—for example, I still come across systems that make use of the root account over SSH for scripted operations, and while my first task is normally to rectify this, if I were to blindly apply the CIS Benchmark to these systems, I would break an otherwise working setup.
However, accepting that anyone who manages an Enterprise Linux environment is incredibly busy, you could be forgiven for thinking that you could just apply the scored level 1 benchmarks to your systems. Indeed, this would give you a reasonable security baseline while incurring a relatively low risk—yet there is no substitute for being thorough. In the next section of this chapter, we will look in greater detail at how to wisely select benchmarks without causing issues in your environment!