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".