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-st...
Or this one for NIST:
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rh...
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".