I wanted to jot down some of my thoughts on creating an enterprise security account for managing AWS. I had one of these created at work and it’s proven invaluable in managing our rapidly expanding cloud footprint.
What is a dedicated security account? For us it serves several purposes:
- It allows us to assume a least-privilege audit role into all of our other AWS accounts
- It serves as a log destination for our CloudTrail events.
- We use it as a central management point for GuardDuty
- We use a slightly more powerful role (but still least-privilege) to deploy our security tools and automations into the other accounts
- It runs a series of lambda/state machines which gather inventory data and stores it in S3 for later ingestion into our SIEM.
Lets dive a bit deeper into each one of this.
The least privilege audit role allows our SOC the ability to investigate events that occur at the cloud layer and allows me and the Vulnerability Management team the ability to hunt and investigate common and uncommon misconfiguration at the cloud-layer. It consists of the SecurityAuditRole, the AWS Managed ReadOnly role, plus the ability to open support tickets, generate the IAM Credential report, and managed TrustedAdvisor settings. In accounts where sensitive data is stored we remove the various GetObject permissions (via an explicit deny).
This audit role is also leveraged by all of our security tooling that gathers vulnerability & compliance data.
For CloudTrail, we have a CloudFormation Template we require to be deployed in all AWS accounts. That template creates a consistent CloudTrail that can both push events into the local CloudWatchLogs and into a S3 Bucket in the security account. We enable MFA Delete and use a physical token for the security account giving us a segregation of duties for the alteration of logfiles.
All our CloudTrail events are ingested from S3 into our SEIM, where we implement queries based on the CIS Benchmark recommendations and experiences from the past.
AWS natively supports managing GuardDuty from a single account and we use the security account to do that. We have CloudWatch Events and a Lambda running in each region that pushes the all the GuardDuty events into our SEIM.
Both the CloudTrail and the GuardDuty are enabled automatically. Every 30 minutes we check our payer accounts for new AWS accounts. If one is created we leverage an admin role which will deploy CloudTrail and execute a script that enables GuardDuty in all regions, then invites the collector into the Security master, and does an assume-role to accept the invitation.
Finally, we use the Audit role to execute our inventory and compliance process. This gathers up all the data on all our resources annotates it with the account and region, and pushes it to S3. This data is also ingested into our SEIM so we can search for a public IP address or a series of resource tags against all our 200+ accounts in whatever region they might be in.
The Audit and Admin Roles and the CloudTrail are deployed via a standardized cloudformation template. We leverage a script to enable, invite and accept GuardDuty. Additional templates are used to deploy our AD Identity provider and roles, along with cross-account access for our financial compliance tools.