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(a)lists.fedorahosted.org>
Subject: Re: STIG Rule Id vs Version
On Mon, Oct 9, 2017 at 2:14 PM, Shawn Wells
<shawn@redhat.com<mailto: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"...
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(a)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(a)lists.fedorahosted.org and others
authorized to receive it. If you are not scap-security-guide(a)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.