Closed shawndwells closed 6 years ago
Rule exists - RHEL-07-032010. resolved.
The rule exists, but should be removed. @tbrunell When will DISA formally remove this?
I think it is a valid check. In RHEL-07-032000 we check to see if an anti-virus program is installed (clamav or mcafee). The signature file that this rule checks is validating part of the configuration of the service and should be validated IMHO as a configuration item. The AV service is worthless without the configuration/signature data - much like any other service.
On 6/19/17 1:21 PM, tbrunell wrote:
I think it is a valid check. In RHEL-07-032000 we check to see if an anti-virus program is installed (clamav or mcafee). The signature file that this rule checks is validating part of the configuration of the service and should be validated IMHO as a configuration item. The AV service is worthless without the configuration/signature data - much like any other service.
If DISA was requesting configuration of technologies that ship natively in RHEL, then I would completely agree with you.
However, DISA is mandating the installation and configuration of 3rd party software (McAfee). The instant 3rd party technology is discussed is the instant the requirement moves out of the operating system STIG. It's not part of our product. While this could be a valid information system requirement -- it has nothing to do with the configuration of RHEL.
RHEL-07-032000 requires the installation of McAfee. They need to either accept ClamAV (provided by the OS), or drop both rules.
@shawndwells we had that discussion with them last year and pushed clamav as a way to satisfy the requirements for the inclusion of the rule. Knowing firsthand how serious they take the AV stuff, I do not see DISA ever wanting to drop the rule. I can discuss it though, but lets open ticket(s) for the things we want to drop to make it easier to track.
Spoke with DISA. The requirement is coming from USCYBERCOM to include the check for AV. I pointed out the OSX 10.12 has very generic "The system needs a government approved virus scanner installed" without mentioning any products (Windows mentions McAfee). They are now going to update the OSX STIG to reflect McAfee as well. ClamAV is still okay to include.
I should point out that there already exists a STIG for McAfee VirusScan Enterprise for Linux: http://iasecontent.disa.mil/stigs/zip/Apr2016/U_McAfee_VSEL_1-9_2-0_Local_Client_V1R2_STIG.zip
Within this STIG, there exists a check (DTAVSEL-001) to ensure the virus definitions be no older than 7 days. I would think that should suffice.
On a side note. I have created SSG SCAP content for the McAfee VSEL STIG and would be happy to share it. I am just so behind the latest changes in SSG due to other work piling up. So its not in sync with how the content is currently built. But the checks and remediations should remain valuable.
I am working with DISA to see what the requirements are to specify a virus scanner technology in an OS STIG. Some other vendors have it and some do not...
On Jun 21, 2017 8:44 AM, "thenefield" notifications@github.com wrote:
I should point out that there already exists a STIG for McAfee VirusScan Enterprise for Linux: http://iasecontent.disa.mil/stigs/zip/Apr2016/U_McAfee_ VSEL_1-9_2-0_Local_Client_V1R2_STIG.zip
Within this STIG, there exists a check (DTAVSEL-001) to ensure the virus definitions be no older than 7 days. I would think that should suffice.
On a side note. I have created SSG SCAP content for the McAfee VSEL STIG and would be happy to share it. I am just so behind the latest changes in SSG due to other work piling up. So its not in sync with how the content is currently built. But the checks and remediations should remain valuable.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenSCAP/scap-security-guide/issues/2048#issuecomment-310066925, or mute the thread https://github.com/notifications/unsubscribe-auth/ADnUJyWBcW4PNiKkcJsd3s8L5NEikpCGks5sGRA0gaJpZM4NyBnO .
On 6/21/17 8:44 AM, thenefield wrote:
On a side note. I have created SSG SCAP content for the McAfee VSEL STIG and would be happy to share it. I am just so behind the latest changes in SSG due to other work piling up. So its not in sync with how the content is currently built. But the checks and remediations should remain valuable.
That would be awesome! If you can open a PR for what you have, we can help message it into current build processes.
On 6/20/17 8:15 AM, tbrunell wrote:
Spoke with DISA. The requirement is coming from USCYBERCOM to include the check for AV. I pointed out the OSX 10.12 has very generic "The system needs a government approved virus scanner installed" without mentioning any products (Windows mentions McAfee). They are now going to update the OSX STIG to reflect McAfee as well. ClamAV is still okay to include.
STIGs are vendor-specific product configuration checklists meant to have configuration checks for elements of the operating system itself.
The CYBERCOM order to have A/V is perfectly legitimate at an information system level. But not inside a RHEL configuration guide.
So, I just went through the McAfee STIG and it doesn't give me vendor specific information on how to do much. Is it up to McAfee or the OS vendors to tell me what the package names are, etc...?
Also, what on earth is this and who do I complain to (NFSv4 with Kerberos or bust)?
If mounting with NFS version 3.0 is not an option, this is a finding.
Finally, how do I get a copy of McAfee (whichever version is approved) to test against, including full EPO and licenses? It's a high bar for a FOSS project to meet.
On 6/21/17 10:08 PM, Trevor Vaughan wrote:
So, I just went through the McAfee STIG and it doesn't give me vendor specific information on how to do much. Is it up to McAfee or the OS vendors to tell me what the package names are, etc...?
Not our product, not our guidance.
Also, what on earth is this and who do I complain to?
|If mounting with NFS version 3.0 is not an option, this is a finding.|
disa.stig_spt@mail.mil
||Finally, how do I get a copy of McAfee (whichever version is approved) to test against, including full EPO and licenses? It's a high bar for a FOSS project to meet.
NFIAA
Am I missing something here? RHEL-07-032000 and ...032010 both allow for ClamAV in place of McAfee in the STIG. See below from ...32000:
Verify the system is using a DoD-approved virus scan program.
Check for the presence of "McAfee VirusScan Enterprise for Linux" with the following command:
# systemctl status nails
nails - service for McAfee VirusScan Enterprise for Linux
Loaded: loaded /opt/NAI/package/McAfeeVSEForLinux/McAfeeVSEForLinux-2.0.2.
enabled) Active: active (running) since Mon 2015-09-27 04:11:22 UTC;21 min ago
If the "nails" service is not active, check for the presence of "clamav" on the system with the following command:
# systemctl status clamav-daemon.socket
systemctl status clamav-daemon.socket
clamav-daemon.socket - Socket for Clam AntiVirus userspace daemon
Loaded: loaded (/lib/systemd/system/clamav-daemon.socket; enabled)
Active: active (running) since Mon 2015-01-12 09:32:59 UTC; 7min ago
If neither of these applications are loaded and active, ask the System Administrator if there is an antivirus package installed and active on the system.
If no antivirus scan program is active on the system, this is a finding.
@nivek1385 You are not missing anything. RHEL ships with ClamAV - so we can comfortably include that in the SSG. DISA includes the same verbiage in the STIG. Note that this may change in the future to something as simple as "must have a DoD approved virus scanner installed" pending a discussion with DISA. The problem is that Red Hat does not ship with McAfee and should not be responsible for the secure configuration of that application. The focus of the RHEL STIG should solely be on RHEL and the default services that it provides.
@tbrunell I was asking because it seemed from shawndwells' comment that the STIG only included McAfee and not both as an either/or.
RHEL-07-032000 requires the installation of McAfee. They need to either accept ClamAV (provided by the OS), or drop both rules.
Closing because rule is in STIG profile.
This is accurate. Configuration and maintenance of 3rd party software is out of scope for the configuration of Red Hat Enterprise Linux. While applicable to an information system, this rule needs to be dropped from the RHEL7 STIG.
@tbrunell please review with DISA and close ticket as appropriate