Ray, We are in the same boat with upcoming inspections, but not even sure if the IV&V team will know what they are doing with Linux - they didn' tast time...
I am seeing the exact same things you have listed when comparing using SSG content w/ SCC3.1 versus OpenScap 0.9.3. I was under the impression most of the issues were OVAL related... Regardless, watching closely to see how this comes together. I prefer OpenScap tbh, but I know inspectors will use SCC. R/ Brian Peake On Feb 21, 2013, at 9:34 AM, "Shaw, Ray V CTR (US)" <[email protected]> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > >> Shawn Wells <[email protected]> wrote: >> 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: >> [email protected] >> >> 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 > > Thanks. I'll be sure to report anything where I would like to see a change > in the actual requirement to the DISA address. > > As a "for instance" for other cases, the prose for the password_min_age check > appears to want this in login.defs: > > PASS_MIN_DAYS 1 > > which is fine, and is what we have. But the actual check appears to be > looking for a value of "7 or higher", so it fails (using both tools; based on > your comments regarding SCC, I won't report anything that fails on SCC but > passes with Open SCAP). > > I'm running into similar issues with the "gconftool-2" type rules, where I've > run the indicated commands and they appear to have written to the appropriate > places, but the checks are still failing. Should I just report things like > that here? > > [We also have an interesting issue where there is an inspection coming up, > and we're not sure whether they're going to use the RHEL5 or RHEL6 draft STIG > to evaluate RHEL6 systems. This is a problem, because there are a bunch of > rules in them that conflict, e.g. /bin/true vs /bin/false or always,exit vs > exit,always; explainable as equivalent and false positives, but makes scans > for one or the other look awful. Hopefully the team will let us know > shortly.] > > -- > Ray Shaw > Contractor, STG > Unix support, Army Research Labs > > > Classification: UNCLASSIFIED > Caveats: NONE > > > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
