Moving to public cloud can bring significant benefits to your platforms 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 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 exists in Azure and Google Cloud.
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 in to user account changes through IAM, so you can be notified of people being granted permissions or changing security groups.
So AWS CloudTrail to 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?” So, 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.
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 time 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, CloudCheckr to help you visualise whats going on for compliance, audit and control. Digital Craftsmen can help you identify how AWS CloudTrail and AWS Config can be used with great effect within your environment to help ensure that you know exactly when key changes are made and who made them. We have a number of AWS certified professionals on our team ready to help.