[PATCH] changed major transforms to handle CCIs as references instead of idents

Shawn Wells shawn at redhat.com
Tue May 1 23:02:58 UTC 2012


On 5/1/12 10:16 AM, Jeffrey Blank wrote:
>
>
>> I'm not a fan of using the string "disa" to reference the CCI controls.
>>  From my understanding CCI's are unique identifiers which can map back to
>> several different policies. For example CCI-000370 maps to:
>> - DISA SRG-OS-00022
>> - DISA Group V-30388
>> - DISA OS SRG Rule SV-40055r1
>> - NIST 800-53 CM-6 (1)
>> - NIST 800-53 CM-6 (1).1
>
> Not exactly.  The actual CCI only maps back to the NIST 800-53 rules.

"Not exactly"..... aka engineering speak for "you're completely effing 
wrong" ;)


> The other thing(s) (which are all redundant labels for the OS SRG item)
> are in fact derived from the CCI.  The OS SRG is a selection of CCIs
> relevant to operating systems, with their language adjusted to make
> their applicability to operating systems more apparent.  (Note that the
> CCI list and the OS SRG are separate documents.)
>
> (The redundant labels for an SRG item are a result of the implementation
> of DISA's VMS, which seems peculiar in many ways.)  I chose to use only
> the CCI number (notated as "disa=") as I believe it to be a longer-term
> identifier, and DISA's primary identifier.
>
> You can think of the relationship between the different documents like
> this, with each one becoming more class/product specific:
>
> 800-53 =>  CCI List =>  SRG =>  STIG

This breakdown helps me a lot.


>> If we start tagging the CCI's as<ref disa..>  I think it will get very
>> confusing. Objections to a patch naming them CCI instead of DISA? This
>> would allow a tag such as below which I think is cleaner.
>>
>> <ref nist="CM-6 (1).1, CM-6" cci="000370" ossrg="00022">
>
> I don't object to renaming "disa=" as "cci=".  Such a renaming would
> largely be for aesthetic purposes (though this conversation reveals that
> there may be some value in comprehensibility/disambiguation).  That
> said, I do object to this particular tag since the "ossrg=" attribute is
> redundant to what you are calling "cci".  It provides no value so long
> as there is a one-to-one function from OS SRG identifiers to CCIs.

This begs another question that Mike McConachie and I were discussing 
some yesterday.

Ultimately we want to authoritatively claim that we've addressed 800-53. 
It seems that by addressing all the CCI's we have a perfect mechanism to 
assert such a claim. We can quickly check this by reviewing the 
policytables/rhel6-table-srgmap.html [1] and verifying we have content 
in the last column.
/
(1) Who is the "authoritative source" on mapping CCIs back to 800-53? /
For right or wrong it's been my experience that C&A teams care about 
800-53 mappings and really haven't heard of CCIs. Because of this I 
believe it'd be incredibly beneficial for us to provide some mapping 
back to NIST 800-53. I know DISA did a CCI to OS SRG mapping, and kindly 
put some NIST 800-53 refs in there, but I have the understanding that is 
not "authoritative." I'd be more than happy to be wrong though!

Is there an authoritative source of CCI to NIST mappings, and if so, 
perhaps we could create some transformational pixie dust that takes our 
CCI mapping and correlates it back to 800-53? This would also free us 
from having to manually perform a <ref nist=*> for the rules.

[1]  
http://people.redhat.com/swells/scap-security-guide-0.1/policytables/rhel6-table-srgmap.html 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://fedorahosted.org/pipermail/scap-security-guide/attachments/20120501/7d0f6ecf/attachment.html>


More information about the scap-security-guide mailing list