How do engineers make the seemingly-obvious mistake of opening their infrastructure to the world? Usually, with the best of intentions. When you’re building out your infrastructure, you tend to accept the first set of permissions that makes things “just work”. I just need this lambda to talk to that database. I just need to read files from that bucket. And quickly.

Yes, maybe now your Lambda is a bit over-provisioned and it could overwrite the data in that S3 bucket, but you wrote the Lambda, and it doesn’t do that. All good. Except when it isn’t. Except when you opened some resource to everyone with an AWS account, instead of everyone in your AWS account. Security misconfigurations aren’t like the other bugs in your application. They don’t break functionality, and usually, customers don’t notice. You probably don’t have an integration test that fails if it can successfully publish to your SNS topic from the wrong AWS account.

Being a responsible engineer, you set out to rectify the problem. You peruse blog posts and look up standards. You determine that you need to enforce least privilege, follow the swiss cheese model, and enable network flow logs. Your ship date slips, a lot. It’s easy to go overboard.

What’s missing is a prioritized list of basic checks and settings. Just like launching without every feature built, you don’t need every security principle fulfilled to the highest level. With that in mind, here’s our short list for when you’re starting out:

  1. Secure your perimeter. You should know, off the top of your head, every resource that is public. It’s probably a short list. A load balancer, an api gateway, or an EC2 instance. Maybe an S3 bucket, or maybe a CDN in front of one. If it’s not a short list, determine how to shorten it. Use this list to conduct a quick audit of your resources. Is it public? It had better be on the list. Otherwise, make sure it’s private.

  2. Secure your credentials. Know which humans have admin access. Use an IAM Group for this. It should be trivial to look up this information. Ensure they all use multi-factor authentication. Know which third parties you’ve given credentials to. Remove the ones you no longer use. Delete any user API credentials that are not needed.

  3. Turn on multi-region CloudTrail. Start building your audit log. You might not need it anytime soon, but someday you’ll be glad you had it enabled.

These steps will largely keep you from falling victim to automated sweeps for infrastructure mistakes. As you grow your team and accumulate data from running your product, your needs will change. The threats will change. You will read about defense-in-depth, and about the perils of a hard exterior shell with a gooey center, and the importance of intrusion detection and auditing. There will be encryption-at-rest, log verification, and IAM access analysis. All of these things are important, but what is often unstated is that they only matter if you have done the basics. Security features must be layered on a foundation, or else they will only end up causing headaches for little benefit. Do the basics first.

Gold Fig can help with the basics, and beyond! Talk to us about getting an assessment of the next steps to take, tailored to the stage of your company.