What changed in Oracle MySQL 8.0 STIG V2R3V2R3 changes

Title

The MySQL Database Server 8.0 must be configured to provide audit record generation capability for DoDW-defined auditable events within all database components.

Fix text

Deploy a MySQL Database Server 8.0 that supports the DoDDoW minimum set of auditable events. Configure the MySQL Database Server 8.0 to generate audit records for at least the DoDDoW minimum set of events. sudo vi /etc/my.cnf [mysqld] audit-log=FORCE_PLUS_PERMANENT audit-log-format=JSON audit-log-encryption=AES After changing the my.cnf, restart the server. SELECT audit_log_encryption_password_set(password); Create auditing rules - for example: Connect to MySQL and Use functions to define audit rules and audited users audit_log_filter_set,audit_log_filter_set_user To log all auditable events: SELECT audit_log_filter_set_filter('log_all', '{ "filter": { "log": true } }'); And to apply this log_all filter to all users: SELECT audit_log_filter_set_user('%', 'log_all');

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 the Database Management System (DBMS) (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 the DBMS 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-235103 in V2R3

Check text

The database supports PKI-based authentication by using digital certificates over TLS in addition to the native encryption and data integrity capabilities of these protocols. Review MySQL Database Server 8.0 configuration to verify DBMS user account certificates are valid by performing RFC 5280-compliant certification path validation. Run the following command to determine the certificate in use along with other details: select @@ssl_ca, @@ssl_capath, @@ssl_cert, @@ssl_cipher, @@ssl_crl, @@ssl_crlpath, @@ssl_fips_mode, @@ssl_key; If ssl_crl is not set to a CRL file, this is a finding. If ssl_crlpath is empty then use the default, which is the datadir path. To get that path run select @@datadir. Next verify the existence of the CRL file. If the CRL file does not exist, this is a finding. Next, verify that require_secure_transport is ON by running: select @@require_secure_transport; If require_secure_transport is not 1 for ON, this is a finding. If the certificate is not a DoDDoW approved certificate, or if no certificate is listed, this is a finding. Confirm Issuer and Subject map to the username. Run the following script: SELECT `user`.`Host`, `user`.`User`, `user`.`ssl_type`, CAST(`user`.`x509_issuer` as CHAR) as Issuer, CAST(`user`.`x509_subject` as CHAR) as Subject FROM `mysql`.`user`; If user accounts are not being mapped to authenticated identities, this is a finding.

Fix text

Configure the DBMS to validate certificates by constructing a certification path with status information to an accepted trust anchor. Configure the database server to support Transport Layer Security (TLS) protocols. mysql> set persist require_secure_transport=ON; Set system variables on the server side specify DoDDoW approved certificate and key files the server uses when permitting clients to establish encrypted connections: ssl_ca: The path name of the Certificate Authority (CA) certificate file. (ssl_capath is similar but specifies the path name of a directory of CA certificate files.) ssl_cert: The path name of the server public key certificate file. This certificate can be sent to the client and authenticated against the CA certificate that it has. ssl_key: The path name of the server private key file. For example, to enable the server for encrypted connections with certificates, start it with these lines in the my.cnf file, changing the file names as necessary: [mysqld] ssl_ca=ca.pem ssl_cert=server-cert.pem ssl_key=server-key.pem Alter users to require X509 certificates Below is an example to add X509 as a requirement. For a new user CREATE USER 'jeffrey'@'localhost' REQUIRE X509; AND SUBJECT '/C=US/ST=Texas/L=Houston/O=SomeCompany/CN=Johan Smith' AND ISSUER '/C=US/ST=Texas/L=Houston/O=SomeCompany/CN=Some CA'; Or to add to an existing user ALTER USER 'johansmith'@'%' REQUIRE X509 AND SUBJECT '/C=US/ST=Texas/L=Houston/O=SomeCompany/CN=Johan Smith' AND ISSUER '/C=US/ST=Texas/L=Houston/O=SomeCompany/CN=Some CA';

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-235134 in V2R3

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 it to impersonate the certificate holder. In cases where the Database Management System (DBMS)-stored private keys are used to authenticate the DBMS 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 DBMS 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 must always be generated and protected in FIPS 140-2 or 140-3 validated cryptographic modules. All access to the private key(s) of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to one or more of the DBMS'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-235135 in V2R3

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. Once a PKI certificate has been validated, it must be mapped to a Database Management System (DBMS) user account for the authenticated identity to be meaningful to the DBMS and useful for authorization decisions.

V-235136 in V2R3

Title

If Database Management System (DBMS) authentication using passwords is employed, the DBMS must enforce the DODoW standards for password complexity and lifetime.

Check text

If DBMS authentication using passwords is not employed, this is not a finding. If the DBMS is configured to inherit password complexity and lifetime rules from the operating system or access control program, this is not a finding. Review the MySQL Database Server 8.0 settings relating to password complexity. Determine whether the following rules are enforced. If any are not, this is a finding. a. Minimum of 15 characters, including at least one of each of the following character sets: - Uppercase - Lowercase - Numeric - Special characters (e.g., ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > &lt) b. Minimum number of characters changed from previous password: 50 percent of the minimum password length; that is, eight. Review the DBMS settings relating to password lifetime. Determine whether the following rules are enforced. If any are not, this is a finding. a. Password lifetime limits for interactive accounts: Minimum 24 hours, maximum 60180 days. b. Password lifetime limits for non-interactive accounts: Minimum 24 hours, maximum 365 days. c. Number of password changes before an old one may be reused: Minimum of five. Connect as an admin. SELECT component_urn FROM mysql.component where component_urn='file://component_validate_password' group by component_urn; If the "validate password" component is installed the result will be file://component_validate_password. If "validate password" component is not installed, this is a finding. If the "component_validate_password" is installed, review the password policies to ensure required password complexity is met. Run the following to review the password policy: SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables where VARIABLE_NAME like 'valid%password%' or VARIABLE_NAME like 'password_%' ; For example the results may look like the following: 'validate_password.check_user_name',’ON’ 'validate_password.dictionary_file','' 'validate_password.length','8' 'validate_password.mixed_case_count','1' 'validate_password.number_count','1' 'validate_password.policy','MEDIUM' 'validate_password.special_char_count','1' 'password_reuse_interval','0' 'password_require_current','OFF' 'password_history','0' If these results do not meet password complexity requirements listed above, this is a finding.

Fix text

If the use of passwords is not needed, configure the MySQL Database Server 8.0 to prevent their use if it is capable of this; if it is not, institute policies and procedures to prohibit their use. If the MySQL Database Server 8.0 can inherit password complexity rules from the operating system or access control program, configure it to do so. Otherwise, use MySQL Database Server 8.0 configuration parameters and/or custom code to enforce the following rules for passwords: a. Minimum of 15 characters, including at least one of each of the following character sets: - Uppercase - Lowercase - Numeric - Special characters (e.g., ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > &lt) b. Minimum number of characters changed from previous password: 50 percent of the minimum password length; that is, eight. c. Password lifetime limits for interactive accounts: Minimum 24 hours, maximum 60180 days. d. Password lifetime limits for non-interactive accounts: Minimum 24 hours, maximum 365 days. e. Number of password changes before an old one may be reused: Minimum of five. As the database admin: INSTALL COMPONENT 'file://component_validate_password'; # Set Password Policies example: set persist validate_password.check_user_name='ON'; set persist validate_password.dictionary_file='&ltFILENAME OF DICTIONARY FILE'; set persist validate_password.length=15; set persist validate_password.mixed_case_count=1; set persist validate_password.special_char_count=2; set persist validate_password.number_count=2; set persist validate_password.policy='STRONG'; set persist password_history = 5; set persist password_reuse_interval = 365; SET GLOBAL default_password_lifetime = 180; Optional set persist password_require_current=YES This can also be set at the account level: ALTER USER 'jeffrey'@'localhost' PASSWORD HISTORY 5 PASSWORD REUSE INTERVAL 365 DAY; ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;

Discussion

OS/enterprise authentication and identification must be used (SRG-APP-000023-DB-000001). Native DBMS authentication may be used only when circumstances make it unavoidable; and must be documented and Authorizing Official (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 other DBMSs, the rules must be enforced using available configuration parameters or custom code.

V-235137 in V2R3

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 Authorizing Official (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 Database Management System (DBMS). To prevent the compromise of authentication information, such as passwords and PINs, during the authentication process, the feedback from the information system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided information when typed into the system is a method used in addressing this risk. For example, displaying asterisks when a user types in a password or PIN, is an example of obscuring feedback of authentication information. The password requirement is applicable when caching_sha2_password, sha2_password, native_mysql, or LDAP user/password authentication is enabled. When this is the case, password-authenticated accounts can be created in, and authenticated by, the MySQL Server. Other STIG requirements prohibit the use of password-based authentication except when justified and approved. This deals with the exceptions. The mysql, mysqlsh, and other command line tools are part of most MySQL installations. These tools can accept a plain-text password, but do offer alternative techniques. Since the typical user of these tools is a Database Administrator (DBA), the consequences of password compromise are particularly serious. Therefore, the use of plain-text passwords must be prohibited as a matter of practice and procedure.

V-235138 in V2R3

Check text

Review configuration settings for encrypting passwords in transit across the network. If passwords are not encrypted, this is a finding. If it is determined that passwords are passed unencrypted at any point along the transmission path between the source and destination, this is a finding. To check, run the following SQL: SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('require_secure_transport') ; If the require_secure_transport VARIABLE_VALUE is not 'ON' (1), this is a finding. If 1 (On), then only SSL connections are permitted; next examine the certificate used. Run the following command to determine the certificate in use along with other details: select @@ssl_ca, @@ssl_capath, @@ssl_cert, @@ssl_cipher, @@ssl_crl, @@ssl_crlpath, @@ssl_fips_mode, @@ssl_key; If the certificate is not a DoDDoW certificate, or if no certificate is listed, this is a finding.

Fix text

Configure encryption for transmission of passwords across the network. If the database does not provide encryption for logon events natively, employ encryption at the OS or network level. Ensure passwords remain encrypted from source to destination. connect to MySQL as admin (root) mysql> set persist require_secure_transport=ON; Set system variables on the server side specify DoDDoW approved certificate and key files the server uses when permitting clients to establish encrypted connections: ssl_ca: The path name of the Certificate Authority (CA) certificate file. (ssl_capath is similar but specifies the path name of a directory of CA certificate files.) ssl_cert: The path name of the server public key certificate file. This certificate can be sent to the client and authenticated against the CA certificate that it has. ssl_key: The path name of the server private key file. For example, to enable the server for encrypted connections with certificates, start it with these lines in the my.cnf file, changing the file names as necessary: [mysqld] ssl_ca=ca.pem ssl_cert=server-cert.pem ssl_key=server-key.pem

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 Authorizing 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. Database Management System (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-235139 in V2R3

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 Database Management System (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. For mysql tools, which can accept a plain-text password, and any other essential tool with the same limitation: 1) Document the need for it, who uses it, and any relevant mitigations, and obtain Authorizing Official (AO) approval 2) Train all users of the tool in the importance of not using the plain-text password option and in how to keep the password hidden by using the "-p" without the password option. The user will then be prompted and the password obfuscated. 3) Make use of OS pluggable password manager integration to protect passwords using keyrings

V-235140 in V2R3

Discussion

Authentication with a DoDDoW-approved PKI certificate does not necessarily imply authorization to access the Database Management System (DBMS). 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 the DBMS 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-235141 in V2R3

Title

The MySQL Database Server 8.0 must be configured in accordance with the security configuration settings based on DoDDoW security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs.

Check text

Review the MySQL documentation and configuration to determine it is configured in accordance with DoDDoW security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs. If the MySQL is not configured in accordance with security configuration settings, this is a finding.

Discussion

Configuring the Database Management System (DBMS) to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoDDoW that reflects the most restrictive security posture consistent with operational requirements. In addition to this SRG, sources of guidance on security and information assurance exist. These include NSA configuration guides, CTOs, DTMs, and IAVMs. The DBMS must be configured in compliance with guidance from all such relevant sources.

V-235142 in V2R3

Discussion

The DODDoW standard for authentication of an interactive user is the presentation of a Common Access Card (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-235178 in V2R3

Check text

Detailed information on the NIST Cryptographic Module Validation Program (CMVP) is available at the following website: http://csrc.nist.gov/groups/STM/cmvp/index.html. Review system documentation to determine whether cryptography for classified or sensitive information is required by the information owner. If the system documentation does not specify the type of information hosted on MySQL: classified, sensitive, and/or unclassified, this is a finding. If classified or sensitive information does not exist within MySQL Server, this is not a finding. Verify that the operating system provides the OpenSSL FIPS Object Module, and is configured to require the use of OpenSSL of FIPS compliant algorithms, available at MySQL runtime. If the Security Setting for FIPS mode option is "Disabled" on the server's OS, this is a finding. If cryptography is being used by MySQL, verify that the cryptography is NIST FIPS certified by running the following SQL query: Determine if MySQL is running in FIPS mode. select @@ssl_fips_mode; If ssl_fips_mode is not "ON" or "STRICT", this is a finding. View the versions of TLS, then review the cipher suites in use for the versions returned by statement: SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'tls_version'; If the results include less than version TLS 1.2, for example TLS 1.0 or 1.1, this is a finding. If the results include TLS 1.2 view the supported ciphers on the MySQL Server, run select * from performance_schema.global_status where variable_name= 'Ssl_cipher_list'; If the results include TLS 1.3 view the supported ciphers on the MySQL Server, run SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'tls_ciphersuites'; If any results list show an uncertified NIST FIPS 140-2 algorithm type, this is a finding. Check MySQL certificate PEM file(s) for compliance with DoDDoW requirements by running this command: openssl x509 -in server-cert.pem -text -noout If any PEM file is not in compliance, this is a finding.

Fix text

Configure cryptographic functions to use NSA-approved cryptography-compliant algorithms. Turn on MySQL FIPS mode. Edit my.cnf [mysqld] ssl_fips_mode=ON or [mysqld] ssl_fips_mode=STRICT To restrict TLS versions: [mysqld] tls_version='TLSv1.2,TLSv1.3' Example to define ciphers for TLSv1.2: [mysqld] ssl_ciphers='ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305' If TLSv1.3 is enabled, the "tls_ciphersuites" setting must contain all or a subset of the following ciphers based on certificates being used by server and client. Enabling FIPS mode will limit the OpenSSL library to operate within the FIPS object module. Example to define TLS ciphers for TLSv1.3: [mysqld] tls_ciphersuites='TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256' After adding any entries to the my.cnf file, restart mysqld. Create and use DODDoW-approved certificates for asymmetric keys used by the database.

V-235187 in V2R3

Title

The MySQL Database Server 8.0 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

To run MySQL in SSL mode, obtain a valid certificate signed by a single certificate authority. Before starting the MySQL database in SSL mode, verify the certificate used is issued by a valid DoDDoW certificate authority. Run this command: openssl x509 -in &ltpath_to_certificate_pem_file> -text | grep -i "issuer" If there is any issuer present in the certificate that is not a DoDDoW-approved certificate authority, this is a finding.

Fix text

Remove any certificate that was not issued by a valid DoDDoW certificate authority. Contact the organization's certificate issuer and request a new certificate that is issued by a valid DoDDoW certificate authorities.

Discussion

Only DoDDoW-approved external PKIs have been evaluated to ensure 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://cyber.mil/pki-pke/interoperability. This requirement focuses on communications protection for the DBMS session rather than for the network packet.

V-235191 in V2R3