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"] } } ] )