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-rh...
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 <shawn(a)redhat.com> 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-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".
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide