Classification: UNCLASSIFIED Caveats: NONE
Shawn Wells shawn@redhat.com 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: 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
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
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)" ray.v.shaw.ctr@mail.mil wrote:
Classification: UNCLASSIFIED Caveats: NONE
Shawn Wells shawn@redhat.com 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: 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
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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 2/21/13 9:34 AM, Shaw, Ray V CTR (US) wrote:
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?
Any chance you could open a ticket (or two) on these? https://fedorahosted.org/scap-security-guide/newticket
Under the "Milestone" piece please select "RHEL6 STIG - IntialDraft...." This will help ensure we don't lose sight of it :)
On 2/21/13 9:34 AM, Shaw, Ray V CTR (US) wrote:
[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.]
On 2/21/13 10:11 AM, Brian Peake wrote:
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.
<i_work_for_the_vendor>RHT has an army of technical architects whose day job is to deal with these situations. I'd be happy to make introductions to whoever your agencies Red Hat architect is.... they may have some agency-specific insight into how this has been tackled in the past. In my day job, I'm one of the Architects for Intelligence programs. Feel free to reach out to me off-list if you fall under that bucket.</i_work_for_the_vendor>
scap-security-guide@lists.fedorahosted.org