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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Jeffrey Blank [blank@eclipse.ncsc.mil] Sent: Monday, August 19, 2013 5:50 PM To: scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Jeffrey Blank [blank@eclipse.ncsc.mil] Sent: Monday, August 19, 2013 5:50 PM To: scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Jeffrey Blank [blank@eclipse.ncsc.mil] Sent: Tuesday, August 20, 2013 10:35 AM To: scap-security-guide@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@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Jeffrey Blank [blank@eclipse.ncsc.mil] Sent: Monday, August 19, 2013 5:50 PM To: scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 8/20/13 10:51 AM, Robert Sanders wrote:
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.
Existing maps are to the CCIs. Do they want the RHEL-06-****** number for some reason?
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 .......)
Should be compatible with any SCAP compliant scanner. We've worked with the Tenable/ACAS folk in the past, and the SPAWAR SCC guys have tested as well.
Interesting. I asked because when I last tried the SSG content with the SCC3.1rc6 beta on a RHEL6.4 box I thought I saw a whole bunch of stuff pop out regarding the OCIL-transitional stuff. Might have been just informational, but I punted then and just ran the oscap stuff. I had hoped to get the increased verbosity out of the SCC scanner for what failed to assist tracing down possible issues with what the prose specified vice what the code was actually doing. So - since I segued into that, is there a magical incantation to give to oscap to dump what is it *really* looking for without having to trace through the content? I'll reference the question I raised last week about the 'Verify File Hashes with RPM' where it seems that the OVAL may be filtering stuff out based on filepath vice where the prose doesn't indicate any filtering.
-Rob
________________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.com] Sent: Tuesday, August 20, 2013 1:57 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: SSG line item references
On 8/20/13 10:51 AM, Robert Sanders wrote:
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.
Existing maps are to the CCIs. Do they want the RHEL-06-****** number for some reason?
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 .......)
Should be compatible with any SCAP compliant scanner. We've worked with the Tenable/ACAS folk in the past, and the SPAWAR SCC guys have tested as well. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
SCC barfing on check systems it can't handle is a problem with SCC. They were not following the XCCDF specification for processing the available check systems. I don't know if they've fixed it -- maybe Jack V is lurking here, and could say so.
I'd look at the OVAL results file if you want to see what openscap is gathering, in order to determine the overall pass/fail in the XCCDF results. Look for a few different options for output in `man oscap` -- look for "oval-results". As for all stages of the OVAL evaluation (including what may be filtered) ... that's pretty complicated and may require putting oscap into a debug mode, but removing any filters temporarily may be informative.
On Tue, Aug 20, 2013 at 2:13 PM, Robert Sanders rsanders@trustedcs.comwrote:
Interesting. I asked because when I last tried the SSG content with the SCC3.1rc6 beta on a RHEL6.4 box I thought I saw a whole bunch of stuff pop out regarding the OCIL-transitional stuff. Might have been just informational, but I punted then and just ran the oscap stuff. I had hoped to get the increased verbosity out of the SCC scanner for what failed to assist tracing down possible issues with what the prose specified vice what the code was actually doing. So - since I segued into that, is there a magical incantation to give to oscap to dump what is it *really* looking for without having to trace through the content? I'll reference the question I raised last week about the 'Verify File Hashes with RPM' where it seems that the OVAL may be filtering stuff out based on filepath vice where the prose doesn't indicate any filtering.
-Rob
From: scap-security-guide-bounces@lists.fedorahosted.org [ scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.com] Sent: Tuesday, August 20, 2013 1:57 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: SSG line item references
On 8/20/13 10:51 AM, Robert Sanders wrote:
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. Existing maps are to the CCIs. Do they want the RHEL-06-****** number for some reason?
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 .......) Should be compatible with any SCAP compliant scanner. We've worked with the Tenable/ACAS folk in the past, and the SPAWAR SCC guys have tested as well. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
SCC will log errors when it finds a check system it doesn't understand but those errors will not stop the processing of OVAL or valid OCIL content. It will process all it can and generate results. Rules that used check systems other than OVAL or OCIL are marked appropriately as NOTCHECKED.
Jim
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jeffrey Blank Sent: Tuesday, August 20, 2013 11:12 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: SSG line item references
SCC barfing on check systems it can't handle is a problem with SCC. They were not following the XCCDF specification for processing the available check systems. I don't know if they've fixed it -- maybe Jack V is lurking here, and could say so.
I'd look at the OVAL results file if you want to see what openscap is gathering, in order to determine the overall pass/fail in the XCCDF results. Look for a few different options for output in `man oscap` -- look for "oval-results". As for all stages of the OVAL evaluation (including what may be filtered) ... that's pretty complicated and may require putting oscap into a debug mode, but removing any filters temporarily may be informative.
On Tue, Aug 20, 2013 at 2:13 PM, Robert Sanders <rsanders@trustedcs.commailto:rsanders@trustedcs.com> wrote:
Interesting. I asked because when I last tried the SSG content with the SCC3.1rc6 beta on a RHEL6.4 box I thought I saw a whole bunch of stuff pop out regarding the OCIL-transitional stuff. Might have been just informational, but I punted then and just ran the oscap stuff. I had hoped to get the increased verbosity out of the SCC scanner for what failed to assist tracing down possible issues with what the prose specified vice what the code was actually doing. So - since I segued into that, is there a magical incantation to give to oscap to dump what is it *really* looking for without having to trace through the content? I'll reference the question I raised last week about the 'Verify File Hashes with RPM' where it seems that the OVAL may be filtering stuff out based on filepath vice where the prose doesn't indicate any filtering.
-Rob
________________________________________ From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.commailto:shawn@redhat.com] Sent: Tuesday, August 20, 2013 1:57 PM
To: scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org Subject: Re: SSG line item references
On 8/20/13 10:51 AM, Robert Sanders wrote:
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.
Existing maps are to the CCIs. Do they want the RHEL-06-****** number for some reason?
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 .......)
Should be compatible with any SCAP compliant scanner. We've worked with the Tenable/ACAS folk in the past, and the SPAWAR SCC guys have tested as well. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Robert Sanders -
Ronayne, James K. -
Shawn Wells