SSG Audit + Aqueduct Remediation Linking

Francisco Slavin fslavin at tresys.com
Fri Sep 28 16:26:11 UTC 2012


Feedback in-line.  Unfortunately, I believe using unique XML markup under a <fix> tag invalidates the XCCDF document.

> -----Original Message-----
> From: scap-security-guide-bounces at lists.fedorahosted.org [mailto:scap- 
> security-guide-bounces at lists.fedorahosted.org] On Behalf Of Jeffrey 
> Blank
> 
> I think it might make more sense to do it in XML instead of JSON.
> Mixing JSON and XML makes one's eyes bleed in two different ways 
> instead of one way.  But I suppose it's parseable and transformable 
> either way.

Using XML occurred to me in order to be consistent with the rest of the document - I don't particularly like the mixed-up look, either.
Unfortunately, using XML in the document would render it invalid XCCDF.  According to the XCCDF schema, the <sub> tag is the only XML tag that can be a child to a <fix> element.  I tested out a simple JSON <fix> tag example to make sure it validated using xmllint.  I tried the same <fix> tag example using some invented XML tags which don't occur elsewhere in the XCCDF schema and the document would no longer validate.

I feel that keeping the XCCDF document valid according to schema is a significant constraint for our approach with this, which takes unique XML markup out of consideration.  If there's another way to do that I would be willing to consider it; I will readily admit I am not an XML expert.

Just to keep the SSG community posted, our approach for the next SecState release is to consume <fix> content with JSON markup.  Based on the use cases I described previously and the constraint of keeping the XCCDF valid it seems to be the cleanest approach to me.  We will certainly be open to shifting in the future if the community moves in a different direction or the schemas mature to the point where we can leverage SCAP-specific mechanisms to represent this information.  This JSON <fix> tag support is targeted for the version of SecState that will ship with CLIP for RHEL 6.2.

> 
> Have you given though to making it look (a little bit) like what's in 
> the CRE spec for a cre_entry (pg 25)?
> http://csrc.nist.gov/publications/drafts/nistir-7831/Draft-NISTIR-
> 7831.pdf
> 
> But perhaps in a more-convenient-for-human-editing format (something 
> for which automated transformation may be possible to CRE)?
> 
We did want to make sure we picked a standard, easily-transformable means of representing this information when we landed on JSON.  We want to be able to support SCAP remediation specifications in the future as they mature.  From taking a quick look at the CPE schema it seems like we could easily boilerplate in RHEL 6.2 info for the <platform> information that the CPE spec will track as the remediation content being developed matures.

Thank you
 - Francisco Slavin



More information about the scap-security-guide mailing list