CIS AWS Foundations v1.2 3.1: Ensure a log metric filter and alarm exist for unauthorized API calls

To meet cis aws foundations v1.2 3.1: ensure a log metric filter and alarm exist for unauthorized api calls requirement, you must (1) send AWS CloudTrail logs to CloudWatch Logs, (2) create a metric filter that detects unauthorized API activity, and (3) attach a CloudWatch alarm that notifies your responders. This is the CIS AWS Foundations v1.2 3.1 control as mapped in AWS Security Hub. ¹

Key takeaways:

• You need both detection (metric filter) and response routing (alarm actions) for unauthorized API calls.
• The control only works if CloudTrail is correctly configured, delivered, and retained in CloudWatch Logs.
• Auditors will focus on repeatability: centralized rollout, consistent naming, and evidence that alarms reach an owned on-call path.

Unauthorized API calls are one of the fastest ways for an attacker (or a misconfigured automation) to escalate impact in AWS: they probe IAM permissions, attempt restricted actions, and generate a trail of “access denied” and authorization failure events. CIS AWS Foundations v1.2 control 3.1 requires you to convert those CloudTrail events into an operational signal: a CloudWatch Logs metric filter plus a CloudWatch alarm that routes to your incident channel. ¹

For a CCO, Compliance Officer, or GRC lead, the operational goal is simple: prove that every in-scope AWS account produces an alert when unauthorized API calls occur, and that the alert is sent somewhere your team actually monitors. This page translates the benchmark requirement into an implementable checklist, an evidence package you can hand to auditors, and an execution plan you can run across an AWS Organization without getting stuck in tooling debates.

Scope-wise, assume this control applies broadly: production accounts, shared services accounts, and any environment where CloudTrail is expected to support security monitoring and investigation.

Regulatory text

Requirement excerpt: “Implement CIS AWS Foundations Benchmark v1.2 requirement 3.1 as mapped in AWS Security Hub.” ¹

Operator interpretation: You must implement the CIS AWS Foundations v1.2 safeguard that detects unauthorized API calls by:

1. recording API activity with CloudTrail,
2. sending CloudTrail to CloudWatch Logs,
3. creating a CloudWatch Logs metric filter for unauthorized events, and
4. alarming on that metric with actionable notifications.
   The “mapped in AWS Security Hub” phrase means you should be able to show this control passing (or remediated) in the Security Hub CIS mapping for the relevant check. ²

Plain-English interpretation (what the control is asking for)

You are building an always-on tripwire for failed authorization attempts in AWS. When a principal (human or workload) tries an API call they are not allowed to perform, CloudTrail records an error. The metric filter turns matching log events into a countable metric, and the alarm triggers when the count crosses your threshold so responders can investigate.

What auditors expect to see:

• The metric filter exists in every in-scope account/region where CloudTrail logs land.
• The alarm exists, is enabled, and has an alarm action (SNS, incident tool, email distribution, or paging system).
• Ownership is clear: who receives alerts, who triages, and where tickets get recorded.

Who it applies to

Entity types: AWS cloud operators running workloads in AWS accounts that must align to CIS AWS Foundations. ³

Operational contexts where it matters most

• Multi-account AWS Organizations (central security account + many workload accounts).
• Regulated environments where audit evidence must show detective controls (SOC 2, ISO 27001, internal control frameworks).
• Environments with CI/CD and IaC where automation frequently hits permission boundaries (you want to detect true anomalies, not constant noise).

Dependencies you must have in place

• CloudTrail enabled for management events and delivered to a log destination you control.
• CloudTrail log delivery to CloudWatch Logs (not only S3), because metric filters run on CloudWatch Logs.
• A notification path (SNS topic subscription or integrated incident management tool) that is owned and tested.

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

Step 1: Confirm CloudTrail is recording the right events

1. Inventory trails across accounts and regions (Organization trail preferred for consistency).
2. Confirm management events are logged (read + write as appropriate for your monitoring strategy).
3. Confirm CloudTrail is delivering to CloudWatch Logs (look for a CloudWatch Logs log group associated with the trail).

Practical note: Many teams have CloudTrail to S3 only. That is good for retention and forensics, but it will not satisfy the “metric filter and alarm” expectation unless logs are also in CloudWatch Logs.

Step 2: Standardize where logs land (naming and centralization)

Pick an approach and document it:

• Centralized logging account: CloudTrail from member accounts delivered to a central log archive account; metric filter + alarm live centrally.
• Per-account monitoring: Each account has its own metric filter and alarm.

Either can work operationally; auditors mainly care that coverage is complete and evidence is consistent. If you use AWS Security Hub, align the implementation so the mapped control reports compliant. ²

Step 3: Create the CloudWatch Logs metric filter for unauthorized API calls

In the CloudWatch Logs log group that receives CloudTrail:

1. Define a metric filter pattern that matches unauthorized events (common signals include “AccessDenied” or client authorization failures in CloudTrail error fields).
2. Emit the count to a dedicated metric namespace (example: CIS/CloudTrail) with a clear metric name (example: UnauthorizedAPICalls).
3. Apply the filter to the correct log group (the log group attached to your trail).

Design tips

• Keep the filter pattern tight enough to avoid constant noise from known, benign automation.
• If you need exceptions, do it deliberately: document them and track them like compensating controls.

Step 4: Create a CloudWatch alarm on that metric

1. Create an alarm on the emitted metric.
2. Set threshold logic appropriate to your environment (many teams alert on any non-zero count within a short evaluation window; choose what your on-call can realistically handle).
3. Attach alarm actions:
   • SNS topic that routes to security monitoring
   • Ticketing integration
   • Paging integration for high-severity environments
4. Ensure the alarm is enabled, in the correct region, and has a clear name and description that states what responders should do.

Step 5: Route and test notifications (operationalize)

1. Verify SNS subscriptions are confirmed (email) or integrated (ChatOps/incident tools).
2. Run a test that produces an unauthorized API event in a controlled way (for example, a test role that attempts a denied action).
3. Confirm:
   • CloudTrail captured the event,
   • the log arrived in CloudWatch Logs,
   • the metric incremented,
   • the alarm transitioned state, and
   • notification arrived at the owned destination.
4. Record the test as evidence.

Step 6: Deploy consistently (IaC + Organization-wide rollout)

For speed and auditability, implement with infrastructure-as-code and push across accounts:

• Central policy: required log group, required metric filter, required alarm, required SNS topic.
• Guardrails: service control policies (SCPs) or config rules to prevent drift, plus Security Hub monitoring of the mapped control. ²

Where Daydream fits: Daydream is useful once you’ve implemented the control and need repeatable evidence: mapping the requirement to the AWS accounts in scope, scheduling periodic verification, and packaging screenshots/CLI outputs/exports into an audit-ready record without rebuilding the same workbook each quarter.

Required evidence and artifacts to retain

Keep evidence at two levels: design (what you intended) and operation (proof it’s running).

Design artifacts

• CloudTrail architecture decision (central vs per-account) and scope statement.
• Runbook: “Unauthorized API Calls Alarm Triage” with owner, severity, and ticketing steps.
• IaC repo references (Terraform/CloudFormation) for metric filter + alarm.

Operational evidence (audit-ready)

• CloudTrail configuration export showing CloudWatch Logs delivery.
• CloudWatch Logs metric filter configuration (pattern, log group, metric namespace/name).
• CloudWatch alarm configuration (threshold, evaluation periods, actions, OK/ALARM behavior).
• SNS topic configuration and subscription list (redact emails if needed).
• Test record: timestamped event, alarm state change, and notification receipt.
• AWS Security Hub evidence showing the mapped CIS control status for affected accounts. ²

Common exam/audit questions and hangups

Auditor question	What they’re really testing	What to show
“Which accounts and regions are covered?”	Completeness of scope	Account inventory, CloudTrail/Log Group locations, deployment method
“How do you know alerts are received?”	Alarm actions + ownership	SNS subscriptions, on-call rotation reference, recent test results
“Is the detection tuned?”	Signal-to-noise and triage maturity	Filter pattern rationale, documented exceptions, runbook
“Can this be bypassed?”	Control resilience	Change control, IaC enforcement, drift detection, Security Hub monitoring 2

Frequent implementation mistakes and how to avoid them

1. CloudTrail logs are not in CloudWatch Logs.
   Fix: Update trails to send to CloudWatch Logs (or add delivery) and verify ingestion.

2. Alarm exists but has no actions.
   Fix: Require at least one alarm action (SNS) in your deployment standard, and test delivery.

3. Built in one region; CloudTrail is elsewhere.
   Fix: Deploy where the log group exists. Document multi-region strategy.

4. Filter pattern is too broad and causes alert fatigue.
   Fix: Start broad during rollout, then add documented exceptions for known noisy roles. Re-test after every change.

5. No evidence of operation.
   Fix: Run a controlled test and retain proof. Tie the alarm to ticket creation so you have durable records.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS control. Treat the risk as operational: if unauthorized API calls are not detected and routed, you can miss early indicators of credential misuse, privilege escalation attempts, or broken automation repeatedly failing authorization. For regulated programs, the bigger issue is control credibility: auditors often view missing detective controls as a sign that incident detection and response is not reliable. ³

Practical 30/60/90-day execution plan

Days 0–30: Establish coverage and a working alert

• Confirm CloudTrail coverage and CloudWatch Logs delivery across in-scope accounts.
• Pick the deployment model (central vs per-account) and document it.
• Implement the metric filter and a basic alarm with SNS notifications in a pilot account.
• Write a one-page triage runbook and assign ownership.

Days 31–60: Scale and harden

• Roll out via IaC across all in-scope accounts (or centralize with an org trail and central monitoring).
• Add naming standards, tags, and ownership metadata for alarms.
• Add a recurring control check in your GRC workflow (Security Hub mapped control review). ²
• Run a controlled test in multiple representative accounts and keep the evidence.

Days 61–90: Reduce noise and make it audit-proof

• Tune filter patterns based on observed false positives; document exceptions.
• Add drift detection and change control gates so alarms don’t get removed quietly.
• Build an evidence packet template: configuration exports + last test + Security Hub status screenshot/export.
• If you use Daydream, map the requirement to cloud accounts, schedule periodic verification, and attach evidence artifacts to the control record for audits and leadership reporting.

Frequently Asked Questions

Do I need both a metric filter and an alarm, or is one enough?

You need both. The metric filter detects and counts matching CloudTrail events in CloudWatch Logs, and the alarm turns that metric into an actionable notification path.

Can I meet this control if CloudTrail only goes to S3?

Not by itself. CloudWatch Logs metric filters run on CloudWatch Logs log groups, so you need CloudTrail delivered to CloudWatch Logs for this requirement.

Should this be implemented per account or centrally?

Either approach can work operationally. Choose the model that gives complete coverage and consistent evidence, and confirm it aligns with how AWS Security Hub evaluates the mapped control. ²

What’s the minimum evidence an auditor will accept?

Expect to provide the CloudTrail-to-CloudWatch Logs configuration, the metric filter definition, the alarm definition with actions, and proof that notifications reach an owned queue or on-call path.

How do I prevent alert fatigue from normal “AccessDenied” noise?

Start with a baseline filter, then tune with documented exclusions for known benign roles or automation. Keep the exclusions reviewed and controlled, and retain a record of why each was added.

How does AWS Security Hub relate to this requirement?

The CIS requirement is mapped to an AWS Security Hub control, so Security Hub can be used to monitor compliance status and highlight accounts where the metric filter/alarm is missing. ²

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