We are going to be looking at one of a set of tools maintained by Red Hat called OpenSCAP. Before we continue, I feel I should warn you that the next section is going to contain a lot of abbreviations, starting with SCAP.

So, what is SCAP? The Security Content Automation Protocol (SCAP) is an open standard that encompasses several components, all of which are open standards themselves, to build a framework that allows you to automatically assess and remediate your hosts against the National Institute of Standards and Technology (NIST) Special Publication 800-53.

This publication is a catalog of controls that is applied to all U.S. federal IT systems, apart from those maintained by the National Security Agency (NSA). These controls have been put in place to help implement the Federal Information Security Management Act of 2002 (FISMA) across U.S federal departments.

SCAP is made up of the following components:

• Asset Identification (AID) is a data model used for asset identification.
• Asset Reporting Format (ARF) is a vendor-neutral and technology agnostic data model for transporting information on assets between different reporting applications and services.
• Common Configuration Enumeration (CCE) is a standard database of recommended configuration for common software. Each recommendation has a unique identifier. At the time of writing, the database has not been updated since 2013.
• Common Configuration Scoring System (CCSS) is the continuation of CCE. It is used for generating a score for various software and hardware configurations across all types of deployments.
• Common Platform Enumeration (CPE) is a method of identifying hardware assets, operating systems, and software present in an organization's infrastructure. Once identified, this data can then be used to search other databases to threat assess the asset.
• Common Weakness Enumeration (CWE) is a common language for dealing with and discussing the causes of weaknesses in system architecture, design, and code that may lead to vulnerabilities.
• Common Vulnerabilities and Exposures (CVE) is a database of publicly acknowledged vulnerabilities. Most system administrators and IT professionals will have come across the CVE database at some point. Each vulnerability receives a unique ID; for example, most people will know CVE-2014-0160, which is also known as Heartbleed.
• Common Vulnerability Scoring System (CVSS) is a method that helps capture the characteristics of a vulnerability to produce a normalized numerical score, which can then be used to describe the impact of a vulnerability, for example, low, medium, high, and critical.
• Extensible Configuration Checklist Description Format (XCCDF) is an XML format for describing security checklists. It can also be used for configuration and benchmarks and provides a common language for all the parts of SCAP.
• Open Checklist Interactive Language (OCIL) is a framework for expressing questions to an end user and also the procedures to process the responses in a standardized way.
• Open Vulnerability and Assessment Language (OVAL) is defined in XML and aims to standardize the transfer of security content across all of the tools and services offered by NIST, the MITRE Corporation, the United States Computer Emergency Readiness Team (US-CERT), and the United States Department of Homeland Security (DHS).
• Trust Model for Security Automation Data (TMSAD) is an XML document that aims to define a common trust model which can be applied to the data being exchanged by all of the components that make up SCAP.

As you can imagine, there have been thousands of man-years that have gone into producing SCAP and the components that go to make its foundation. Some of the projects have been around in one form or another since the mid 90s, so they are well-established and considered the de facto standard when it comes to security best practices; however, I am sure you are thinking that it all sounds very complicated—after all, these are standards that have been defined and are being maintained by scholars, security professionals, and government departments. 

This is where OpenSCAP comes in. The OpenSCAP project, maintained by Red Hat and also certificated by NIST for its support of the SCAP 1.2 standard, allows you to apply all of the best practices we have discussed using a command-line client.

OpenSCAP, like a lot of Red Hat projects, is gaining support for Ansible and the current release introduces support for automatically generating Ansible playbooks to remediate non-conformance discovered during an OpenSCAP scan.

In the sections that follow, we will launch a CentOS 7.5.1804 Vagrant box, scan it, and generate the remediation playbook. As playbook support has only just been introduced, there is not yet 100% coverage of the fixes, so we will then scan the host a second time and then, using Ansible, generate a remediation bash script, and execute it on our host, before executing another scan, so we can compare the results of all three scans.