STIGQter STIGQter: STIG Summary: Oracle MySQL 8.0 Security Technical Implementation Guide Version: 1 Release: 1 Benchmark Date: 28 Jan 2021:

The MySQL Database Server 8.0 must generate audit records when privileges/permissions are deleted.

DISA Rule

SV-235119r638812_rule

Vulnerability Number

V-235119

Group Title

SRG-APP-000499-DB-000330

Rule Version

MYS8-00-003200

Severity

CAT II

CCI(s)

Weight

10

Fix Recommendation

If currently required, configure the MySQL Database Server to produce audit records when privileges/permissions are deleted.

See the supplemental file "MySQL80Audit.sql".

Check Contents

Review the system documentation to determine if MySQL Server is required to audit when privileges/permissions are deleted.

Check if MySQL audit is configured and enabled. The my.cnf file will set the variable audit_file.

To further check, execute the following query:

SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE 'audit%';

The status of the audit_log plugin must be "active". If it is not "active", this is a finding.

Review audit filters and associated users by running the following queries:
SELECT `audit_log_filter`.`NAME`,
`audit_log_filter`.`FILTER`
FROM `mysql`.`audit_log_filter`;

SELECT `audit_log_user`.`USER`,
`audit_log_user`.`HOST`,
`audit_log_user`.`FILTERNAME`
FROM `mysql`.`audit_log_user`;

All currently defined audits for the MySQL server instance will be listed. If no audits are returned, this is a finding.

To check if the audit filters in place are generating records when privileges/permissions are deleted, run the following, which will test auditing without destroying data:
delete from mysql.procs_priv where 1=2;

Review the audit log by running the Linux command:
sudo cat <directory where audit log files are located>/audit.log|egrep procs_priv
For example if the values returned by - "select @@datadir, @@audit_log_file; " are /usr/local/mysql/data/, audit.log
sudo cat /usr/local/mysql/data/audit.log |egrep procs_priv

The audit data will look similar to the example below:
{ "timestamp": "2020-08-19 21:24:26", "id": 2, "class": "general", "event": "status", "connection_id": 9, "account": { "user": "root", "host": "localhost" }, "login": { "user": "root", "os": "", "ip": "::1", "proxy": "" }, "general_data": { "command": "Query", "sql_command": "delete", "query": "delete from procs_priv", "status": 0 } }

If the audit event is not present, this is a finding.

Vulnerability Number

V-235119

Documentable

False

Rule Version

MYS8-00-003200

Severity Override Guidance

Review the system documentation to determine if MySQL Server is required to audit when privileges/permissions are deleted.

Check if MySQL audit is configured and enabled. The my.cnf file will set the variable audit_file.

To further check, execute the following query:

SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE 'audit%';

The status of the audit_log plugin must be "active". If it is not "active", this is a finding.

Review audit filters and associated users by running the following queries:
SELECT `audit_log_filter`.`NAME`,
`audit_log_filter`.`FILTER`
FROM `mysql`.`audit_log_filter`;

SELECT `audit_log_user`.`USER`,
`audit_log_user`.`HOST`,
`audit_log_user`.`FILTERNAME`
FROM `mysql`.`audit_log_user`;

All currently defined audits for the MySQL server instance will be listed. If no audits are returned, this is a finding.

To check if the audit filters in place are generating records when privileges/permissions are deleted, run the following, which will test auditing without destroying data:
delete from mysql.procs_priv where 1=2;

Review the audit log by running the Linux command:
sudo cat <directory where audit log files are located>/audit.log|egrep procs_priv
For example if the values returned by - "select @@datadir, @@audit_log_file; " are /usr/local/mysql/data/, audit.log
sudo cat /usr/local/mysql/data/audit.log |egrep procs_priv

The audit data will look similar to the example below:
{ "timestamp": "2020-08-19 21:24:26", "id": 2, "class": "general", "event": "status", "connection_id": 9, "account": { "user": "root", "host": "localhost" }, "login": { "user": "root", "os": "", "ip": "::1", "proxy": "" }, "general_data": { "command": "Query", "sql_command": "delete", "query": "delete from procs_priv", "status": 0 } }

If the audit event is not present, this is a finding.

Check Content Reference

M

Target Key

5277

Comments