Steps to Enable CloudTrail for an AWS Organization

ACM.187 View all your CloudTrail logs for an organization in one place

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Security | Cloud Governance | Cybersecurity

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In my last post I explored some things you will want to consider when creating a backup account to help protect your assets from ransomware.

I mentioned a couple of services in that post that we want to enable. One of those is CloudTrail at the Organization level. An AWS organization trail is beneficial for multiple reasons. You can consolidate the logs in one place and grant your security team access so they can see logs across the entire organization. You can centralize the management of CloudTrail logs to ensure you don’t forget to enable them for any account. We can apply policies and alerts to ensure that the configuration of our logs does not get altered inadvertently.

The instructions for setting up an AWS Organization trail start here but they jump around a bit. I’m going to summarize the steps and considerations in this post. Then I’ll see if we can add the automation to do this to our existing scripts in upcoming posts.

I’ve taken the above documentation and related links and reorganized it a bit to plan out what we need to do to set this up.

Steps to enable CloudTrail for an Organization

Here are the steps to enable CloudTrail at the Organization level.

1. Enable all features for AWS Organizations.
2. Determine if partitions affect you or not (they will if you are using the China region, GovCloud, and check the documentation for any future updates.)
3. Decide if you want to allow a delegated administrator to set up the account, or a user in the root account.
4. Ensure the person creating the trail has sufficient permissions.
5. Decide what name you want to give your trail.
6. Create a KMS Key
7. Create an S3 bucket
8. Create the trail.
9. Set up SNS alerts to know if someone is tampering with CloudTrail.
10. Ensure no one can delete that trail or disable or delete the trail.
11. Manage trails for existing accounts to maintain appropriate logs.
12. Configure data events logging.
13. Monitor CloudTrail logs.
14. Consider the cost and optimize according to budget.
15. Automate

Enable all features for AWS Organizations

In a prior post and in my existing code, I enabled service control policies for our organization. To create an organizational trail we need to enable all features. This is a requirement. You can’t just enable CloudTrail and SCPs or whatever specific organizational features you need, unfortunately. We will follow these instructions to enable all features.

There’s a long list of caveats in the above post.

• Accounts created with AWS Organizations will not have any issues.
• Accounts that were not created by AWS Organizations but rather inited to join your organization will need to accept the request to enable all features. You cannot finish enabling all features until every account in the organization accepts the request. You could remove an account from the Organization to complete the process but that comes with it’s own list of caveats you want to consider. If you have consolidated billing set up, where will that bill go?
• The following role is mandatory in AWS accounts to enable all features: AWSServiceRoleForOrganizations. If you deleted it, you will need to recreate it. Unfortunately, AWS does not provide guidance in the documentation I can find for restoring that role. I presume you could create a new account and copy and create a role that mirrors the AWSServiceRoleForOrganizations if you have deleted it. Note that this role is a separate role from the one administrators in AWS use for cross-account access that I gave a unique name in my scripts in GitHub. I explained all that in a separate posts.

Permissions to set up an AWS Organizations CloudTrail log

The person setting up the trail needs IAM permission to do so. AWS recommends granting AWSCloudTrail_FullAccess and the following policy to work with the AWS Organizations services.

Note that the full access policy includes deleting logs and disabling CloudTrail. We will address that with an SCP after the logs are in place. You may also want to reduce the permissions once the logs are in place, or use a separate role for this purpose than the ones people use on a daily basis. In my case, I’m going to use the OrgRoot user which will not be used after the organization base setup is complete as explained in other posts.

Delegated administrator

As just mentioned, I’m using my OrgRoot user for initial configuration. If I want to set up a delegated administrator, I would need to set up a new account for that and I don’t to add more accounts before some basic security logging and alerting gets set up. I will likely add a delegated administrator later to manage CloudTrail logs from a non-root account. As I keep repeating, your SCPs do not apply to the AWS root account.

If you have an existing account structure where you already have users who are supposed to manage CloudTrail then you might opt to use the delegated administrator option so the users in a different account can manage the organizational trail.

Decide on a name for your trail

I already have an ID for the organization that can be passed into my script. The consideration is whether I want that value to be more protected or visible to anyone who can view the CloudTrail logs. For my initial script I’m going to keep it simple and use that parameter to also name the trail.

Partitions: AWS, GovCloud, China Region

AWS partitions exist for different types of AWS accounts. The three partitions at the time of this writing are for standard AWS accounts, GovCloud accounts, and AWS China accounts.

The ARN format will be different for each of the above because the partition is part of the ARN.

For example:

Most organizations won’t have to worry about partitions but likely US Government and some multi-national organizations will.

If you have multiple partitions, you will need to enable your organizations trail for each partition. By default AWS only creates the organization trail for the aws partition.

Create KMS Key(s) for CloudTrail logs

We will want to create a KMS key for our CloudTrail logs, both to view the logs and for SNS messages. To save money, I’m going to create one key for everything. You might decide you want separate keys for different parts of your organization administered by different people or to limit the blast radius if one of the AWS services is compromised but not another, for example.

Create an S3 bucket for CloudTrail logs

Create our own S3 bucket if setting up an organization trail from the AWS CLI. If you use the console the bucket gets created for you. Although setting up an S3 bucket can be painful to configure correctly, you will have control over the configuration of the bucket.

AWS recommends restricting access to the resources we created for the organization trail to the CloudTrail ARN using a condition in the related policies including S3, KMS and SNS:

"Condition": {
    "StringEquals": {
      "AWS:SourceArn": ["Trail_ARN_1",..., "Trail_ARN_n"]
    }
}

Amazon provides the following S3 bucket policy. Note the restriction to the CloudTrail ARN. Here we have a catch 22. We won’t have the CloudTrail ARN until we create the trail and we need the bucket to store the trail logs.

SNS Alerts

You’re going to want to know if someone changes your CloudTrail configuration. We’ll likely want an alert for that. AWS provides the following policy for SNS alerts.

Prevent disabling or deleting CloudTrail logs

When a trail is created for an organization, AWS creates a service linked role for CloudTrail: AWSServiceRoleForCloudTrail. We need to make sure no one can tamper with that role. In addition, we need to ensure no one can disable or delete our CloudTrail logs. This sounds like a job for a Service Control Policy (SCP). We’ll likely want that policy at the root of our Organization.

Note that removing an account from the organization removes the service linked role, stops the logs, does not delete existing logs.

Maintaining existing CloudTrail logs

You may already have AWS accounts with CloudTrail logs. If you add an organization trail you don’t want to pay double (two trails) but you also might not want to lose any logs. AWS recommends leaving your existing CloudTrail logs running for one day. Then after one day stop the account level logging. You can delete them if you don’t need them.

Configure data event logging

AWS lists the following differences between an Organization Trail and member trails.

* When you create a trail in the console and choose whether to log data events for Amazon S3 buckets or AWS Lambda functions, the only resources listed in the CloudTrail console are those for the management account or delegated administrator account, but you can add the ARNs for resources in member accounts.

* Data events for specified member account resources are logged without having to manually configure cross-account access to those resources.

Monitoring CloudTrail Logs

Once you have enabled your organizational CloudTrail you’ll need to give people access to monitor it. This is a whole separate topic that an entire class might cover so I’ll refer you to the AWS documentation for now on that topic.

Note that some organizations send logs to S3 for analysis which may cost less than CloudWatch. However, then you will need to be able to unzip and parse the logs. You can use Amazon Athena for that.

Other companies opt to send logs to a SIEM such as Splunk where they consolidate all logs to correlate and identify security threats. Microsoft offers a SIEM called Sentinel. AWS relies on third parties for this purpose.

Note that you should perform a proper security assessment on any third-party tools you use for security monitoring, just as you should assess AWS or any cloud provider security if you plan to use it.

Consider the costs

The cost of your CloudTrail logs will vary depending on where you store them and how long.

Sending them to S3 may be cheaper than CloudWatch but then they may be more difficult to access and query.

Some organizations may choose to send them to a SIEM. If you do that consider the cost of sending data out of AWS which incurs a cost, compared to sending data into AWS which is free. This can include sending data to third-party SIEMS. If the SIEM is hosted on AWS you may be able to reduce costs if a PrivateLink connection is an option, but you should test that out and verify it works and costs what you expect before signing up for the service.

If you send logs to S3, consider how long you need to keep them and how often you need to access them. If you only need the logs infrequently or only for archiving purposes for a certain length of time consider creating a life-cycle policy to move the logs to AWS Glacier periodically.

Automate

We’ll try to automate this in upcoming posts.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab