SSG Audit + Aqueduct Remediation Linking

Ronayne, James K. jkronay at nsa.gov
Fri Sep 28 18:23:28 UTC 2012


It might help to at least add the id attribute to fix.  
Here is an example of how we initially planned to include CREs in a Windows benchmark.

<fixtext fixref="cre_com.example_31-5_fix">Set Domain Group Policy Object (Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options) using the IGroupPolicyObject interface.   Network security: LAN Manager authentication level should be set to <sub idref=”lan_manager_authentication_level_var” />.</fixtext> 
<fix id="cre_com.example_31-5_fix" system=”http://cre.mite.org/cre.xsd”>
                cre:com.example:31-5:
lan_manager_authentication_level:<sub idref=”lan_manager_authentication_level_var” />
</fix>

Adding an id (ideally an id unique across across all remediations) provides the option of adding fixtext and makes it easier for us to turn it into a CRE at a later point if we want.

Jim




------------------------------

Message: 2
Date: Fri, 28 Sep 2012 16:26:11 +0000
From: Francisco Slavin <fslavin at tresys.com>
To: "scap-security-guide at lists.fedorahosted.org"
	<scap-security-guide at lists.fedorahosted.org>
Subject: RE: SSG Audit + Aqueduct Remediation Linking
Message-ID:
	<24EF0A937B77C942811D893DF06A28353A115D at Exchange10.columbia.tresys.com>
	
Content-Type: text/plain; charset="utf-8"

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