No Alarm for IAM Policy Changes (CIS 3.4): Detect and Fix It

IAM is the front door to your AWS account. Every permission boundary, every trust relationship, and every escalation path runs through it. When someone modifies an IAM policy, whether attaching AdministratorAccess to a compromised user or loosening a resource policy on a critical role, that change should never pass silently. The No Alarm for IAM Policy Changes check verifies that your account has a CloudWatch alarm configured to detect exactly these events, as recommended by CIS AWS Foundations Benchmark control 3.4.

---

What this check detects

The check looks for a CloudWatch metric filter and associated alarm that monitor your CloudTrail logs for IAM policy mutation events. Specifically, CIS 3.4 expects a metric filter matching API calls such as:

• DeleteGroupPolicy, DeleteRolePolicy, DeleteUserPolicy
• PutGroupPolicy, PutRolePolicy, PutUserPolicy
• CreatePolicy, DeletePolicy, CreatePolicyVersion, DeletePolicyVersion
• AttachRolePolicy, DetachRolePolicy
• AttachUserPolicy, DetachUserPolicy
• AttachGroupPolicy, DetachGroupPolicy

If no metric filter matches these events, or a filter exists but is not connected to an alarm with a working SNS notification, the check fails.

---

Why it matters

Permission changes are the quietest and most dangerous part of an account compromise. An attacker rarely starts with full admin. They land with a foothold, often a leaked access key or an over-permissioned CI role, and then escalate. Attaching a managed policy or editing an inline policy is one of the fastest paths from "limited user" to "owns the account."

Consider a realistic chain:

1. A developer commits an access key to a public repo.
2. An automated scanner picks it up within minutes.
3. The attacker calls AttachUserPolicy to bind AdministratorAccess to the user tied to that key.
4. They create new access keys, spin up mining instances, and exfiltrate data.

Step 3 is the moment you want to know about. With a CIS 3.4 alarm in place, that single AttachUserPolicy call pages your on-call within a minute. Without it, you find out when the bill arrives or when a customer reports a breach.

Beyond external attackers, this alarm catches internal mistakes too. An engineer broadening a role policy during a late-night incident, a Terraform run that drifts a trust policy, a contractor granting themselves more access than agreed. These are not malicious, but they erode your security posture, and you want a record and a signal when they happen.

---

How to fix it

The remediation has three parts: a metric filter on your CloudTrail log group, an SNS topic with a subscription, and a CloudWatch alarm linking them. Below is the full sequence using the AWS CLI. Replace the placeholder values with your own.

1. Create an SNS topic and subscribe to it

aws sns create-topic --name cis-iam-policy-changes

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:111122223333:cis-iam-policy-changes \
  --protocol email \
  --notification-endpoint [email protected]

Confirm the subscription from the email you receive before moving on, otherwise the alarm will fire into the void.

2. Create the metric filter on the CloudTrail log group

aws logs put-metric-filter \
  --log-group-name "CloudTrail/DefaultLogGroup" \
  --filter-name "CIS-IAMPolicyChanges" \
  --filter-pattern '{($.eventName=DeleteGroupPolicy)||($.eventName=DeleteRolePolicy)||($.eventName=DeleteUserPolicy)||($.eventName=PutGroupPolicy)||($.eventName=PutRolePolicy)||($.eventName=PutUserPolicy)||($.eventName=CreatePolicy)||($.eventName=DeletePolicy)||($.eventName=CreatePolicyVersion)||($.eventName=DeletePolicyVersion)||($.eventName=AttachRolePolicy)||($.eventName=DetachRolePolicy)||($.eventName=AttachUserPolicy)||($.eventName=DetachUserPolicy)||($.eventName=AttachGroupPolicy)||($.eventName=DetachGroupPolicy)}' \
  --metric-transformations \
      metricName=IAMPolicyChanges,metricNamespace=CISBenchmark,metricValue=1

3. Create the CloudWatch alarm

aws cloudwatch put-metric-alarm \
  --alarm-name "CIS-3.4-IAMPolicyChanges" \
  --alarm-description "Alarm for IAM policy changes (CIS 3.4)" \
  --metric-name IAMPolicyChanges \
  --namespace CISBenchmark \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:cis-iam-policy-changes

Doing it in the console

1. Open CloudWatch → Log groups and select your CloudTrail log group.
2. Choose Metric filters → Create metric filter and paste the filter pattern above.
3. Name the metric IAMPolicyChanges under namespace CISBenchmark with a value of 1.
4. On the created filter, choose Create alarm, set the threshold to >= 1 over a 5 minute period.
5. Attach an SNS topic for notifications and confirm the subscription.

---

Terraform: make it reproducible

Clicking through the console once is fine, but you want this codified so every account gets the same alarm. Here is the equivalent in Terraform.

resource "aws_sns_topic" "iam_policy_changes" {
  name = "cis-iam-policy-changes"
}

resource "aws_sns_topic_subscription" "email" {
  topic_arn = aws_sns_topic.iam_policy_changes.arn
  protocol  = "email"
  endpoint  = "[email protected]"
}

resource "aws_cloudwatch_log_metric_filter" "iam_policy_changes" {
  name           = "CIS-IAMPolicyChanges"
  log_group_name = var.cloudtrail_log_group_name

  pattern = "{($.eventName=DeleteGroupPolicy)||($.eventName=DeleteRolePolicy)||($.eventName=DeleteUserPolicy)||($.eventName=PutGroupPolicy)||($.eventName=PutRolePolicy)||($.eventName=PutUserPolicy)||($.eventName=CreatePolicy)||($.eventName=DeletePolicy)||($.eventName=CreatePolicyVersion)||($.eventName=DeletePolicyVersion)||($.eventName=AttachRolePolicy)||($.eventName=DetachRolePolicy)||($.eventName=AttachUserPolicy)||($.eventName=DetachUserPolicy)||($.eventName=AttachGroupPolicy)||($.eventName=DetachGroupPolicy)}"

  metric_transformation {
    name      = "IAMPolicyChanges"
    namespace = "CISBenchmark"
    value     = "1"
  }
}

resource "aws_cloudwatch_metric_alarm" "iam_policy_changes" {
  alarm_name          = "CIS-3.4-IAMPolicyChanges"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = 1
  metric_name         = "IAMPolicyChanges"
  namespace           = "CISBenchmark"
  period              = 300
  statistic           = "Sum"
  threshold           = 1
  treat_missing_data  = "notBreaching"
  alarm_actions       = [aws_sns_topic.iam_policy_changes.arn]
}

---

How to prevent it from happening again

One-off remediation does not scale. The real win is making sure no account ever exists without this alarm.

• Centralize with an organization-wide trail. Use a single multi-region CloudTrail at the organization level so every member account logs to one place. You can then build the CIS 3.x metric filters and alarms against that central log group once.
• Bake it into your landing zone. If you use AWS Control Tower, Account Factory, or a custom Terraform baseline, include the metric filters and alarms in the module that provisions every new account. A new account should arrive fully monitored.
• Gate it in CI/CD. Run a policy-as-code scan on every infrastructure pull request. Tools like Checkov, tfsec, or OPA can assert that the CIS alarm resources exist before a Terraform apply is allowed to merge.
• Continuous detection. Lensix re-runs this check on a schedule, so if someone deletes the alarm or the metric filter drifts, you find out fast rather than at your next audit.

A simple Checkov-style guardrail in your pipeline can confirm the alarm resource is present:

checkov -d ./terraform --check CKV_AWS_111 --compact

---

Best practices

• Tune the noise. In environments where IAM changes flow through automated pipelines, you may see frequent legitimate alarms. Do not silence them. Instead, route pipeline-driven changes through a known role and enrich your alerting so human-initiated changes stand out.
• Correlate, do not just alert. Feed these events into a SIEM or Amazon Security Lake so an IAM policy change can be correlated with other suspicious activity, like a new access key created moments earlier.
• Add preventive controls alongside detection. Service control policies can deny attaching AdministratorAccess outside a break-glass role, and permission boundaries cap what a role can grant. Detection tells you what happened, prevention limits the blast radius.
• Test the path end to end. Perform a benign IAM change in a test account and confirm the alarm fires and the notification lands where it should. An alarm nobody receives is no alarm at all.
• Cover the full CIS monitoring set. IAM policy changes are one of several CIS monitoring controls. Root account usage, console logins without MFA, security group changes, and route table changes all deserve the same treatment.

Setting up the IAM policy change alarm takes a few minutes, but it buys you something hard to overstate: a real-time signal the moment someone reaches for the keys to your account. Configure it once, codify it everywhere, and let continuous checks make sure it stays in place.