CIS AWS Foundations v1.2 3.11: Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)

CIS AWS Foundations v1.2 3.11 requires you to detect and alert on any changes to Network Access Control Lists (NACLs) by creating a CloudWatch Logs metric filter on CloudTrail events and a CloudWatch alarm that notifies responders. Operationally, that means: CloudTrail must be logging, the log group must have a metric filter for NACL API calls, and the alarm must route to an owned response channel. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Key takeaways:

• Implement a CloudWatch Logs metric filter on CloudTrail logs for NACL change API events, then alarm on matches. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)
• Make the alarm actionable: route to SNS with an on-call owner, a runbook, and triage expectations. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)
• Retain evidence that proves the control exists and works: filter pattern, alarm config, notification path, and test results. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

The target keyword for this page is cis aws foundations v1.2 3.11: ensure a log metric filter and alarm exist for changes to network access control lists (nacl) requirement. This CIS AWS Foundations requirement is a detective control: it does not prevent changes to NACLs, it ensures you will know when they happen and can respond fast.

NACL changes are high-signal events because NACLs can open or block entire subnet traffic flows. A single inbound allow rule on a public subnet can expose workloads even if security groups are well managed, and a single deny rule can cause an outage that looks like an application failure. The control therefore focuses on: (1) collecting the right audit trail (CloudTrail), (2) turning specific NACL change events into measurable signals (CloudWatch Logs metric filters), and (3) generating an alert that reaches humans or automation (CloudWatch alarms + SNS).

AWS Security Hub maps this requirement to its CIS control set (notably, the mapped control identifier in the provided data is CloudWatch.11), which is how many compliance teams track pass/fail across accounts. Your job as CCO/GRC lead is to make this “exists in AWS” and “works in production” with clean evidence. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Regulatory text

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

Operator interpretation: You must implement the CIS AWS Foundations v1.2 control that detects changes to Network Access Control Lists by creating:

1. a CloudWatch Logs metric filter that matches CloudTrail log events for NACL changes, and
2. a CloudWatch alarm that fires when the metric indicates a NACL change.
   Track and validate it the way AWS Security Hub evaluates the benchmark mapping. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Plain-English interpretation (what the requirement really wants)

• You are expected to notice NACL changes quickly.
• “Log metric filter” means you convert specific CloudTrail events into a CloudWatch metric that increments when a matching event appears.
• “Alarm” means you set a threshold (often “>= 1 within an evaluation window”) and notify a channel that someone monitors.
• The requirement is about NACL change events, not every VPC event and not data-plane flow logs.

Who it applies to

Entity scope

• Any organization operating AWS accounts where VPCs and NACLs exist, including production, staging, and shared services accounts. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Operational scope (where teams get tripped up)

• Multi-account AWS Organizations: you need consistent implementation across accounts, or a centrally managed pattern that still produces alarms per account/region.
• Multi-region: NACLs are regional. If CloudTrail is not capturing events in a region where NACLs exist, you have a blind spot.
• Shared networking models: central network teams often change NACLs. Your alerting and runbook must reflect that ownership reality.

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

Below is an implementation sequence that auditors can follow and operators can run.

Step 1: Confirm CloudTrail is capturing NACL management events

1. Verify at least one CloudTrail trail is enabled to log management events.
2. Ensure logs are delivered to a CloudWatch Logs log group (or establish a pipeline that lands CloudTrail into CloudWatch Logs if you currently only write to S3).
3. Confirm the trail covers all in-scope regions (or that your organizational logging strategy covers them in an equivalent, documented manner).

Evidence outcome: You can point to the trail configuration and the CloudWatch Logs log group receiving CloudTrail events. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Step 2: Create a CloudWatch Logs metric filter for NACL changes

1. Identify the CloudWatch Logs log group that receives CloudTrail events.
2. Create a metric filter that matches NACL change API calls in CloudTrail. In practice, teams typically match on eventSource and eventName fields for EC2/VPC APIs related to network ACLs (for example, create/delete/replace entry; associate/disassociate; create/delete NACL).
3. Configure the metric transformation:
   • Metric namespace: pick a consistent namespace (example: CIS/AWS or your internal security namespace).
   • Metric name: something explicit like NACLChangeCount.
   • Metric value: 1 per match.

Operator note: Keep the filter focused. Over-broad patterns create alert fatigue; under-broad patterns miss real changes. Document which API actions you include and why. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Step 3: Create a CloudWatch alarm on the metric

1. Create a CloudWatch alarm for the metric emitted by the filter.
2. Set the alarm to trigger when the metric is >= 1 during the evaluation window you choose (choose a window that fits your SOC/on-call reality).
3. Configure alarm actions:
   • Send to an SNS topic owned by security operations or the network/security team.
   • If you use ChatOps or paging, route SNS into that tool using your standard integration.
4. Add alarm description text that includes:
   • Why the alarm exists (CIS 3.11 NACL changes),
   • Immediate triage steps,
   • Link/reference to the runbook (don’t rely on tribal knowledge).

Operational goal: the alarm must reach a human (or automation) that will take action, not a dead mailbox. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Step 4: Add a runbook and triage expectations

Minimum runbook steps your responders need:

• Identify the who/what/when from the triggering CloudTrail event (principal, time, source IP, API action, request parameters).
• Validate whether the change was authorized (ticket/change record, approved pipeline, planned maintenance).
• Assess impact:
  • Which subnet(s) the NACL applies to,
  • Whether the rule change opens inbound/outbound traffic broadly,
  • Whether it blocks required flows.
• Containment options:
  • Revert to last known-good NACL entries,
  • Temporarily disassociate the NACL from the subnet if that is part of your design (where feasible),
  • Escalate if the change is suspicious.

Tie the runbook to your incident process (severity definitions, paging, escalation). This is where many “checkbox” implementations fail in real audits.

Step 5: Validate the control with a test (and keep the proof)

Run a controlled test in a non-production account (or a maintenance window):

• Make a benign NACL change (for example, add then remove a temporary rule).
• Confirm:
  • The CloudTrail event appears in the log group,
  • The metric increments,
  • The alarm triggers,
  • The notification reaches the intended channel,
  • The runbook is usable.

Capture screenshots/exports and keep them with your control evidence package.

Step 6: Operationalize across accounts (repeatable deployment)

For serious operators, make this reproducible:

• Use infrastructure-as-code to deploy metric filters and alarms.
• Standardize naming, tagging, and alarm routing.
• Centralize evidence collection (see next section).

If you manage benchmark performance through AWS Security Hub, verify that the mapped control reads as passing after deployment. (AWS Security Hub CIS AWS Foundations mapping table)

Required evidence and artifacts to retain

Keep evidence that proves both design (it exists) and operation (it works).

Configuration evidence

• CloudTrail trail settings showing management event logging and destination to CloudWatch Logs. (CIS AWS Foundations Benchmark)
• CloudWatch Logs metric filter:
  • Filter name
  • Filter pattern
  • Target log group
  • Metric namespace/name/value mapping
• CloudWatch alarm configuration:
  • Metric reference
  • Threshold/evaluation settings
  • Alarm actions (SNS topic)
  • Alarm description/runbook reference

Operational evidence

• SNS topic subscription list (who receives the alert).
• One successful test record:
  • CloudTrail event excerpt (redact as needed)
  • Metric graph showing increment
  • Alarm state change history
  • Notification receipt (ticket, pager event, chat message)

Governance evidence

• Control narrative (1 page): purpose, scope, owners, and how often you review it.
• Exception record if an account/region is out of scope, with rationale and compensating control.

Common exam/audit questions and hangups

1. “Show me the exact events you alert on.” Be ready to explain which eventName values you match and why they are sufficient for NACL changes.
2. “How do you know the alarm reaches a responder?” Auditors will ask for SNS subscriptions and incident/ticket evidence.
3. “Does this cover all accounts/regions?” Have an inventory view (Security Hub, config management, or Daydream reporting) that shows coverage.
4. “What happens after the alert?” A runbook and an example triage record turn this from a technical control into an operational control.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
CloudTrail exists but does not send to CloudWatch Logs	Metric filters only work on log groups	Ensure CloudTrail delivery to a CloudWatch Logs log group (or adjust your architecture to support metric filters)
Filter pattern is too broad (matches unrelated EC2 API calls)	Alert fatigue, responders ignore	Narrow to NACL-related API actions; document the included actions
Alarm sends to an SNS topic with no real subscribers	“Alarm exists” but nobody sees it	Make subscriptions part of go-live and review them during access recertifications
Alarm has no runbook or owner	Findings linger and audits fail on “operational effectiveness”	Assign an owner, add on-call routing, and require ticketing for each alert
Only deployed in one region/account	Partial coverage is treated as noncompliance	Deploy via IaC and validate centrally (AWS Security Hub CIS AWS Foundations mapping table)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS AWS Foundations requirement, so you should treat this as a security baseline expectation rather than a directly penalized regulatory obligation. The practical risk is straightforward: unauthorized or mistaken NACL changes can create exposure or outages, and without alerting you may not detect the change until external symptoms appear. (CIS AWS Foundations Benchmark)

Practical 30/60/90-day execution plan

First 30 days (foundation and design)

• Confirm CloudTrail coverage and CloudWatch Logs destinations for in-scope accounts.
• Define your standard filter pattern for NACL change events and document it.
• Decide alarm routing (SNS topics per account, central topic, or both) and name/ tagging standards.
• Write the runbook and assign a primary owner (security ops or network security).

By 60 days (deployment and validation)

• Deploy metric filters and alarms across accounts using your standard change process.
• Test in at least one non-production environment and one production-like environment.
• Onboard the alert into ticketing/on-call, including escalation rules.
• Verify pass status where you track CIS alignment (often AWS Security Hub). (AWS Security Hub CIS AWS Foundations mapping table)

By 90 days (operational maturity)

• Add periodic verification: confirm alarms are enabled, SNS subscriptions are valid, and patterns still match current CloudTrail schemas.
• Create an evidence bundle template so every audit cycle is a pull, not a scramble.
• If you use Daydream for control mapping and evidence collection, connect the control to automated checks and store test artifacts alongside configuration snapshots for cleaner audits. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Frequently Asked Questions

Do I need VPC Flow Logs for CIS 3.11?

No. This requirement is about detecting configuration changes to NACLs via CloudTrail-derived metrics and alarms. Flow logs can help investigations, but they do not satisfy the “metric filter and alarm” requirement. (CIS AWS Foundations Benchmark)

Can I send CloudTrail only to S3 and still comply?

The requirement calls for a CloudWatch Logs metric filter, which operates on a CloudWatch Logs log group. If you only write to S3, you need an architecture that also gets CloudTrail events into CloudWatch Logs (or an equivalent approach that still meets the mapped expectation in your compliance program). (AWS Security Hub CIS AWS Foundations mapping table)

What NACL actions should the metric filter include?

Include the API actions that create, delete, associate, disassociate, or modify NACL entries. Document your selected eventName list and review it when AWS adds or changes relevant APIs so the control remains effective. (CIS AWS Foundations Benchmark)

Who should own the alarm: networking or security?

Assign ownership to the team that can validate intent quickly and revert safely. In many orgs, security owns detection and triage while networking owns approved change implementation, but the SNS routing can notify both. Keep a single accountable owner in the control record.

How do we prove the alarm “works” to an auditor?

Keep one controlled test record with the CloudTrail event, metric increment, alarm history, and the resulting ticket/page. Pair it with current screenshots/exports of the filter and alarm configuration. (CIS AWS Foundations Benchmark)

Does AWS Security Hub automatically create these alarms?

Security Hub reports findings against the CIS mapping, but it does not automatically implement your metric filters and alarms. Treat Security Hub as validation/reporting, then deploy the underlying CloudWatch components yourself. (AWS Security Hub CIS AWS Foundations mapping table)