EXTERNAL: Re: SECSCN and all_rules profile

Jeffrey Blank blank at eclipse.ncsc.mil
Tue Nov 12 05:18:22 UTC 2013


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 <blank at 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-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 <shawn at 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-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
>> scap-security-guide at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>>


More information about the scap-security-guide mailing list