<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Trevor makes an interesting point.&nbsp;</div><div><br></div><div>Representing a specific security policy is just one use case for a "profile".</div><div><br></div><div>A profile is just statement about a set of controls: a collection of controls plus variable settings.&nbsp;</div><div><br></div><div>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.&nbsp;</div><div><br></div><div><br>Greg Elin<div>P: 917-304-3488</div><div>E: &nbsp;<a href="mailto:gregelin@gitmachines.com">gregelin@gitmachines.com</a></div><div><br></div><div>Sent from my iPhone</div></div><div><br>On Sep 16, 2014, at 6:06 PM, Trevor Vaughan &lt;<a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">"<span style="font-family:arial,sans-serif;font-size:13px">Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families"</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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).</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Do we have actual conflicting guidance between regs?</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Trevor</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 16, 2014 at 9:39 AM, Chen, Wei (Contractor)(CFPB) <span dir="ltr">&lt;<a href="mailto:Wei.Chen@cfpb.gov" target="_blank">Wei.Chen@cfpb.gov</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.&nbsp; The set of controls may be different based on the control selection and tailoring process that each system has to go through.&nbsp; Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families.<br>
<br>
Regards,<br>
Wei Chen<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield &lt; <a href="mailto:trey.henefield@ultra-ats.com">trey.henefield@ultra-ats.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt; That is a great breakdown Shawn!<br>
&gt;<br>
&gt; I think it would it be useful to create profiles that align with the<br>
&gt; RMF IA control baselines (low, moderate, high) and also include<br>
&gt; profiles that build upon the IA control baseline profiles to<br>
&gt; additionally support the current 5 overlays (CNSSI No. 1253).<br>
&gt;<br>
&gt; Best regards,<br>
&gt;<br>
&gt;<br>
&gt; Trey Henefield, CISSP<br>
&gt; Senior IAVA Engineer<br>
&gt;<br>
&gt; Ultra Electronics<br>
&gt; Advanced Tactical Systems, Inc.<br>
&gt; 4101 Smith School Road<br>
&gt; Building IV, Suite 100<br>
&gt; Austin, TX 78744 USA<br>
&gt;<br>
&gt; <a href="mailto:Trey.Henefield@ultra-ats.com">Trey.Henefield@ultra-ats.com</a><br>
&gt; Tel: <a href="tel:%2B1%20512%20327%206795%20ext.%20647" value="+15123276795">+1 512 327 6795 ext. 647</a><br>
&gt; Fax: <a href="tel:%2B1%20512%20327%208043" value="+15123278043">+1 512 327 8043</a><br>
&gt; Mobile: <a href="tel:%2B1%20512%20541%206450" value="+15125416450">+1 512 541 6450</a><br>
&gt;<br>
&gt; <a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:scap-security-guide-bounces@lists.fedorahosted.org">scap-security-guide-bounces@lists.fedorahosted.org</a> [mailto:<br>
&gt; <a href="mailto:scap-security-guide-bounces@lists.fedorahosted.org">scap-security-guide-bounces@lists.fedorahosted.org</a>] On Behalf Of Shawn<br>
&gt; Wells<br>
&gt; Sent: Tuesday, September 16, 2014 6:26 AM<br>
&gt; To: <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt; Subject: Re: DIACAP vs DIARMF &amp; STIGs &amp; CCEs.<br>
&gt;<br>
&gt; On 9/15/14, 5:02 PM, Greg Elin wrote:<br>
&gt; &gt; I was wondering if anyone was available to explain DIACAP transition<br>
&gt; &gt; to DIARMF and what it means for STIGS and SSG?<br>
&gt; &gt;<br>
&gt; &gt; Happy to have a public email thread, but also happy to take it offline.<br>
&gt; &gt;<br>
&gt; &gt; Here is my summary understanding.<br>
&gt; &gt;<br>
&gt; &gt; DoD developed its own list of information assurance controls under<br>
&gt; &gt; DIACAP (DoD Information Assurance Certification and Accreditation<br>
&gt; &gt; Process).<br>
&gt; &gt;<br>
&gt; &gt; In recent years (2010-2012), the DIACAP started transitioning to<br>
&gt; &gt; DIARMF (DoD Information Assurance Risk Management Framework) to<br>
&gt; &gt; align it with NIST RMF, and to bring the catalog of controls into<br>
&gt; &gt; alignment with the controls listed in 800-53, with some special<br>
&gt; &gt; overlays available for Defense-related systems.<br>
&gt; &gt;<br>
&gt; &gt; As of Spring 2014, that transition is complete.<br>
&gt; &gt;<br>
&gt; &gt; But I'm trying to make sure I understand how the STIGs play into all<br>
&gt; &gt; of this. When I look at the STIGs, I see different control number<br>
&gt; &gt; tracking than from the 800-53s or the CCEs.<br>
&gt; &gt;<br>
&gt; &gt; Is it the case that the Control catalog is now 800-53r4 for both<br>
&gt; &gt; civilian and DoD, but DoD is using STIGs to get to platform specific<br>
&gt; &gt; details while civilian side is using CCEs?<br>
&gt; &gt;<br>
&gt; &gt; If there were just 5 or 6 documents about current/active control<br>
&gt; &gt; catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ???<br>
&gt; &gt;<br>
&gt; &gt; Thanks...<br>
&gt;<br>
&gt; The various RMF implementations call out NIST 800-53 as the place to<br>
&gt; derive implementation requirements.<br>
&gt;<br>
&gt; When DoD (via DISA FSO) goes through NIST 800-53 and pulls out things<br>
&gt; they care about, they call it a STIG.<br>
&gt; When Civilian (via NIST) goes through, the output is called USGCB.<br>
&gt;<br>
&gt; NIST 800-53 has some high-level framework control, e.g. "ABC-1," could<br>
&gt; say something along "Do secure passwords, using [agency defined]<br>
&gt; values for length and complexity."<br>
&gt;<br>
&gt; DISA FSO then takes that requirement defines it further into "Control<br>
&gt; Correlation Identifiers":<br>
&gt; CCI-12345 Passwords must be 12 characters<br>
&gt; CCI-12346 Passwords must contain 2 upper case<br>
&gt; CCI-12347 Passwords must contain 2 special chars<br>
&gt;<br>
&gt; DISA has an entire spreadsheet of these CCI controls per product<br>
&gt; category<br>
&gt; -- they call these the Security Requirements Guide (SRG). The one RHEL<br>
&gt; must follow is the operating System SRG, and you can find the<br>
&gt; underlying RHEL7 STIG requirements here:<br>
&gt; <a href="http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx" target="_blank">http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx</a><br>
&gt;<br>
&gt; When a vendor such as Red Hat creates implementation guidance --<br>
&gt; exactly what variable to change in some specific file -- that is<br>
&gt; mapped to a Configuration Control Enumerator (CCE).<br>
--<br>
SCAP Security Guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
<a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Trevor Vaughan<br>Vice President, Onyx Point, Inc<br>(410) 541-6699<br><a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a><br><br>-- This account not approved for unencrypted proprietary information --
</div>
</div></blockquote><blockquote type="cite"><div><span>-- </span><br><span>SCAP Security Guide mailing list</span><br><span><a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a></span><br><span><a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a></span><br><span><a href="https://github.com/OpenSCAP/scap-security-guide/">https://github.com/OpenSCAP/scap-security-guide/</a></span></div></blockquote></body></html>