STIGViewer Support

The audit information produced by the MySQL Database Server 8.0 must be protected from unauthorized read access.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-235099MYS8-00-001200SV-235099r960930_ruleCCI-000162medium
Description
If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to their advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions utilizing file system protections and limiting log data location. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. If the value of audit_log_file is a relative path name, the plugin interprets it relative to the data directory. If the value is a full path name, the plugin uses the value as is. A full path name may be useful if it is desirable to locate audit files on a separate file system or directory. For security reasons, write the audit log file to a directory accessible only to the MySQL server and to users with a legitimate reason to view the log.
STIGDate
Oracle MySQL 8.0 Security Technical Implementation Guide2024-09-04

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (5) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-02Secure Baseline Configurations
1.00
CRY-01Use of Cryptographic Controls
1.00
DCH-01Data Protection
1.00
IAC-21Least Privilege
1.00
MON-08Protection of Event Logs
1.00
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (54) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-10Concurrent Session Control
1.00
AC-17(1)Monitoring and Control
1.00
AC-17(10)Authenticate Remote Commands
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(10)Shared and Group Account Credential Change
1.00
AC-2(2)Automated Temporary and Emergency Account Management
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-3Access Enforcement
1.00
AC-3(4)Discretionary Access Control
1.00

+44 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.3.8
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

7 NICE work roles and 7 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-235099r960930_chk)

Review locations of audit logs, both internal to the database and database audit logs located at the operating system level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized access. Run this script in the database to find the path and file name: SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME LIKE 'audit_log_file'; If there is no path for audit_log_file, then the audit files are located in the datadir. Run the this script to find the data directory: SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME LIKE 'datadir'; From the OS command line, run: ls -l <directory where audit log files are located> ls -l <directory where audit log files are located> | grep -i <audit_file_name> For example if the values returned by - "select @@datadir, @@audit_log_file; " are /usr/local/mysql/data/, audit.log ls -l /usr/local/mysql/data/ See below for an example: Note: .enc file extension means the files are encrypted. ls -l <directory where audit log files are located>/ | grep -i audit -rw-r----- 1 _mysql _mysql 10083871 Apr 16 15:38 audit.20190416T203832.log -rw-r----- 1 _mysql _mysql 398709 Apr 18 10:34 audit.20190418T153446.log -rw-r----- 1 _mysql _mysql 15237 Apr 18 10:44 audit.20190418T154402.log -rw-r----- 1 _mysql _mysql 876206 Apr 24 14:00 audit.20190424T190008.log -rw-r----- 1 _mysql _mysql 30208 Apr 24 14:10 audit.20190424T191044.log.enc If the owner and group are not "mysql" or "_mysql", this is a finding. If the directory or file permissions are more permissive than owner having Read/Write (RW) and group having Read (R) access to the audit files, aka "750", this is a finding.

Fix Text (F-38281r623418_fix)

Apply controls and modify permissions to protect database audit log data from unauthorized access, whether stored in the database itself or at the OS level. 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. If not performed already, set the audit log password. SELECT audit_log_encryption_password_set(password); Set appropriate permissions on the directory and audit files. sudo chown mysql <audit directory path> sudo chgrp mysql <audit directory path> Change permissions chmod 750 <directory path>