Simplicity is a form of art...

Automating compliance checks

With the configuration baseline for a technical service being described fully (see the first, second and third post in this series), it is time to consider the validation of the settings in an automated manner. The preferred method for this is to use Open Vulnerability and Assessment Language (OVAL), which is nowadays managed by the Center for Internet Security, abbreviated as CISecurity. Previously, OVAL was maintained and managed by Mitre under NIST supervision, and Google searches will often still point to the old sites. However, documentation is now maintained on CISecurity's github repositories.

But I digress...

Documenting a rule

In the first post I talked about why configuration documentation is important. In the second post I looked into a good structure for configuration documentation of a technological service, and ended with an XCCDF template in which this documentation can be structured.

The next step is to document the rules themselves, i.e. the actual content of a configuration baseline.

Structuring a configuration baseline

A good configuration baseline has a readable structure that allows all stakeholders to quickly see if the baseline is complete, as well as find a particular setting regardless of the technology. In this blog post, I'll cover a possible structure of the baseline which attempts to be sufficiently complete and technology agnostic.

If you haven't read the blog post on documenting configuration changes, it might be a good idea to do so as it declares the scope of configuration baselines and why I think XCCDF is a good match for this.

Documenting configuration changes

IT teams are continuously under pressure to set up and maintain infrastructure services quickly, efficiently and securely. As an infrastructure architect, my main concerns are related to the manageability of these services and the secure setup. And within those realms, a properly documented configuration setup is in my opinion very crucial.

In this blog post series, I'm going to look into using the Extensible Configuration Checklist Description Format (XCCDF) as the way to document these. This first post is an introduction to XCCDF functionally, and what I position it for.

Giving weights to compliance rules

Now that we wrote up a few OVAL statements and used those instead of SCE driven checks (where possible), let's finish up and go back to the XCCDF document and see how we can put weights in place.

The CVE (Common Vulnerability Exposure) standard allows for vulnerabilities to be given …

Doing a content check with OVAL

Let's create an OVAL check to see if /etc/inittab's single user definitions only refer to /sbin/sulogin or /sbin/rc single. First, the skeleton:

(XML content lost during blog conversion)

The first thing we notice is that there are several namespaces defined within OVAL. These namespaces refer to …

What is OVAL?

Time to discuss OVAL (Open Vulnerability Assessment Language). In all the previous posts I focused the checking of rules (does the system comply with the given rule) on scripts, through the Script Check Engine supported by openscap. The advantage of SCE is that most people can quickly provide automated checks …

Remediation through SCAP

I promised in my previous post to give some information about remediation.

Remediation is the process where you fix a system to become compliant again after finding out there is a violation on the system. The easiest form of remediation of course is to just notify the administrator and give …

Running a bit with the XCCDF document

In my previous post I introduced automated checking of rules through SCE (Script Check Engine). Let's focus a bit more now on running with an XCCDF document: how to automatically check the system, read the results and find more information of those results.

To provide a usable example, you can …

XCCDF - Documenting a bit more than just descriptions

In my previous post I made a skeleton XCCDF document. By now, we can create a well documented "baseline" (best practice) for our subject (say PostgreSQL). But for now I only talked about <description> whereas XCCDF allows many other tags as well.

You can add metadata information for a particular …