Follow best practices with AWS Config and Security Hub
31 May 2023
Configuring the cloud environment is not an easy task. Despite a lot of effort being taken away from ops engineers, it still takes a lot to ensure that our systems are configured correctly, and more important, securely. Today, let me introduce you to AWS Config and AWS Security Hub.
What is AWS Config?
AWS Config is a service that allows you to track changes to your AWS resources and apply rules that will filter our configurations that are not in line with your policies. It's not a tool to enforce policies, but rather to track which ones are broken.
Security Hub is an extension to AWS Config that contains predefined best practices in terms of security. It has a separate dashboard but uses Config under the hood. However, it can also receive findings from other services such as AWS GuardDuty or Macie. It can also emit CloudWatch Events that can be chained further with for example Lambda to automatically fix the issue.
A badly configured environment
I will create some new AWS resources that are not configured correctly. Let's start by adding access keys to the root user. It's one of the worst practices as root user should only be used for emergencies so CLI access shouldn't be needed.
Next, I will create an EC2 instance with security group that allows SSH and MySQL traffic from anywhere. You should restrict who can access your SSH and database ports.
I will also create a MariaDB RDS instance with allowed public access and the same security groups that allow anyone to connect.
Activating AWS Config and Security Hub
In order to check our account for compliance, we need to activate AWS Config and
one or more of the Security Hub standards. First, let's search for
the search bar and activate using
1-Click button. Config is bound to AWS
Next, we need to activate Security Hub. We can do it by searching for
Security Hub. In this example I will use
CIS Foundations Benchmark 1.2.
Security Hub is also bound to AWS region.
Checking for compliance
Both dashboards show what rules and resources are compliant and which are not.
However, Security Hub might take up to 24 hours to show the score. However, it
might already show something in
Findings tab. By searching for
severity, it seems that the fact that root has access keys is already visible.
Let's delete the access key and see if it will be marked as compliant. We can follow the rule from Security Hub to be shown in AWS Config. From there we can see how often it is evaluated. For root access keys it is 12 hours. However, there's an option to trigger it manually.
Let's go back to Security Hub and see if it's compliant now. In
Security standards search for
IAM.4. It still shows
No Data. But let's
click inside the rule.
Inside the rule we can clearly see that the status is
RESOLVED. So the
re-evaluation of the Config rule worked! In each of the controls in Security Hub
there's also a link in the description that will take you to AWS page with
instructions how to fix the issue.
To see the big picture, we have to wait around 24 hours or manually trigger and review the rules.
The following day
Now we clearly see our security score and we know what should be fixed. Some of the changes are trivial, for example password requirements for IAM users. Some are more tricky like disabling public access to your SQL database. If your application is configured to use such connection it would require rework and downtime to adapt to the new network configuration.
The selected security standard does not take into account all the best practices but it is a good start. We can go through the list of found issues and fix them one by one.
Fixing some of the found issues
We will go through some of the issues, particularly critical and high severity, and some others that are easy to fix.
The only critical problem that was found was existence of root access key (fixed in previous paragraph) and lack of hardware MFA for root user. For the latter it requires a device such as Yubikey or Passkey capable device (such as iPhone). Afterwards you have to remove all the virtual MFA methods (but before you do this, log out and try signing in again using the new security key).
This one should be trivial to solve. Search for
"what is my ip" in Google from
multiple places (home, office, etc.) or search for geo IP databases. Based on
the collected knowledge, add your subnets to the security group. For example if
your IP is
184.108.40.206, change this to
way you should not be locked out of SSH. But remember that you can always edit
the security group via console or CLI. However, the best approach would be to
AWS Client VPN
(OpenVPN compatible) or implement
Default security group
Open your EC2 dashboard and click on
Security Groups on the left. Look for
security group named
default. Remove all inbound and outbound rules from it.
When starting a new EC2, RDS or anything that uses security groups, always pick
one that you created.
Go to CloudTrail and click
Create trail. If this is first one, it will create
a multi-region trail with default settings.
Next open it, click
Edit, scroll down and enable
Log file validation.
IAM password policies
This one is trivial. Go to IAM, click on
Account settings on the left and edit
the password policy. Set minimum length to more than 14, select all the password
requirements, expire it every 90 days or less and remember last 24.
After another day, the score should go up. Here we see increase from 27% to 47%.
There are just examples of best practices. Once you complete or almost complete
Foundations 1.2, you can enable more standards such as
AWS Foundational Security Best Practices 1.0. But these are only about
security. You can also browse some other AWS best practices in Config. Open your
Config console, select
Conformance packs and
Deploy conformance pack. There
you can find both best security practices for individual services but also
For example I deployed Operational best practices for S3. It also shows score on
how much practices you have implemented in your account. By clicking
can see exactly which rules are not compliant and what has to be changed.