Ensure a log metric filter and alarm exist for unauthorized API calls

Perform the following to setup the metric filter, alarm, SNS topic, and subscription:

1. Create a metric filter based on filter pattern provided which checks for unauthorized API calls and the <cloudtrail_log_group_name> taken from audit step 1.

aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --filter-name `<unauthorized_api_calls_metric>` --metric-transformations metricName=`<unauthorized_api_calls_metric>`,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.errorCode = "*UnauthorizedOperation") || ($.errorCode = "AccessDenied*") }'

Note You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together.

1. Create an SNS topic that the alarm will notify

aws sns create-topic --name <sns_topic_name>

Note you can execute this command once and then re-use the same topic for all monitoring alarms.

1. Create an SNS subscription to the topic created in step 2

aws sns subscribe --topic-arn <sns_topic_arn> --protocol <protocol_for_sns> --notification-endpoint <sns_subscription_endpoints>

Note you can execute this command once and then re-use the SNS subscription for all monitoring alarms.

1. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2

aws cloudwatch put-metric-alarm --alarm-name `<unauthorized_api_calls_alarm>` --metric-name `<unauthorized_api_calls_metric>` --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions <sns_topic_arn>

Impact

This alert may be triggered by normal read-only console activities that attempt to opportunistically gather optional information, but gracefully fail if they don't have permissions.

If an excessive number of alerts are being generated then an organization may wish to consider adding read access to the limited IAM user permissions simply to quiet the alerts.

In some cases doing this may allow the users to actually view some areas of the system - any additional access given should be reviewed for alignment with the original limited IAM user intent.

References

1. https://aws.amazon.com/sns/
2. CCE-79186-3
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html
4. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html
5. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html

Notes

Configuring log metric filter and alarm on Multi-region (global) CloudTrail

• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored

Service-wide remediation

Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.

AWS

Use AWS Organizations guardrails, AWS Config rules or conformance packs where they fit, approved account baselines, and IaC modules so new resources inherit the secure setting.

Operational rollout

1. Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
2. Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
3. Re-scan and track approved exceptions with an owner and expiry date.