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