On 11/4/13, 7:38 PM, Kordell, Luke T wrote:
Thank you! I am using the all_rules profile to compare currently developed SCAP
rules to the checks carried-out by SECSCN. For some of the auditing checks
that SECSCN runs this may be difficult, but I hope to prove that SCAP is just
as comprehensive.
This conversation creeps up every now and then. SECSCN is a tool.
OpenSCAP is a tool. SCAP Security Guide, I suppose, can be argued is a
tool. Tools must comprehensively address /policy/.
To ensure SSG addresses /policy/, collaboration occurred directly with
policy owners such as DISA FSO (for the STIG) and NSA (for the SNAC
guides). DISA calls out this collaboration within section 1.1 of the
STIG Overview:
The consensus content was developed using an open-source project
called SCAP Security Guide.
The project’s website is
https://fedorahosted.org/scap-security-guide/. Except for differences in
formatting to accommodate the DISA STIG publishing process, the
content of the RHEL6 STIG
should mirror the SCAP Security Guide content with only minor
divergence as updates from
multiple sources work through the consensus process.
To aid in this, refer to the policy tables, such as this one for the STIG:
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-stig-rhel6.html
Or this one for NIST:
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rhel6-nistrefs.html
Thoughts on what additional information SSG could provide to show policy
correlations would be most welcome.
I guess this has turned into an OVAL oriented question concerning how it defines system
objects. I think at this point a fail/pass value and a well-described rule should be more
than enough for a system administrator to find and address whatever caused a
"fail".
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
