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.henefi...@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.henefi...@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-boun...@lists.fedorahosted.org [mailto: > scap-security-guide-boun...@lists.fedorahosted.org] On Behalf Of Shawn > Wells > Sent: Tuesday, September 16, 2014 6:26 AM > To: scap-security-guide@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@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.henefi...@ultra-ats.com <trey.henefi...@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@lists.fedorahosted.org > <scap-security-guide@lists.fedorahosted.org> * and others authorized to > receive it. If you are not * scap-security-guide@lists.fedorahosted.org > <scap-security-guide@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@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
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
