Amongst all security services that AWS offers in its cloud environment, AWS Config is one of the most remarkable ones. It enables us to asses, audit and evaluate the configuration of AWS resources, automating the evaluation and response against desired or undesired changes in the configurations.
If we want to implement and use this service as part of our automation security plan in the cloud, we must start by understanding WHAT parts it is formed by and which role they play within the service:
- –Resources: every AWS entity we can work with (WAF rules, IAM Roles, Security Groups, Subnets, S3 Buckets, RDS clusters….).
- –Rules: Lambda functions that you create yourself (custom rule) or that is created by default (managed rule) that evaluates the configuration of an AWS resource in comparison with the desired state of it and assess whether it is compliant or non-compliant with it.
- –Aggregator: multi-account & multi-region data collector for AWS Config. It allows us to centralize the configuration changes of multiple resources in a big multi-account organization into a single place, making it much easier to control and remediate possible failures and security breaches.
To illustrate this service before continuing to the next section I will describe a typical usage example; do not worry if you feel it is too much, in the last section of this article we will explain another use case step by step: Use an AWS predefined rule that checks if a S3 bucket is public and link it with a S3 bucket we own and we never want to be public. The rule also makes the bucket private as soon as it goes public (could be accidentally or intentionally caused by an attack to leak information). In the beginning, and supposing the bucket is private, the rule will check it and will announce it is ok (COMPLIANT). If we manually change the bucket resource policy and make it public, the rule will automatically detect it and turn into NON-COMPLIANT. It will automatically make the bucket private again and turn into COMPLIANT, while saving this changes in a configuration timeline.
Now that we have a first impression of what AWS Config is and some basic characteristics, we are going to dive into more advanced features to really understand WHY we should use it:
- -Comprehensive and intuitive dashboard (also if using the aggregator for multi-account®ion strategy). In the blink of an eye we are able to see how many resources we manage, which rules are compliant and which not besides getting further information and remediation actions by just clicking on each non-compliant rule.
- -Configuration and compliance timeline allowing us to see in a very graphic and direct way, for every resource that is being checked with our rules, a full history of changes since the first moment AWS Config was activated and checked the resource until now. We can see exactly when a change was produced in some resource configuration and by whom, as well as if it has been automatically remediated or we must do it manually. This is one of the most powerful features of this service, as this kind of granularity and observability would be very hard to get with normal security automation services.
- -As mentioned before, rules are nothing but Lambda functions. When adding a new rule, we can choose between using a AWS Managed rule or creating our own. What does it mean? It means that, by knowing how to build Lambda functions, we can automate the detection and remediation of absolutely any resource we have in AWS. However, for the most common checks (security groups, key rotation policies…) AWS already has some predefined rules we can use with no additional cost.
Here a useful link to the github section of the AWS community regarding custom rules:
We can even use predefined set of rules called ‘Conformance packs’ to allow us comply with AWS operational best practises and security standards (S3, CIS, NIST CSF, PCI DSS…).
- -AWS Config rules across all accounts in your organization: this is something really important and useful about this service but, for my surprise, it is only available from the API.
For security reasons, it allows the person in charge of the security of your AWS Organization set up AWS Config rules in the root account, being deployed automatically in the child accounts. No other users than the creator can modify or delete this rules, making centralization of security much easier to handle.
- -When talking about a native AWS service, it is expected that the integration with other services would be as easy as it can get. In this case, AWS Config can be easily integrated with CloudTrail (logging) and CloudWatch Events (monitoring) to increase its automation power. As seen in the picture, AWS Config can trigger an event rule if some compliant change takes place (we can configure it as granular as we wish) and then trigger one of the many services linked to CloudWatch Events (SNS, lambda, SSM, SQS, EC2…). The possibilities are just endless.
In the third and last section of this article and after all the reading, it is time to show you HOW we can implement an AWS Config managed rule (restricted ssh port in security groups) and how it will react to a change of state step by step:
1- First of all we go to the AWS Config console and, if it is the first time that you do it, you have to perform a basic configuration before starting to add rules (which resources you want to monitor, the S3 bucket where the history will be stored, if you want to connect it with an SNS topic and a role to perform all the actions required). For this demo, I will leave it all as default.
2- After clicking ‘Next’, we will search ssh and select ‘restricted-ssh’. Click on ‘Next’ and ‘Confirm’. This will setup a rule that checks all the security groups in our account and tells us if ssh connection are restricted (COMPLIANT) or non-restricted (NON-COMPLIANT).
3- After one minute, the rule has already been evaluated and we get the result: in my case, ssh access is restricted in all security groups and i get a COMPLIANT status.
4- I am going to create a new Security Group called ‘ConfigTrial’ that allows ssh from everywhere (0.0.0.0/0) and re-evaluate the rule we just created. By doing this, the rule turns into ‘NON-COMPLIANT’ due to this newly created resource.
5- Once this happened, we have two options: we can create a CloudWatch Event to react to this change of compliance that triggers a lambda function to close the ssh port (totally automatic) or do it manually. For the purpose of this demo we are going to do it manually, as we just want to show how AWS Config works, but best practise would always be automating. I will now restrict the inbound ssh access of that security group to only my IP and re-evaluate the rule again.
After a couple minutes, we can see that it worked as expected and we can se when the changes took effect under the compliance timeline of the selected resource.
As mentioned before, this is just a tiny example of the huge range of possibilities that you can do with AWS Config.
Now it is your time to get some hands-on experience with this awesome service of AWS, discover all its possibilities and make your cloud infrastructure as secure as possible.