Thank you for all the useful feedback! I am actually comparing the SCAP rules against SECSCNcontrols that have already been selected. My team may choose to utilize additional SCAP scans as we see fit, but my minimum requirements are somewhat straight-forward. I realize that many of the controls are open to interpretation but I think in some of these cases a series of SCAP rules can be called to check all aspects. For instance one of our user account configuration control requirements can be covered by calling two SCAP rules. I know this may not work in all cases, but to me it's worth putting in the time to connect all the dots. In some situations SCAP seems more precise than SECSCN which can make the two difficult to compare. ________________________________________ From: [email protected] [[email protected]] on behalf of Jeffrey Blank [[email protected]] Sent: Monday, November 11, 2013 10:18 PM To: [email protected] Subject: Re: EXTERNAL: Re: SECSCN and all_rules profile
Relatedly, there is a security controls catalog which is an ISO standard, so I'd be curious to know if there is any interest in linking the SSG content to it: http://en.wikipedia.org/wiki/ISO/IEC_27002 On Mon, Nov 11, 2013 at 11:02 PM, Jeffrey Blank <[email protected]> wrote: > It is also important to note that NIST 800-53 is not a requirements > document. It is a catalog of security controls (designed to provide a > common vocabulary), from which parties can choose the controls they > wish to implement, often in order to create policy. CNSSI-1253 is one > such example; DISA SRGs (which are being synchronized with Common > Criteria Protection Profiles) are another example as these represent a > DoD selection from the NIST catalog. > > The NIST controls mapped in > http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rhel6-nistrefs.html > are subject to great deal of interpretation. Future patches may bring > these much more in line with DISA's approach (used for the STIG), > which is based on their CCI list (which is itself a deconstructed > version of 800-53, and was created in order to provide the information > from 800-53 in a granular and machine-parseable form). This approach > seems like a more reasonable way to use 800-53. > > Vague association with an 800-53 control, or several 800-53 controls, > as featured in the other table, is not a policy-driven approach; it is > more like a policy-decorated approach, assuming there is any such > policy requiring the implementation of the controls listed there. > > Of course, in the absence of any authoritative guidance on how to > effectively use 800-53, it's very much choose your own adventure. I > suggest choosing one with a degree of clarity, and in which the > benefits outweigh the costs. > > > > > > > > On Mon, Nov 4, 2013 at 8:34 PM, Shawn Wells <[email protected]> wrote: >> 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 >> _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
