SNS
Last updated
Last updated
When creating effective Cloudwatch security alarms, it's important to ensure you've created an SNS topic that notifies when an alert is triggered – for example, via email. This means if a CloudWatch alarm event is triggered, you'll get feedback via a channel that you monitor, as you likely won't have the CloudWatch alarms dashboard open at all times). The CIS benchmark for AWS documents this well as it's part of their alarm guidance. However, it's out of scope for the purposes of this lab.
When a CloudWatch alarm is triggered, it doesn't actually give any visibility into what triggered it. For example, take CIS Benchmark 3.2 – Ensure a log metric filter and alarm exist for AWS Management Console sign-in without MFA. The metric filter for this event to trigger an alarm is the following:
This triggers the alarm, but the alarm has no understanding of which user actually triggered it. it only knows that a log event has appeared that matches the metric filter.
A mature organization would likely send all of its CloudTrail logs to a central SIEM to be processed (such as Splunk). If an alert was triggered in this scenario, you'd use Splunk to search the logs, investigate what caused the event, work out whether the event needs to be escalated, and determine if triage is required.
Now to Create the following metric filter using the Metrolio-LG log group.
Filter pattern: { ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") && ($.userIdentity.type = "IAMUser") && ($.responseElements.ConsoleLogin = "Success") }
Filter name: CIS-NO-MFA-FILTER
Namespace: Enter LogMetrics for the namespace
Metric name: CIS-NO-MFA-METRIC
Metric value: 1
Leave the other settings as default.
Now to Create an alarm based on the metric filter in Part 1 above that meets the following criteria:
In the Metric section, leave the default values
Under Conditions, for Threshold, choose Static
For Define the alarm condition, choose Greater/Equal
For Define the threshold value, enter 1
Ensure you remove the Alarm Trigger state
Set a name of CIS-NO-MFA-ALARM
Now to create an alarm based on CIS Benchmark 3.6 – Ensure a log metric filter and alarm exist for AWS Management Console authentication failures
Create the following metric filter using the Metrolio-LG log group.
Filter pattern: {($.eventName=ConsoleLogin) && ($.errorMessage="Failed authentication")}
Filter name: CIS-CONSOLE-AUTH-FAILURE-FILTER
Namespace: Enter LogMetrics for the namespace
Metric name: CIS-CONSOLE-AUTH-FAILURE-METRIC
Metric value: 1
Leave the other settings as default.
Create an alarm based on the metric filter in Part 1 above that meets the following criteria:
In the Metric section, leave the default values
Under Conditions, for Threshold, choose Static
For Define the alarm condition, choose Greater/Equal
For Define the threshold value, enter 1
Ensure you remove the Alarm Trigger state
Set a name of CIS-CONSOLE-AUTH-FAILURE-ALARM
Leave the other settings as default.
Now create an alarm based on CIS Benchmark 3.8 – Ensure a log metric filter and alarm exist for S3 bucket policy changes
An IAM user will shortly log in to the AWS console a number of times with MFA disabled. Using the Log Events page in the Metrolio-LG log group and the MFA failure filter pattern, what is name of the IAM user?
A number of IAM user login failures will shortly occur for the same IAM user. Using the Log Events page in the Metrolio-LG log group and the filter pattern for login failure, what is name of the IAM user that these failures relate to?
An S3 bucket policy will shortly change and trigger the alarm. Using the Log Events page in the Metrolio-LG log group and the Bucket Policy Changed filter pattern, what is the name of the IAM user who changed the S3 bucket policy on the bucket with the prefix metrolio-sensitive-data-*
