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:
On Mon, Nov 11, 2013 at 11:02 PM, Jeffrey Blank <blank(a)eclipse.ncsc.mil> 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-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
>