CIS AWS Foundations v1.2 3.4: Ensure a log metric filter and alarm exist for IAM policy changes

CIS AWS Foundations v1.2 control 3.4 focuses on a narrow but high-signal detection: changes to IAM policies. In practice, attackers and rogue insiders often aim to add permissions (or broaden scope) to enable data access, persistence, and lateral movement. This requirement forces you to implement a basic “tripwire” for those actions by turning CloudTrail log events into an actionable alert.

Operationally, you are implementing two connected pieces: (1) CloudTrail events delivered to CloudWatch Logs, and (2) a CloudWatch Logs metric filter + CloudWatch alarm that fires when IAM policy changes occur. AWS Security Hub maps this expectation to CloudWatch.4 in the CIS AWS Foundations benchmark integration (AWS Security Hub CIS AWS Foundations mapping table).

For a Compliance Officer, CCO, or GRC lead, the fast path is to standardize this as an account-level detective control: define the event set, enforce deployment across accounts (ideally via infrastructure-as-code), and retain proof that the alert path is monitored and tested. The rest of this page is requirement-level guidance you can hand to a cloud platform team and then audit cleanly.

Regulatory text

Excerpt / requirement intent: “Implement CIS AWS Foundations Benchmark v1.2 requirement 3.4 as mapped in AWS Security Hub.” (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Operator interpretation: You must (a) collect CloudTrail logs in a way that supports alerting, (b) define a log metric filter that matches IAM policy change events, and (c) configure an alarm that reliably notifies a responder. Passing intent is not “logs exist”; passing intent is “policy changes create an alert someone will see.”

Plain-English interpretation (what the requirement really asks)

You need an automated alarm for IAM policy changes so you can detect:

• Creation, deletion, and updates to managed policies
• Attachment/detachment of managed policies to identities (users, roles, groups)
• Updates to inline policies on users/roles/groups

The benchmark’s expectation (as implemented via AWS Security Hub’s CIS mapping) is that you use CloudWatch Logs metric filters on your CloudTrail log group and an alarm on the resulting metric (AWS Security Hub CIS AWS Foundations mapping table).

Who it applies to

In-scope entities

• Any organization operating workloads in AWS where IAM is used to control access, including enterprises, SaaS providers, financial services, and regulated operators.
• Teams that manage AWS accounts through a central platform function, cloud center of excellence, or delegated administrators.

In-scope operational context

• All production AWS accounts are typically in-scope; many teams also include staging if it has sensitive data or privileged access paths.
• Control ownership usually sits with Cloud Security / Platform Engineering, with Security Operations owning alarm response.

Out-of-scope (usually)

• Accounts with no CloudTrail logging to CloudWatch Logs cannot satisfy this requirement as written; those accounts need logging remediation first.

What you actually need to do (step-by-step)

Below is a practical, auditable sequence. Treat this as your runbook.

Step 1: Confirm CloudTrail is delivering events to CloudWatch Logs

1. Identify the organization’s CloudTrail strategy:
   • A centralized, multi-account trail (common in AWS Organizations), or
   • Per-account trails.
2. For each in-scope account/region, confirm:
   • CloudTrail is enabled for management events.
   • A CloudWatch Logs log group is configured as a destination.
3. Record the log group name(s). You will attach metric filters to these.

Audit point: If CloudTrail only goes to S3, you can still meet many logging needs, but this specific control expects a CloudWatch Logs metric filter and alarm path (AWS Security Hub CIS AWS Foundations mapping table).

Step 2: Define the IAM policy change event set (your detection scope)

Your goal is to capture the API calls that change IAM policy documents or change which policies are attached. Common event names to include:

• Managed policy lifecycle: CreatePolicy, CreatePolicyVersion, DeletePolicy, DeletePolicyVersion, SetDefaultPolicyVersion
• Attachments: AttachUserPolicy, DetachUserPolicy, AttachRolePolicy, DetachRolePolicy, AttachGroupPolicy, DetachGroupPolicy
• Inline policies: PutUserPolicy, DeleteUserPolicy, PutRolePolicy, DeleteRolePolicy, PutGroupPolicy, DeleteGroupPolicy
• Permission boundaries and related permission controls (optional but often included for better coverage): PutRolePermissionsBoundary, PutUserPermissionsBoundary, DeleteRolePermissionsBoundary, DeleteUserPermissionsBoundary

Write this list down as your control definition so you can defend what “policy change” means in your environment.

Step 3: Create a CloudWatch Logs metric filter on the CloudTrail log group

1. Go to CloudWatch Logs → Log groups → (select CloudTrail log group) → Metric filters → Create metric filter.
2. Use a filter pattern that matches CloudTrail records where:
   • eventSource is iam.amazonaws.com, and
   • eventName is one of the policy change events you defined.

Implementation tips that prevent false negatives:

• Validate your pattern against real CloudTrail events from your environment (download one event JSON and confirm fields).
• Ensure the filter is applied to the correct log group for each account/region (teams often apply it only to a “shared services” account and miss workload accounts).

3. Create a metric in a dedicated namespace (example naming convention):
   • Namespace: CIS/AWSFoundation
   • Metric name: IAMPolicyChanges
   • Metric value: 1

Step 4: Create a CloudWatch alarm on the metric

1. Go to CloudWatch → Alarms → Create alarm.
2. Select the metric you created: CIS/AWSFoundation / IAMPolicyChanges.
3. Set alarm condition:
   • Trigger when the metric is >= 1 within a short evaluation window (near-real-time detection).
4. Configure actions:
   • Send notifications to an SNS topic that is subscribed by your paging/on-call tool, email distribution list, or ticketing integration.
5. Name the alarm with an auditable identifier (include account and region if deployed per account).

Control expectation: The alarm must notify a monitored channel. An SNS topic with no subscriptions, or an email alias nobody monitors, fails the operational intent even if the alarm exists.

Step 5: Route alerts to response and define triage steps

Document a minimal triage workflow:

• Confirm change was authorized (change ticket, IaC pipeline, approved request).
• Identify actor (user/role), source IP, MFA status, and time.
• Review the policy diff and impacted identities.
• Roll back or detach if unauthorized.
• Open an incident if suspicious.

This is where a GRC lead can add value quickly: require an “authorization check” artifact (ticket link or CI/CD run link) as part of incident notes.

Step 6: Deploy consistently across accounts (standardize)

For multiple accounts, standardize deployment via:

• Infrastructure-as-code (CloudFormation/Terraform), or
• A centralized pipeline that applies to all in-scope accounts, or
• A governed baseline enforced by the platform team.

If you already use AWS Security Hub, track the mapped control status for drift and exceptions (AWS Security Hub CIS AWS Foundations mapping table).

Required evidence and artifacts to retain

Keep evidence that proves design, deployment scope, and operation. Minimum set:

• Control statement: event names in scope and intended alert path.
• Screenshot or export of the metric filter configuration (pattern, log group, metric namespace/name).
• Screenshot or export of the alarm configuration (threshold, period, actions).
• SNS topic configuration: subscriptions proving delivery to a monitored destination.
• Test record: a controlled IAM policy change (in a test account) and the resulting alarm notification, including timestamp and the CloudTrail event ID.
• Account/region coverage matrix: which AWS accounts and regions have the filter+alarm deployed, and documented exceptions.

If you use Daydream to manage control evidence, store these artifacts alongside the control definition and recurring verification results so audits do not turn into screenshot hunts.

Common exam/audit questions and hangups

Auditors and internal assessors repeatedly ask:

• “Show me the metric filter pattern and prove it matches IAM policy change events.”
• “Which accounts are covered? Is this deployed in every production account?”
• “Where do alerts go, and who responds?”
• “Show a test notification or incident ticket created from a real event.”
• “How do you prevent alerting gaps when new accounts are created?”

Hangups you can preempt:

• Partial coverage: filter exists only in one account or one region.
• No operational monitoring: alarm points to SNS with no active subscription.
• Overly narrow pattern: catches managed policy updates but misses inline policy changes.

Frequent implementation mistakes (and how to avoid them)

1. Filtering the wrong log group

   • Fix: inventory CloudTrail-to-CloudWatch log groups per account. Build the control from that inventory, not tribal knowledge.

2. Assuming CloudTrail to S3 is enough

   • Fix: keep S3 for retention, but add CloudWatch Logs delivery for alerting that Security Hub expects for this mapping (AWS Security Hub CIS AWS Foundations mapping table).

3. Alarm exists but nobody sees it

   • Fix: require proof of delivery (subscription + test message) as part of control acceptance.

4. Metric filter catches too much noise

   • Fix: include only IAM policy change events, not all IAM events. If you need broader IAM monitoring, create a separate control so this one stays high-signal.

5. No linkage to change management

   • Fix: add a standard field in the incident/ticket template: “Authorized change? Ticket/PR link.” This makes reviews fast.

Enforcement context and risk implications

CIS AWS Foundations is a benchmark standard used for security baselining and is commonly assessed through internal audit, customer security reviews, and cloud security posture management tools rather than direct regulator enforcement (CIS AWS Foundations Benchmark). The practical risk is straightforward: if IAM policy changes go undetected, an attacker can grant themselves access that bypasses application controls, and you may not have an early warning until data access or fraud shows up elsewhere.

Practical 30/60/90-day execution plan

First 30 days (establish control design + pilot)

• Define the IAM policy change event list and write the control statement.
• Identify CloudTrail log groups for all production accounts.
• Implement metric filter + alarm in a pilot set of accounts.
• Run an end-to-end test and capture evidence.

Day 31–60 (scale deployment + standardize response)

• Deploy across all in-scope production accounts and required regions.
• Centralize alert routing (SNS subscriptions) to the on-call/ticketing path.
• Publish a one-page triage runbook for responders.
• Add a monthly verification task: confirm alarms are enabled and SNS subscriptions exist.

Day 61–90 (audit readiness + drift management)

• Create an account/region coverage matrix and exception process.
• Add automated checks (for example, via Security Hub tracking of the CIS mapping) and remediate drift (AWS Security Hub CIS AWS Foundations mapping table).
• Run a tabletop exercise using a simulated unauthorized policy change and document outcomes.
• Store artifacts and recurring verification results in your GRC system (Daydream can hold control narratives, evidence, and review workflows in one place).

Frequently Asked Questions

Do I need this in every AWS region?

Deploy it wherever CloudTrail management events are delivered to CloudWatch Logs for that account. Many teams centralize CloudTrail to specific regions; your evidence should show that your chosen architecture still detects policy changes across the environment.

Does this cover inline policies and managed policies?

It can, but only if your filter pattern includes event names for both managed policy version changes and inline policy put/delete actions. Document the event list you included so the scope is explicit.

Can I alert from CloudTrail in EventBridge instead of CloudWatch metric filters?

You can build strong detections with EventBridge, but this CIS requirement is explicitly written around a log metric filter and alarm mapping in AWS Security Hub (AWS Security Hub CIS AWS Foundations mapping table). If you use EventBridge, keep the metric filter/alarm for compliance or document a formally approved compensating control.

What’s the minimum evidence an auditor will accept?

Expect to provide the metric filter configuration, the alarm configuration, proof of notification delivery (SNS subscription), and a test result showing the alarm fired from a known IAM policy change.

How do we handle automation that legitimately updates policies often?

Route alerts to ticketing with suppression rules in the ticketing layer (for known automation identities) or tag-approved automation roles and add a triage step that checks “expected pipeline run.” Avoid weakening the filter so much that it misses real abuse.

How do we keep coverage when new AWS accounts are created?

Add this control to your account vending/baseline process so new accounts inherit the log group, metric filter, alarm, and SNS wiring automatically. Track coverage in a simple matrix and review it on a recurring cadence.

Related compliance topics

• 03.01.18: Access Control for Mobile Devices
• 03.01.19: Withdrawn
• 03.01.20: Use of External Systems
• 03.01.21: Withdrawn
• 03.01.22: Publicly Accessible Content