No subject


Fri Apr 27 03:18:18 UTC 2012


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
</pre>
      </blockquote>
      <pre wrap="">

Not exactly.  The actual CCI only maps back to the NIST 800-53 rules.</pre>
    </blockquote>
    <br>
    "Not exactly"..... aka engineering speak for "you're completely
    effing wrong" ;)<br>
    <br>
    <br>
    <blockquote cite="mid:4F9FF02F.7030704 at eclipse.ncsc.mil" type="cite">
      <pre wrap="">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 =&gt; CCI List =&gt; SRG =&gt; STIG</pre>
    </blockquote>
    <br>
    This breakdown helps me a lot.<br>
    <br>
    <br>
    <blockquote cite="mid:4F9FF02F.7030704 at eclipse.ncsc.mil" type="cite">
      <blockquote type="cite">
        <pre wrap="">If we start tagging the CCI's as &lt;ref disa..&gt; 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.

&lt;ref nist="CM-6 (1).1, CM-6" cci="000370" ossrg="00022"&gt;
</pre>
      </blockquote>
      <pre wrap="">

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.
</pre>
    </blockquote>
    <br>
    This begs another question that Mike McConachie and I were
    discussing some yesterday.<br>
    <br>
    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.<br>
    <i><br>
      (1) Who is the "authoritative source" on mapping CCIs back to
      800-53? </i><br>
    For right or wrong it's been my experience that C&amp;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!<br>
    <br>
    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 &lt;ref nist=*&gt; for the
    rules.<br>
    <br>
    [1] 
<a class="moz-txt-link-freetext" href="http://people.redhat.com/swells/scap-security-guide-0.1/policytables/rhel6-table-srgmap.html">http://people.redhat.com/swells/scap-security-guide-0.1/policytables/rhel6-table-srgmap.html</a>
  </body>
</html>

--------------090309080902090000010004--


More information about the scap-security-guide mailing list