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:[email protected]] Sent: Tuesday, October 10, 2017 10:09 AM To: SCAP Security Guide <[email protected]> Subject: Re: STIG Rule Id vs Version On Mon, Oct 9, 2017 at 2:14 PM, Shawn Wells <[email protected]<mailto:[email protected]>> 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 [email protected] sent at 2017-10-10 12:02:25 is confidential and may be legally privileged. It is intended solely for use by [email protected] and others authorized to receive it. If you are not [email protected] 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 mailing list -- [email protected] To unsubscribe send an email to [email protected]
