The SCAP benchmarks are available as ZIP downloads on this site as well. The DISA SCAP scan is only available to those with a DoD CAC and can be downloaded from the DoD Cyber Exchange NIPR site. See the URL above for more information. You use the benchmark files to load into the SCAP scanner and that allows the scan to match against good known security standards. The results of a SCAP scan can be exported as an XCCDF format XML file and then imported into a Checklist using a tool such as STIG viewer or OpenRMF OSS to create an actual checklist of findings.
And the OpenSCAP tool at -scap.org/ also produces SCAP results that OpenRMF OSS can take in and use to create STIG Checklists from your scan results. This is as of version 1.4 and later of OpenRMF OSS.
The benchmarks, offered free for CIS members in the form of PDFs, are not directly usable by a scanning tool, but they are human readable. They do offer some benchmarks in an XCCDF1 format, that can be used by tools, but they are reserved for paying members. These benchmarks, even if they were to be available, do not contain the automation and remediation steps required to change a server state to reach compliance. That is why Red Hat produces the scap-security-guidelines package, which contains what is necessary to scan for compliance, automate and remediate the results.
[1] As explained by the National Institute of Standards and Technologies (NIST), XCCDF is a specification language for writing security checklists, benchmarks, and related kinds of documents. An XCCDF document represents a structured collection of security configuration rules for some set of target systems.
Red Hat has provided the CIS Benchmark for Red Hat Enterprise Linux (RHEL) with the scap-security-guide RPM since RHEL 8.3. This provides a number of capabilities for organisations to adopt the CIS Benchmark for RHEL:
Let's use the OpenSCAP tooling available with Red Hat Enterprise Linux (RHEL) to scan a system using the CIS benchmark. Firstly, you'll need to install the scap-security-guide and openscap-scanner RPMs:
The scap-security-guide RPM provides Ansible playbooks, SCAP profiles (in XML format), and kickstart snippets, which can be used to remediate, scan and provision systems hardened against the CIS Benchmarks. Here's a listing of the Ansible playbooks and Kickstart snippets for the CIS Benchmarks, as well as the SCAP datastream file containing the XCCDF profiles.
There's four CIS Benchmarks shipped with Red Hat Enterprise Linux (RHEL), and I'm going to perform a scan using the CIS Red Hat Enterprise Linux 9 Benchmark for Level 2 - Server profile. I can simply use the oscap CLI to kick this off:
I can use the oscap-podman tool to perform a CIS scan of a container image, similar to how we scanned a RHEL system. To scan a Red Hat Universal Base Image (UBI) with oscap-podman, I first need to pull it down:
You could use oscap-podman to do this with a customised SCAP profile, like we've done here. Or, you could create a new policy in Red Hat Advanced Cluster Security for Kubernetes (RHACS) that checks this at deployment and build-time, and can be integrated with CI/CD pipelines via roxctl. For example, here's a policy that checks whether the dnsmasq package is present in a container image:
I also looked at whether the benchmarks are applicable for container images. I think the answer is 'no' for a lot of controls, with the exception of those looking at package installation. I showed an example of a Red Hat Advanced Cluster Security for Kubernetes (RHACS) policy that can detect package installation during CI/CD pipeline builds or at deployment time.
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level1_server --results-arf arf.xml --report report.html /usr/share/ubuntu-scap-security-guides/1/benchmarks/ssg-ubuntu2004-ds.xml
# Run OpenSCAP to do compliance check and generate the html report with a specific file name.
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level1_server --results-arf arf.xml --report $1 /usr/share/ubuntu-scap-security-guides/1/benchmarks/ssg-ubuntu2004-ds.xml
The compliance tooling has two objectives: it lets our customers harden their Ubuntu systems effortlessly and then quickly audit those systems against the published CIS Ubuntu benchmarks. The SCAP content for audit tooling that scans the system for compliance is CIS certified.
Many enterprise solutions today are built upon complex distributed systems which are accessible to the users globally. Due to this global access, the security of the host platforms becomes critical. The platform administrators use security automation techniques such as those provided by Security Content Automation Protocol (SCAP) standards to protect the systems from the vulnerabilities that are reported daily; furthermore, they are responsible for keeping their systems compliant to the relevant security recommendations (governmental or industrial). Additionally, third party audit and certification processes are used to increase user trust in enterprise solutions. However, traditional audit and certification mechanisms are not continuous, that is, not frequent enough to deal with the daily reported vulnerabilities, and for that matter even auditors expect platform administrators to keep the systems updated. As a result, the end user is also forced to trust the platform administrators about the latest state of the platform. In this paper we develop an automated security audit and certification system (ASArP) which can be used by platform users or by third party auditors. We use security automation techniques for continuous monitoring of the platform security posture and make the results trustworthy by using trusted computing (TCG) techniques. The prototype development of ASArP validates the implementation feasibility; it also provides performance benchmarks which show that the ASArP based audit and certification can be done much more frequently (e.g. daily or weekly). The feasibility of ASArP based continuous audits is significantly better than traditional platform audits which are dependent on the physical presence of the auditors, thus making frequent audits much more expensive and operationally infeasible.
760c119bf3