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: [email protected] [[email protected]] on behalf of Jeffrey Blank [[email protected]] Sent: Tuesday, August 20, 2013 10:35 AM To: [email protected] 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: [email protected] > [[email protected]] on behalf of Jeffrey > Blank [[email protected]] > Sent: Monday, August 19, 2013 5:50 PM > To: [email protected] > 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 >> [email protected] >> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >> > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ > scap-security-guide mailing list > [email protected] > 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 [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
