DIACAP vs DIARMF & STIGs & CCEs.

David Smith dsmith at secure-innovations.net
Tue Sep 16 13:01:02 UTC 2014


Fortunately, NIST provides 800-53 Rev 4 in XML form to allow for just that
kind of wizardry.

On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield <
trey.henefield at ultra-ats.com> wrote:

>
>
> That is a great breakdown Shawn!
>
> I think it would it be useful to create profiles that align with the RMF
> IA control baselines (low, moderate, high) and also include profiles that
> build upon the IA control baseline profiles to additionally support the
> current 5 overlays (CNSSI No. 1253).
>
> Best regards,
>
>
> Trey Henefield, CISSP
> Senior IAVA Engineer
>
> Ultra Electronics
> Advanced Tactical Systems, Inc.
> 4101 Smith School Road
> Building IV, Suite 100
> Austin, TX 78744 USA
>
> Trey.Henefield at ultra-ats.com
> Tel: +1 512 327 6795 ext. 647
> Fax: +1 512 327 8043
> Mobile: +1 512 541 6450
>
> www.ultra-ats.com
>
>
> -----Original Message-----
> From: scap-security-guide-bounces at lists.fedorahosted.org [mailto:
> scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of Shawn
> Wells
> Sent: Tuesday, September 16, 2014 6:26 AM
> To: scap-security-guide at lists.fedorahosted.org
> Subject: Re: DIACAP vs DIARMF & STIGs & CCEs.
>
> On 9/15/14, 5:02 PM, Greg Elin wrote:
> > I was wondering if anyone was available to explain DIACAP transition
> > to DIARMF and what it means for STIGS and SSG?
> >
> > Happy to have a public email thread, but also happy to take it offline.
> >
> > Here is my summary understanding.
> >
> > DoD developed its own list of information assurance controls under
> > DIACAP (DoD Information Assurance Certification and Accreditation
> > Process).
> >
> > In recent years (2010-2012), the DIACAP started transitioning to
> > DIARMF (DoD Information Assurance Risk Management Framework) to align
> > it with NIST RMF, and to bring the catalog of controls into alignment
> > with the controls listed in 800-53, with some special overlays
> > available for Defense-related systems.
> >
> > As of Spring 2014, that transition is complete.
> >
> > But I'm trying to make sure I understand how the STIGs play into all
> > of this. When I look at the STIGs, I see different control number
> > tracking than from the 800-53s or the CCEs.
> >
> > Is it the case that the Control catalog is now 800-53r4 for both
> > civilian and DoD, but DoD is using STIGs to get to platform specific
> > details while civilian side is using CCEs?
> >
> > If there were just 5 or 6 documents about current/active control
> > catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ???
> >
> > Thanks...
>
> The various RMF implementations call out NIST 800-53 as the place to
> derive implementation requirements.
>
> When DoD (via DISA FSO) goes through NIST 800-53 and pulls out things they
> care about, they call it a STIG.
> When Civilian (via NIST) goes through, the output is called USGCB.
>
> NIST 800-53 has some high-level framework control, e.g. "ABC-1," could say
> something along "Do secure passwords, using [agency defined] values for
> length and complexity."
>
> DISA FSO then takes that requirement defines it further into "Control
> Correlation Identifiers":
> CCI-12345 Passwords must be 12 characters
> CCI-12346 Passwords must contain 2 upper case
> CCI-12347 Passwords must contain 2 special chars
>
> DISA has an entire spreadsheet of these CCI controls per product category
> -- they call these the Security Requirements Guide (SRG). The one RHEL must
> follow is the operating System SRG, and you can find the underlying RHEL7
> STIG requirements here:
> http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx
>
> When a vendor such as Red Hat creates implementation guidance -- exactly
> what variable to change in some specific file -- that is mapped to a
> Configuration Control Enumerator (CCE).
>
>
>
> --
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/
>
>
> *Disclaimer*
> The information contained in this communication from *
> trey.henefield at ultra-ats.com <trey.henefield at ultra-ats.com> * sent at
> 2014-09-16 08:58:20 is private and may be legally privileged or export
> controlled. It is intended solely for use by *
> scap-security-guide at lists.fedorahosted.org
> <scap-security-guide at lists.fedorahosted.org> * and others authorized to
> receive it. If you are not * scap-security-guide at lists.fedorahosted.org
> <scap-security-guide at lists.fedorahosted.org> * you are hereby notified
> that any disclosure, copying, distribution or taking action in reliance of
> the contents of this information is strictly prohibited and may be unlawful.
>
>
> --
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/
>



-- 
David Smith
Sr. Information Security Engineer
Secure Innovations, LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140916/2db6ce5e/attachment-0001.html>


More information about the scap-security-guide mailing list