FYI: There are tasks that do the right thing but fail oscap audits using DISA SCAP content
juliedavila opened this issue · comments
I'm not sure why but I get the feeling the SCAP content provided by DISA at https://iasecontent.disa.mil/stigs/zip/U_Red_Hat_Enterprise_Linux_7_V2R1_STIG_SCAP_1-2_Benchmark.zip is faulty.
These are the rules which seem to be fixed with the content of this role...but somehow still fail oscap xccdf eval.... I'll add others as I find them.
- RHEL-07-021350 - The Red Hat Enterprise Linux operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
This is because DISA doesn't include the latest RHEL version as "supported" in the benchmark. Manual workaround is to downgrade redhat-release-server package to a version DISA likes.
-
RHEL-07-040170 - The Red Hat Enterprise Linux operating system must display the Standard Mandatory DoD Notice and Consent Banner immediately prior to, or as part of, remote access logon prompts.(workaround #224) Would be better for DISA to fix the benchmark, though. -
RHEL-07-040110 - The Red Hat Enterprise Linux operating system must use a FIPS 140-2 approved cryptographic algorithm for SSH communications.
DISA doesn't include the latest RHEL version as "supported" in the benchmark. Manual workaround is to downgrade redhat-release-server package to a version DISA likes.
- RHEL-07-040400 - The Red Hat Enterprise Linux operating system must be configured so that the SSH daemon is configured to only use Message Au
thentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms.
DISA doesn't include the latest RHEL version as "supported" in the benchmark. Manual workaround is to downgrade redhat-release-server package to a version DISA likes.
- RHEL-07-041001 - The Red Hat Enterprise Linux operating system must have the required packages for multifactor authentication installed.
DISA is overly-aggressive in "requiring" packages for smartcard. Specifically, they require the unnecessary
escpackage, which pulls in gnome/X.
Yes, I expect that the Benchmark update accompanying the STIG update did not include the same extensive set of changes. There were a few things that failed that I wouldn't have expected, and some things that didn't fail, that should have, based on STIG changes.
Some of this goes deeper, not sure why. For example looking at the benchmark XML directly I snagged up the regex for the DoD Banner, doing my own manual testing against that banner "passed" and doing a deeper level debug with oscap showed that errors are thrown in that particular rule. I havent deep dived into the other rules yet though.
DISA auditors will use a different program (SCC) to gauge compliance, rather than OSCAP. Have you compared SCC results?
Results are identical when using the same content, regardless of which scanner to is used.
- This is a false positive, for which I haven't yet nailed down the reason. Would be good to e-mail DISA and inquire.
- This is a false positive in a poor attempt to "ensure no extra text is present" in the banner. An ugly workaround is to strip all the newlines except those delimiting paragraphs; this renders the banner illegible on an 80-char wide terminal.
- Broken for the same reason as 1.
- Same as 1 and 3.
- The DISA benchmark checks that pam_pkcs11, esc, and authconfig-gtk are installed; the latter two are bloat on a non-GUI system and wolud pull in an additional 74 packages at 113M installed size. This, too, should be brought up w/ DISA. (You don't need the latter 2 packages, and you don't even need pam_pkcs11 if you're using SSSD to do Smart Card auth.)
I'm not sure why but I get the feeling the SCAP content provided by DISA at https://iasecontent.disa.mil/stigs/zip/U_Red_Hat_Enterprise_Linux_7_V2R1_STIG_SCAP_1-2_Benchmark.zip is faulty.
Your reasoning is faulty. DISA provides the benchmark for use with SCC, not OSCAP. SCC is NOT fully SCAP compliant. If it were, we could substitute OSCAP results for SCC results when importing into the STIG Viewer.
Results are identical when using the same content, regardless of which scanner to is used.
Perhaps on this finding, but I find it difficult to believe that all scans are identical. Again, if the results were identical, OSCAP results would work when imported into the STIG Viewer.
If we're scanning to determine compliance, we need to use SCC, since that is what DISA will use to gauge compliance.
If we're scanning to determine the security of the system, I trust OSCAP more.
- RHEL-07-041001 - The Red Hat Enterprise Linux operating system must have the required packages for multifactor authentication installed.
- The DISA benchmark checks that pam_pkcs11, esc, and authconfig-gtk are installed; the latter two are bloat on a non-GUI system and would pull in an additional 74 packages at 113M installed size. This, too, should be brought up w/ DISA. (You don't need the latter 2 packages, and you don't even need pam_pkcs11 if you're using SSSD to do Smart Card auth.)
Your point regarding esc and authconfig-gtk is valid for non-gui systems. For that reason, the finding would be marked not applicable during the manual phase of scanning.
pam_pkcs11 is still required to use PIV smart cards (aka CAC) for 2FA login on RHEL 6, even with SSSD. I haven't upgraded workstations to RHEL 7, and haven't tested minimum configuration for requiring CAC/token login. If it is true that SSSD makes pam_pkcs11 unnecessary, then this is a holdover, and it might be possible to ask DISA to change that rule.
The way these rules work in application is, automated scan results using SCC are imported into STIG viewer with the STIG. This populates the checklist with all of the automated check results. The auditors then carry out the manual checks with the administrator able to provide input. Once the results are completed, the organization can refute false positives. During adjudication, the examiners take into account findings that are remediated using alternative means (STIGs are guidelines after all), and those which are accepted risks by the organization.
My point is that for non-gui systems, the findings would for RHEL-07-041001 would be marked n/a since they are essentially a false positive for non-gui systems.
FWIW, I ran the Benchmark using the SCC tool. Identical results. Do you have any example where the SCC tool gives different results than openscap scanner?
When I say "results" I mean the xccdf file produced by the automated scan. Even if every test produces the same result in the scan, if the resulting file is not usable in STIG viewer, it is worthless. Now I haven't tested this since we had a pre-inspection visit in May/June 2018.
SCC scans are imported into the STIG Viewer, and a STIG Viewer checklist is used to evaluate the automated scan results, and to carryout manual checks. Also, SCC is available for multiple OS and is the tool the DISA personnel who do the scanning are instructed to use for scanning. This is from direct experience with a DISA pre-inspection visit during the past year.
OSCAP is great for ongoing scanning and remediation of the system, but until DISA allows OSCAP results in their auditing process, results are not applicable to the auditing process.
1. This is a false positive, for which I haven't yet nailed down the reason. Would be good to e-mail DISA and inquire.
This is failing for two reasons:
- DISA Benchmark doesn't recongize 7.6 as a supported release
- DISA Benchmark only passes fips=1 check if both BIOS and UEFI grub.cfg files are compliant. Normally only one set of files is present.
I've sent a PR to workaround the second half here: https://github.com/MindPointGroup/RHEL7-STIG/pull/225
2. This is a false positive in a poor attempt to "ensure no extra text is present" in the banner. An ugly workaround is to strip all the newlines except those delimiting paragraphs; this renders the banner illegible on an 80-char wide terminal.
I've sent a PR for this workaround: https://github.com/MindPointGroup/RHEL7-STIG/pull/224
3. Broken for the same reason as 1. 4. Same as 1 and 3.
Hello,
I wanted to reach out and let you know that this issue is being closed. We have re-worked the role and want to start with a fresh issues list with this latest version. There was a post in the Ansible-Lockdown google group (https://groups.google.com/g/ansible-lockdown) with the details of the changes that are coming. Please checkout the thread titled RHEL 7 CIS and STIG Changes for all of the details, I also have the message pasted at below.
Please as you use the latest version and open issue tickets as you find them, it is the best way for us to improve the role for everyone. Thank you for being part of the community and providing awareness of problems or advice on improvement. Reporting is a huge part of improving this project.
Hello,
Thank you to everyone in the Ansible-Lockdown community who has contributed to RHEL7 STIG/CIS. Our team at MindPoint Group has been working with the entirety of the Ansible-Lockdown project, and we have some significant updates for both RHEL 7 STIG and CIS. With these updates, some larger changes have been made. I have these changes/updates outlined below.
Testing:
- CI/CD - We have implemented some automated testing pipelines to test pull requests into the devel and main branches. With the current workflow, the community will PR into the devel branch (never the main branch) for review by the administrators. When your PR is created, the first check will remain the DCO check. The second check is a functional testing pipeline that will automatically perform a functional test of the branch the PR is initiated from. Once both tests pass, someone from the Administrator Team will review the changes and merge them into the devel branch. From there, an additional review is completed before the devel branch is merged into the main branch. Only the Admin Team will perform PRs/merges into the main branch. There is also an automated pipeline for PRs from devel to main. Please do not edit the .github/workflows files since those are used as part of the pipeline.
- Compliance Checking – MindPoint Group has been working to create our own compliance audit scan tool. The tool uses a goss framework executable to run custom checks that we have created. The goal is to provide a more thorough check for control compliance and decrease the number of false positives/negatives. For example, it will check the configuration file related to the control and as well as checking if that configuration is active. With a smarter scan, we can hopefully identify attempts to trick scanners as well (for example stacking a parameter in a config file where the first instance is enabled and second disabled. Most audit tools search for the first instance but the application might look for the last instance of the parameter, thus making the scanning tool think it's enabled). In testing, we have found that our audit scan runs significantly faster than other audit tools, reducing audit times. Our audit tool and profiles will have their own repositories in the Ansible-Lockdown org, but within the remediation role there will be an integrated way to incorporate the audit. Keep an eye out for the audit tools as they are released. We plan on developing a goss audit profile for each current remediation role. Going forward, we plan to release a remediation role and goss audit tool profile simultaneously.
Role Updates: - RHEL 7 STIG/CIS – We have re-written much of the RHEL 7 STIG and CIS roles to increase clarity and readability and address some functionality items. We performed these updates while creating our goss testing framework for each of these roles. We plan on pushing our update to the devel and main branches. We will move the current devel and master branches to a devel_stable_ and master_stable_ branch in the respective repositories. Accordingly, community members who rely on the current version can still use that version going forward; this process will not remove what is currently there. The latest versions of the roles have also been updated to comply with the latest benchmarks.
- Role Architecture – All roles will change with regard to the structure in the tasks folder. Taking CIS as an example, there will be a folder per section and yaml files for each sub-section. For example control 1.2.1 in CIS will be located in RHEL7-CIS/tasks/section_1/cis_1.2.x.yml. The cis_1.2.x.yml file will contain all controls related to section 1.2.x. This will hopefully make updates to roles a bit easier with less risk. This matches the architecture of our audit tool, creating consistency across remediation and audit platforms. The end goal is to repeat this architecture (the best we can) on STIG roles, but we are starting with CIS.
- Existing PRs and Issues – With all of these changes comes the task of cleaning up existing PR’s and issues. Our plan is to close all of the existing PR’s and issues because of the re-work. Our team is growing and should be able to stay on top of the new issues and PRs as they come in.
Again, I would like to thank the community for your involvement in this project. The input and work from the community has contributed significantly to the success of this project. Please keep an eye out for these changes, which will be rolling out in the coming weeks.