Excessive FIPS checks

[chuckatkins]

Many of the FIPS related rules unnecessarily check whether or not the installed OS is FIPS certified.

For example, take the rule to check whether AIDE is configured to use FIPS 140-2 hashes. The criteria are:

<oval:criteria operator="AND">
  <oval:extend_definition comment="Installed OS is FIPS certified" definition_ref="oval:ssg-installed_OS_is_FIPS_certified:def:1"/>
  <oval:extend_definition comment="Aide is installed" definition_ref="oval:ssg-package_aide_installed:def:1"/>
  <oval:criterion comment="non-FIPS hashes are not configured" test_ref="oval:ssg-test_aide_non_fips_hashes:tst:1"/>
  <oval:criterion comment="FIPS hashes are configured" test_ref="oval:ssg-test_aide_use_fips_hashes:tst:1"/>
</oval:criteria>

Whether or not the OS is FIPS certified is orthogonal to whether or not the FIPS approved algorithms are being used.

This is problematic when evaluating benchmarks on CentOS since it's not RHEL proper and thus not FIPS certified. Certainly it should fail the"Installed OS is FIPS certified" test, which is it's own stand alone rule, but that shouldn't preclude validation that various crypto components like ssh and AIDE use FIPS approved crypto algorithms and hashes.

[redhatrises]

Except that it does, meaning that CentOS will always fail. Same thing with Fedora, and others.

[redhatrises]

Specifically NIST 800-53 SI-1 and SC-13 in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

[chuckatkins]

They would certainly always fail the "Is the OS Certified", as they should. But whether something like SSH is using FIPS-approved crypto algorithms isn't dependent on the OS being FIPS certified, right?

[redhatrises]

They would certainly always fail the "Is the OS Certified", as they should. But whether something like SSH is using FIPS-approved crypto algorithms isn't dependent on the OS being FIPS certified, right?

"Is the OS Certified" rules have been tailored out when they shouldn't have and have been caught by AOs and some Fed Agencies after the fact. However, running FIPS on a non-validated FIPS system is equivalent to running in cleartext, so while SSH is not technically (SSH won't run) dependent on FIPS, the rules requiring the use of FIPS are dependent on a FIPS validated system.
The rules and profiles are about getting users to a compliant end-state in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards, not just "hardening a system to technical capability".

[chuckatkins]

Okay, I see the mismatch now. The rules themselves are documented to check whether or not ssh (and friends) is configured to use fips approved ciphers. That by itself shouldn't be checking if the os is validated. If I'm understanding this correctly though, the intent of the rule is to ensure that ssh is configured as a fips validated module, which as discussed, is more than checking the cipher configuration. So at a minimum, maybe the documentation for the rule should change? Beyond that though, looking at the RHEL documentation, what needs to be checked to test whether or not ssh is configured as a fips validated module is the cipher configuration, whether or not the kernel is in fips mode, and if the os is fips certified. It seems those three things together are what makes ssh a fips validated module. As implemented, the checks would pass if ssh is configured with the right algorithms on rhel proper even if the kernel isn't in fips mode. So should the related rules be changed to also check the kernel mode?

Is it then reasonable that the fips related rules for individual packages be changed as follows?:

• The description changed to "package is configured as a fips validated module"
• Checks implemented as requiring all of the following:
  • Package is configured to exclusively use fips approved algorithms
  • Kernel is in fips mode
  • OS is fips certified

[redhatrises]

Completely is reasonable and makes sense to me. It would avoid confusion for sure.

…

On Sun, Oct 13, 2019 at 9:04 PM Chuck Atkins ***@***.***> wrote: Okay, I see the mismatch now. The rules themselves are documented to check whether or not ssh (and friends) is configured to use fips approved ciphers. That by itself shouldn't be checking if the os is validated. If I'm understanding this correctly though, the intent of the rule is to ensure that ssh is configured as a fips validated module, which as discussed, is more than checking the cipher configuration. So at a minimum, maybe the documentation for the rule should change? Beyond that though, looking at the RHEL documentation, what needs to be checked to test whether or not ssh is configured as a fips validated module is the cipher configuration, whether or not the kernel is in fips mode, and if the os is fips certified. It seems those three things together are what makes ssh a fips validated module. As implemented, the checks would pass if ssh is configured with the right algorithms on rhel proper even if the kernel isn't in fips mode. So should the related rules be changed to also check the kernel mode? Is it then reasonable that the fips related rules for individual packages be changed as follows?: - The description changed to "package is configured as a fips validated module" - Checks implemented as requiring all of the following: - Package is configured to exclusively use fips approved algorithms - Kernel is in fips mode - OS is fips certified — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#4917?email_source=notifications&email_token=ACACP5F2HTHBVIHNHM32SL3QOPOSJA5CNFSM4I7PQL42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBDHTFY#issuecomment-541489559>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACACP5BXLEUYG7ZC5UM7Z43QOPOSJANCNFSM4I7PQL4Q> .