Build a customized hardened image

The first phase of this process involves using customized security policies to build a customized hardened image. The following steps show you how.

To get full benefit from this lesson, you will need:

• A Red Hat Enterprise Linux subscription.
• Access to console.redhat.com.
• An environment to deploy your host (e.g., bare metal, VMware, AWS, Azure, etc.).
• Knowledge of the security compliance baseline to align with your system (e.g., CIS or PCI-DSS) and any customizations needed for the baseline to suit your requirements.

In this lesson, you will:

• Define and customize your security compliance policy.
• Generate a customized hardened image with Insights image builder.

Define and customize your security compliance policy

All Red Hat Enterprise Linux security compliance scanning and remediation is underpinned by content from the OpenSCAP project. OpenSCAP provides a mature and well-supported method for assessing, reporting, and enforcing security compliance at scale. For this guide, I will use the CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Server policy and customize it according to my requirements.

Follow these steps to define and customize your security compliance policy:

1. Log in to console.redhat.com.
2. Navigate to Insights for RHEL -> Security -> Compliance -> SCAP Policies (or take a shortcut via https://console.redhat.com/insights/compliance/scappolicies).
3. Create a new policy.
4. Select RHEL 9 as the OS.
5. Select CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Server.

6. Give the policy a more meaningful and unique name if required. I suggest leaving the compliance threshold at 100% since you will want your system to be 100% compliant with your new customized policy (Figure 1).

   

7. Select an existing system running the same RHEL minor release as the one you will build your image to include in the policy. This is a limitation of the policy creation workflow at the time of writing, and you can remove the selected system from the policy immediately after creation. I want to build a RHEL 9.5 image, so I need an existing RHEL 9.5 system registered with Insights for this task, as shown in Figure 2.

   

8. Here's where it gets interesting. Select which individual rules to exclude from the policy and customize parameters for rules that will remain included. OpenSCAP refers to this as tailoring. In this example, I will change the value for "Lock Accounts After Failed Password Attempts" (CCE-83587-6) from 3 failed log on attempts to 5 because I am a sloppy typist and want to cut myself some slack. (You probably don't want to do this in a real environment.) I will also exclude the rule "Disable Network File System (nfs)" (CCE-90850-9) to be able to use this system as an nfs server to share storage. Figures 3 and 4 depict this.

   

   

9. Review and finish creating the policy.

Now that we have a policy, we can use it as part of the new build process.

Generate a customized, hardened image with Insights image builder

The RHEL compliance policies include Red Hat Ansible Automation Platform code snippets and shell scripts to help remediate most compliance check failures, but not all. This means that applying my customized CIS policy at build time is unlikely to make a system 100% compliant. One example of this is the rule "Ensure /tmp Located On Separate Partition" (CCE-90845-9). Remediating this requires that I create a separate partition somewhere in my storage, create a filesystem, and ensure it's mounted at boot time. Automation can't magically find this storage, but I can factor this into my new image's partitioning scheme to ensure that a new system is compliant to this control.

Here's what to do:

1. Navigate to Insights for RHEL -> Inventory -> lmages (or go straight here: https://console.redhat.com/insights/image-builder).
2. Create a new blueprint, then fill out the following menu items.

3. Image Output: Select RHEL 9 for the x86_64, and select the target environment. I will be building a qcow2 virtualization guest image in this example, but you can choose whichever environment(s) suits your needs (Figure 5).

   

4. Register: Select the registration method and Activation Key (if applicable).

5. Compliance: Select the Insights compliance radio button to use a profile from Insights and select the profile created earlier (Figure 6).

   

6. File system configuration: Customize the system partitioning, factoring in the need for a separate /tmp partition in this particular case, as shown in Figure 7.

   

7. Repository snapshot: Select the Use latest content radio button to build a system with the latest packages available, or select Use a snapshot and choose a date to create an image that only contains packages that were available up until that date.
8. Custom repositories: Add any custom repositories the host needs to have available.

9. Additional packages: Add any additional packages to include in systems built from the image (Figure 8). I personally find tmux and vim particularly useful.

   

10. First boot script configuration: Add any shell scripts to execute at first boot. You can find more reading on first boot scripts here. 

11. Details: Give the blueprint a meaningful name and description as shown in Figure 9. 

    

12. Review: Double-check the configuration and revise any items that need changing or correcting.

13. Create the blueprint, and optionally, build the image at the same time (Figure 10).

    

14. Download the qcow2 image. If building the image in a different format, ensure that the image is downloaded locally before it expires (usually 6 hours) or pushed to the cloud provider as required.

Now that we have built and downloaded the image, it’s time to deploy the first custom-hardened system.

Common issues and troubleshooting

The most challenging part of the process has nothing to do with the tools or procedures. Instead, it is coming to an agreement on what the security baseline should be and getting sign-off on any customizations (i.e., tailoring) required for the application workload or general operations. Success requires collaboration between application teams, Linux teams, and security teams to come up with workable agreements that allow applications to run correctly and minimize the risk to the business.

The final call-out to make is the previously mentioned limitation where a compliance policy must be assigned to a system at creation time. This presents two challenges:

• You may need to create a (temporary) RHEL instance (host) to work around this step.
• Any host you assign to the profile (and then immediately un-assign if required) must be running the same minor RHEL release as what you want Insights image builder to build on. This is because tailoring is done on a per-minor release basis (e.g., RHEL 9.4 and RHEL 9.5), and the tailoring you do for RHEL 9.4 compliance won't be applied to RHEL 9.5.

Try it yourself

Now you know how to create a tailored compliance policy using the Insights compliance service and how to bake that policy into images built using Insights image builder. 

Feel free to experiment with the services at console.redhat.com and build images that meet your needs. Remember that these services are included in your Red Hat Enterprise Linux subscription. So make the most of the value of your subscription to help reduce security risk and drive consistency in your environment.

The next steps are to build a system using the newly created image, assign it to the chosen compliance profile, perform a compliance scan against that system, and consider how to remediate any issues identified.

In the next lesson, you will learn how to scan your system and assess any compliance issues you identify with the Insights compliance service.

Learn more

• Chapter 1. Red Hat Insights compliance service overview
• Learn about Red Hat Enterprise Linux and Insights image builders
• OpenSCAP
• CIS Benchmarks