Customizing Lockdown

Tuning and Overriding

Turning Rules On/Off

All controls are setup with variables that can toggle depending on whether a control is running. These toggles are in the defaults/main.yml file, near the top of the main.yml file. This is a common location/methodology for all baseline Roles from MindPoint Group. The variables in the defaults/main.yml file can be overwritten by the extra vars in an Ansible Tower template. This means as an end user, you won’t have to have make any modifications to the Role itself if you are using Ansible Tower

Example 1: You want to turn off all category 3 controls for the RHEL 8 STIG Role. You will set the rhel8stig_cat3_patch variable to false in defaults/main.yml. This means rhel8stig_cat3_patch: true will become rhel8stig_cat3_patch: false in that defaults main file.
Example 2: You want to turn off a specific control in the RHEL 8 STIG Role. You will set the control you want to disable to false. This means in defaults/main.yml you will set rhel_08_010000: false. This will skip control 010000.

There is a tagging system with each control that allows for advanced control over toggling the rules on/off. For example, controls that are SELinux related will have an selinux tag. This allows you to put the tag, selinux, in the Ansible Tower template allowing you not to run tasks that have the selinux tag.
There are other more global task toggles that can be used. For example:

Complexity high (rhel8stig_complexity_high): There are controls that can't have an automated remediation. When this is set to “true” it will run controls that require review.
Disruption high (rhel8stig_disruption_high): This will toggle controls that are likely to cause disruption in normal workflows. These items can be remediated automatically but are disabled by default to avoid disruption.
System is container (rhel8stig_system_is_container): This will turn off tasks that aren’t applicable to a container environment.

Path Customization

Within the Role there are controls that require parameters specific to you and your setup. Customizable options are created as variables within the Role and those variables are set within the defaults/main.yml file. These variables in the defaults/main.yml can be overwritten by the extra vars section in Ansible Tower, which means you won’t have to modify the Role itself.

Example: Your SSH session timeout should be set to two minutes. The control allows you to set the timeout to anything less than ten minutes. You would modify the variable rhel8stig_ssh_session_timeout to reflect the duration needed. In this case you would set rhel8stig_ssh_session_timeout: 120 for 120 seconds.

Applying Lockdown in Net-New Environments

Our Roles are designed to be run against new environments and existing environments. This means that the Role is just as affective if the instance is a brand new, or if it’s been running for years. All of the same rules and customizations will apply in both scenarios.
Since all controls can be toggled easily, you can have an Ansible Tower template for fresh systems that runs the complete Role against the host. Then you can have a separate Ansible Tower template for existing systems that has specific controls disabled. For example, if you currently run systems with SELinux disabled, but all new hosts will have SELinux enabled. You can configure the template for new systems to have all of the SELinux controls enabled and the template for existing systems to have the SELinux controls disabled.

Applications

Our baselines don’t just work with the OS, they work on the application layer as well. The variables for application Roles work the same way as with the OS Roles. The Roles for applications are written to apply pin-pointed config/system changes that allow for running the Role repeatedly over a system without breaking it. Because we don’t rely on templating configuration files, it allows us to apply the needed configuration changes while leaving existing (non-related) configurations intact. Applications currently with Roles include:

PostgreSQL-9 STIG
Apache httpd 2.4 STIG/CIS
Apache Tomcat 9 STIG/CIS

Integrations

CI/CD

Our Roles are written with a top-level site.yml that will trigger the Role within itself, by referencing its own directories. This makes it very easy to add our Role into your CI/CD pipelines by referencing our site.yml.

Manual

You can easily run our Role form the command line. Just remember, you will need to have a valid inventory setup and you will need to edit the defaults/main.yml within the Role to apply your changes.

Other Management Tooling

Our Role integrates very easily with Ansible Tower to add Role-based access to the Roles, as well as allow you to schedule these baselines to run. You can create many different templates for various scenarios based on what controls are enabled. For example, if you can create a template to run once a day to apply only RHEL8 STIG Category 1 fixes, then another template to run once a week to apply the RHEL 8 STIG Category 2 fixes.

What Not To Do

Do not edit the Role directly. The tasks are written in a way where anything that should be modified is created as a variable in the defaults/main.yml. That is the only file that should be modified, and only if there are no other options, such as not using Ansible Tower.
Do not use your initial run in a production environment. Running the Roles will make changes, and those changes could break things on that system. Make sure to run these Roles against a system in your test environment.
Do not use exposed passwords. There are controls that use passwords as variables. These should be converted to use either a local PW management system or hidden as an Ansible Vault value.