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."
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.
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.
Check Content: Inspect the system to determine if intrusion detection software or intrusion prevention software has been installed. Verify the installed software is active. If neither a host-based intrusion detection tool (For DoD systems, this is HBSS) nor a host-based intrusion prevention tool (SELinux) is installed, this is a finding.
Fix Text: Install either a host-based intrusion detection tool (For DoD systems, install HBSS) or a host-based intrusion prevention tool (SELinux). ========================
William G. (Bill) Saxon, CISSP, GSLC, VIP, Security+, Network+, Master and B.S. CpE, B.S. PHY CSWF IAM2/IAT2
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of scap-security-guide-request@lists.fedorahosted.org Sent: Wednesday, September 25, 2013 8:00 To: scap-security-guide@lists.fedorahosted.org Subject: scap-security-guide Digest, Vol 25, Issue 74
Send scap-security-guide mailing list submissions to scap-security-guide@lists.fedorahosted.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide or, via email, send a message with subject or body 'help' to scap-security-guide-request@lists.fedorahosted.org
You can reach the person managing the list at scap-security-guide-owner@lists.fedorahosted.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of scap-security-guide digest..."
Today's Topics:
1. RE: RHEL5 vs RHEL6 language on HBSS (Moessbauer, David) 2. Re: RHEL5 vs RHEL6 language on HBSS (Brian Peake)
----------------------------------------------------------------------
Message: 1 Date: Tue, 24 Sep 2013 16:35:29 -0400 From: "Moessbauer, David" david.moessbauer@progeny.net To: "scap-security-guide@lists.fedorahosted.org" scap-security-guide@lists.fedorahosted.org Subject: RE: RHEL5 vs RHEL6 language on HBSS Message-ID: 6BC30DD8322F394CB35455E71037B2F61252B95A58@ES2K7-MBX-1.progeny.net Content-Type: text/plain; charset="utf-8"
I am not sure about your comment regarding "[HBSS] isn't *mandated.*"
My experience with the fleet tells me otherwise, as both ODAA during accreditation and deployed platforms are requiring compliance with HBSS of our system. Additionally, I do believe I have seen a CTO distributed by the Navy that states otherwise, though I can't seem to put my hands on it at the moment.
Please advise if I am incorrect in this belief.
v/r
David Moessbauer (410) 627-5633 (M)
The Information contained in or attached to this communication may be confidential and privileged proprietary intended only for the individual/s or entity to whom/which it is addressed. Any unauthorized use, distribution, copying or disclosure of this information is strictly prohibited. If you have received this communication in error please contact the sender immediately and delete from your system.
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Truhn, Chad M CTR NSWCDD, CXA30 Sent: Tuesday, September 24, 2013 4:12 PM To: scap-security-guide@lists.fedorahosted.org Subject: (nwl) RE: RHEL5 vs RHEL6 language on HBSS
Shawn,
Reverting back to an email you sent to gov-sec back in June (attached), you said:
" So, even though you've configured your system with all these auditing rules, configured AIDE for integrity checking, *and* have SELinux enforcing, FSO wants you to layer on an *additional* level of host intrusion detection which can provide "complementary or duplicative monitoring, reporting, and reaction capabilities."
As stated in the STIG, DoD provides McAfee HBSS to perform this function. But it isn't *mandated.*"
Then in ticket #262 from the SSG page:
"HIPS is a category of technology, and while McAfee? is commonly used to meet this, is not tied to a particular product/vendor. Users would be wise to select technology which is certified to run on RHEL6 without disabling key OS level protection mechanisms (e.g., if McAfee? breaks your system, use something else)." [1]
" MPO/FSO/RH: 3rd party products should work with the operating systems they run on, without forcing users to disable security mechanisms. Won't fix."
I have always been confused about this language. Do we want SELinux enabled *AND* HIPS installed? Or should it be an *OR*? One says McAfee HBSS/HIPS is fine, another says it isn't. I'm confused!!!
[1] https://fedorahosted.org/scap-security-guide/ticket/262
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Tuesday, September 24, 2013 3:21 PM To: scap-security-guide@lists.fedorahosted.org Subject: RHEL5 vs RHEL6 language on HBSS
I received the following note from a colleague today, outlining the wording changes between RHEL5 and RHEL6 regarding HBSS. I searched the mailing archives, and can't figure out *why* the language was changed.
- Anyone remember why? - Objections to reverting to the RHEL5 language?
EMail:
from the RHEL 6 STIG:
============================ 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 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 system, which may not otherwise exist in an organization's systems management regime.
Check Content: Inspect the system to determine if intrusion detection software has been installed. Verify the intrusion detection software is active. If no host-based intrusion detection tools are installed, this is a finding.
Fix Text: 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.
to look more like this from the RHEL 5 STIG:
========================= Group ID (Vulid): V-782 Group Title: GEN006480 Rule ID: SV-37746r2_rule Severity: CAT II Rule Version (STIG-ID): GEN006480 Rule Title: The system must have a host-based intrusion detection tool installed.
Vulnerability Discussion: Without a host-based intrusion detection tool, there is no system-level defense when an intruder gains access to a system or network. Additionally, a host-based intrusion detection tool can provide methods to immediately lock out detected intrusion attempts.
Responsibility: System Administrator IAControls: ECID-1
Check Content: Ask the SA or IAO if a host-based intrusion detection application is loaded on the system. The preferred intrusion detection system is McAfee HBSS available through Cybercom. If another host-based intrusion detection application, such as SELinux, is used on the system, this is not a finding. =========================
People are getting confused and SElinux and HBSS are getting installed with SElinux being disabled to make things work.
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
------------------------------
Message: 2 Date: Tue, 24 Sep 2013 18:00:13 -0400 From: Brian Peake PEAKE@HIPKLLC.COM To: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL5 vs RHEL6 language on HBSS Message-ID: CE678204.7C03%PEAKE@HIPKLLC.COM Content-Type: text/plain; charset="ISO-8859-1"
I believe the current guidance is to have McAfee Agent installed only. At least that is where we are at now, and just went through our IV&V. I also have uvscan installed along with AIDE w/ daily cron jobs for both. HIPS etcŠ are not "required". But again I am not an expert and do not delineate any guidance.
I would have to find the guidance, and am on travel right now, however when I return my ePo/HBSS "guy" can give me the reference.
Very Respectfully, Brian Peake
On 9/24/13 4:35 PM, "Moessbauer, David" david.moessbauer@progeny.net wrote:
I am not sure about your comment regarding "[HBSS] isn't *mandated.*"
My experience with the fleet tells me otherwise, as both ODAA during accreditation and deployed platforms are requiring compliance with HBSS of our system. Additionally, I do believe I have seen a CTO distributed by the Navy that states otherwise, though I can't seem to put my hands on it at the moment.
Please advise if I am incorrect in this belief.
v/r
David Moessbauer (410) 627-5633 (M)
The Information contained in or attached to this communication may be confidential and privileged proprietary intended only for the individual/s or entity to whom/which it is addressed. Any unauthorized use, distribution, copying or disclosure of this information is strictly prohibited. If you have received this communication in error please contact the sender immediately and delete from your system.
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Truhn, Chad M CTR NSWCDD, CXA30 Sent: Tuesday, September 24, 2013 4:12 PM To: scap-security-guide@lists.fedorahosted.org Subject: (nwl) RE: RHEL5 vs RHEL6 language on HBSS
Shawn,
Reverting back to an email you sent to gov-sec back in June (attached), you said:
" So, even though you've configured your system with all these auditing rules, configured AIDE for integrity checking, *and* have SELinux enforcing, FSO wants you to layer on an *additional* level of host intrusion detection which can provide "complementary or duplicative monitoring, reporting, and reaction capabilities."
As stated in the STIG, DoD provides McAfee HBSS to perform this function. But it isn't *mandated.*"
Then in ticket #262 from the SSG page:
"HIPS is a category of technology, and while McAfee? is commonly used to meet this, is not tied to a particular product/vendor. Users would be wise to select technology which is certified to run on RHEL6 without disabling key OS level protection mechanisms (e.g., if McAfee? breaks your system, use something else)." [1]
" MPO/FSO/RH: 3rd party products should work with the operating systems they run on, without forcing users to disable security mechanisms. Won't fix."
I have always been confused about this language. Do we want SELinux enabled *AND* HIPS installed? Or should it be an *OR*? One says McAfee HBSS/HIPS is fine, another says it isn't. I'm confused!!!
[1] https://fedorahosted.org/scap-security-guide/ticket/262
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Tuesday, September 24, 2013 3:21 PM To: scap-security-guide@lists.fedorahosted.org Subject: RHEL5 vs RHEL6 language on HBSS
I received the following note from a colleague today, outlining the wording changes between RHEL5 and RHEL6 regarding HBSS. I searched the mailing archives, and can't figure out *why* the language was changed.
- Anyone remember why?
- Objections to reverting to the RHEL5 language?
EMail:
from the RHEL 6 STIG:
============================ 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 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 system, which may not otherwise exist in an organization's systems management regime.
Check Content: Inspect the system to determine if intrusion detection software has been installed. Verify the intrusion detection software is active. If no host-based intrusion detection tools are installed, this is a finding.
Fix Text: 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. ========================
to look more like this from the RHEL 5 STIG:
========================= Group ID (Vulid): V-782 Group Title: GEN006480 Rule ID: SV-37746r2_rule Severity: CAT II Rule Version (STIG-ID): GEN006480 Rule Title: The system must have a host-based intrusion detection tool installed.
Vulnerability Discussion: Without a host-based intrusion detection tool, there is no system-level defense when an intruder gains access to a system or network. Additionally, a host-based intrusion detection tool can provide methods to immediately lock out detected intrusion attempts.
Responsibility: System Administrator IAControls: ECID-1
Check Content: Ask the SA or IAO if a host-based intrusion detection application is loaded on the system. The preferred intrusion detection system is McAfee HBSS available through Cybercom. If another host-based intrusion detection application, such as SELinux, is used on the system, this is not a finding. =========================
People are getting confused and SElinux and HBSS are getting installed with SElinux being disabled to make things work.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
------------------------------
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
End of scap-security-guide Digest, Vol 25, Issue 74 ***************************************************
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."
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.
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.
<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.
-josh
Hi,
Is there any reason why SSG doesn't use the profile values on the description, eg:
(...) <description>The SELinux state should be set to <tt><sub idref="var_selinux_state_name"/></tt> at (...)
Instead of the current: (...) <description>The SELinux state should be set to <tt>enforcing</tt> at (...)
With the current approach, the rule description (possibly) won't match the profile and will mention misleading remediations.
Regards
-- Rui Pedro Bernardino CTE2/Tecnologias e Desenvolvimento PT Inovação
Forgive me for answering myself.
I edited the XCCDF to use the profile values and both the guide and evaluation reports look ok (and coeherent with the profile values). Should I submit a patch with these changes?
Best regards
-- Rui Pedro Bernardino CTE2/Tecnologias e Desenvolvimento PT Inovação
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: quinta-feira, 26 de Setembro de 2013 11:36 To: scap-security-guide@lists.fedorahosted.org Subject: XCCDF: using value references in rule description
Hi,
Is there any reason why SSG doesn't use the profile values on the description, eg:
(...) <description>The SELinux state should be set to <tt><sub idref="var_selinux_state_name"/></tt> at (...)
Instead of the current: (...) <description>The SELinux state should be set to <tt>enforcing</tt> at (...)
With the current approach, the rule description (possibly) won't match the profile and will mention misleading remediations.
Regards
-- Rui Pedro Bernardino CTE2/Tecnologias e Desenvolvimento PT Inovação
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 9/27/13 6:45 AM, Rui Pedro Bernardino wrote:
Forgive me for answering myself.
I edited the XCCDF to use the profile values and both the guide and evaluation reports look ok (and coeherent with the profile values). Should I submit a patch with these changes?
Definitely!
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.
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-Assessmen...
~Ed
On Fri, Sep 27, 2013 at 11:51 AM, Shawn Wells shawn@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org