NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 control SI.L2-3.14.7 require organizations handling Controlled Unclassified Information (CUI) to detect and report unauthorized use of their information systems — in cloud environments this must be implemented with cloud-native telemetry, detection logic, and centralized alerting so you can spot anomalous or malicious access quickly and prove compliance during audit.
\n\nThis control expects continuous monitoring that: collects authoritative audit data (console/API events, authentication, network flows, resource changes), generates detections for unauthorized actions (privilege escalation, atypical logins, disabled logging, suspicious API activity), and alerts responsible personnel so incidents can be contained and documented. For a Compliance Framework implementation, tie monitoring to documented processes (who investigates, SLA to triage, evidence retention) so monitoring is both technical and auditable.
\n\nImplement a three-tier approach: (1) Enable and centralize authoritative logs at the organization/account level; (2) Apply detection rules and analytics (cloud-native or SIEM) that map to known unauthorized-use behaviors; (3) Automate alerting, containment, and evidence capture. Key controls: enforce organization policies so logs cannot be turned off, use multi-region trails or organization-level sinks, encrypt and retain logs per your compliance retention schedule, and maintain an incident playbook that references the monitoring outputs.
\n\nEnable Activity Logs, Resource Diagnostic Settings, and Network Watcher flow logs at subscription/management group scope and forward to a central Log Analytics workspace and Microsoft Sentinel. Example commands:\n- Create a Log Analytics workspace and enable diagnostic settings:\n az monitor log-analytics workspace create -g RG -n central-law --location eastus\n az monitor diagnostic-settings create --name sendToLAW --resource /subscriptions/{subId} --workspace central-law --logs '[{\"category\":\"Administrative\",\"enabled\":true},{\"category\":\"Security\",\"enabled\":true},{\"category\":\"Action\",\"enabled\":true}]'\n- Enable Network Watcher flow logs for subnets:\n az network watcher flow-log configure --nsg NSG --enabled true --retention 365 --workspace central-law\nIn Sentinel, create analytics rules for unauthorized-use patterns: failed privileged account logins from new geolocations, service principal creation, disabling of diagnostic settings, and anomalous resource creation. Protect the workspace via an Azure Policy that denies deletion of diagnostic settings or requires forwarding to the central workspace (policy definition available in Azure Policy samples).
\n\nEnable organization-level CloudTrail (multi-region), CloudWatch Logs, VPC Flow Logs, and GuardDuty. Send CloudTrail to a central S3 bucket with write-only IAM, enable CloudTrail Insights and integrate with CloudWatch Logs for metric filters. Example commands:\n- Create a multi-region trail and send to S3:\n aws cloudtrail create-trail --name org-trail --s3-bucket-name my-org-cloudtrail-bucket --is-multi-region-trail\n aws cloudtrail start-logging --name org-trail\n- Enable VPC Flow Logs:\n aws ec2 create-flow-logs --resource-type Subnet --resource-ids subnet-123456 --traffic-type ALL --log-group-name vpc-flow-logs\nTurn on GuardDuty across the organization and use CloudWatch Events / EventBridge rules to detect suspicious API calls (e.g., CreateUser, PutUserPolicy, DeleteTrail) and trigger Lambda playbooks to snapshot auth artifacts and quarantine assets. Use AWS Organizations SCP to prevent disabling CloudTrail and S3 bucket access policies that forbid log deletion.
\n\nEnable Audit Logs at the organization level, create centralized logging sinks (to BigQuery, Cloud Storage, or Pub/Sub) and enable VPC Flow Logs. Example commands:\n- Create a centralized sink to Pub/Sub or BigQuery:\n gcloud logging sinks create org-sink bigquery.googleapis.com/projects/ORG_PROJECT/datasets/logs_dataset --organization=ORG_ID --log-filter='resource.type=\"gce_instance\" OR protoPayload.methodName:\"google.iam\"'\n- Enable flow logs for subnets:\n gcloud compute networks subnets update SUBNET --region REGION --enable-flow-logs\nUse Security Command Center (SCC) or Chronicle (if deployed) to detect unauthorized-use patterns (new service account keys, IAM role changes, console logins from rare geos). Enforce organization policies to prevent disabling admin activity logs and to require sinks be present for new projects.
\n\nScenario: a 25-employee contractor handling CUI with three AWS accounts (prod, dev, shared-services). Implementation steps: (1) In shared-services account create a central S3 bucket with encryption and a bucket policy that only allows CloudTrail write; (2) enable an organization CloudTrail that logs all accounts; (3) enable GuardDuty and centralize findings in Security Hub (or set EventBridge to push findings to an on-call Slack via Lambda); (4) keep a minimal SIEM by centralizing logs to an inexpensive storage (S3/BigQuery) and run scheduled Athena/BigQuery queries for anomalies if a paid SIEM is cost-prohibitive. Example detection rules for a small shop: alert on root account console usage, new access key creation for privileged users, disabling logging, and console login from new countries. This pattern provides strong evidence for auditors without enterprise SIEM costs.
\n\nBest practices: enforce log-forwarding with organizational policies (SCPs, Azure Policy, GCP Organization Policy), retain logs for a documented period (typical minimum 1 year depending on contract), protect access to logs with separate admin roles, and automate evidence collection for audits. Map each detection to a documented incident response playbook and record triage actions in a ticketing system. Risks of not implementing: undetected unauthorized access can lead to CUI exfiltration, contract termination, monetary penalties, and inability to demonstrate due care during audits — all of which are material risks to small businesses working with the federal government.
\n\nIn summary, achieving SI.L2-3.14.7 in cloud environments requires organization-level log enablement, centralization, platform-specific detections, and documented response workflows. Use cloud-native services (Azure Monitor/Sentinel, AWS CloudTrail/GuardDuty/Security Hub, GCP Audit Logs/SCC) combined with organization policies and simple automation to detect and prove containment of unauthorized use — a practical, auditable path for small and medium-sized businesses to meet NIST/CMMC obligations.
", "plain_text": "NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 control SI.L2-3.14.7 require organizations handling Controlled Unclassified Information (CUI) to detect and report unauthorized use of their information systems — in cloud environments this must be implemented with cloud-native telemetry, detection logic, and centralized alerting so you can spot anomalous or malicious access quickly and prove compliance during audit.\n\nWhat SI.L2-3.14.7 expects (practical interpretation)\nThis control expects continuous monitoring that: collects authoritative audit data (console/API events, authentication, network flows, resource changes), generates detections for unauthorized actions (privilege escalation, atypical logins, disabled logging, suspicious API activity), and alerts responsible personnel so incidents can be contained and documented. For a Compliance Framework implementation, tie monitoring to documented processes (who investigates, SLA to triage, evidence retention) so monitoring is both technical and auditable.\n\nCloud-native implementation strategy (high-level)\nImplement a three-tier approach: (1) Enable and centralize authoritative logs at the organization/account level; (2) Apply detection rules and analytics (cloud-native or SIEM) that map to known unauthorized-use behaviors; (3) Automate alerting, containment, and evidence capture. Key controls: enforce organization policies so logs cannot be turned off, use multi-region trails or organization-level sinks, encrypt and retain logs per your compliance retention schedule, and maintain an incident playbook that references the monitoring outputs.\n\nAzure — practical steps and sample commands\nEnable Activity Logs, Resource Diagnostic Settings, and Network Watcher flow logs at subscription/management group scope and forward to a central Log Analytics workspace and Microsoft Sentinel. Example commands:\n- Create a Log Analytics workspace and enable diagnostic settings:\n az monitor log-analytics workspace create -g RG -n central-law --location eastus\n az monitor diagnostic-settings create --name sendToLAW --resource /subscriptions/{subId} --workspace central-law --logs '[{\"category\":\"Administrative\",\"enabled\":true},{\"category\":\"Security\",\"enabled\":true},{\"category\":\"Action\",\"enabled\":true}]'\n- Enable Network Watcher flow logs for subnets:\n az network watcher flow-log configure --nsg NSG --enabled true --retention 365 --workspace central-law\nIn Sentinel, create analytics rules for unauthorized-use patterns: failed privileged account logins from new geolocations, service principal creation, disabling of diagnostic settings, and anomalous resource creation. Protect the workspace via an Azure Policy that denies deletion of diagnostic settings or requires forwarding to the central workspace (policy definition available in Azure Policy samples).\n\nAWS — practical steps and sample commands\nEnable organization-level CloudTrail (multi-region), CloudWatch Logs, VPC Flow Logs, and GuardDuty. Send CloudTrail to a central S3 bucket with write-only IAM, enable CloudTrail Insights and integrate with CloudWatch Logs for metric filters. Example commands:\n- Create a multi-region trail and send to S3:\n aws cloudtrail create-trail --name org-trail --s3-bucket-name my-org-cloudtrail-bucket --is-multi-region-trail\n aws cloudtrail start-logging --name org-trail\n- Enable VPC Flow Logs:\n aws ec2 create-flow-logs --resource-type Subnet --resource-ids subnet-123456 --traffic-type ALL --log-group-name vpc-flow-logs\nTurn on GuardDuty across the organization and use CloudWatch Events / EventBridge rules to detect suspicious API calls (e.g., CreateUser, PutUserPolicy, DeleteTrail) and trigger Lambda playbooks to snapshot auth artifacts and quarantine assets. Use AWS Organizations SCP to prevent disabling CloudTrail and S3 bucket access policies that forbid log deletion.\n\nGCP — practical steps and sample commands\nEnable Audit Logs at the organization level, create centralized logging sinks (to BigQuery, Cloud Storage, or Pub/Sub) and enable VPC Flow Logs. Example commands:\n- Create a centralized sink to Pub/Sub or BigQuery:\n gcloud logging sinks create org-sink bigquery.googleapis.com/projects/ORG_PROJECT/datasets/logs_dataset --organization=ORG_ID --log-filter='resource.type=\"gce_instance\" OR protoPayload.methodName:\"google.iam\"'\n- Enable flow logs for subnets:\n gcloud compute networks subnets update SUBNET --region REGION --enable-flow-logs\nUse Security Command Center (SCC) or Chronicle (if deployed) to detect unauthorized-use patterns (new service account keys, IAM role changes, console logins from rare geos). Enforce organization policies to prevent disabling admin activity logs and to require sinks be present for new projects.\n\nSmall-business real-world example and low-cost architecture\nScenario: a 25-employee contractor handling CUI with three AWS accounts (prod, dev, shared-services). Implementation steps: (1) In shared-services account create a central S3 bucket with encryption and a bucket policy that only allows CloudTrail write; (2) enable an organization CloudTrail that logs all accounts; (3) enable GuardDuty and centralize findings in Security Hub (or set EventBridge to push findings to an on-call Slack via Lambda); (4) keep a minimal SIEM by centralizing logs to an inexpensive storage (S3/BigQuery) and run scheduled Athena/BigQuery queries for anomalies if a paid SIEM is cost-prohibitive. Example detection rules for a small shop: alert on root account console usage, new access key creation for privileged users, disabling logging, and console login from new countries. This pattern provides strong evidence for auditors without enterprise SIEM costs.\n\nCompliance tips, best practices, and risks of non-implementation\nBest practices: enforce log-forwarding with organizational policies (SCPs, Azure Policy, GCP Organization Policy), retain logs for a documented period (typical minimum 1 year depending on contract), protect access to logs with separate admin roles, and automate evidence collection for audits. Map each detection to a documented incident response playbook and record triage actions in a ticketing system. Risks of not implementing: undetected unauthorized access can lead to CUI exfiltration, contract termination, monetary penalties, and inability to demonstrate due care during audits — all of which are material risks to small businesses working with the federal government.\n\nIn summary, achieving SI.L2-3.14.7 in cloud environments requires organization-level log enablement, centralization, platform-specific detections, and documented response workflows. Use cloud-native services (Azure Monitor/Sentinel, AWS CloudTrail/GuardDuty/Security Hub, GCP Audit Logs/SCC) combined with organization policies and simple automation to detect and prove containment of unauthorized use — a practical, auditable path for small and medium-sized businesses to meet NIST/CMMC obligations." }, "metadata": { "description": "Learn step-by-step cloud-native monitoring patterns and platform-specific configurations for Azure, AWS, and GCP to meet NIST SP 800-171 Rev.2 / CMMC 2.0 SI.L2-3.14.7 by reliably detecting and alerting on unauthorized use.", "permalink": "/how-to-implement-cloud-native-monitoring-to-satisfy-nist-sp-800-171-rev2-cmmc-20-level-2-control-sil2-3147-and-identify-unauthorized-use-across-azure-aws-and-gcp.json", "categories": [], "tags": [] } }