Tracking and Notifying on AWS Sign-in activities

#devsecops #aws #stepfunctions #security

It is critical to prevent root user access from getting into the wrong hands and to be aware whenever root user activity occurs in your AWS account. Here are some of the key recommendations include:

Avoid using Root account.
All IAM users including Root account must be enabled multi factor authentication (MFA)
Abnormal activities (many failed sign-in attempts, ...) must be detected and notified

However, there are certain actions that can only be performed by the root user. To be certain that all root user activity is authorized and expected, it is important to monitor root API calls to a given AWS account and to notify when this type of activity is detected. This notification gives you the ability to take any necessary steps when an illegitimate root API activity is detected or it can simply be used as a record for any future auditing needs

In order to to comply best practices above, this post I walk through a solution that tracks and notifies on root user activities and abnormal sign-in activities for an AWS account.

Requirements

Tracking all sign-in and related activities
Be notified/alerted whenever Root account sign-in
Be notified/alerted whenever an IAM user sign-in without MFA
Be notified/alerted if the number of failed sign-in of an IAM user greater than 3 in the last hour

Prerequisites

Create and enable a multi-region AWS CloudTrail trail for all AWS regions

Solution

The picture below shows a high-level architecture of the solution

IAM users and/or Root account sign-in to either Web Console or Mobile Console
That sign-in activity is captured and tracked by Cloud Trail
A Cloud Trail event is sent to Event Bridge automatically
Event Bridge triggers a state machine in Step Function
The state machine process the event and send a message SNS topic if needed
SNS with a Lambda function subscribed to the topic will send appropriate notifications Slack

Here are details of the state machine - the main part of the solution

At the first step in the above state machine, the activity is stored in a DynamoDB table. The reason for storing is that we will need historical data of a user for other purposes such as security audits in the future, investigating security issues, etc. We also need it for a later step in the state machine (Count failed sign-in attempt) to determine an alert should be sent or not.

The DynamoDB table is designed (hash key, partition key, indexes, etc.) to store not only sign-in activities but also other kinds of activities. This will help us easily to extend the solution in the future.

At the last steps of the state machine, send alert steps, SNS publish tasks are used instead of Lambda tasks is because we don't want to duplicate sending alert code. A centralized Lambda function that is subscribed to SNS topic will do sending messages to Slack via an incoming webhook.