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/rhel...