The CIS (Center for Internet Security) produces various cyber security related services. In particular, it produces benchmarks, which are “configuration guidelines for various technology groups to safeguard systems against today evolving cyber threat" in the words of the CIS.
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.
In the following illustration one can see that, at the time of writing, CIS has made one version benchmark available for Red Hat Enterprise Linux (RHEL) 8, version 1.0.0.
The OpenSCAP ecosystem provides multiple tools to assist administrators and auditors with assessment, measurement, and enforcement of security baselines. The OpenSCAP project provides a variety of hardening guides and configuration baselines developed by the open source community, allowing you to choose a security policy that best suits the needs of your organization, regardless of its size.
There is a dedicated security team at Red Hat managing the related packages, in particular:
openscap-scanner: The scanner (it contains the tool
scap-security-guide: This contains the "source datastream" files containing the profiles, and the files required for remediation like Red Hat Ansible Automation Platform playbooks or Bash scripts.
scap-workbench: The GUI allowing modifications of the policies, among other features.
For the following explanation it is required to install these packages using
Optionally, you can install another package called
scap-workbench. It is a GUI, which allows modifications of the policies, among other features that won’t be covered in this blog post.
The command is:
yum install openscap-scanner scap-security-guide
From a RHEL 8.3 server, we can find more information about the
At the time of writing, the latest version of that package was:
You can check the content of the RPM using this command:
rpm -qlp scap-security-guide-0.1.48-7.el8.noarch.rpm
The package contains files that are used for the supported remediation method Ansible, bash and anaconda:
/usr/share/scap-security-guide/ansible/ /usr/share/scap-security-guide/bash/ /usr/share/scap-security-guide/kickstart/Note: these files are managed by Red Hat OpenSCAP security team and used automatically by oscap tool when using the remediation feature. They are not meant to be modified by the user.
The other important files are the “DataStream” files, the scap content—the files containing the information to scan the system for compliance with a benchmark that can have several profiles.
/usr/share/xml/scap/ssg/content/ssg-rhel8-ds-1.2.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xmlAs seen, there are two files ending with
ds-1.2 means the data stream is SCAP version 1.2. The
ds means the data stream is SCAP version 1.3, which is currently the latest version.
We can use the latest version, so the relevant file is the one named
Read the data stream file containing profiles:
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml | grep "Title:"
oscap info --profiles /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
Get more information on the profile related to CIS, using the profile id (visible after the Title in the ssg-rhel8-ds.xml file):
oscap info --profile xccdf_org.ssgproject.content_profile_cis /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
An important piece of information is contained in the Description field: “Description: This baseline aligns to the Center for Internet Security Red Hat Enterprise Linux 8 Benchmark, v1.0.0, released 09-30-2019.”It means that is the profile which corresponds to CIS Benchmark version 1.0.0 for RHEL 8, the one and only at the time of writing. Using that with OpenSCAP will help ensure that the system based on RHEL 8.3 will be compliant with CIS Benchmark version 1.0.0.
Once that the profile required for scanning a RHEL 8 system for compliance with CIS Benchmark version 1.0.0 is identified, the OpenSCAP scanner can be used.
Generate a result file and a html report using OpenSCAP scanner tool:
oscap xccdf eval --profile xccdf_org.ssgproject.content_Optionally, the user can look at the resulting report in html format using a web browser:
profile_cis --results scan_results.xml --report scan_report.html /usr/share/xml/scap/ssg/ content/ssg-rhel8-ds.xml
Illustration showing how much a server is compliant with CIS Benchmark version 1.0.0 for RHEL 8
After that step, the system can be remediated automatically using the Ansible fix type (currently that appears to be the best or the more complete remediation unlike bash, puppet, anaconda):
oscap xccdf generate fix --fix-type ansible --output PlaybookToRemediate.yml --result-id "" scan_results.xml
--result-id “”’ means all the results are selected to be remediated.
At this point, the remediation file that we named
PlaybookToRemediate.yml is ready to be used in Ansible. It will run and apply all the required changes to ensure compliance with that CIS Benchmark version 1.0.0 for RHEL 8 systems. After that, the system should be more compliant.
Note: how to run an Ansible playbook is out of scope of this document. In a configure system with Ansible, it could be done by running the command
At this point, it is a good idea to run a compliance scan again to see the progress made:
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis --results scan_resultsAfterRemediation.xml --report scan_reportAfterRemediation.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
Note: At the moment the RHEL 8 CIS Profile doesn't cover 100% of what CIS requires, but after running the playbooks the report should be mostly green (~98%). In fact, at the time of writing, it has 270 rules related to CIS, most of them have their automated remediation.
In summary, we’ve showed you how to scan a RHEL 8.3 server for compliance with CIS Benchmark version 1.0.0 for RHEL 8 using the OpenSCAP tools provided within RHEL. Also, using Ansible Automation, we applied the remediation, resulting in a system more compliant with the same CIS benchmark. The work is almost done.
It is tempting to think that it is required to reach 100% compliance for the compliance scan to be considered successful. It is normal and acceptable that a server is not reaching 100% compliance. This comment, copied from the CIS website’s FAQ page, more clearly explains:
What if my CIS CSAT report is not 100% compliant?
That’s okay! It’s quite common for organizations not to be completely compliant with the recommendations found in the CIS Controls and this isn’t necessarily a devastating thing. Some controls may be unreasonable for your organization to deploy or you have compensating controls put in place. To help accommodate these nuanced issues, you have the option of identifying the Control as “not-applicable” which means the Control doesn’t count against you. In addition, there is an old adage that says, “You cannot manage what you cannot measure.” You may want to consider your first assessment as the starting point for your journey implementing the CIS Controls
In practice, the security teams are usually defining a threshold for a server to be considered successfully compliant with a benchmark.
Illustration showing a configuration page in cloud.redhat.com allowing the user to define a threshold for a system to be considered as compliant.
Is OpenSCAP available only in RHEL?
What if there are no profile for the given compliance, for example if CIS is missing?
Current versions of supported profiles for a given version of RHEL are included in the scap-security-guide package. It is possible to verify that the latest version of that package is deployed, and also a good idea to check that package's changelogs:
As with other Red Hat products, it is also possible to make a Request for Feature Enhancement (RFE) as explained in the article "The Request for Feature Enhancement (RFE) Process for Red Hat product suite."
What if there is a problem with the OpenSCAP tool or in the remediation?
A good approach could be to search for any existing bug that might have been reported already in the Red Hat bugzilla tool or to raise a support case. If an issue is clearly identified and has not been reported yet, it is recommended and helpful to open a new bug report.
As part of Red Hat open source philosophy, everyone can go to the OpenSCAP GitHub page and submit an issue, or even better, contribute to it with fixes.
How does OpenSCAP compliance scanning compare with other companies' tools like Tripwire?
Tripwire can be used to audit a system and check if it is compliant with a given benchmark. In the example of CIS, there are existing profiles to scan a RHEL 8 system for compliance with CIS Benchmark version 1.0.0 for RHEL 8.
First, Tripwire does not provide remediation; it is only used to scan the system for compliance. OpenSCAP tool both scans and creates a file that can be used for automated remediation.
Second, while OpenSCAP and Tripwire are both scanning for compliance with the same CIS Benchmark version 1.0.0 for RHEL 8, it is possible that the guidelines are interpreted slightly differently in some cases. So scan results may not be identical when comparing Tripwire and OpenSCAP.
Is running OpenSCAP manually the only option?
This blog post is more about understanding the packages OpenSCAP and scap-security-guide. At an operational level, there are more powerful tools available from Red Hat like Ansible Tower, Red Hat Insights, Red Hat Satellite, and cloud.redhat.com which has its own compliance sections, among other useful and related features.
The tools allow group servers to be scanned in host groups, present reports, enforce the security policies to detect the needed erratas. There is also a tool named “Tracer” within Red Hat Satellite, that informs if a process needs to be restarted to protect the system against the known vulnerabilities. It is explained more in detail here: Introduction to the Tracer feature in Satellite.
 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.