Implementing Content for Automated Security Compliance to Custom Policies

Matej Tyc, Software Engineer and Tech Lead - Security Compliance in Red Hat^® Enterprise Linux^® (RHEL) Security, Red Hat^®

Marek Haicman, Senior Quality Engineer and Product Owner - Security Compliance in RHEL Security, Red Hat^®

Lucy Kerner, Senior Principal Security Global Technical Evangelist and Strategist, Red Hat^®

Gabriel Gaspar Becker, Software Engineer - Security Compliance in RHEL Security, Red Hat^®

Jan Cerny, Software Engineer - Security Compliance in RHEL Security, Red Hat^®

Watson Sato, Software Engineer - Security Compliance in RHEL Security, Red Hat^®

Matúš Marhefka, Quality Engineer - Security Compliance in RHEL Security, Red Hat^®

Vojtěch Polašek, Software Engineer - Security Compliance in RHEL Security, Red Hat^®

This lab introduces you to the ComplianceAsCode project, a comprehensive tool that creates content for automated security tools. The project contains over 1,000 rules—​elements of security policies. Rules have descriptions, justifications, and references to existing security standards. They also have Open Vulnerability and Assessment Language (OVAL) checks, bash remediations, and Red Hat^® Ansible^® Automation content to a varying degree.

ComplianceAsCode enables automated evaluation and fast and efficient remediations against security controls for compliance with regulatory or custom profiles, and for automated configuration compliance. It allows you to produce a tailor-made security policy for your company with minimal effort, and the OpenSCAP ecosystem can do the scanning and support for problem resolution. Specifically, OpenSCAP is a National Institute of Standards and Technology (NIST) certified scanner designed to perform configuration and vulnerability scans on a system, validate security compliance content, generate reports and guides based on these scans and evaluations, and allows users to automatically remediate systems that have been found in a non-compliant state.

Red Hat^® Enterprise Linux^® provides tools that allow for fully automated compliance audits. These tools are based on ComplianceAsCode and the Security Content Automation Protocol (SCAP) standard and are designed for automated tailoring of compliance policies.

This lab is geared toward system administrators, cloud administrators and operators, architects, and others working on infrastructure operations management who are interested in learning how to automate security compliance using Red Hat^® provided tooling for compliance against both industry standard and custom policies.

The prerequisites for this lab include basic Linux skills gained from a Red Hat^® Certified System Administrator (RHCSA^®) certification or equivalent system administration skills.

Your entire lab environment is hosted online and includes Red Hat^® Enterprise Linux^® and Red Hat^® Ansible^® Automation.

Congratulations, now you are in your text console.

This section contains various tips that may be useful to keep in mind as you are doing the lab exercises.

This lab has been designed for you to learn how things work from top to bottom. This means there are lots of descriptions and reading, not just commands for you to copy and paste! If you just copy and paste all the commands you can be done in 30 minutes…​ but you won’t learn anything!

You have plenty of time to complete the lab, take it slow and read everything. If you get stuck, don’t be afraid to ask for help at any time, but the answer is probably in the lab documentation.

In this lab, you will become familiar with the ComplianceAsCode project. The purpose of this project is to help content authors create security policy content for various platforms. The ComplianceAsCode project enables content authors to efficiently develop and share security content.

Using the powerful build system, you can generate output in various formats such as Ansible^® Playbooks or SCAP datastreams that you can use to automate security auditing and hardening. The project contains many useful rules and checks that form various security policies and enables content authors to easily add new rules and checks.

You work with the project source repository at https://github.com/ComplianceAsCode/content.

In Red Hat^® Enterprise Linux^® (RHEL), the SCAP content generated from ComplianceAsCode data is shipped as the scap-security-guide RPM package.

The ComplianceAsCode project consists of human-readable files that are compiled into standard-compliant files that are difficult to read and edit directly.

For your convenience, the environment is already set up, so the content is built and ready to be used. No worries, though—​you get to rebuild it later in the exercise.

To start the hands-on section, take the following steps:

A rule needs more than a description to be of any use. Other functions are:

For these reasons, a rule should contain a check and possibly also remediations. The additional content is placed in subdirectories of the rule, so explore your accounts_tmout rule.

You can browse the associated content if you list the contents of the directory. In the terminal, run the following commands:

The following sections describe the currently supported associated content types.

As you already know from Lab Exercise 1, the ComplianceAsCode project provides security content that can be used for automated security scanning of your system.

Red Hat^® Enterprise Linux^® 8 (RHEL 8) contains OpenSCAP Scanner, which is a security scanner that works with ComplianceAsCode content. The content that you build in ComplianceAsCode can be simply passed to OpenSCAP Scanner and the scan can be started right away.

OpenSCAP Scanner allows you to perform security compliance checks in a fully automated way. It is possible to run the scan using either the oscap command line tool or the SCAP Workbench graphical application. Several integrations for continuous scanning also exist, but in this lab exercise, you focus on one-off scanning.

OpenSCAP provides a command line tool called oscap that can be used for automated security scanning.

In this section, you build the security content for Red Hat^® Enterprise Linux^® 8 from ComplianceAsCode source code and then you use the built content with the OpenSCAP command line tool to scan your machine.

Putting the machine into compliance (for example, by changing its configuration) is called remediation in the SCAP terminology. Remediation changes the configuration of the machine, and it is possible to lock yourself out or disable important workloads! As a result, it is a best practice to test the remediation changes before deploying.

You use Terminal on your laptop for the next part—​there is no need to use graphical console.

The Ansible Playbook can be used to configure a system to meet a compliant state. Using Ansible Playbooks is discussed in Lab Exercise 4. The Bash remediation script also can be used to change the configuration of the system. It is recommended that you review the contents of these scripts and test them in a testing environment first, as they have the potential to make unexpected or harmful changes.

Imagine that your company has approved an internal security policy that enforces certain configurations for laptops being used outside the company site. Your task is to implement an automated way of checking the laptop configuration. In this lab exercise, you learn how to solve the task using ComplianceAsCode.

The basic building block of a security policy in ComplianceAsCode is a rule. The rule represents a single configuration setting—​for example, "Password length is at least 8 characters" or "Logging is enabled."

A set of rules is called a profile. A profile represents a specific security policy. In ComplianceAsCode, there are multiple profiles.

Rules and profiles are also standardized by the XCCDF standard, which is part of SCAP. However, there is also a concept in-between — a Security Control. As profiles are usually based on policies that are available as documents that group requirements by chapters or sections, it makes sense to introduce this concept of Security Controls that corresponds to that sectioning. As a result, the profile definition doesn’t have to reference tens or hundreds of rules individually, but it can reference Security Controls that point directly to the essence of the policy the profile implements.

Security Control has the same structure as profile — it consists of selections and associated metadata. One can use available Security Controls as an additional means of how to define profiles — one can use Security Controls in addition to already mentioned rules and other selections.

There are profiles for different products. The term "product" means operating systems or applications—​for example, Red Hat^® Enterprise Linux^® 8 or Red Hat^® OpenShift^® Container Platform 4. The products are represented by directories in the products directory of the ComplianceAsCode repository—​for example, rhel8, fedora or ocp4 subdirectories.

Each product has a different set of profiles because some security policies are relevant only for certain operating systems or applications. The profiles are located in the profiles directory in the product directory. The profiles are represented by a simple YAML (YAML Ain’t Markup Language) file, such as ospp.profile, which defines a profile.

In this lab, you create a new “Travel” profile for Red Hat^® Enterprise Linux^® 8. The profile represents your company’s new security policy for laptops.

Next, imagine that one of the requirements of your company policy is that the root user cannot log in to the machine via SSH. ComplianceAsCode already contains a rule implementing this requirement. You only need to add this rule to your “Travel” profile.

Imagine that one of the requirements set in your company policy is that the user sessions must timeout if the user is inactive for more than 5 minutes.

ComplianceAsCode already contains an implementation of this requirement in the form of a rule. You now need to add this rule to your “Travel” profile.

However, the rule in ComplianceAsCode is generic—​or, in other words, customizable. It can check for an arbitrary period of user inactivity. You need to set the specific value of 5 minutes in the profile.

Imagine that one of the requirements in your corporate policy is that users have to install the Hexchat application when their laptops are used during travel outside the company site because Hexchat is the preferred way to communicate with the company IT support center.

You want to add a check to your new profile that checks if Hexchat is installed.

ComplianceAsCode does not have a rule ready for installing this application yet. That means you need to add a new rule for that.

In the final section, you use the new profile that you just created to scan your machine using OpenSCAP.

You have examined only the HTML guide so far, but for automated scanning, you use a datastream instead. A datastream is an XML file that contains all of the data (rules, checks, remediations, and metadata) in a single file. The datastream that contains your new profile was also built during the content build. It is called ssg-rhel8-ds.xml and is located in the build directory.

Profiles can grow quite complex — check out e.g. the products/rhel8/profiles/ospp.profile that contains group of rule selections and comments. Such files can get non-functional changes that regroup selections or modify comments, and this creates noise in the profile commit’s history. As a result, it is not clear how a profile really changed in course of its history.

The project addresses this problem — it allows you to "freeze" a profile in a certain state, so each substantial change to it has to be confirmed, and the history of changes is easily available.

It’s build artifacts that play the key role here. One of those artifacts is a compiled profile, which is a profile file that doesn’t contain any comments, and whose selections are sorted lexicographically. For instance, let’s take a look at our compiled travel profile by writing its contents to the console using the cat command:

As the exact form of the compiled profile is not relevant to content authors and also a likely subject to change, in the future, we escape those lines from the listing using the ellipsis (…​). As we can see, first come rule selections, then variable assignments, and finally rule refinements.

Then, we copy the file to a directory where reference compiled profiles are expected, and we also remove yaml keys except selections and title. Only selections are taken into the account when comparing the reference profile with the actual profile, so the title isn’t needed, but we include it to see that other keys are allowed. So we make sure that the directory tests/data/profile_stability/<product> exists, we copy the build artifact, and we remove redundant lines.

Note in the nano editor, the keyboard shortcut Ctrl+K is useful — it removes the current line. In case when you remove wrong line by accident, remember that you can undo using Alt+U. So edit the file, that it matches the listing below:

After you are done editing, press Ctrl+X, then enter y to save and exit.

Time to try it out - let’s execute the profile stability test! We do so by executing ctest to execute tests that have stability in mind, considering the build directory as the base test directory:

The test should have 100% passed.

Will the test fail if we change the profile? Let’s try that out by modifying the project’s profile.

Let’s change the severity override in the selections section from high to medium in the profile file, then recompile and retest.

This time, the test will fail, and thanks to the --output-on-failure option, it will tell us that the changed severity is indeed a problem. We will keep the original profile reference in the tests directory, and we will restore the severity back to high in the upcoming section.

We have created a travel profile, but perhaps we would also create other company profiles that could share the same big-picture concepts. For instance, the travel profile is about session protection, SSH hardening, and about installing a communication tool. Therefore, let’s formally define a company policy file with Security Controls, and use those in the profile definition.

Red Hat^® Ansible^® Automation is a powerful tool for automating the configuration of systems. By running a predefined file called an Ansible Playbook, you can quickly configure the system according to your needs.

Ansible Automation can easily be used for security compliance automation, because it allows you to keep your system hardened, and it can operate on a large scale. Using Ansible Automation, you can set everything you need, including minimal password lengths, firewall rules, package installation, or the disabling of services.

ComplianceAsCode works great with Ansible Automation. ComplianceAsCode connects a human-readable security policy with Ansible tasks that implement the settings required by the security policy. The rules in ComplianceAsCode profiles contain Ansible tasks that configure the system to conform to the rule. From these Ansible tasks and rule metadata, ComplianceAsCode generates an Ansible Playbook that you can use to harden your system. After running the playbook, your system meets the requirements of the security policy.

ComplianceAsCode generates a playbook for each profile that conforms to the profile definition. Moreover, it generates separate playbooks for every rule.

Ansible tasks can be attached to every rule in a ComplianceAsCode project. A lot of rules already contain Ansible tasks.

As an example, you add a new Ansible task for the accounts_tmout rule. You have already encountered this rule in Lab Exercise 1. This rule is about the interactive session timeout for inactive users. Terminating an idle session within a short time period reduces the risk of unauthorized operations. The Ansible task that you add configures the session timeout in the respective configuration file.

You work in the context of Red Hat^® Enterprise Linux^® 8 (RHEL 8) product and the OSPP profile for Red Hat^® Enterprise Linux^® 8, but the structure is the same for all rules in ComplianceAsCode.

As you already know from Lab Exercise 1, source code for the accounts_tmout rule is located in the linux_os/guide/system/accounts/accounts-session/accounts_tmout directory.

At this point, your task does not fully conform to the rule description in rule.yml. The difference is that rule.yml does not define a specific value for the timeout.

You now generate a playbook for the accounts_tmout rule you modified. You do this in the context of the Red Hat^® Enterprise Linux^® 8 product and the OSPP profile for Red Hat^® Enterprise Linux^® 8.

To generate Ansible Playbooks, a complete build of the content for the product needs to be performed. That means that all of the other playbooks for all of the other rules are generated as well. Moreover, the SCAP content is also generated.

You no longer need console view in this lab.

In the previous section, you learned about using a playbook for the accounts_tmout rule. However, security policies are usually complex, which in turn means that profiles consist of many rules. It is not convenient to have a separate Ansible Playbook for each rule, because that means you need to apply many Ansible Playbooks to the system. Fortunately, ComplianceAsCode also generates Ansible Playbooks that contain all of the tasks for a given profile in a single playbook.

The playbooks are located in the build/ansible directory. This directory contains Ansible Playbooks for each profile. The Playbooks files have .yml extension.

OVAL stands for Open Vulnerability and Assessment Language. In a nutshell, it is an XML-based declarative language that is part of the SCAP standard. This lab focuses on its ability to query and evaluate the state of a system. Quoting from the OVAL FAQ:

The language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, configuration, patch state, etc.); and reporting the results of this assessment.

The ComplianceAsCode project supports OVAL as the language for writing automated configurable checks. It compiles OVAL snippets into checks that are understood by OVAL interpreters—​for example, the OpenSCAP scanner. The scanner evaluates the check, and determines whether the system passes.

In this lab exercise, you go through the OVAL snippet of the accounts_tmout rule. You see how even simple checks can rapidly become complicated, and what you can do about it. Finally, you discover that the check was written incorrectly and you fix it.

There is already a built HTML guide in the build directory.

The ComplianceAsCode project features a test suite that is useful for defining which scenarios the check and remediation are supposed to handle. It sets up a system to a certain state and runs the scan and possibly remediations. Results are reported in the form of console output, and detailed reports are saved to a log directory.

Regarding scenarios, consider, for example, the accounts_tmout rule—​the two simplest cases are handled using the following scenarios:

The test suite has to prepare a system, scan it, and report results. Due to practical considerations, the system under test should be isolated from the system running the test. The test suite supports libvirt VMs, and docker or podman containers that satisfy this isolation requirement. In this exercise, you are going to use a podman container with the Red Hat^® Enterprise Linux^® 7 (RHEL 7) image.

In this section, you analyze the OVAL check for the accounts_tmout rule and perform the following steps: