Skip to main content
CUI

STIG Rule - V-279334

Back to STIG Browser

V-279334

SV-279334r1179504_rule

CAT II

MongoDB must provide audit record generation for DOD-defined auditable events within all DBMS/database components.

From: MongoDB Enterprise Advanced 8.x Security Technical Implementation Guide (V1R1)

Description

<VulnDiscussion>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 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. DOD 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. Satisfies: SRG-APP-000080-DB-000063, SRG-APP-000089-DB-000064, SRG-APP-000090-DB-000065, SRG-APP-000091-DB-000066, SRG-APP-000091-DB-000325, SRG-APP-000092-DB-000208, SRG-APP-000095-DB-000039, SRG-APP-000096-DB-000040, SRG-APP-000097-DB-000041, SRG-APP-000098-DB-000042, SRG-APP-000099-DB-000043, SRG-APP-000100-DB-000201, SRG-APP-000101-DB-000044, SRG-APP-000381-DB-000361, SRG-APP-000492-DB-000332, SRG-APP-000492-DB-000333, SRG-APP-000494-DB-000344, SRG-APP-000494-DB-000345, SRG-APP-000495-DB-000326, SRG-APP-000495-DB-000327, SRG-APP-000495-DB-000328, SRG-APP-000495-DB-000329, SRG-APP-000496-DB-000334, SRG-APP-000496-DB-000335, SRG-APP-000498-DB-000346, SRG-APP-000498-DB-000347, SRG-APP-000499-DB-000330, SRG-APP-000499-DB-000331, SRG-APP-000501-DB-000336, SRG-APP-000501-DB-000337, SRG-APP-000502-DB-000348, SRG-APP-000502-DB-000349, SRG-APP-000503-DB-000350, SRG-APP-000503-DB-000351, SRG-APP-000504-DB-000354, SRG-APP-000504-DB-000355, SRG-APP-000505-DB-000352, SRG-APP-000506-DB-000353, SRG-APP-000507-DB-000356, SRG-APP-000507-DB-000357, SRG-APP-000508-DB-000358, SRG-APP-000745-DB-000120, SRG-APP-000795-DB-000130</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

Check Procedure

Check the MongoDB configuration file (default location /etc/mongod.conf) for a key named "auditLog:". Examples shown below: auditLog: destination: file format: BSON path: <mongodb audit log directory>/auditLog.bson filter: '{ atype: { $in: [ "createCollection", "dropCollection" ] } }' -OR- auditLog: destination: syslog If an "auditLog:" key is not present, this is a finding. If the "auditLog:" key is present, ensure the subkey of "destination:" is set to either "file" or "syslog". If not, this is a finding. If the "auditLog:" key is present and contains a subkey of "filter:", ensure the filter is valid. If the filter is invalid, this is a finding. The site auditing policy must be reviewed to determine if the "filter:" being applied meets the site auditing requirements. If not, this is a finding. Check the MongoDB configuration file (default location: /etc/mongod.conf) for the following entry: setParameter: auditAuthorizationSuccess: true If this setParameter entry does not have "auditAuthorizationSuccess: true", this is a finding.

Fix Text

Edit the MongoDB configuration file (default location /etc/mongod.conf) and add a configured "auditLog" setting: auditLog: destination: file format: BSON path: <mongodb audit log directory>/auditLog.bson -OR- auditLog: destination: syslog Add the following entry to the MongoDB configuration file: setParameter: auditAuthorizationSuccess: true Restart the MongoDB service from the OS. $ sudo systemctl restart mongod Setting of auditAuthorizationSuccess enables auditing of authorization success for the authCheck action. The parameter value must be true to audit read and write operations. However, when auditAuthorizationSuccess is false, auditing has less performance impact because the audit system only logs authorization failures. If the "auditLog" setting was present and contained a "filter:" parameter, ensure the "filter:" expression does not prevent the auditing of events that should be audited. The filter can be modified accordingly to ensure it complies. Alternatively, remove the "filter:" parameter to enable auditing for all events. Refer to the MongoDB documentation for details of audit operations and event configuration: https://www.mongodb.com/docs/v8.0/core/auditing/ https://www.mongodb.com/docs/v8.0/tutorial/configure-audit-filters/

CCI Reference

CCI-000166,CCI-000169,CCI-000171,CCI-000172,CCI-001464,CCI-000130,CCI-000131,CCI-000132,CCI-000133,CCI-000134,CCI-001487,CCI-000135,CCI-003938,CCI-003821,CCI-003831
Created
2026-04-07 20:08:22
Last Updated
2026-04-07 20:08:22
Back to Browse
CUI