Jeff,
I had gotten a request from a customer to provide a mapping of what STIG line items were
covered by Security Blanket. I didn't know initially if my customer meant the
officially approved STIG that DISA posted or the SSG content. The official STIG has the
identifiers (such as RHEL-06-000001) in the actual line item code within the xccdf
document. The SSG content does not, and I was speculating that the references (x.y.z) in
the prose/reports were programmatically generated from the xccdf.
I should note, that having the references either in-line or available in a direct
mapping makes life much easier for those of us who read the contents of the files but are
doing so somewhat outside the scap/oscap world. Granted, the content is in a defined
format which an associated spec, and should be read in said fashion.
Turns out I only need to address the official STIG document for now, but this raised the
questions of how the SSG line items would be mapped back to the STIG line items, including
the concerns on how the issues of 'new entries' and 'deprecated/retired
entries' would be handled to produce a consistent numbering.
Stupid question of the day as well since I'm on the topic of numbering. Is the SSG
content directly consumable by other SCAP scanners? I realize this may be a somewhat
loaded question with a convoluted answer (SCAP version number, OVAL version numbers, OCIL
.......)
-Rob
________________________________________
From: scap-security-guide-bounces(a)lists.fedorahosted.org
[scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of Jeffrey Blank
[blank(a)eclipse.ncsc.mil]
Sent: Tuesday, August 20, 2013 10:35 AM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: SSG line item references
There is an attempt in
scap-security-guide/RHEL6/input/auxiliary/stig_overlay.xml.
To advance the conversation, what are you trying to build? I'm open to
making more transforms, to create specialized tables for SRTM-style docs.
David, Leland, Shawn, I think it makes sense to get together for a call
early next week on this. Can one of you invite?
On 08/19/2013 05:56 PM, Robert Sanders wrote:
Thanks Jeff. I concur wholeheartedly with not using the x.y.z
references. I haven't seen a overlay for DISA STIG <-> SSG Rule maping, is this
internal to DISA or buried somewhere in the SSG?
-Rob
________________________________________
From: scap-security-guide-bounces(a)lists.fedorahosted.org
[scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of Jeffrey Blank
[blank(a)eclipse.ncsc.mil]
Sent: Monday, August 19, 2013 5:50 PM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: SSG line item references
The Rule id (the id attribute) in SSG is your best bet for a stable
identifier. This is what Profiles use to reference Rules, too. The
x.y.z-style section numbers may change at any time and they should not
be used as references.
I will shortly be posting a table that shows the ID in human readable form.
The STIG "overlay" should provide linkage between the issued DISA IDs
(randomly assigned numbers), but I do not know if this is accurate at
present. Maintaining transparent, reproducible linkage between the SSG
upstream and the issued STIG remains a goal.
It may be worth revisiting, with DISA, the idea of the STIG as a Profile
in SSG instead of this overlay construct.
On 08/19/2013 10:59 AM, Robert Sanders wrote:
> Quick question - I'm looking at the SSG content files and trying to
> determine the 'line item' number for a particular check. The DISA STIG
> content is layed out so that the line item information (i.e.,
> rhel-06-0000001) is inline with a particular check. The SSG content
> doesn't appear to have this inline, and I suspect that the line items
> are being generated programmatically via the oscap command but I haven't
> drilled down to see what oscap is actually doing. Considering that the
> SSG is the upstream document for the RHEL6 STIG - is DISA responsible
> for remapping the SSG items to the STIG items, or will DISA adopt the
> way that the SSG is generating line items? If the latter, could this
> result in line item x.z.y from version A be a *very* different best than
> line item x.y.z from version B?
>
> -Rob
>
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
--
___________________________
Jeffrey Blank
410-854-8675
Technology and Systems Analysis / Network Components
NSA Information Assurance
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide