Detections
Analytics

MD4X-00-001100 - MongoDB must associate organization-defined types of security labels having organization-defined security label values with information in storage and transmission.

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

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

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

If security labeling is required then ensure the following:

1. Organizational or site-specific documentation and guidance is available or developed.
2. Ensure that security labels are or have been applied to those 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.

The example below shows 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 can be constructed can be found here: https://docs.mongodb.com/v4.4/reference/operator/aggregation/redact/

See Also

https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_MDB_Enterprise_Advanced_4-x_V1R1_STIG.zip

Item Details

References: CAT|II, CCI|CCI-002262, CCI|CCI-002263, CCI|CCI-002264, Rule-ID|SV-252144r817017_rule, STIG-ID|MD4X-00-001100, Vuln-ID|V-252144

Plugin: MongoDB

Control ID: e1a58bba897bcb06f1ee59cbc8f9c7dbd21911aaa4ff9b7a2a4b00baffdcb010