OpenControls Logo

STIG Viewer

STIGViewer Support

The audit information produced by MariaDB must be protected from unauthorized modification.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-253680MADB-10-002100SV-253680r960933_ruleCCI-000163medium
Description
If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized modification. This requirement can be achieved through multiple methods that will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions and limiting log data locations. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys to make access decisions regarding the modification of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Modification of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.
STIGDate
MariaDB Enterprise 10.x Security Technical Implementation Guide2026-03-02

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 (47) 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-17(1)Monitoring and Control
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(7)Role-based Access Control
1.00
AC-4Information Flow Enforcement
1.00
AC-6(10)Prohibit Non-privileged Users from Executing Privileged Functions
1.00

+37 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
CCI-000163
1.00
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.

PR.DS-10
1.00

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-253680r960933_chk)

Determine if the MariaDB Enterprise Audit plugin is logging to a file or syslog. MariaDB> SHOW GLOBAL VARIABLES LIKE 'server_audit_output_type'; If FILE, find the location of the audit log: MariaDB> SHOW GLOBAL VARIABLES LIKE 'server_audit_file_path'; If FILE, check the permission of the file: $ sudo ls -al /path/to/audit.log Consult the organization's security guide on acceptable permissions and ownership of logs with respect to who can modify them. Verify the log files have the set configurations. If the permissions are not set to the organization's standards, this is a finding. If the MariaDB server is configured to use syslog for logging, consult the organization's syslog setting for permissions and ownership of logs with respect to who can modify them.

Fix Text (F-57083r841564_fix)

If the audit.log file permissions do not comply with organization's standards, change the permissions. Example: $ chown user:group /path/to/audit.log $ chmod 660 /path/to/audit.log If the MariaDB server is configured to use syslog for logging, consult the organization's syslog setting for permissions and ownership of logs with respect to who can modify them.