You’ve got your platform launched, you’ve had your pen tests done and everything is ticking over nicely but how do you know what’s going on within your environment?
Moving to the public cloud can bring significant benefits to your platform’s performance, reliability and cost-effectiveness but it is important to be careful that this doesn’t come at a cost to security.
The only way to be able to effectively monitor security within a cloud environment is by automation of event triggers and reporting. All of the public clouds offer a wide range of tools to analyse and implement the best security practices around your cloud estate. Security is a very wide-ranging function and in this article, we’re drilling down on monitoring for security incidents in your environment within AWS but, the same principles and functionality also exist in Azure and Google Cloud.
Monitoring for changes in your environment
AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. CloudTrail records important information about each action, including who made the request, the services used, the actions performed, parameters for the actions, and the response elements returned by the AWS service.
You can view your CloudTrail logs through the console, It’s turned on at the basic level by default on all accounts and goes back 90 days. The free version is limited to management events with ‘create’, ‘modify’ and ‘delete’ API calls and account activity. Deeper level analysis and triggers can be created by configuring your own CloudTrail trails. The trails you create are done at the account level so regardless of how many regions your platform runs across you can run security at the account level. This also ties into user account changes through IAM, so you can be notified of people being granted permissions or changing security groups.
Finding out what has changed
So AWS CloudTrail logs user and API activity on your account and assets, and allows you to access information about this activity but, what was the outcome of the action?
This comes from AWS Config which records point-in-time configuration details for your AWS resources as Configuration Items (CIs).
A Configuration Item is a record of the current configuration of an AWS resource, when a change is made then a new copy of the CI is made and the previous record is left in an audit trail over time so that you can see a full history of that item.
You can use a CI to answer “What did my AWS resource look like?” at a point in time and you can then use AWS CloudTrail to answer “Who made an API call to modify this resource?”
As an example, you can use a combination of CloudTrail and Config to show that the IAM user “Joe Blogs” modified the security group “Prod-DB” was changed to add direct SQL access from his home IP address.
Extending this auditing capability using AWS Lambda
AWS config rules can either be the managed set provided by AWS to cover most of the functions you would require within a well-run environment or can be custom rules running bespoke AWS Lambda functions. A great real-world example of how powerful these custom Lambda rules can be is by the Financial Times where they run functions on item changes to ensure that resources still adhere to their specific tagging policy for cost attribution and security. If the CI does not adhere to it then a series of emails is triggered which will eventually terminate or reconfigure the resource if no action is taken.
There are several ways of ensuring your environment is being maintained correctly and is not slipping out of agreed bounds. The tools are there, including integration with third-party apps and services like Splunk, ServiceNow, and CloudCheckr to help you visualise what’s going on for compliance, audit and control. Our AWS certified professional team is available to help you identify how AWS CloudTrail and AWS Config can be used with great effect within your environment and to make sure you know exactly when key changes are made and who made them.