Hi all,
I noticed something strange in the information we have about the STIG Profiles. The problem is that what we internally refer as "Stig ID" is actually the STIG Rule "Version", it seems like "RHEL-7-01010101", meanwhile, we just ignore the real id of the STIG Rule that seems like "SV-86473r2_rule".
When SSG is built, this id (version actually) is output as a Rule reference, for example: "<reference href="http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx">RHEL-07-010010</reference>"
Although this "Version" is different for each Rule, it does not change when there is new revision, meaning that we are not able to tell which revision of a rule we are evaluating based on this field, on the other hand, the real id gets incremented when there is a new revision for that rule, for example "SV-86473r2_rule" becomes "SV-86473r3_rule".
I'm currently trying to enable OpenSCAP to output the result of a scanning in a way the STIG Viewer is able to read it and populate a checklist, but it only understands the real id. Unfortunatelly, there is no place, except for comments, where I can get this id.
A workaround for my development is to create another tag (probably a reference) in the Rule with the actual STIG id, but I'd like to hear from you if someone know the story behind this before I move on.
Thanks
Wesley
On 10/9/17 1:19 PM, Wesley Ceraso Prudencio wrote:
Hi all,
I noticed something strange in the information we have about the STIG Profiles. The problem is that what we internally refer as "Stig ID" is actually the STIG Rule "Version", it seems like "RHEL-7-01010101", meanwhile, we just ignore the real id of the STIG Rule that seems like "SV-86473r2_rule".
When SSG is built, this id (version actually) is output as a Rule reference, for example: "<reference href="http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx">RHEL-07-010010</reference>"
Although this "Version" is different for each Rule, it does not change when there is new revision, meaning that we are not able to tell which revision of a rule we are evaluating based on this field, on the other hand, the real id gets incremented when there is a new revision for that rule, for example "SV-86473r2_rule" becomes "SV-86473r3_rule".
I'm currently trying to enable OpenSCAP to output the result of a scanning in a way the STIG Viewer is able to read it and populate a checklist, but it only understands the real id. Unfortunatelly, there is no place, except for comments, where I can get this id.
A workaround for my development is to create another tag (probably a reference) in the Rule with the actual STIG id, but I'd like to hear from you if someone know the story behind this before I move on.
I don't really know what is fact vs fiction anymore, but from my version of reality wayyyy back when SSG started DoD accreditors were asking for the RHEL-06-XXXXX identifiers (and we carried that forward to RHEL7 content).
IMHO there is no consistency between users and various tools on the usage between RHEL-07-#### and the SV-#####r#_rule tags. We should support both -- especially if it means progress with STIG Viewer.
I started marking Puppet code with CCE references. Is there any consistent notation used across multiple tools ?
On Oct 9, 2017, at 4:14 PM, Shawn Wells shawn@redhat.com wrote:
On 10/9/17 1:19 PM, Wesley Ceraso Prudencio wrote: Hi all,
I noticed something strange in the information we have about the STIG Profiles. The problem is that what we internally refer as "Stig ID" is actually the STIG Rule "Version", it seems like "RHEL-7-01010101", meanwhile, we just ignore the real id of the STIG Rule that seems like "SV-86473r2_rule".
When SSG is built, this id (version actually) is output as a Rule reference, for example: "<reference href="http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx">RHEL-07-010010</reference>"
Although this "Version" is different for each Rule, it does not change when there is new revision, meaning that we are not able to tell which revision of a rule we are evaluating based on this field, on the other hand, the real id gets incremented when there is a new revision for that rule, for example "SV-86473r2_rule" becomes "SV-86473r3_rule".
I'm currently trying to enable OpenSCAP to output the result of a scanning in a way the STIG Viewer is able to read it and populate a checklist, but it only understands the real id. Unfortunatelly, there is no place, except for comments, where I can get this id.
A workaround for my development is to create another tag (probably a reference) in the Rule with the actual STIG id, but I'd like to hear from you if someone know the story behind this before I move on.
I don't really know what is fact vs fiction anymore, but from my version of reality wayyyy back when SSG started DoD accreditors were asking for the RHEL-06-XXXXX identifiers (and we carried that forward to RHEL7 content).
IMHO there is no consistency between users and various tools on the usage between RHEL-07-#### and the SV-#####r#_rule tags. We should support both -- especially if it means progress with STIG Viewer. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
On Mon, Oct 9, 2017 at 2:14 PM, Shawn Wells shawn@redhat.com wrote:
On 10/9/17 1:19 PM, Wesley Ceraso Prudencio wrote:
Hi all,
I noticed something strange in the information we have about the STIG Profiles. The problem is that what we internally refer as "Stig ID" is actually the STIG Rule "Version", it seems like "RHEL-7-01010101", meanwhile, we just ignore the real id of the STIG Rule that seems like "SV-86473r2_rule".
When SSG is built, this id (version actually) is output as a Rule reference, for example: "<reference href="http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx" http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx>RHEL-07-010010</reference>"
Although this "Version" is different for each Rule, it does not change when there is new revision, meaning that we are not able to tell which revision of a rule we are evaluating based on this field, on the other hand, the real id gets incremented when there is a new revision for that rule, for example "SV-86473r2_rule" becomes "SV-86473r3_rule".
I'm currently trying to enable OpenSCAP to output the result of a scanning in a way the STIG Viewer is able to read it and populate a checklist, but it only understands the real id. Unfortunatelly, there is no place, except for comments, where I can get this id.
A workaround for my development is to create another tag (probably a reference) in the Rule with the actual STIG id, but I'd like to hear from you if someone know the story behind this before I move on.
I don't really know what is fact vs fiction anymore, but from my version of reality wayyyy back when SSG started DoD accreditors were asking for the RHEL-06-XXXXX identifiers (and we carried that forward to RHEL7 content).
IMHO there is no consistency between users and various tools on the usage between RHEL-07-#### and the SV-#####r#_rule tags. We should support both -- especially if it means progress with STIG Viewer.
I have yet to see accreditors ask for SV- rule tags. I guess it happens in some circles, but the RHEL identifiers were the ones that I have always seen referenced. Of course when RMF came into the picture, it was all about NIST mappings and very little about STIG identifiers.
On 10/10/2017 11:24 AM, Gabe Alford wrote:
I have yet to see accreditors ask for SV- rule tags. I guess it happens in some circles, but the RHEL identifiers were the ones that I have always seen referenced. Of course when RMF came into the picture, it was all about NIST mappings and very little about STIG identifiers.
eMASS uses SV tags for mapping. It's the only way to link an issue in an (eMASS) POA&M directly back to the STIG rule.
I believe I was the one to originally request adding in the STIG identifiers. From my standpoint, it was a matter of being able to associate a rule to a requirement and being able to demonstrate all requirements are met. The STIG requirements have generally been referred to by STIG ID, because quite honestly, its easier to track STIG IDs than the rule IDs.
But for the purpose of being able to import results into the STIG Viewer, I 100% agree that this change needs to happen. Can it be done without losing the reference to the STIG IDs though? Its very useful seeing the associated STIG ID for each rule within the scan report.
I also agree that with the growing presence of RMF, IA control identifiers are also quite essential. To that regard, it would be nice to create another table mapping of the RMF IA controls addressed for each STIG.
Best regards,
Trey Henefield, CISSP
From: Gabe Alford [mailto:redhatrises@gmail.com] Sent: Tuesday, October 10, 2017 10:09 AM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: Re: STIG Rule Id vs Version
On Mon, Oct 9, 2017 at 2:14 PM, Shawn Wells <shawn@redhat.commailto:shawn@redhat.com> wrote:
On 10/9/17 1:19 PM, Wesley Ceraso Prudencio wrote:
Hi all,
I noticed something strange in the information we have about the STIG Profiles. The problem is that what we internally refer as "Stig ID" is actually the STIG Rule "Version", it seems like "RHEL-7-01010101", meanwhile, we just ignore the real id of the STIG Rule that seems like "SV-86473r2_rule".
When SSG is built, this id (version actually) is output as a Rule reference, for example:
"<reference href="http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx"http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx>RHEL-07-010010</reference>"
Although this "Version" is different for each Rule, it does not change when there is new revision, meaning that we are not able to tell which revision of a rule we are evaluating based on this field, on the other hand, the real id gets incremented when there is a new revision for that rule, for example "SV-86473r2_rule" becomes "SV-86473r3_rule".
I'm currently trying to enable OpenSCAP to output the result of a scanning in a way the STIG Viewer is able to read it and populate a checklist, but it only understands the real id. Unfortunatelly, there is no place, except for comments, where I can get this id.
A workaround for my development is to create another tag (probably a reference) in the Rule with the actual STIG id, but I'd like to hear from you if someone know the story behind this before I move on.
I don't really know what is fact vs fiction anymore, but from my version of reality wayyyy back when SSG started DoD accreditors were asking for the RHEL-06-XXXXX identifiers (and we carried that forward to RHEL7 content).
IMHO there is no consistency between users and various tools on the usage between RHEL-07-#### and the SV-#####r#_rule tags. We should support both -- especially if it means progress with STIG Viewer.
I have yet to see accreditors ask for SV- rule tags. I guess it happens in some circles, but the RHEL identifiers were the ones that I have always seen referenced. Of course when RMF came into the picture, it was all about NIST mappings and very little about STIG identifiers.
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.com sent at 2017-10-10 12:02:25 is confidential and may be legally privileged. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
scap-security-guide@lists.fedorahosted.org
-
Arnold, Paul C CTR USARMY PEO STRI (US) -
Dan White -
Gabe Alford -
Shawn Wells -
Trey Henefield -
Wesley Ceraso Prudencio