January 28th, 2016

Four ways to handle waivers with OpenSCAP

This tutorial describes three approaches how to handle a system that for whatever reason needs to be keept not fully compliant.

After installing scap-security-guide package there is a couple of DataStream files.

    # yum install -y scap-security-guide
    # rpm -ql scap-security-guide | grep .ds.xml

I can use any of them to run the scan of a system, for example on Red Hat Enterprise Linux 7:

    # oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_common --report x.html /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

I have noticed, that when I run such scan on all of my systems, some of them report positives I cannot remediate. I mean the systems are technically incompliant with the profile, but I need to keep the systems in the incompliant state to avoid breakage of the running services. For instance, on one of my clusters, I have couple messaging brokers. On each broker system, I need to keep qpid daemon running, although scap-security-guide advises me to turn-it off. I can tell the broker system from any other easily. The broker has python-acme-broker package installed on it.

So how do I proceed? Basically there are three options.

  1. Prepare nothing. Keep the reports coming red. Print-them out. Sign-off the failures. There are highly secured deployments that needs to do this. However, for others this is not affordable solution.

  2. This is rather footnote: You can advocate for the waiver support in OpenSCAP tooling. There is waiver support in XCCDF standard and we have it preliminary implementation in OpenSCAP (example usage). The problem is that we do not have nice user interface to include waiver yet. The presentation of the waivers in HTML is done.

  3. Customize policy for each specific system. Scap-workbench is great tool for customization. The scap-workbench produces XCCDF Tailoring files. The process is very quick, however You will need to distribute these Tailoring files along the existing DataStream files. You also need to make sure nobody tampers with the tailoring files once they are distributed to the target systems.

  4. The last option is to include waivers directly in the policy. This allows you to have single policy/profile for whole infrastructure. In my specific example, I could amend existing DataStream file and make the "Disable qpid" rule apply only on the systems that do not have python-acme-broker package installed. This approach to things, however, needs to be applied with security engineering rigor. For example, I risk that someone install the python-acme-broker package on other system to allow qpid daemon run unnoticed. In this case, I am fine accepting the risk.

In the following blog post, I would like to shed more light how to implement the fourth option.