There are a number of acronyms related to various security efforts that we’ve thrown around while discussing the Bandolier project (XCCDF, OVAL, SCAP, FDCC, etc…). I thought it would help to have a brief discussion about how each of these relate to one another and Bandolier. We’ve added some SCADApedia entries for XCCDF and OVAL, so let’s start there.

The Extensible Configuration Checklist Description Format (XCCDF) is an effort led by the US government to foster good security practices by developing a standard language to communicate security checklists and configuration guidelines. It basically defines a data model and an XML representation of that model. The specification defines an XCCDF document as “a structured collection of security configuration rules for some set of target systems”.

OVAL stands for the Open Vulnerability and Assessment Language and is another US government-funded project maintained by MITRE. Like XCCDF, it is an open XML specification for security benchmarks. It operates at a much lower level, however, and can be used by a variety of products including vulnerability scanners, security event mangers, and configuration audit tools. For Bandolier, we are interested in the configuration audit function.

To further clarify, XCCDF defines a high-level security benchmark that is designed to interface with lower level rule checks (OVAL) that in turn can be used by a security tool to perform a configuration check or other functions. For example, the XCCDF document for a Windows best practice configuration might define that the minimum password length should be eight characters. This check would get passed to the OVAL document that actually defines the registry value to validate that the setting on a target machine matches the XCCDF specification.

We will take the control system audit files developed for Nessus and make them available in the XCCDF and OVAL formats. This order of events may seem backward given the progression I described above (XCCDF-OVAL-Security Tool). Because of the popularity of Nessus, I believe that getting the compliance checks developed there first is the fastest way to deliver some real value to the community. So the Nessus compliance checks will be our RAD (Rapid Application Development) tool of sorts to loosely borrow an application development term.

So why does this matter? Trust me, it’s not the XML and acronyms that get me excited. For Bandolier it’s two things. First, the end result is a practical, usable product that will enable an asset owner to validate security best practice at the operating system and control system application level. Second, and perhaps equally as valuable, the process is an opportunity to work with vendors and asset owners to define a secure configuration for their applications. Making the configuration checks available in the XCCDF/OVAL format expands the impact of the end result and opens the door for use in a variety of security products.