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