If security labeling is not required, this is not a finding. If security labeling is required then there must be organizational or site-specific documentation on what the security labeling policy is and guidance on how and where to apply it. Review the organizational 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 result returned 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", a role that has been created, which has access to read/view database/collections that require security labels). Review the data in the MongoDB collections requiring security labels to ensure 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 the data in those collections use an appropriately constructed MongoDB $redact operation as part of the query pipeline to verify only the data appropriate for the query (that meets the security label requirements) is returned. Verify 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/v8.0/reference/operator/aggregation/redact/ Any queries that target a MongoDB database/collection that has security labels, and that pass through the trusted middleware and do 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"] } } ] )