MongoDB Enterprise Advanced 7.x STIG

MongoDB Enterprise Advanced 7.x Security Technical Implementation Guide

The MongoDB Enterprise Advanced 7.x Security Technical Implementation Guide (V1 R2) has 51 STIG checks. New to STIG checklists? Read What is a STIG checklist?, CKL vs CKLB, and STIG vs SCAP benchmark.

Find STIG checks

51STIG checks

Search filters this STIG's checks locally. Separate terms must all match (use quotes for an exact phrase). A search you ran on the Search page carries over here.

Severity

Version

V1 · R2

CurrentPublished Wed Jul 01 2026

MongoDB must associate organization-defined types of security labels having organization-defined security label values with information in storage.

MongoDB Enterprise Advanced 7.x Security Technical Implementation Guide

Assessment Title

Rule Text

MongoDB must associate organization-defined types of security labels having organization-defined security label values with information in storage.

Description

Discussion Text

Without the association of security labels to information, there is no basis for MongoDB to make security-related access-control decisions.

Security labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.

These labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling, or distribution instructions, or support other aspects of the information security policy.

One example includes marking data as classified or CUI. These security labels may be assigned manually or during data processing, but, either way, it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise.

The mechanism used to support security labeling may be a feature of MongoDB product, a third-party product, or custom application code.

Satisfies: SRG-APP-000311-DB-000308, SRG-APP-000313-DB-000309, SRG-APP-000314-DB-000310

New to STIG checklists? Read What is a STIG checklist? and CKL vs CKLB.

Objective

V-265934

Rule

SV-265934r1138540_rule

Severity

medium

Rule Version

MD7X-00-006400

Documentable

false

IA Controls

NIST SP 800-53

Rev 5

Assessment Procedure

Check Text

If security labeling is not required, this is not a finding.

If security labeling is required then there must be an organizational or site specific documentation on what the security labeling policy is and guidance on how and where to apply it.

Review the organization- or site-specific security labeling documentation to understand how documents in specific MongoDB collection(s) must be marked. This marking process should be applied as data is entered into the database.

Upon review of the security labeling documents, the following checks will be required.

1. Check if the role "SLTagViewer" exists. If this role does not exist, this is a finding.

Note: The role name "SLTagViewer" is a user-defined (custom) role and is organizational or site specific. The role name of "SLTagViewer" is used here as an example.

Run the following commands:

> use admin
> db.getRole( "SLTagViewer", { showPrivileges: true } )

If the results returned from this command is "null", this is a finding.
 
2. Check that data is appropriately marked in the specific MongoDB collection(s) that require security labeling. This check will be specific to the security labeling policy and guidance.

Log in to MongoDB with a user that has a Security Label Tag Viewer role ("SLTagViewer", which is a role that has been created and has access to read/view those database/collections that require security labels). Review the data in the MongoDB collections requiring security labels to ensure that the data is appropriately marked according to the security labeling documentation. For example, if documents in a MongoDB collection need to be marked as "TS", "S", "C" or "U" (or combination of) at the root level of the document and at each field level of the document, then the security labeling policy and guidance would indicate a document might look like the following and this would not be a finding ("sl" is the security label):

{
    "_id": 1,
    "sl": [["TS"], ["S"]],
    "field1" : { "sl" : [ ["S"] ], "data" : "field1 value" },
    "field2" : { "sl" : [ ["TS"] ], "data" : "field2 value" },
    "field3" : { "sl" : [ ["S"] ], "data" : "field3 value" }
}

The following document would be a finding because at the field level, field2 is missing its security label of "sl":

{
    "_id": 1,
    "sl": [["TS"], ["S"]],
    "field1" : { "sl" : [ ["S"] ], "data" : "field1 value" },
    "field2" : { "data" : "field2 value" },
    "field3" : { "sl" : [ ["S"] ], "data" : "field3 value" }
}


3. Check that queries against that data in those collections use an appropriately constructed MongoDB $redact operation as part of the query pipeline to ensure that only the data appropriate for the query (that meets the security label requirements) is returned.

Ensure that any query that targets the databases/collections that have security labeling have the appropriate MongoDB $redact operation applied.

This is done through trusted middleware. This trusted middleware configuration is purpose built (custom) code and integrations and is organizational or site specific. Information on the basics of this can be found here: https://www.mongodb.com/docs/v7.0/reference/operator/aggregation/redact/ 

Any queries that target a MongoDB database/collection that has security labels and pass through the trusted middleware and does not have an appropriately constructed $redact operator that is part of the query aggregation pipeline is a finding.

The following is an example of the $redact operator for the example document:

> db.security_collection.aggregate(
[{ 
   $redact:
    { $cond: [{ $anyElementTrue:
          { $map: { input: "$sl",
                      as: "setNeeded",
                in: { $setIsSubset: 
                ["$$setNeeded", ["S"]] }
               }
          }
          },
          "$$DESCEND", "$$PRUNE"]
    }
}
]
)

Implementation Procedure

Fix Text

To implement security labeling, ensure the following:

1. Organizational or site specific documentation and guidance is available or developed.

2. Ensure security labels are applied to MongoDB collection(s) requiring them in accordance with the organization or site specific documentation.

3. Create a Security Label Tag Viewer role ("SLTagViewer") with "find" privileges on the specific database and collection that requires security labeling.

In the example below, there are three databases and collections in those databases where security labels are required:

> use admin
> db.createRole(
   {
     role: "SLTagViewer",
     privileges: [
       { resource: { db: "db1", collection: "coll1" }, actions: [ "find" ] },
       { resource: { db: "db1", collection: "coll2" }, actions: [ "find" ] },
       { resource: { db: "db1", collection: "coll3" }, actions: [ "find" ] },
       { resource: { db: "db2", collection: "coll1" }, actions: [ "find" ] },
       { resource: { db: "db2", collection: "coll5" }, actions: [ "find" ] },
       { resource: { db: "db2", collection: "coll9" }, actions: [ "find" ] },
       { resource: { db: "db3", collection: "coll81" }, actions: [ "find" ] }
     ],
     roles: [ ]
   },
   { w: "majority" , wtimeout: 5000 }
) 

4. Ensure that any query that targets the databases/collections that have security labeling have the appropriate MongoDB $redact operation applied.

The $redact operator is applied through trusted middleware. This trusted middleware configuration is purpose built (custom) code and integrations and is organizational or site specific. 
Information on the basics of how this is constructed can be found here: https://www.mongodb.com/docs/v7.0/reference/operator/aggregation/redact/

STIG check 30 of 51 in the MongoDB Enterprise Advanced 7.x STIG checklist

← Previous · V-265933The DBMS must automatically terminate a user session after organization-defined conditions or trigger events requiring session disconnect.Next · V-265935 →MongoDB must enforce discretionary access control (DAC) policies, as defined by the data owner, over defined subjects and objects.