Detections
Analytics
MADB-10-004400 - MariaDB must use NIST FIPS 140-2 validated cryptographic modules for cryptographic operations.
Warning! Audit Deprecated
This audit has been deprecated and will be removed in a future update.
View Next Audit VersionInformation
Use of weak or not validated cryptographic algorithms undermines the purposes of utilizing encryption and digital signatures to protect data. Weak algorithms can be easily broken and not validated cryptographic modules may not implement algorithms correctly. Unapproved cryptographic modules or algorithms should not be relied on for authentication, confidentiality, or integrity. Weak cryptography could allow an attacker to gain access to and modify data stored in the database as well as the administration settings of the DBMS.Applications, including DBMSs, utilizing cryptography are required to use approved NIST FIPS 140-2 validated cryptographic modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
The security functions validated as part of FIPS 140-2 for cryptographic modules are described in FIPS 140-2 Annex A.
NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified, hardware-based encryption modules.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.
Solution
If crypto.fips_enabled = 0, for Red Hat Linux, configure the operating system to implement DoD-approved encryption by following the steps below:To enable strict FIPS compliance, the fips=1 kernel option must be added to the kernel command line during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place.
Enable FIPS mode with the following command:
# sudo fips-mode-setup --enable
Modify the kernel command line of the current kernel in the 'grub.cfg' file by adding the following option to the GRUB_CMDLINE_LINUX key in the '/etc/default/grub' file and then rebuild the 'grub.cfg' file:
fips=1
Changes to '/etc/default/grub' require rebuilding the 'grub.cfg' file as follows:
On BIOS-based machines, use the following command:
# sudo grub2-mkconfig -o /boot/grub2/grub.cfg
On UEFI-based machines, use the following command:
# sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
If /boot or /boot/efi reside on separate partitions, the kernel parameter 'boot=<partition of /boot or /boot/efi>' must be added to the kernel command line. Identify a partition by running the df /boot or df /boot/efi command:
# sudo df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 495844 53780 416464 12% /boot
To ensure the 'boot=' configuration option will work even if device naming changes occur between boots, identify the universally unique identifier (UUID) of the partition with the following command:
# sudo blkid /dev/sda1
/dev/sda1: UUID='05c000f1-a213-759e-c7a2-f11b7424c797' TYPE='ext4'
For the example above, append the following string to the kernel command line:
boot=UUID=05c000f1-a213-759e-c7a2-f11b7424c797
Reboot the system for the changes to take effect.
More information can be found here:
RedHat: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations
Ubuntu: https://security-certs.docs.ubuntu.com/en/fips
See Also
https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_MariaDB_Enterprise_10-x_V1R3_STIG.zip
Item Details
Audit Name: DISA MariaDB Enterprise 10.x v1r3 OS Linux
References: CAT|I, CCI|CCI-000803, Rule-ID|SV-253703r879616_rule, STIG-ID|MADB-10-004400, Vuln-ID|V-253703
Plugin: Unix
Control ID: 35f4be3a67d47d7ec3c3c9d095b7ec4f08c3d52b691af0cabb8fc988bae625d3