Trevor makes an interesting point. Representing a specific security policy is just one use case for a "profile".
A profile is just statement about a set of controls: a collection of controls plus variable settings. A profile explicitly about audit rules, for example, could be a useful training tool. Another profile focused on services or libraries, could be useful gathering an adhoc inventory across many systems. Greg Elin P: 917-304-3488 E: grege...@gitmachines.com Sent from my iPhone > On Sep 16, 2014, at 6:06 PM, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > > "Not to mention no single SCAP benchmark can encompass all of the minimum > required controls from the different control families" > > I'm not so sure about this one. Or rather, I'm wondering if a single SCAP > benchmark can encompass the *maximum* required controls from the different > control families. > > In theory, a cross matrix of all regulations should provide a system that > meets all regulations (and is probably unusable, but that's a different > issue). > > Do we have actual conflicting guidance between regs? > > Trevor > >> On Tue, Sep 16, 2014 at 9:39 AM, Chen, Wei (Contractor)(CFPB) >> <wei.c...@cfpb.gov> wrote: >> That sounds great on paper, but it's a one size fits all approach that >> neglects the fact that not all systems will have the same set of controls. >> The set of controls may be different based on the control selection and >> tailoring process that each system has to go through. Not to mention no >> single SCAP benchmark can encompass all of the minimum required controls >> from the different control families. >> >> Regards, >> Wei Chen >> >> 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/ > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaug...@onyxpoint.com > > -- This account not approved for unencrypted proprietary information -- > -- > 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/
