CIS AWS Foundations v1.2 3.5: Ensure a log metric filter and alarm exist for CloudTrail configuration changes

To meet cis aws foundations v1.2 3.5: ensure a log metric filter and alarm exist for cloudtrail configuration changes requirement, you must create a CloudWatch Logs metric filter that detects CloudTrail configuration changes and a CloudWatch alarm that notifies your response channel when those events occur. Operationally, this is “detect and alert” on any attempt to disable, alter, or bypass audit logging. ¹

Key takeaways:

• Detect CloudTrail configuration changes with a CloudWatch Logs metric filter on your CloudTrail log group. ²
• Route the alarm to a monitored destination (SNS, ticketing, or SIEM) and test it with a controlled change. ³
• Retain evidence: filter pattern, alarm config, notification wiring, and recurring validation across accounts/regions. ³

This requirement exists to protect the integrity of your audit trail. If an attacker (or an admin mistake) disables CloudTrail, changes which S3 bucket receives logs, alters multi-region behavior, or modifies event selectors, your security team can lose the ability to reconstruct what happened. CIS AWS Foundations v1.2 control 3.5 expects you to catch those changes quickly with automated detection and alerting, using a log metric filter and alarm aligned to the AWS Security Hub CIS mapping. ¹

For a CCO or GRC lead, the operational goal is straightforward: confirm CloudTrail logs flow into CloudWatch Logs, implement a metric filter that matches CloudTrail “configuration change” events, then bind that metric to an alarm that pages or tickets with enough context to investigate. Your audit success depends less on whether you created “an alarm” and more on whether it is complete across accounts and regions, routes to a monitored destination, and produces durable evidence.

This page gives requirement-level implementation guidance you can hand to a cloud platform owner and then audit with tight, testable artifacts. ³

Regulatory text

Requirement summary: Implement CIS AWS Foundations Benchmark v1.2 requirement 3.5 as mapped in AWS Security Hub. ¹

Operator interpretation: You need a detection control that triggers when CloudTrail’s configuration is changed (for example: trail stopped, trail deleted, logging disabled, event selectors changed) and an alerting control that notifies your responders promptly. The benchmark is satisfied by a CloudWatch Logs metric filter (detection) and a CloudWatch alarm (alerting) tied to the CloudTrail logs. ¹

Plain-English interpretation (what the requirement really demands)

Your CloudTrail trail is your audit log. This requirement expects you to:

1. Observe CloudTrail management events by sending CloudTrail logs to CloudWatch Logs, and
2. Automatically alert when someone changes CloudTrail itself.

If CloudTrail is modified without detection, you can end up with a blind spot exactly when you need evidence most: during unauthorized access, privilege escalation, key misuse, or destructive activity. This control is designed to make tampering noisy.

Who it applies to (entity and operational context)

Applies to:

• Any organization operating workloads in AWS accounts where CloudTrail is part of the security logging baseline. ³
• Teams using AWS Security Hub’s CIS AWS Foundations mapping (the mapped control for this requirement is CloudWatch.5). ²

Operational contexts where auditors expect this control:

• Multi-account AWS Organizations environments (central security/logging account plus member accounts).
• Regulated environments where audit logging supports incident response, investigations, and change control.
• Any production environment with privileged admin access where CloudTrail modifications could be accidental or malicious.

Notable scoping decision: If you run multiple trails (e.g., org trail plus workload trails), scope the metric filter and alarm to the log groups that receive the CloudTrail events you rely on for assurance. Document which trail(s) satisfy the baseline and why. ³

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

Below is a practical implementation path that works for most AWS environments and is easy to audit.

Step 1: Confirm CloudTrail delivers logs to CloudWatch Logs

1. Identify your baseline trail (or organization trail).
2. Verify “CloudWatch Logs” integration is enabled for that trail.
3. Confirm the CloudTrail log group exists and is receiving events.

Audit check: If CloudTrail only writes to S3 and not to CloudWatch Logs, a CloudWatch Logs metric filter cannot evaluate the events. You would need an alternative detection approach, but CIS 3.5 specifically expects the metric filter + alarm pattern. ³

Step 2: Create a CloudWatch Logs metric filter for CloudTrail configuration changes

Create a metric filter on the CloudTrail log group that matches CloudTrail events indicating configuration changes. Your cloud team can implement this in console, CloudFormation, Terraform, or an account factory pattern.

What to match (practical guidance):

• API calls that change trails, stop logging, delete trails, update event selectors, or alter delivery destinations.
• “Write” actions against CloudTrail itself.

Implementation notes for operators:

• Use a dedicated metric namespace (e.g., CIS/CloudTrail) and metric name (e.g., CloudTrailConfigChangeCount) so evidence is unambiguous.
• Treat each match as a count increment.

Evidence-friendly design choice: Keep the filter pattern text in version control so you can show exactly what is being detected. ³

Step 3: Create a CloudWatch alarm tied to the metric

Create an alarm that triggers when the metric indicates a configuration change.

Recommended alarm characteristics (operator-grade):

• Alarm triggers on a low threshold (because any CloudTrail config change is high-signal in most environments).
• Alarm actions publish to an SNS topic that is subscribed by:
  • Security on-call / incident response, or
  • A ticketing integration, or
  • Your SIEM/SOAR ingestion path.

Important: “Alarm exists” is not the same as “alarm is seen.” Confirm the SNS topic has at least one active subscription that reaches a monitored queue (email, webhook, PagerDuty integration, SIEM collector, etc.). ³

Step 4: Make it consistent across accounts and regions

Most failed audits happen here.

• If you use an organization trail, confirm the log group and the metric filter/alarm coverage for the organization logging pattern.
• If you use per-account trails, deploy the metric filter and alarm via an automated mechanism to every in-scope account.
• Ensure regional design matches how CloudTrail writes events (many organizations want multi-region trails to reduce blind spots). Document your decision. ³

Step 5: Test the control (and document the test)

Run a controlled test in a non-production account or approved change window:

• Temporarily change a CloudTrail setting (e.g., update an event selector).
• Verify the metric increments.
• Verify the alarm transitions to ALARM state.
• Verify the notification is received and creates a ticket/page with the right context.

Capture screenshots or exported JSON of the metric datapoint, alarm state history, and notification receipt. This becomes durable audit evidence. ³

Step 6: Operationalize response and ownership

Define:

• Who owns the alarm (Cloud platform vs. security operations).
• Expected triage workflow (validate change ticket vs. incident escalation).
• How to handle known-good changes (maintenance windows, change approvals).

Keep it simple: a short runbook with 5–10 steps beats a long policy that nobody uses.

Required evidence and artifacts to retain

Auditors and internal assessors typically want proof of design, deployment, and operation.

Retain these artifacts for each in-scope environment:

1. CloudTrail configuration evidence
   • Trail name(s), scope (org vs account), and confirmation that CloudWatch Logs delivery is enabled.
2. Metric filter evidence
   • Filter name, log group name, filter pattern, metric namespace/name, and creation timestamp.
   • IaC snippet (Terraform/CloudFormation) or config export showing the exact pattern.
3. Alarm evidence
   • Alarm name, metric it watches, threshold logic, action targets (SNS topic ARN), and state history.
4. Notification routing evidence
   • SNS topic subscriptions (redact endpoints as needed), plus proof it lands in a monitored channel.
5. Testing evidence
   • Change record ID, test steps, alarm state change, and resulting notification/ticket.
6. Periodic verification
   • A recurring control check (manual checklist or automated query) proving the filter/alarm still exists and is enabled. ¹

Common exam/audit questions and hangups

Use these to prep your cloud owner and avoid “we’ll get back to you” moments.

Auditor question	What they are really testing	What to show
“Which log group is the filter attached to?”	Are you filtering the right CloudTrail feed?	CloudTrail trail settings + log group name match
“How do you know it alerts?”	Operational effectiveness	Alarm state history + notification receipt
“Is this deployed everywhere?”	Completeness	Org-wide deployment approach + account/region inventory
“Who responds to these alerts?”	Governance	On-call rota, ticket queue, runbook owner
“What about approved changes?”	Noise control without blind spots	Change process mapping and triage steps

Frequent implementation mistakes (and how to avoid them)

1. CloudTrail not sending to CloudWatch Logs

   • Fix: enable CloudWatch Logs integration for the baseline trail; confirm events are flowing before building the filter.

2. Metric filter matches the wrong thing

   • Fix: test with a real CloudTrail change and confirm the metric increments; keep filter pattern under version control.

3. Alarm exists but no one receives it

   • Fix: verify SNS subscriptions; route to a monitored system, not a shared inbox.

4. Deployed in one account only

   • Fix: treat this as a baseline control and deploy via Organizations automation/IaC across in-scope accounts.

5. No evidence of operation

   • Fix: capture an initial test and schedule periodic checks; store results where audit can find them. ³

Enforcement context and risk implications

CIS AWS Foundations is a benchmark and an AWS Security Hub mapping, not a regulation by itself. Your risk comes from what the control protects: audit logging integrity. If CloudTrail is modified without detection, you can lose forensic evidence and delay incident containment, which can trigger downstream compliance failures under your own policies, contracts, and any applicable regulatory obligations that depend on logging and monitoring.

From a governance perspective, treat this as a “detect control failure” mechanism. If this alarm fires unexpectedly, assume you might have an adversary attempting to reduce visibility until proven otherwise. ³

Practical 30/60/90-day execution plan

First 30 days (establish baseline and prove it works)

• Inventory CloudTrail trails and identify the baseline trail(s) used for assurance.
• Confirm CloudWatch Logs delivery is enabled for those trails.
• Implement the metric filter and alarm in a pilot account.
• Wire notifications to your security on-call or ticketing queue.
• Execute a controlled test and store evidence. ³

Days 31–60 (scale and harden)

• Roll out to all in-scope accounts using IaC or account vending automation.
• Standardize naming (filter, metric, alarm, SNS topic) so evidence is consistent.
• Build a minimal runbook: triage steps, escalation criteria, and “approved change” verification.
• Enable AWS Security Hub CIS visibility for centralized tracking of drift (mapped control CloudWatch.5). ²

Days 61–90 (operational maturity and audit-readiness)

• Add periodic verification: confirm filter/alarm enabled and SNS subscriptions active.
• Add drift detection: alert if the filter/alarm is deleted or disabled (meta-monitoring).
• Run a tabletop exercise: simulate an unauthorized CloudTrail change and walk through response.
• Package an audit-ready evidence bundle per environment: configs, screenshots/exports, test record, and ownership attestations. ³

Tooling note (where Daydream fits naturally)

Most teams lose time collecting evidence across multiple accounts and proving “still in place” over time. Daydream can help by mapping CIS AWS Foundations requirements to concrete AWS checks, storing evidence artifacts, and scheduling recurring verification so audits don’t become a one-time scramble. ¹

Frequently Asked Questions

Do we need this in every AWS region?

Deploy it wherever your CloudTrail logs are delivered to CloudWatch Logs and where changes could occur. If you centralize CloudTrail in a single log group (common with org trails), document that architecture and show the single control covers the environment. ³

What if our CloudTrail logs only go to S3 and not CloudWatch Logs?

This specific requirement is implemented as a CloudWatch Logs metric filter and alarm, so you need CloudTrail delivery to CloudWatch Logs for the control as written. If you have constraints, document an exception and implement an alternate detection path, but expect the CIS check to fail. ³

Which events count as “CloudTrail configuration changes”?

Any API activity that modifies, stops, deletes, or changes the behavior of CloudTrail should trigger. Keep the exact filter pattern in version control and validate it by performing an approved change and observing the metric/alarm. ³

Can we route the alarm to our SIEM instead of email?

Yes. Auditors care that notifications are monitored and actionable. Show the SNS subscription or integration path into the SIEM/SOAR and evidence that it generates an incident or alert record. ³

How do we handle legitimate CloudTrail changes without creating constant incidents?

Use triage: responders validate whether there is an approved change ticket. Keep the alarm high-signal; don’t suppress it broadly, because unauthorized changes look the same as authorized ones at the event level. ³

What evidence is strongest for audits?

A configuration export (metric filter + alarm), proof of active notification routing, and a test record showing the alarm fired from a real CloudTrail change. Pair that with a periodic verification record to prove ongoing operation. ³

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

Footnotes

1. CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table

2. AWS Security Hub CIS AWS Foundations mapping table

3. CIS AWS Foundations Benchmark