As a DoD Program, "HBSS" 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'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't really help with the newer STIG requirement of HIDS.
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't be used together, as well as the implications of attempting
to use both together (not a good idea at all).
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 "sensor" and the alerts are immediately reported
upstream, not having it installed means the regional security centers won'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'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).
1.
http://www.sealingtech.org/wp-content/uploads/2013/09/Analysis-and-Assess...
~Ed
On Fri, Sep 27, 2013 at 11:51 AM, Shawn Wells <shawn(a)redhat.com> wrote:
On 9/25/13 10:48 AM, Josh Kayse wrote:
On 09/25/2013 10:40 AM, Saxon, William G CIV SPAWARSYSCEN-ATLANTIC, 58810
wrote:
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.
I asked DISA about the HBSS/SELinux conflict and this was their reply:
"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."
There are *so* many things wrong with that response you received.
s/SELinux is not compatible with HBSS/HBSS is not compatible with SELinux/r
Anyway.
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 "verbal
understanding" between Cybercom and HBSS to give *nix systems flexibility
in their configuration until the HBSS/SELinux conflict is resolved which is
why Brain's system made it through IV&V.
FWIW, we (NSA + Red Hat) reached out to DISA FSO to get this sorted. We'll
see how things shake out, with aspirations for some type of formally
documented note in the STIG.
Granted, informal "understandings" within the DoD make me nervous but
that is where we are in right now. So what's the best way to articulate
this within a STIG? Beats me. I suggest the following for group
discussion:
============================
Group ID (Vulid): V-38667
Group Title: SRG-OS-000196
Rule ID: SV-50468r1_rule
Severity: CAT II
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.
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'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.
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's validity in keeping the two
(HIPS, HIDS) as separate requirements.
<snip>
What if the last 3 sentences were:
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.
Perhaps a remapping of SSG rules back to CCIs could be used. The language
from the requirement:
SRG-OS-000196
180.a. The system must have a host-based intrusion detection tool
installed.
<VulnDiscussion>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's systems management regime.</VulnDiscussion>
Remediation instructions
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.
The intent seems to be 'layered defense,' 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*.
Perhaps we could lobby FSO to alter this language to ensure that a HIDS is
installed, regardless of where it comes from.
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
--
R/S
*Ed Sealing
Senior IA/CND Engineer*
*CISSP, CEH, RHCSA*