As we discussed earlier in this chapter, the oscap tool is a command-line utility designed for scanning the local machine that it is installed on. The security policies that you wish to audit the host against must also be on the filesystem of the host that it runs on. If you have completed the steps in the section entitled Evaluating and selecting policies, then you should already have everything you need.

With that said, if using the oscap tool to scan your infrastructure is going to be your way forward, you may wish to consider Ansible as a tool to both install it and gather the results when the scan is complete.

Before we come to this, let's look at how we might scan a single host:

1. Assuming that we are working on our Ubuntu 18.04 server and that we have unpacked the latest upstream SSG into our current working directory so that we have the required Ubuntu 18.04 support, we would use the oscap info command to query the XCCDF policy file to see which policies are available to us:

$ oscap info scap-security-guide-0.1.47/ssg-ubuntu1804-ds.xml

The output of the info command will yield something like that shown in the following screenshot:

2. From here, we will choose the profile (or profiles—after all, you could always run more than one scan) that you wish to audit against. In our case, we are running a general-purpose server, so we will choose the profile with Id: xccdf_org.ssgproject.content_profile_standard.

3. To run this scan, and save the output in a human-readable HTML report, you would then run a command such as the following:

$ sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard --report /var/www/html/report.html ./scap-security-guide-0.1.47/ssg-ubuntu1804-ds.xml

We must run this command using sudo, as it requires access to some core system files that would not otherwise be accessible. The scan runs and produces a nice human-readable output on the screen, an example of which is shown in the following screenshot:

As you can see, the XCCDF policy produces a highly readable output, with a clear pass/fail result for each test. Hence, even within these first few lines of the output, you can see that our test system is not compliant in several areas.

Furthermore, the oscap command has also generated a nice HTML report that we have put into the web root of this server. Of course, you wouldn't do this in a production environment—the last thing you'd want to do is publicize any security issues with your server! However, you could send this report to your IT Security team, and if you were running OSCAP using an Ansible playbook, Ansible could copy the report from the remote server to a known place where the reports can be collated.

A portion of this HTML report is shown in the following screenshot—you can see how readable it is. Further, even at a quick glance, someone non-technical can see that this system fails compliance tests and needs remedial steps:

Suddenly, it becomes apparent how powerful this tool is, and why you would wish to use it to scan your infrastructure! In addition to this report, we can also check the patch status of our test system using the com.ubuntu.bionic.cve.oval.xml policy that we downloaded in the section entitled Installing other OpenSCAP policies. As we discussed, OVAL policies do not produce reports that are as readable as XCCDF reports, but nonetheless they are still incredibly valuable. To scan our Ubuntu system to see whether it is missing any critical security patches, you would run this:

$ sudo oscap oval eval --report /var/www/html/report-patching.html com.ubuntu.bionic.cve.oval.xml

As shown in the following screenshot, the output is not as readable as the XCCDF output and needs a little more interpretation. In short, the false result means that the machine being scanned does not fail the compliance test, and so infers that the requisite patch has already been applied, whereas true means that a patch is missing from the system:

Once again, however, the HTML report comes to our rescue—to start with, it has a summary section at the top, which shows that our system has a total of 432 detected package vulnerabilities, but also 8,468 test passes. Hence, we urgently need to apply patches to fix known security vulnerabilities, as we understood by the policy file we ran the audit against:

Of course, it is highly important to download an updated copy of this policy regularly to ensure that it is up to date. If you drill down into the report, you will see that, for each check, there is a cross-reference CVE vulnerability report so you can find out which vulnerabilities your system exhibits:

Just through these few examples, I'm sure you can see how valuable these reports are and how they could be easily reviewed by an IT Security team without any specific Linux command-line knowledge.

The process for running OSCAP-based scans on CentOS or RHEL is broadly similar:

1. Assuming that you are using the SSG policy packaged by your operating system vendor and included with the OS, you would query the XCCDF profiles so that you know which to run against:

$ oscap info /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml

2. You can then run an XCCDF-based scan in exactly the same way as we did on Ubuntu—here, we are choosing the standard profile to scan our system with:

$ sudo oscap xccdf eval --fetch-remote-resources --report /var/www/html/report.html --profile standard /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml

You will observe the presence of the --fetch-remote-resources flag here too—this is used because the CentOS 7 policy requires some additional content that it downloads directly from Red Hat so that it is always working with the most up-to-date copy. The scan runs in much the same way as before, producing the same human-readable report. One thing you will see as the scan runs is that many of the tests return notapplicable—unfortunately, the CentOS 7 security policy is very much a work in progress and the version included with CentOS 7 at the time of writing does not include complete support for this operating system. This demonstrates how pedantic OpenSCAP policies can be—most CentOS 7 security requirements will apply equally to RHEL 7 and vice versa, yet the policies are coded to work very specifically with certain operating systems. The following screenshot shows the scan in progress and the aforementioned notapplicable test results:

In spite of this, the audit still reveals some valuable insights—for example, as we can see from the following screenshot of the HTML report, we have accidentally allowed accounts with empty passwords to log in:

If you are running CentOS 7 specifically, you will not receive vendor support from Red Hat, and so it is worth trying the upstream SSG policy as the support for operating systems such as CentOS and Ubuntu is improving all the time (as we saw earlier in this section when we audited our Ubuntu Server 18.04 host). Rerunning the exact same scan but using SSG 0.1.47, our scan results look quite different:

This just highlights the importance of understanding the policy you are using and making sure that you download the right version for your situation. If you are using RHEL 7, you would be advised to make use of the packages supplied by Red Hat, whereas with CentOS 7 and Ubuntu Server 18.04, you would be better off trying the latest version from the upstream GitHub repository. Indeed, the following screenshot shows the results of the exact same scan on our CentOS 7 test system using the version 0.1.47 SSG, and we can see that this time, we have run a total of 958 tests and have a much clearer understanding of the security of our server:

On CentOS 7, you can also run the OVAL scan for package vulnerabilities in the same manner that we did with Ubuntu Server, but using the com.redhat.rhsa-RHEL7.xml file that we downloaded previously. Just as we did on Ubuntu Server, we would run this scan with this command:

$ sudo oscap oval eval --report /var/www/html/report-patching.html com.redhat.rhsa-RHEL7.xml

The report is interpreted in exactly the same way as on Ubuntu, and if we refer directly to the HTML report, we can see that this system is fully patched against known package vulnerabilities at this time:

This wraps up our look at the oscap command-line tool, but by now you should have all of the information you need to run your own scans regularly. Automating this process is left as an exercise for you, but here are some tips on what I would consider a good Ansible solution:

• Use the yum or apt modules to install the required OpenSCAP packages on the server before performing any other tasks.
• Use the get_url module to download SSG and/or the package vulnerability OVAL definition file to ensure you have the most up-to-date copy (except on RHEL 7, where you would use the version supplied by Red Hat). Use the unarchive module to unzip the file you downloaded.
• Run the OSCAP scan using the shell module.
• Use the fetch module to grab a copy of the HTML report(s) for distribution and analysis.

In the next section, we will look at running scheduled regular scans using the OpenSCAP Daemon.