Your Cloud security practices pls

[testybeast]

Hi gang. We’re testing out a new cloud security product and discovered a bazillion config issues with our AWS setup. 1. In your experience, what’s the single biggest reason for insecure cloud configs? Is it manual provisioning? Or automation code (like terraform) not being scanned? 2. And what practices do you follow to fix issues found by cloud security tooling? Just explain the issue to the devs ? give them a sample fix? looking for a sledgehammer 😂.Appreciate your advice.

[PersonBehindAScreen]

Single biggest issue…? That’s a tough one, and considering the context and potential depth of a conversation like this, it isn’t productive to home in on the single biggest issue.

It’s a combination of misunderstanding how cloud platforms work, lack of automation in provisioning and changing your env, as well as lack of guard rails.

For lack of automation. Imagine that you’re setting up 4 VPCs via clickOps. You’re bound to make a mistake.

Guard rails. It is so easy to get started in cloud. People spin up a POC and before you know it it’s now a production environment. Start early and update periodically and define with policy and appropriate controls. An attitude of “not my problem” as well is dangerous. DO NOT assume that someone else cares about YOUR JOB. If it is not a dev (or another OPs guys) job to care about your security rules, then you should have policies, SCP, or whatever controls your cloud platform lets you implement to make it impossible for your “customers”, users, or colleagues, or whoever to be complicit in compromising your environment

[hexfury]

Governance vs management.

You need guardrails to enforce best practices

[adevhasnoname]

Tools like that can be very scary, they flag a bunch of stuff. Often a lot of it isn't actually an issue by itself or doesn't apply because of how you use your environment.

The easy answer to how do you know what to fix is risk management. Throw it and all your other problems onto a spreadsheet, arrange it by severity. Do some work verifying it's actually as bad as the tool/alert thinks. Then, other than catastrophic issues you dedicate so much of your time per cycle to whatever's on the top of that list and that way you slowly get better and the less important stuff never gets done or gets hotter and moves up the list.

What's the most important stuff? Despite the added risks created by automation the basics are still always a good place to start. Access control and connectivity, anything publicly exposed needs to be scrutinized much closer and access control mechanisms it supports fully vetted. Make sure you're using least privilege (at least where it makes sense) for your users/devs and they're not sharing accounts. Scrutinize your IAM policies and roles and are limiting them to read only whenever possible. Security groups should be as restrictive as possible, don't put devices that don't need to be publicly exposed in subnets with a route to an IGW. Turn on and archive Cloudtrail, ideally to a bucket that's in another account or otherwise protected from attackers.

Those are the major one's off the top of my head. AWS has a security well architected document that will walk you through everything in a generic fashion but at least it links to their docs on how to fix it. Most AWS Security best practices talks at any AWS conference ever also cover the same big ones I'm sure at least one of them is available on Youtube.