Chris Farris

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.

Public Cloud introduced a new concept that not everyone fully grasps. In the on-prem days of old, you had a room & you had connections going into said room. Hopefully those connections had a firewall. Then there were lots of things in that room that authorized users needed to access to accomplish whatever goal your business has, and a bunch of other things in that room that the techies needed to access in order to keep those first things running and secure.

I’m spending more time thinking about Cloud Security in Google and Azure and trying to grok the differences between those platforms and AWS. One of the critical components for understanding your enterprise security stance is what is the source of authority for creating & managing resources in the cloud. As I was thinking about this, I realized that the three main players have very different models. Each model reflects on that companies pre-cloud origins.

Since returning to Turner, I’ve been implementing a lot more tools in Lambda, DynamoDB and Step Functions which has been a somewhat new experience. In many cases I need to execute a function 100+ times. Step Functions doesn’t offer a method of fanning out N number of times with a different event for each step. There are two methods I’ve used to solve this issue. 99 Bottles of Beer The 99 Bottles model leverages Step Functions.

Security best practices typically call for some form of multi-factor authentication when accessing sensitive information system, or when accessing systems with elevated privileges (admin level). In most cases, accessing a public cloud provider via WebConsole or API is accessing the system for administrative purposes and requires an extra level of protection than a simple password. AWS Provides the ability to use MFA on it’s systems, but the ability to enforce that across all facets of the AWS API is not a trivial task.

So I recently posted about AWS S3 Bucket security and all the way AWS makes it easy for your to mess things up. This post contains some example Bucket Policies I like to use for various needs. Bucket Policies are pretty powerful. You can specify specific AWS accounts who can access your bucket. You can apply specific conditions around Source IP or Encryption settings. You can limit the access by object prefix.

For a project at work, I needed to highlight users who have access to IAM Actions that are considered “privileged”. There not being a good record of those, I decided to create one. AWS Interesting API Calls is a yaml file in github that contains a list of high risk calls and some data about them. I’ve also written a python module that can parse the file in various ways.

AWS S3 Bucket security has been in the news a lot recently. Almost 200 million records on US Voters were found on an unsecured S3 bucket owned by a GOP data analytics firm. A third-party vendor to Verizon left 14 million customer records (including SSN partials) publicly readable. Then Dow Jones exposed 2 to 4 million customer records. AWS has responded to this spate of bad press with a several changes to the AWS Console, and most recently took the extra-ordinary step of emailing account owners informing of any publicly readable buckets.

Anyone who follows my blog (and that’s none of you) would notice I rarely find time to post. Since moving my blog from Linode to AWS EC2 a few years ago I’ve spent way more time patching WordPress than writing in it. MySQL would run out of memory and crash, leaving my blog down for days on end. I never use the bloggy features of Wordpress since the only folks who ever commented were spammers.

New employer uses Terraform, so I’ve finally had a reason to grok Terraform and what it can do. I’m not convinced it is better than CloudFormation. Here are my thoughts on it. Pros Terraform can manage more than just AWS Resources. Useful if you need to orchestrate across multiple clouds, but I’d fear the dependency issues there. At my ex-job I’d have been very interested in how Terraform could control both AWS and Chef.