STIGhubSTIGhub
STIGsRMF ControlsCompare

STIGhub

A free tool to search and browse the entire DISA STIG library. Saves up to 75% in security compliance research time.

Navigation

  • Browse STIGs
  • Search
  • RMF Controls
  • Compare Versions

Resources

  • About
  • Release Notes
  • VPAT
  • DISA STIG Library
STIGs updated 5 hours ago
Powered by Pylon
© 2026 Beacon Cloud Solutions, Inc. All rights reserved.
← Back to MongoDB Enterprise Advanced 8.x Security Technical Implementation Guide

V-279334

CAT II (Medium)

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

Rule ID

SV-279334r1179504_rule

STIG

MongoDB Enterprise Advanced 8.x Security Technical Implementation Guide

Version

V1R1

CCIs

CCI-000166CCI-000169CCI-000171CCI-000172CCI-001464CCI-000130CCI-000131CCI-000132CCI-000133CCI-000134CCI-001487CCI-000135CCI-003938CCI-003821CCI-003831

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 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

Check Content

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/