Automating compliance checks
by Sven Vermeulen, post on Sat 03 March 2018With 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
by Sven Vermeulen, post on Wed 24 January 2018In 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
by Sven Vermeulen, post on Wed 17 January 2018A 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
by Sven Vermeulen, post on Sun 07 January 2018IT 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.
Putting OVAL at work
by Sven Vermeulen, post on Thu 01 August 2013When we look at the SCAP security standards, you might get the feeling of "How does this work". The underlying interfaces, like OVAL and XCCDF, might seem a bit daunting to implement.
This is correct, but you need to remember that the standards are protocols, agreements that can be made …