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”
<fix id="cre_com.example_31-5_fix" system=”http://cre.mite.org/cre.xsd”>
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
Date: Fri, 28 Sep 2012 16:26:11 +0000
From: Francisco Slavin <fslavin(a)tresys.com>
Subject: RE: SSG Audit + Aqueduct Remediation Linking
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.
From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto:scap-
security-guide-bounces(a)lists.fedorahosted.org] On Behalf Of Jeffrey
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
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
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)?
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
- Francisco Slavin