As you have now understood the basis of scanning with the oscap command-line tool, it will be easy to set up regular scanning with the OpenSCAP Daemon as the techniques involved are the same. Assuming that you have already installed the daemon, as we discussed earlier, it is fairly easy to create automated scans, although, at the time of writing, the OpenSCAP Daemon does not run on Ubuntu Server 18.04. This is a result of a missing CPE file, which, to date, has not been rectified, and although this did not impact our use of the oscap command-line tool (though those of who are eagle-eyed will have noticed an error relating to this file at the end of the scan), it does prevent the OpenSCAP Daemon from starting.

As a result, the examples in this section will be based on CentOS 7 only—however, the procedure would be broadly similar on Ubuntu Server 18.04 when the OpenSCAP packages are fixed. In fact, this issue, which was first reported in October 2017 according to the ComplianceAsCode GitHub project, seems to be relatively long-standing and so is an excellent reason to make use of Ansible in conjunction with the oscap tool for your scanning needs.

When this Ubuntu related issue is fixed, you will be able to schedule scans for both CentOS and Ubuntu hosts from one central scanning host using the process outlined in this chapter. Note that the SSG files for all of your hosts (be they CentOS, RHEL, or Ubuntu) must live on the same host as the OpenSCAP Daemon – they are copied across to each host to be scanned whenever a scan is run by the OpenSCAP Daemon, and so do not need to be deployed on every host.

Nonetheless, if you want to set up a scheduled scan using the OpenSCAP Daemon, the easiest way to do this is by using the oscapd-cli tool in interactive mode:

1. This is achieved by invoking oscapd-cli with the following parameters:

$ sudo oscapd-cli task-create -i

2. This launches a text-based guided configuration that you can easily complete—the following screenshot shows an example of how I set up the daemon to run a daily scan on my CentOS 7 test system:

Most of the steps in that interactive setup should be self-explanatory—however, you will note a step that asks about Online remediation. The OpenSCAP profiles include the capability to automatically rectify any compliance issues they find as they go through the scan. It is up to you whether you wish to enable this or not, as this will depend on whether you feel happy with an automated process making changes to your systems, even for security purposes. You may want to separate your audit tasks from your policy enforcement tasks, in which case you would use Ansible for the remediation steps. 

3. Once you have enabled the scan, you will find that, at the scheduled time, it deposits the scan results in /var/lib/oscapd/results. Under this, you will find a numbered subdirectory that corresponds to the task ID you were given when you created the task (1, in the preceding screenshot), and then under another numbered directory, which is the scan number. Hence, the results for the first scan for task ID 1 will be found in /var/lib/oscapd/results/1/1.
4. When you examine the contents of this directory, you will notice that the results are only stored in an XML file, which, while suited for further processing, is not very readable. Fortunately, the oscap tool that we looked at previously can easily convert scan results into human-readable HTML—for this result, we would run the following command:

$ sudo oscap xccdf generate report --output /var/www/html/report-oscapd.html /var/lib/oscapd/results/1/1/results.xml

Once this command has run, you can view the HTML report in your web browser just as we did earlier in this chapter. Of course, if you aren't running a web server on this machine, you can simply copy the HTML report to a host that has one (or even open it locally on your computer).

The beauty of setting up the OpenSCAP Daemon is that, unlike the oscap tool, it can scan remote hosts as well as the local one. This scanning is performed over SSH, and you must ensure that you have set up passwordless SSH access from the server running the OpenSCAP Daemon to the remote host. If you are using an unprivileged account to log in, you should also ensure that the account has sudo access, again without requiring a password. This should be quite easy for any experienced system administrator to set up.

Once you have set up the remote access, configuring the OpenSCAP Daemon through the interactive task creation process is no more complex than for the local machine—the only difference this time around is that you need to specify the remote connection in this format:

ssh+sudo://<username>@<hostname>

If you are logging in directly as root (not recommended), you can leave out the +sudo part of the preceding string. Hence, to set up add another remote scan from my test server, I ran through the commands shown in the following screenshot:

As you can see, this creates task number 2 for this purpose. The advantage of this setup is that, once you have set up the SSH and sudo access, you can have one designated host that is responsible for scanning your entire estate of Linux servers. Also, the hosts being scanned only need the OpenSCAP libraries present—they do not need the OpenSCAP Daemon or the security policy files—these are automatically transferred to the hosts as part of the remote scanning process. 

The results of the scheduled scan are stored in XML format in the /var/lib/oscapd/results directory exactly as before and can be analyzed or converted into HTML as required.

The OpenSCAP Daemon is almost certainly your quickest and easiest route to scanning your infrastructure, and the fact that it collects and stores all of the results locally as well as uses security policies stored on its own filesystem means it is fairly resistant to tampering. For automated, ongoing SCAP-based scanning of your environment, the OpenSCAP Daemon is almost certainly your best choice, and you could always create a cron job to automatically convert the XML results into HTML and put them into your web server root directory so that they can be viewed.

Last but not least, in the next section, we will look at the SCAP Workbench tool and see how that can help you with your security auditing.