<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 9/25/13 10:48 AM, Josh Kayse wrote:<br>
</div>
<blockquote cite="mid:5242F7CC.50202@gtri.gatech.edu" 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>
"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."
<br>
</blockquote>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:5242F7CC.50202@gtri.gatech.edu" 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 "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.
<br>
</blockquote>
</blockquote>
<br>
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. <br>
<br>
<blockquote cite="mid:5242F7CC.50202@gtri.gatech.edu" type="cite">
<blockquote type="cite">
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:
<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'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>
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.<br>
<br>
<blockquote cite="mid:5242F7CC.50202@gtri.gatech.edu" type="cite"><snip>
<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>
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="color: rgb(0, 0, 0); font-family: sans-serif;
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: justify; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); display: inline
!important; float: none;"><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><br>
</span><br>
<h4 class="short" style="color: rgb(0, 0, 0); font-family:
sans-serif; font-size: medium; font-style: normal; font-variant:
normal; letter-spacing: normal; line-height: normal; orphans:
auto; text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255);">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 '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*.<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>
</body>
</html>