SSG Audit + Aqueduct Remediation Linking

Francisco Slavin fslavin at tresys.com
Fri Sep 7 16:24:15 UTC 2012


> 
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb at redhat.com]
> Sent: Friday, September 07, 2012 10:07 AM
> To: scap-security-guide at lists.fedorahosted.org
> Cc: Francisco Slavin
> Subject: Re: SSG Audit + Aqueduct Remediation Linking
> 
> On Thursday, September 06, 2012 10:25:48 PM Francisco Slavin wrote:
> > We are planning to continue using the <fix> tag with a custom system 
> > attribute string to indicate that the <fix> tag contains BASH
> remediation
> > content.  We are currently considering JSON notation as the leading 
> > candidate for writing the <fix> content because it is both easy to
> write
> > and easy to parse.  The information we want to make sure we cover 
> > for running a remediation script is:
> 
> One of the fundamental items that show up over and over is the 
> kickstart script for system installation. If you want to spin up a VM, 
> kickstart can be used. If you want to make a liveCD, kickstart again. 
> If you want to install a bare-metal system...you guessed it.
Please allow me to clarify our target use case.  We are not simply looking to use the scripts for a kickstart to generate a compliant system at build-time.  The goal of linking the remediation directly in to the XCCDF is to be able to remediate a system throughout its lifecycle in order to maintain compliance.  Rolling a compliant system once was the original problem addressed by previous iterations of CLIP.  The development of SCAP standards has allowed for compliance checking throughout a system's lifecycle, and the goal of integrating remediation in with the XCCDF content is to assure  compliance throughout a system's lifecycle.


> 
> The open scap tool can take the XCCDF docs and turn it into a 
> remediation script. You then add boiler plate at the top for 
> partitioning, language, time zone, etc...and you have a kickstart 
> file.

Forgive my lack of familiarity here - if I'm reading this right, then what the oscap tool is doing is simply pulling the content from the <fix> tags so that that content can be directly appended to a kickstart?  And thus use of JSON (or another format) in the <fix> tag would make the oscap tool have to perform an additional parsing step?

I would be curious to see a content example from a <fix> tag that oscap can process.  Part of our goal for approaching the problem the way we've proposed is to allow for remediation authors to be flexible in how they write their scripts.  Thus we put in provisions to support passing variables from the XCCDF content in to the remediation scripts via positional arguments or environment variables.  I believe this is compliant with the SCAP vision of XCCDF as the policy language.  All variables would be defined in XCCDF, and those would get propagated down to the OVAL checks and to the remediation scripts.  Our current Aqueduct scripts have hard-coded values in them, and the goal is to move away from that so that key variables are defined only once in the XCCDF policy language.

Are these goals something that you address in your vision of how <fix> tag content is written and used?

> 
> I'd really like to keep things so that moving between XCCDF and 
> kickstart is simple.
One of our key reasons for choosing JSON markup was ease of parsing.  To move between XCCDF and kickstart would be slightly more difficult with the addition of JSON, but it is not a costly parsing process or a particularly complex one.  I think it would require only minor updates to the oscap tool to be able to support this approach.  We are hoping to address the problem in a way that is not too burdensome on tool developers.

Thank you
 - Francisco

> 
> -Steve


More information about the scap-security-guide mailing list