What changed in MariaDB Enterprise 10.x STIG V2R6V2R6 changes

Check text

If all accounts are authenticated by the organization-level authentication/access mechanism, such as LDAP, Kerberos, or Active Directory, and not by MariaDB, this is not a finding. If any accounts are managed by the DBMS, review the system documentation for justification and approval of these accounts. If any DBMS-managed accounts exist that are not documented and approved, this is a finding. As the OS administrator, review the configuration in the /etc/pam.conf file or the /etc/pam.d directory. If there are no configuration file(s), this is a finding. Example for LDAP authentication and authorization via PAM would be /etc/pam.d/mariadb_ldap: ############################# auth required pam_ldap.so account required pam_ldap.so ############################# Verify that PAM is installed: MariaDB> SHOW PLUGINS; If pam is not listed as active, this is a finding. To find users not using PAM plugin for authentication: MariaDB> SELECT user, host, plugin FROM mysql.user WHERE plugin != 'pam'; If any usersDBMS-managed accounts exist that are returnednot documented and approved, this is a finding.

V-253667 in V2R6

Discussion

Authentication with a DODDoW-approved PKI certificate does not necessarily imply authorization to access MariaDB. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DODDoW-approved PKIs, all DODDoW systems, including databases, must be properly configured to implement access control policies. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications, a category that includes database management systems. If MariaDB does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.

V-253668 in V2R6

Title

MariaDB must provide audit record generation capability for DoDW-defined auditable events within all DBMS/database components.

Fix text

Configure MariaDB to generate audit records for at least the DoDDoW minimum set of events. Edit the mariadb-enterprise.cnf configuration file located in /etc/my.cnf.d/. Under [mariadb], add the following: server_audit_logging = ON Save the configuration file. This change will not take effect until MariaDB Enterprise Server is restarted. Using the MariaDB Enterprise Audit plugin, MariaDB can be configured to audit these requests. The MariaDB Enterprise Audit plugin can be configured to audit these changes. Update necessary audit filters. Ex: MariaDB> DELETE FROM mysql.server_audit_filters WHERE filtername = 'default'; MariaDB> INSERT INTO mysql.server_audit_filters (filtername, rule) VALUES ('default', JSON_COMPACT( '{ "connect_event": [ "CONNECT", "DISCONNECT" ], "query_event": [ "ALL" ] }' )); More information about MariaDB auditing can be found here: https://mariadb.com/docs/security/mariadb-enterprise-audit/

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within MariaDB (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoDDoW has defined the list of events for which MariaDB will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities, or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. Organizations may define additional events requiring continuous or ad hoc auditing.

V-253670 in V2R6

Title

If MariaDB authentication, using passwords, is employed, then MariaDB must enforce the DODoW standards for password complexity.

Check text

Check the simple_password_check plugin variables to ensure they match the password requirements. MariaDB> SHOW GLOBAL VARIABLES LIKE 'simple_password_check_%'; Determine whether the following rules are enforced. If they do not meet the following password requirements, this is a finding. a.Minimum minimum of 15 characters, including at least one of each of the following character sets: - Uppercase - Lowercase - Numerics - Special characters (e.g., ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > &lt) b. Minimum number of characters changed from previous password: 50 percent of the minimum password length; that is, eight.

Discussion

OS/enterprise authentication and identification must be used (SRG-APP-000023-DB-000001). Native MariaDB authentication may be used only when circumstances make it unavoidable; and must be documented and Authorizingauthorizing Officialofficial (AO)-approved. The DODDoW standard for authentication is DODDoW-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate and requires AO approval. In such cases, the DODDoW standards for password complexity and lifetime must be implemented. DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so. For MariaDB, the rules must be enforced using available configuration parameters or custom code. By default, MariaDB Enterprise Server has the simple_password_check plugin installed and enabled. However, the default password requirements are eight character minimum, one numeric character, and one special character.

V-253695 in V2R6

Title

If MariaDB authentication using passwords is employed, MariaDB must enforce the DODoW standards for password lifetime.

Check text

Check the default password lifetime variable to verify it matches the password requirement. MariaDB> SHOW GLOBAL VARIABLES LIKE 'default_password_lifetime%'; If the value returned is not 60180 or less, this is a finding.

Fix text

Locate the MariaDB Enterprise Server configuration file (mariadb-enterprise.cnf) that contains the password variables within /etc/my.cnf.d/. Edit the variables. Example: default_password_lifetime = 60180

Discussion

OS/enterprise authentication and identification must be used (SRG-APP-000023-DB-000001). Native MariaDB authentication may be used only when circumstances make it unavoidable and must be documented and Authorizingauthorizing Officialofficial (AO)-approved. The DODDoW standard for authentication is DODDoW-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate and requires AO approval. In such cases, the DODDoW standards for password complexity and lifetime must be implemented. DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so. For MariaDB, the rules must be enforced using available configuration parameters or custom code.

V-253696 in V2R6

Discussion

The DODDoW standard for authentication is DODDoW-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate and requires Authorizingauthorizing Officialofficial (AO) approval. In such cases, database passwords stored in clear text, using reversible encryption, or using unsalted hashes would be vulnerable to unauthorized disclosure. Database passwords must always be in the form of one-way, salted hashes when stored internally or externally to the MariaDB.

V-253697 in V2R6

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate and requires AOauthorizing official (AO) approval. In such cases, passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission. DBMS passwords sent in clear text format across the network are vulnerable to discovery by unauthorized users. Disclosure of passwords may easily lead to unauthorized access to the database.

V-253698 in V2R6

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. A certificate's certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate. Certification path validation includes checks such as certificate issuer trust, time validity and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses. Database Management Systems that do not validate certificates by performing RFC 5280-compliant certification path validation are in danger of accepting certificates that are invalid and/or counterfeit. This could allow unauthorized access to the database.

V-253699 in V2R6

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. PKI certificate-based authentication is performed by requiring the certificate holder to cryptographically prove possession of the corresponding private key. If the private key is stolen, an attacker can use the private key(s) to impersonate the certificate holder. In cases where the MariaDB-stored private keys are used to authenticate MariaDB to the system's clients, loss of the corresponding private keys would allow an attacker to successfully perform undetected man in the middle attacks against the MariaDB system and its clients. Both the holder of a digital certificate and the issuing authority must take careful measures to protect the corresponding private key. Private keys should always be generated and protected in FIPS 140-2 validated cryptographic modules. All access to the private key(s) of MariaDB must be restricted to authorized and authenticated users. If unauthorized users have access to one or more of the MariaDB s private keys, an attacker could gain access to the key(s) and use them to impersonate the database on the network or otherwise perform unauthorized actions.

V-253700 in V2R6

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. Once a PKI is validated, it is mapped to the DBMS user account for the authentication identity and then can be used for authorization decisions.

V-253701 in V2R6

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. Normally, with PKI authentication, the interaction with the user for authentication will be handled by a software component separate from the DBMS, such as ActivIdentity ActivClient. However, in cases where the DBMS controls the interaction, this requirement applies. To prevent the compromise of authentication information such as passwords and PINs during the authentication process, the feedback from the system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided authentication secrets when typed into the system is a method used in addressing this risk. Displaying asterisks when a user types in a password or a smart card PIN is an example of obscuring feedback of authentication secrets. This calls for review of applications, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.

V-253702 in V2R6

Fix text

If crypto.fips_enabled = 0, for Red Hat Linux, configure the operating system to implement DODDoW-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=&ltpartition 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

V-253703 in V2R6

Discussion

The DODDoW standard for authentication of an interactive user is the presentation of a Commoncommon Accessaccess Cardcard (CAC) or other physical token bearing a valid, current, DODDoW-issued Public Key Infrastructure (PKI) certificate, coupled with a Personal Identification Number (PIN) to be entered by the user at the beginning of each session and whenever reauthentication is required. Without reauthentication, users may access resources or perform tasks for which they do not have authorization. When applications provide the capability to change security roles or escalate the functional capability of the application, it is critical the user reauthenticate. In addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances: (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) When the execution of privileged functions occurs; (v) After a fixed period of time; or (vi) Periodically. Within the DODDoW, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

V-253735 in V2R6

Title

MariaDB must only accept end entity certificates issued by DoDDoW PKI or DoDDoW-approved PKI Certification Authorities (CAs) for the establishment of all encrypted sessions.

Check text

As the database administrator, check the following variables: MariaDB> SHOW GLOBAL VARIABLES LIKE 'ssl_ca'; MariaDB> SHOW GLOBAL VARIABLES LIKE 'ssl_cert'; The Value column will show the fully qualified file name of the ssl_ca and ssl_cert respectively. The issuer can be found by running the following command: $ openssl x509 -in fully-qualified-file-name-of-ssl_ca -noout -issuer $ openssl x509 -in fully-qualified-file-name-of-ssl_cert -noout -issuer The issuer should be checked against the authoritative list of DoDDoW-approved PKIs, which is published at https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/unclass-ss_using_commercial_pki_certificates.pdf. If the DBMS will accept non-DoDDoW approved PKI end-entity certificates, this is a finding.

Fix text

Revoke trust in any certificates not issued by a DoDDoW-approved certificate authority. Configure MariaDB to accept only DoDDoW and DoDDoW-approved PKI end-entity certificates.

Discussion

Only DoDDoW-approved external PKIs have been evaluated to ensure that they have security controls and identity vetting procedures in place that are sufficient for DoDDoW systems to rely on the identity asserted in the certificate. PKIs lacking sufficient security controls and identity vetting procedures risk being compromised and issuing certificates that enable adversaries to impersonate legitimate users. The authoritative list of DoDDoW-approved PKIs is published at https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/unclass-ss_using_commercial_pki_certificates.pdf. This requirement focuses on communications protection for the MariaDB session rather than for the network packet.

V-253738 in V2R6