<div dir="ltr">As a DoD Program, &quot;HBSS&quot; is comprised of numerous products (McAfee Agent, McAfee or Symantec A/V, HIPS, Policy Auditor, DCM/DLP, etc, etc), many of which are compatible with RHEL and SELinux. HIPS is the only problem. I&#39;m not up2date on the more recent CTOs, but from what I remember, FRAGO 13 on RHEL meant you had to install the McAfee Agent, and possibly A/V (because the STIG requires it)... but not McAfee HIPS due to conflict with SELinux. Additionally, if you did not use SELinux it was recommended that you install McAfee HIPS. However, If you DO use SELinux (in enforcing mode) then it was recommended that you DO NOT use McAfee HIPS. However, this doesn&#39;t really help with the newer STIG requirement of HIDS.<div>
<br></div><div>If it helps the FSO lobbyying efforts, here is a (1)whitepaper I wrote about 1.5 years ago on the the technical reasons that SELinux and McAfee HIPS 8.0 can&#39;t be used together, as well as the implications of attempting to use both together (not a good idea at all).</div>
<div><br></div><div>The testing we did, although relatively simple, clearly shows that using HIPS in-lieu of SELinux is not in the best interest of security, and allows more attack vectors than it blocks. DISA and Cybercom are aware of these implications and have reviewed the official testing reports, which is why they do not strictly require HIPS on RHEL **If SELinux is Enforcing**. One of the main driving forces for wanting to enable HIPS is for visibility reasons. Since HIPS is a &quot;sensor&quot; and the alerts are immediately reported upstream, not having it installed means the regional security centers won&#39;t have situational awareness of those systems. I believe the question of Security OR Visibility is still being discussed. Hopefully in the near future we&#39;ll have a better way of stacking kernel modules on-top of LSM (would need to be done by either McAfee or SELinux upstream, or both).</div>
<div><br></div><div><div class="gmail_extra">1. <a href="http://www.sealingtech.org/wp-content/uploads/2013/09/Analysis-and-Assessment-of-SELinux-and-McAfee-HIPS.docx">http://www.sealingtech.org/wp-content/uploads/2013/09/Analysis-and-Assessment-of-SELinux-and-McAfee-HIPS.docx</a></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">~Ed</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 27, 2013 at 11:51 AM, Shawn Wells <span dir="ltr">&lt;<a href="mailto:shawn@redhat.com" target="_blank">shawn@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div>
    <div>On 9/25/13 10:48 AM, Josh Kayse wrote:<br>
    </div>
    <blockquote type="cite">On
      09/25/2013 10:40 AM, Saxon, William G CIV SPAWARSYSCEN-ATLANTIC,
      58810 wrote:
      <br>
      <blockquote type="cite">The CTO to which David is referring is
        10-17 (28 July 2010) which mandates that HBSS be deployed on all
        Linux and Unix systems.
        <br>
        <br>
        I asked DISA about the HBSS/SELinux conflict and this was their
        reply:
        <br>
        <br>
        &quot;SELinux is not compatible with HBSS...you can either use
        SELinux as is and submit a waiver to Cybercom, disable the SE
        features and install the required point product(s) (if
        possible), or migrate to a different OS.&quot;
        <br>
      </blockquote>
    </blockquote>
    <br></div>
    There are *so* many things wrong with that response you received. <br>
    <br>
    s/SELinux is not compatible with HBSS/HBSS is not compatible with
    SELinux/r<br>
    <br>
    Anyway.<div><br>
    <br>
    <blockquote type="cite">
      <blockquote type="cite">
        When I contacted the HBSS office to find out how to get a
        waiver, they told me that a waiver was not necessary and that
        there was a &quot;verbal understanding&quot; between Cybercom and HBSS to
        give *nix systems flexibility in their configuration until the
        HBSS/SELinux conflict is resolved which is why Brain&#39;s system
        made it through IV&amp;V.
        <br>
      </blockquote>
    </blockquote>
    <br></div>
    FWIW, we (NSA + Red Hat) reached out to DISA FSO to get this sorted.
    We&#39;ll see how things shake out, with aspirations for some type of
    formally documented note in the STIG. <br><div>
    <br>
    <blockquote type="cite">
      <blockquote type="cite">
        Granted, informal &quot;understandings&quot; within the DoD make me
        nervous but that is where we are in right now.  So what&#39;s the
        best way to articulate this within a STIG?  Beats me.  I suggest
        the following for group discussion:
        <br>
        <br>
        ============================
        <br>
        Group ID (Vulid): V-38667
        <br>
        Group Title: SRG-OS-000196
        <br>
        Rule ID: SV-50468r1_rule
        <br>
        Severity: CAT II
        <br>
        Rule Version (STIG-ID): RHEL-06-000285 Rule Title: The system
        must have a host-based intrusion detection tool and/or a
        host-based intrusion prevention tool installed.
        <br>
        <br>
        Vulnerability Discussion: Adding host-based intrusion detection
        tools can provide the capability to automatically take actions
        in response to malicious behavior, which can provide additional
        agility in reacting to network threats. These tools also often
        include a reporting capability to provide network awareness of
        the system, which may not otherwise exist in an organization&#39;s
        systems management regime.  For DoD systems, the McAfee
        Host-based Security System (HBSS) is provided to fulfill this
        role. Adding host-based intrusion prevention tools increases
        system security by confining privileged programs and user
        sessions.  SELinux is provided to fulfill this role.  At this
        time, HBSS and SELinux are not compatible.
        <br>
      </blockquote>
    </blockquote>
    <br></div>
    This is a good start, though to be fair, while SELinux plays a key
    role in holistic host-based intrusion prevention, it is *not*
    particularly an intrusion detection tool of itself. There&#39;s validity
    in keeping the two (HIPS, HIDS) as separate requirements.<div><br>
    <br>
    <blockquote type="cite">&lt;snip&gt;
      <br>
      <br>
      What if the last 3 sentences were:
      <br>
      Adding host-based intrusion prevention tools increases system
      security by confining privileged programs and user sessions. 
      SELinux can be configured to fulfill the security prevention
      role.  At this time, HBSS and SELinux are not compatible.
    </blockquote></div>
    Perhaps a remapping of SSG rules back to CCIs could be used. The
    language from the requirement:<br>
    <br>
    <blockquote type="cite">SRG-OS-000196<br>
      180.a. The system must have a host-based intrusion detection tool
      installed.<br>
      <span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:justify;font-style:normal;font-weight:normal;float:none;line-height:normal;text-transform:none;font-size:medium;white-space:normal;font-family:sans-serif;word-spacing:0px;display:inline!important">&lt;VulnDiscussion&gt;Adding
        host-based intrusion detection tools can provide the capability
        to automatically take actions in response to malicious behavior,
        which can provide additional agility in reacting to network
        threats. These tools also often include a reporting capability
        to provide network awareness of system, which may not otherwise
        exist in an organization&#39;s systems management
        regime.&lt;/VulnDiscussion&gt;<br>
      </span><br>
      <h4 style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:start;font-style:normal;line-height:normal;text-transform:none;font-size:medium;white-space:normal;font-family:sans-serif;word-spacing:0px">

Remediation instructions<br>
        The base Red Hat platform already includes a sophisticated
        auditing system that can detect intruder activity, as well as
        SELinux, which provides host-based intrusion prevention
        capabilities by confining privileged programs and user sessions
        which may become compromised. Install an additional intrusion
        detection tool to provide complementary or duplicative
        monitoring, reporting, and reaction capabilities to those of the
        base platform. For DoD systems, the McAfee Host-based Security
        System is provided to fulfill this role.</h4>
    </blockquote>
    The intent seems to be &#39;layered defense,&#39; e.g. if native
    capabilities break down within RHEL -- meaning someone corrupts not
    only the AIDE database but further somehow mitigates SELinux -- the
    3rd party software (HBSS) will still hold integrity. This is
    laughable. If native capabilities are mitigated, the box is *owned*.<br>
    <br>
    Perhaps we could lobby FSO to alter this language to ensure that a
    HIDS is installed, regardless of where it comes from.<br>
  </div>

<br>_______________________________________________<br>
scap-security-guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><p><span lang="EN-GB" style="font-size:9pt;font-family:&#39;Times New Roman&#39;,serif">R/S <br><b>Ed Sealing <br>Senior IA/CND Engineer</b><br><b>CISSP, CEH, RHCSA</b></span></p>

</div></div></div>