This blog post is the start of a new series of posts. In this series, I will create a brand new AWS account and then use several common tools to identify areas of vulnerability which we will then remediate. We will secure this account prior to the account being used to host any workloads. Everything we create in this account will be to follow recommendations for securing the account. After this series, the next step could be to spin up some sample workloads and see new guidance from the tools we use based on the resources those workloads create.
Although it is best practice to always have a multi-account organization in AWS [1], this series will focus on a single AWS account for simplicity. I previously wrote about my recommendation not to use AWS Control Tower (in its current form) for setting up and managing multiple accounts in an AWS organization. This post comes from my exploration of alternatives to Control Tower. When you have an AWS organization with numerous accounts to manage, you have some additional tools at your disposal that greatly assist in achieving your goals. However, everyone starts their AWS journey with a single account. We need to know how to secure that single account before scaling it to many accounts. For additional tools available in an organization, I am referring to tools like an Organizational CloudTrail, Service Control Policies (SCPs), and IAM Identity Center (the AWS service formerly known as Single-Sign-On or SSO).
The first tool we will start with is AWS’s Trusted Advisor. Let’s start with a brand-new account. I created this account through the standard process any new customer will use and not through an account vending machine [2] process. To create the account, I went to https://aws.amazon.com/ and clicked “Create an AWS Account.” During sign-up, I chose the basic (free) support plan.
After signing up for the new account, we have the root user credentials, which is the email/password provided during setup. While the best practice to never use the root account is commonly known, let’s log in and open AWS Trusted Advisor to see what recommendations it gives us on a brand new account.
When you first open Trusted Advisor in a new account, it is not immediately obvious that many checks have yet to run. Trusted Advisor presents us with its dashboard with zero recommendations across all severity levels. Click on one of the categories to confirm that the checks have yet to run. Security is a good category to pick because some of that category’s checks are available with a basic support plan. After running a check, you will see something like this:
With the timestamp of when it was the last run. If you instead see this, click the refresh icon:
Or even better, at the top of the page, click:
It shouldn’t take long for the checks available for free to complete. As of this writing, with the basic (free) support plan in Trusted Advisor, there are six security checks and 51 service limit checks.
Now that all of the checks are updated, click back to the Trusted Advisor dashboard, and we will see the accurate results:
We now have two items to fix, MFA on Root Account and IAM Use. We will do that now. We will configure MFA on our Root Account using a Virtual MFA application. Then we will create an IAM user with the AdministratorAccess policy attached, log out of the root user and log back in as that user.
Now those two items are solved:
At the bottom of that screenshot, it explains that we need to upgrade our support plan to get the rest of the Trusted Advisor checks. Let’s do that. I have now upgraded the support plan to the business level ($100 a month), as that’s the lowest cost plan to get the “Full set of checks” [3] in Trusted Advisor. Then I refreshed all of the checks again.
Now we have a lot more checks, especially in the security area. In total, we now have the following number of checks in each category:
- Cost Optimization: 22
- Security: 155
- Fault Tolerance: 25
- Performance: 13
- Service Limits: 51 (unchanged)
As of this writing, we have a total of 155 checks in the security category of Trusted Advisor, which is impressive. However, digging a little deeper, I was disappointed to see 134 of those checks have no data because they rely on AWS Security Hub. We still need to set up AWS Security Hub in this account. I have confirmed that if you set up Security Hub but are not paying for at least the business-level support plan, you will not be able to see those 134 Security Hub recommendations in Trusted Advisor. In my opinion, Trusted Advisor should show those 134 checks if you have already configured and are paying for Security Hub (and Config) since Trusted Advisor is just giving you another view of the checks you already have.
Now back to discussing the 15 new security checks available in Trusted Advisor after we upgraded to the business support plan. We now have recommendations on two in our brand-new empty account. They are:
That’s easy enough to solve. Now we will set a password policy for our account in IAM (why this isn’t there by default is beyond me.) and set up a multi-region CloudTrail.
Now let’s refresh the checks in Trusted Advisor, then wait a few minutes. Hmm, now we have two new recommendations:
These are now in the fault tolerance section and say “Investigation” is recommended rather than “Action” is recommended, so a lower severity level. The fault tolerance section now looks like this:
In resolving the previous recommendations, we set up a CloudTrail, which requires an S3 bucket (and CloudTrail created it for us). We can easily enable versioning on that bucket for the second finding here. However, the first finding, “Amazon S3 Bucket Logging”, will be more challenging to solve, which I will explain next.
To resolve this “Amazon S3 Bucket Logging” recommendation for a bucket, you must configure the bucket’s “server access logging” settings to point to another S3 bucket in the same AWS account [4]. This finding gets flagged on every S3 bucket that does not have “server access logging” configured. I cannot imagine it will go well if you enable a bucket to log to itself. This same account requirement means you will still have this finding on your AWS account unless you create an infinite loop of logging within your account (please don’t).
A side note, despite AWS’s documentation recommending against using bucket ACLs to grant the S3 log delivery group access to your logging bucket [4]. AWS Support has confirmed bucket ACLs are the only way to satisfy this check in Trusted Advisor. Since I have confirmed, there is no way we can resolve this recommendation for the entire account. I recommend suppressing this one. However, I will leave it here for the rest of this post. The last thing I would like to say is, in addition to the bucket ACL piece. I also find it ridiculous that setting up a CloudTrail to log S3 Data Events does not satisfy this check in Trusted Advisor.
That brings us to the end of the recommendations Trusted Advisor will provide us on our new AWS account that is not yet running any workloads. Next, let’s move to Security Hub, which requires AWS Config.
I set up AWS Config and enabled Security Hub with all the security standards. As of the time of this writing, that is the following standards:
- AWS Foundational Security Best Practices v1.0.0
- CIS AWS Foundations Benchmark v1.2.0
- CIS AWS Foundations Benchmark v1.4.0
- PCI DSS v3.2.1
Next, we give Security Hub a reasonable amount of time to update. I waited until the following day to resume, but Security Hub’s console says it can take up to two hours. Upon updating, Trusted Advisor now has the following recommendations:
And Security Hub reports the following:
How did AWS decide which checks to bring over to Trusted Advisor? Let’s get started by addressing the recommendations in Trusted Advisor and then we can come back to Security Hub and see what’s left.
In Trusted Advisor, we have three items in Trusted Advisor’s higher priority category of “action recommended,” all three in security. Those are:
These are straightforward. Let’s fix these.
We have now enabled GuardDuty.
Next, the default VPC seems to have a default security group that allows all network traffic from members of that security group to communicate with other members. Usually, I would delete the default VPC, but since Trusted Advisor recommends changes to the default VPC, let’s do that and see where this leads. I’ll remove those inbound and outbound rules from that security group.
Now to resolve the Hardware MFA recommendation. Previously Trusted Advisor told us to enable MFA for the root user, so we set up virtual MFA as most users do. However, now that we have set up Security Hub, we now see a recommendation that more than virtual MFA is needed. Trusted Advisor is now recommending that we configure a Hardware MFA for the root user. Yubikey is the most common for these hardware MFA keys. The great news is that in July 2022, AWS began providing hardware MFA keys for “U.S.-based AWS account root users who have spent more than $100 each month over the past three months” [5]. If that is you, go to https://console.aws.amazon.com/securityhub/home/#/free-mfa-security-key to order your key.
In November 2022, AWS made it so that you can assign multiple MFA devices to your user, including the root user. However, I have confirmed that this check will flag non-compliant if you have any Virtual MFA devices assigned to your root user. So if you previously added a virtual MFA to your root user, you will need to remove it while adding the hardware MFA device. Now let’s give Trusted Advisor some time to refresh the checks.
As we work on remediating these checks that Trusted Advisor is displaying from Security Hub, it is essential to know that the “last updated” timestamp in Trusted Advisor does not necessarily mean when the check was the last run. That timestamp is when Trusted Advisor was last updated, but it’s updating from AWS Config, which may not have checked the resource for several hours. The rule in AWS Config will say that Security Hub created it. To update these in Trusted Advisor, go to AWS Config, find the associated config rule, and then you can force AWS Config to re-evaluate the rule. Once the compliance status in AWS Config is updated, return to Trusted Advisor to refresh the check.
Now our Trusted Advisor Recommendations look like this:
Let’s take a look at those 2 in the fault-tolerance category:
The first is the bucket logging issue we discussed in depth above. The second is that we do not have versioning enabled on the AWS config bucket. I will enable versioning now on that bucket.
Then the 15 in the Security category:
Let’s start working our way through these.
1. Amazon EC2 should be configured to use VPC endpoints that are created for the Amazon EC2 service
Trusted Advisor wants us to add an Amazon EC2 VPC endpoint to the default VPC. Ok, so this is going to start incurring costs. A basic VPC (without a NAT Gateway, endpoints, flow logs, etc.), like the default VPC, does not incur any charges. But VPC endpoints are not free. Oh well, I’ll create it and see where this leads. We now have a VPC endpoint for the EC2 service.
2. AWS Config should be enabled
This check, “PCI.Config.1”, requires AWS Config to record global resources to pass. [6] So in AWS Config, I updated our settings to include global resources.
3. CloudTrail log file validation should be enabled
We have enabled log file validation on our CloudTrail.
4. CloudTrail should have encryption at-rest enabled
We have enabled Log file SSE-KMS encryption on our CloudTrail.
5. CloudTrail trails should be integrated with Amazon CloudWatch Logs
We have configured CloudWatch logs integration from within our CloudTrail.
6. EBS default encryption should be enabled
Configured new EBS volumes to default to being encrypted.
7. EC2 subnets should not automatically assign public IP addresses
In our default VPC, we turned off “Auto-assign public IPv4 address” on all subnets.
8. Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389
On our default VPC’s NACL, we have added deny rules for TCP ports 22 and 3389.
9. S3 Block Public Access setting should be enabled
The two S3 buckets we have at this point already have this setting, but we want to enable “Block Public Access settings for this account” in S3 for the entire account.
10. S3 bucket server access logging should be enabled
We already discussed this earlier in this post.
11. S3 buckets should have event notifications enabled
I do not understand why Trusted Advisor runs this check on all buckets. In my experience, it is rare to need event notifications on buckets. When you need them, you set them up. I recommend suppressing this one.
12. S3 buckets should have server-side encryption enabled
We have now enabled default encryption on the S3 buckets.
13. S3 buckets should require requests to use Secure Socket Layer
We have updated the bucket policy on our two buckets to require SSL.
14. S3 buckets with versioning enabled should have lifecycle policies configured
We have created a lifecycle rule on each of our buckets.
15. VPC flow logging should be enabled in all VPCs
We have created a VPC flow log.
While I was waiting for all of the checks to refresh, two new recommendations came up in Trusted Advisor:
To fix those, we will create a group, attach the AdministratorAccess policy to that group, make our IAM user that we’ve been using a member of that group, and disconnect the policy from being directly attached to our user. A new user is automatically attached to the policy IAMUserChangePassword. We will disconnect that as well. Then we will add MFA to our IAM user.
Now our Trusted Advisor has two recommendations, both at the investigation level. One in the fault tolerance and the other in the security category. However, both are the server access logging item we have already discussed in depth.
We have reached the end of Trusted Advisor giving us recommendations regarding our brand-new AWS account. Trusted Advisor will generate new recommendations if you keep the business or higher support plan as you add workloads to this account. To wrap up this post, let’s look at the remaining items in Security Hub to see what else we may want to do prior to adding workloads.
As you can see, this gives us a good amount of additional items to discuss.
AWS Foundational Security Best Practices v1.0.0:
CIS AWS Foundations Benchmark v1.2.0:
CIS AWS Foundations Benchmark v1.4.0
PCI DSS v3.2.1:
In the next post, we will start resolving the findings that Security Hub is giving us. We can also run Cloud Mapper. What else should we use to scan our account for possible results? Let me know in the comments or via Twitter.
Please let me know if you would like to see me run any other tools against this account to report on Security Issues.
References:
[1] https://aws.amazon.com/organizations/getting-started/best-practices/
[2] https://aws.amazon.com/blogs/mt/automate-account-creation-and-resource-provisioning-for-aws-govcloudus-using-aws-service-catalog-aws-organizations-and-aws-lambda/
[3] https://aws.amazon.com/premiumsupport/plans/
[4] https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html
[5] https://aws.amazon.com/blogs/security/eligible-customers-can-now-order-a-free-mfa-security-key/
[6] https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-pcidss-to-disable.html
Top comments (0)