Classification: UNCLASSIFIED Caveats: NONE
During the public comment period, should I be sending comments to DISA regarding the benchmark content (which they didn't include in their download), or just regarding the prose (e.g. "I would like to see ___ as an acceptable setting as well as the stated value of ____")?
I have about 67 total checks that are failing (using SCC 3.1...getting somewhat different results with Open SCAP 0.9.3, which I will have more details on later). Many of them are false positives (they comply with the prose, but - IMHO - the benchmark check is getting it wrong). For the others, I'd like a change in the actual requirement. I just want to make sure I'm reporting the right things to the right place.
[I also plan to try to "become a developer" and make contributions so I don't just feel like I'm complaining, but editing this sort of content is new to me.]
The benchmark content I'm using is the recently rebased RPM (scap-security-guide-0.1-10.el6.noarch.rpm).
Thanks,
-- Ray Shaw Contractor, STG Unix support, Army Research Labs
Classification: UNCLASSIFIED Caveats: NONE
On 2/20/13 12:49 PM, Shaw, Ray V CTR (US) wrote:
Classification: UNCLASSIFIED Caveats: NONE
During the public comment period, should I be sending comments to DISA regarding the benchmark content (which they didn't include in their download), or just regarding the prose (e.g. "I would like to see ___ as an acceptable setting as well as the stated value of ____")?
It is a little awkward and confusing.
Feedback against the DISA RHEL6 STIG prose should be sent to DISA FSO. They are the publishing authority of the STIG and we don't want to avoid a situation where FSO is unaware of said feedback (and thus the feedback doesn't make it into the final STIG). Their EMail address is: disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil
With that said, the SSG serves as upstream for the RHEL6 STIG content. If you give us a heads up, we may be able to get it fixed before the public comment period even ends :) We also track feedback via our ticketing system, which allows us to correlate any reported findings with DISA FSO: https://fedorahosted.org/scap-security-guide/report/3
I have about 67 total checks that are failing (using SCC 3.1...getting somewhat different results with Open SCAP 0.9.3, which I will have more details on later). Many of them are false positives (they comply with the prose, but - IMHO - the benchmark check is getting it wrong). For the others, I'd like a change in the actual requirement. I just want to make sure I'm reporting the right things to the right place.
FSO's public draft doesn't include OVAL content yet, so please do sent reports here.
The SCC developers allowed me to have access to their Alpha and Release Candidate builds, and were incredibly communicative as we discussed challenges. Unfortunately, even with the SCC 3.1 GA release, issues remain around the proper parsing of XCCDF and certain OVAL checks. Until these issues are resolved the SCC tool simply isn't capable of scanning systems against the RHEL6 STIG. People are going to be forced to use different tooling.
One of the largest issues with SCC is that it skips a rule, entirely, if OCIL content is present. This automatically causes several failures, you can view my logs here: http://people.redhat.com/swells/SCC/Logs/RHEL6_SCC-3.1_2013-02-17_102333_Scr...
[I also plan to try to "become a developer" and make contributions so I don't just feel like I'm complaining, but editing this sort of content is new to me.]
The benchmark content I'm using is the recently rebased RPM (scap-security-guide-0.1-10.el6.noarch.rpm).
Very cool! Let us know if there's anything we can assist with as you start down the developer path. Actually, speaking of getting started as a developer... I've been debating about hosting a "Intro to SSG" / hacksession at the RHT office. I'll post about that shortly.
One of the largest issues with SCC is that it skips a rule, entirely, if OCIL content is present. This automatically causes several failures, you can view my logs here: http://people.redhat.com/swells/SCC/Logs/RHEL6_SCC-3.1_2013-02-17_102333_Scr...
In this case the SCC behavior is a bug per the XCCDF specification, on page 59: http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf
When you get different results from different tools, the specification is the place to look, for what is "correct" behavior. It may not be an easy read, but it does provide an authoritative answer...
[I also plan to try to "become a developer" and make contributions so I don't just feel like I'm complaining, but editing this sort of content is new to me.]
The benchmark content I'm using is the recently rebased RPM (scap-security-guide-0.1-10.el6.noarch.rpm).
scap-security-guide@lists.fedorahosted.org