The ability to provide traceability and automatically react to security events occurring in your workload is vital to maintaining a high security posture within your application. Through the use monitoring key activity metrics, architects are able to detect potentially malicious behaviour at an early stage and respond according to the event. By combining this early detection approach with appropriate alerting, we can create an autonomous feedback loop which ensures that cloud administrators are adequately informed before a serious event takes place.
In AWS you can use AWS CloudTrail to capture all API based activity within an AWS account. However, simply capturing these activities is not be sufficient without the ability to contextualize events and create the mechanism to automatically react in an appropriate manner. The integration of Amazon CloudWatch in combination with CloudTrail and our other services, allows customers to produce adequate alerting and visibility to important system events triggered by a key activity metric.
One such example of a key activity metric would be Key Management Service (KMS) activity. KMS is integral to most secure architecture designs and responsible for autonomous encryption and decryption activity. Whilst we would expect regular activity which is triggered as a byproduct from user interaction with an architecture, significantly high activity could be an early warning signal that the architecture could be subject to data exfiltration by an interested third party or competitor.
In this lab we will walk you through an example scenario of monitoring our KMS service for encryption and decryption activity. We will autonomously detect abormal activity beyond a predefined threshold and respond accordingly, using the following services:
Our lab is divided into several sections as follows:
We have included CloudFormation templates for the first few steps to get your started, and also provide optional templates for the rest of the lab so you can choose between creating the monitoring resources via cloudformation or manually through the console.
Note: For simplicity, we have used Sydney ‘ap-southeast-2’ as the default region for this lab. Please ensure all lab interaction is completed from this region.
NOTE: You will be billed for any applicable AWS resources used if you complete this lab that are not covered in the AWS Free Tier.