Thanks for the explanation Shawn! +1 Trey. The more baked starting points SSG offers the better.
You are giving me some ideas, Mt Smith. Greg Elin P: 917-304-3488 E: grege...@gitmachines.com Sent from my iPhone > On Sep 16, 2014, at 9:01 AM, David Smith <dsm...@secure-innovations.net> > wrote: > > 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 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 and others >> authorized to receive it. If you are not >> 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/
-- 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/
