Releasing ComplianceAsCode / Content 0.1.58

Sep 30, 2021  -  Gabriel Becker, Marcus Burghardt, Watson Sato, Matěj Týč, Matthew Burket

With a bit more than one thousand commits since last release we are happy to announce that ComplianceAsCode / Content v0.1.58 was released on September 24th, 2021.

Highlight of this release

The project now supports another checking engine: Script Checking Engine (SCE). By default, the content is built without SCE checks, check Building SCE section in the docs for how to enable it. Note that content built with SCE checks is not SCAP compliant.

What’s new in the content?

New Profiles

Notable new profiles added in this release:

  • An initial version of Security Technical Implementation Guide (STIG) for Ubuntu 20.04; and
  • Center for Internet Security (CIS) for SUSE Linux Enterprise 12.

Profile updates

Some of the profiles that were updated:

  • The CIS profiles for Red Hat Enterprise Linux 8 were reorganized according to its target (workstation or server) and level (Level 1 or 2). Now there are 3 more profiles aligning to Workstation Level 1, Level 2, and Server Level 1.

  • A significant amount of new rules was added to the STIG profile for Red Hat Enerprise Linux 8.

What’s new for content developers?

Automated addition of CCEs

Tired of finding out that a couple of important rules doesn’t have a CCE, because extracting one from a CCE pool and assigning it to a rule file is cumbersome? The fix_rules.py utility has been extended, so it now automatically picks up a CCE in a CCE file, and places it right into the specified rule.

You can use it like this:

$ PYTHONPATH=. utils/rule_dir_json.py  # that's a general prerequisite of fix_rules
$ PYTHONPATH=. utils/fix_rules.py  --product products/rhel7/product.yml add-cce accounts_tmout

If you try the code above, you will find out that nothing has changed - the utility is able to detect that the rule already has a RHEL7 CCE.

If you are reading it as a non-RHEL developer, the tool accepts a --cce-pool options, that allow introduction of another CCE files than the one in shared/references/cce-redhat-avail.txt. If you would like to bring your CCEs upstream, you will just need to extend the cce.py to integrate it with the script.

Sorting of references and identifiers

The rules in the project can reference security policy requirements to indicate that they implement or support them, and be assigned identifiers to uniquely identify a configuration item within a product.

References and identifiers are added as a list of items under keys of the same name in the rule’s rule.yml. See an example snippet from rule accounts_password_pam_pwhistory_remember_system_auth.

identifiers:
    cce@rhel7: CCE-83479-6
    cce@rhel8: CCE-83480-4
    cce@rhel9: CCE-89176-2

references:
    cis-csc: 1,12,15,16,5
    cis@rhel7: 5.4.4
    cis@rhel8: 5.4.3
...
    stigid@ol7: OL07-00-010270
    stigid@rhel7: RHEL-07-010270
    stigid@rhel8: RHEL-08-020220
    vmmsrg: SRG-OS-000077-VMM-000440

These references and identifiers were sorted in upstream and from now on any new addition needs to maintain it. Content developers can use fix_rules.py utility to check for issues and sort them:

$ PYTHONPATH=. utils/rule_dir_json.py  # that's a general prerequisite of fix_rules
$ PYTHONPATH=. utils/fix_rules.py --dry-run sort_subkeys  # This will check for rules with unsorted references or identifiers
$ PYTHONPATH=. utils/fix_rules.py sort_subkeys  # This will sort any unsorted reference or identifier and ask for confirmation before writing to disk

Sorting of prodtype keys

In similar vain to the previous section we also added sorting the prodtype key in rule.yml. The prodtype key defines what products the rule applies to.

All prodtypes were sorted in upstream and from now on any new addition needs to maintain it. Content developers can use fix_rules.py utility to check for issues and sort them:

$ PYTHONPATH=. utils/rule_dir_json.py  # that's a general prerequisite of fix_rules
$ PYTHONPATH=. utils/fix_rules.py --dry-run sort_prodtypes  # This will check for rules with an unsorted prodtype key 
$ PYTHONPATH=. utils/fix_rules.py sort_prodtypes  # This will sort any unsorted prodtype keys and ask for confirmation before writing to disk

Migration of the shared Bash remediations functions to Jinja macros

Writing remediations is an important part of developing security content. And although each rule addresses a single configuration change, different rules may need to run similar commands to remediate the system. So it is only natural that the project provides a library to streamline development and reduce code duplication.

The project features two mechanisms that make Bash code available for use in remediations. The first mechanism is the bash_remediation_functions. A mechanism that makes use of the XCCDF substitution capability to inject the Bash function into the remediations, this means that OpenSCAP is used to make the substitutions and render the final remediation snippet. This approach also requires the remediation to declare an include for the build system to transform the Bash function calls into the XCCDF substitution syntax.

The second mechanism is the Jinja macros, which are expanded during the content build.

In this release a good portion of the Bash remediation functions were migrated to Jinja macros, and by the next release all of them will have been migrated. This will leave the project with a single mechanism, which should streamline how we define and make available Bash snippets to remediations. The expansion of snippets at build time will provide more clarity on the final remediation; And the Jinja templating engine provides a formidable customization power, allowing the Bash snippet to be expanded differently for each product, for example.

Development environment setup via Ansible

We have now an Ansible role to help us to very quickly prepare a completely functional development environment. About 10 minutes are enough for Ansible to safely conclude the hard work and deliver a ready to go development environment.

This is a great option to start contributing faster, aligned with the official documentation while enjoying the automation benefits.

More information can be found in the development documentation.

Style guide

To help content developers we have created a style guide. This document’s goal is to help ensure constancy across the codebase and help during the code review process. This document is a living document, if you want to add or change something please open an issue, or better yet a pull request.

You can find the full guide in the development documentation

Twitter Facebook