Using Amazon Macie to Find and Tag CUI Files in S3 (MP.L2-3.8.4)

NIST SP 800-171 Rev. 2 practice MP.L2-3.8.4 requires media containing CUI to display applicable CUI markings and distribution limitations; for S3 objects, this means identifying CUI-bearing files and applying consistent metadata that users and automated workflows can recognize. Using Amazon Macie to find and tag CUI files in S3 can support this requirement when Macie classification findings trigger an AWS automation workflow that applies S3 object tags for the CUI banner, category, owner, and approved dissemination limitation.

Amazon Macie does not write markings into a document or directly add S3 object tags by itself. The practical AWS design is Macie for discovery, Amazon EventBridge for finding events, and AWS Lambda for applying governed S3 object tags based on the finding and the data owner’s approved CUI designation.

What configuration is required for using Amazon Macie to find and tag CUI files in S3?

1. Enable Amazon Macie in every in-scope AWS Region. Sign in to the AWS Management Console using the account designated as the Macie administrator. Open Amazon Macie, select the appropriate Region, and choose Get started or Enable Macie. For a multi-account environment, open Amazon Macie > Settings > Accounts and configure the AWS Organizations delegated administrator before enabling member accounts.

   Do not assume that enabling Macie in one Region covers S3 buckets in all Regions. Macie discovery and findings are Regional, so maintain a documented list of CUI-capable S3 buckets and their Regions.

2. Turn on automated sensitive data discovery for broad coverage. In the Macie console, go to Settings > Automated sensitive data discovery, choose Enable, and confirm the feature is enabled. This provides ongoing discovery for eligible S3 buckets, but it should not replace a targeted classification job for known CUI repositories.

3. Create a custom data identifier for visible CUI markings. Go to Settings > Custom data identifiers > Create. Create an identifier named CUI_Banner_Marking with a description such as Detects CUI banners and common CUI category markings in files stored in S3.

   Use the following regular expression as a starting point:

   (?i)(CONTROLLED UNCLASSIFIED INFORMATION|CUI(?:\/\/[A-Z0-9 -]+){0,3})

   Add the keywords CUI, CONTROLLED, and UNCLASSIFIED. Set Maximum match distance to 50. This helps Macie identify documents that already contain a CUI banner, such as CUI//SP-CTI, while reducing matches from unrelated uses of the word “controlled.”

4. Create identifiers for organization-specific contract indicators. In the same Custom data identifiers area, create separate identifiers for contract numbers, supplier data labels, drawing release codes, or other markers that indicate likely CUI. Avoid using a single generic identifier as the sole basis for automatic tagging. A matching phrase can indicate that a file needs review; it does not always establish the correct CUI category or dissemination control.

5. Create a targeted sensitive-data discovery job. Navigate to Amazon Macie > Jobs > Create job. Select One-time job for an initial inventory or Scheduled job for recurring review. Under Choose S3 buckets, select only the approved CUI repositories. Under Managed data identifiers, select the identifiers relevant to your environment, and under Custom data identifiers, select CUI_Banner_Marking and the approved contract-specific identifiers.

   For the first baseline scan, set Sampling depth to 100% for priority repositories. Name the job descriptively, such as CUI-S3-Engineering-Weekly-Classification. A weekly schedule is often appropriate for active document repositories, while upload-triggered review may be needed for faster-moving workflows.

6. Define the S3 object-tagging taxonomy before automating it. Use standardized tag keys that can be evaluated by IAM policies, S3 inventory reports, and compliance evidence reviews. A practical tag set is shown below.

   Tag key	Example value	Purpose
   CUI	Yes	Flags the object as containing or suspected of containing CUI.
   CUI_Banner	CUI//SP-CTI	Records the approved CUI category marking.
   CUI_Distribution	NOFORN	Records an approved limited dissemination control, when applicable.
   CUI_Owner	Engineering-Data-Owner	Supports ownership identification associated with MP.L2-3.8.8.
   CUI_Status	Pending-Owner-Review	Prevents a detection result from being treated as a final legal determination.

7. Create an EventBridge rule for Macie sensitive-data findings. Open Amazon EventBridge > Rules > Create rule. Select the default event bus, choose Event pattern, select AWS events or EventBridge partner events, and use the following event pattern:

   {
     "source": ["aws.macie"],
     "detail-type": ["Macie Finding"],
     "detail": {
       "type": ["SensitiveData:S3Object/Multiple"]
     }
   }

   Set the target to an AWS Lambda function such as macie-cui-object-tagger. If your findings use additional sensitive-data finding types, include those types in the event pattern after validating them in the Macie Findings page.

8. Configure the Lambda function to preserve existing tags and apply CUI tags. The function should call the Macie GetFindings API using the finding ID from EventBridge, identify the affected bucket, object key, and version ID, retrieve current object tags with s3:GetObjectTagging, and then apply the approved tag set with s3:PutObjectTagging. Grant the Lambda execution role only the required permissions: macie2:GetFindings, s3:GetObjectTagging, s3:PutObjectTagging, and CloudWatch Logs permissions.

   Make the function apply CUI_Status=Pending-Owner-Review by default. Only apply a final banner value such as CUI//SP-CTI or a restriction such as NOFORN when the finding matches a pre-approved rule and the data owner has authorized that mapping.

For example, a 275-person precision machining and metal fabrication firm may store customer-controlled CAD exports, inspection reports, and technical data packages in an S3 bucket used by its engineering document portal. Macie can detect a visible CUI//SP-CTI banner in a technical drawing package, while the Lambda workflow adds CUI=Yes, CUI_Banner=CUI//SP-CTI, CUI_Owner=Engineering-Data-Owner, and CUI_Status=Pending-Owner-Review. The engineering data owner then confirms whether a dissemination limitation applies before the status is changed to Approved.

How do you verify that Macie discovery and S3 tagging worked?

1. Open Amazon Macie > Findings and filter by the classification job name, affected S3 bucket, or custom data identifier name. Confirm that the finding identifies the expected bucket and object path.

2. Select the finding and review Resources affected and Sensitive data. Confirm that the custom data identifier or managed identifier matched the expected content rather than a false positive.

3. Open Amazon S3 > Buckets > [bucket name] > Objects, select the identified object, and open the Properties tab. Under Tags, verify the required values, including CUI, CUI_Banner, CUI_Distribution when applicable, and CUI_Owner.

4. Open Amazon CloudWatch > Log groups and review the Lambda log group for the tagging event. The log should record the Macie finding ID, bucket, object key, tag action, timestamp, and any review status without writing sensitive file contents to logs.

What evidence should be retained for a CMMC assessor?

For a stronger evidence package, configure Amazon Macie > Settings > Findings export configuration to export findings to a protected S3 evidence bucket encrypted with an approved AWS KMS key. Retain the associated review record showing who approved the final CUI category and any limited dissemination control.

Where does Amazon Macie fall short of MP.L2-3.8.4?

Using Amazon Macie to find and tag CUI files in S3 does not itself place a visible CUI banner in a PDF, CAD file, spreadsheet, printed drawing, removable drive label, or downloaded report. S3 object tags are metadata; they are useful for governance and automated access decisions, but a user may not see them when opening a file outside the AWS Console.

Macie also cannot determine the correct CUI category or distribution limitation solely from content detection. The CUI category, marking syntax, and limited dissemination controls must come from the contract, data owner, legal counsel, export-control process, and applicable NARA CUI guidance. A finding should therefore initiate a controlled review workflow, not automatically assign restrictive labels based on a keyword alone.

Fill these gaps with a documented CUI marking procedure that requires document owners to apply visible headers, footers, cover sheets, drawing title-block markings, and physical-media labels where required. For OT/ICS-related engineering data, include the export path from the manufacturing engineering system, historian, or quality platform into S3, because the file may lose its original visual marking during conversion or report generation.

Next, assign an engineering or operations data owner to approve the CUI tag taxonomy and run a controlled Macie classification job against one in-scope S3 bucket before expanding the workflow across your environment.