How to shift AWS security left: 10 ways to empower your developers

In this post, Don Magee — veteran cloud architect, security engineer extraordinaire, and Cloud Security Lead at Stedi — shares some essential shift-left security strategies and lessons learned around building a better security posture. This content is based on Don's Securing Your AWS Environment ACG webinar. Any mistakes are on the part of the editor.

You can do everything in your power to reduce your blast radius, ensure compliance, and secure your environment. But one of the best moves for improving security is to help developers make the right choices and solid IT training programs

And the best way to get a developer to make the right choice is to make the right choice the easy choice — make it easier to do things the right way than the wrong way. In this way, you can empower your developers and shift AWS security to the left in your AWS environment.

In this free, on-demand webinar, Don Magee gives a detailed breakdown of taking complex AWS environments from zero to secure.

Why empower your developers? Because centralized management leads to less developer engagement and fewer deploys.

We don’t want the security team to take over parts of developers’ jobs or building IAM rules for them. That slows developers down and makes their jobs harder.

Instead, find tools that make developers' lives easier. The goal is to stop centralization and ensure developers are part of the process. You can accomplish this by giving teams direct feedback.

Developers are best when they can make their own decisions. Don’t just say "no." Be transparent about what is being done and why. Then, audit the results and redirect as required.

Is cloud security a concern of yours? With the AWS Security Certification your team will be equipped with ninga-level security skills and ready for any complex AWS project.

CloudFormation Guard is easy to use and allows you to write rules (that are somewhat similar to AWS Config). Engineers can run CloudFormation Guard on CloudFormation locally or in the CI/CD process.

• Allows engineers to check compliance locally or in the pipelines
• Parity to AWS Config rules
• Can auto-generate some types of rules

• IaC templates for building common resources with secure-by-default configurations
• Use modules for more complex items such as VPCs

At Stedi, they build a lot of reference examples that engineers can look at. This includes a top 10 list of the most common misconfigurations and how to fix them.

Boundary permissions create limits on IAM roles that can be created by engineers.

These boundary permissions are essentially a "cannot do " policy that has to be attached to any role you make on your team. So you can say, "You're allowed to make all the roles you want . . . as long as this boundary permission is attached."

These permissions can be all the things you know you don't want your engineers to get into — like making roles that can have administrator access. You trust your people to do the right thing, but you can help ensure they don't accidentally do the wrong thing.

Building on that last point, you can use SCPs to take things a step further.

At Stedi, all denies are piped into Slack, so engineers can see when something is going wrong. This way, they don't have to say, "I can't deploy. What's going on?" They can look in the channel and see, "Oh, I just tried to deploy in EU-West 2, which is a banned region." They can see they were in the wrong region and then change it.

We want to make sure developers are building alarms for their systems and their health. They're responsible for them. That's why it's DevOps. But any system that goes to production needs to be observable.

There's a lot to cover here, but here's a quick list of things to consider.

• Use secret detection tools
• Provide common paths for sensitive things like secrets management, encryption, and deployment tools
• Managed everything as code, even if it means building your own resource providers
• Review the OWASP Top 10 at owasp.org
• Perform security awareness training for all staff
• Use AWS Organizations to segment sensitive systems
• Leverage third-party cloud security tools
• Leverage third-party assessments
• Build a vulnerability management program

So where do you start in all of this? You begin with writing. If you can’t explain it and get buy-in on it, you probably can’t build it. Write up how you’re going to approach security and build it — the controls, everything.

Amazon has some great examples around that with their PR/FAQ process and their one-pagers and six-pagers. You can also find videos on that. Try it — it works!

No infrastructure in the management account. None!

org-formation is probably the single greatest open-source for managing AWS account out there. Check it out!

• Standardized critical infrastructure and account creation
• Enforces minimum security policies
• Allows Stedi to provision new fully compliant accounts in under 10 minutes

Use a CSPM. Config is similar to that. But there are a lot of third-party, open-source, and paid options. That will give you an audit log and full visibility into all resources, compliance rules, and auto-remediation of critical concerns.

• Remember: you can’t secure what you can’t see.
• Reduce public access by default.
• Build rules in Config or your favorite CSPM.
• Get feedback directly to your engineers.
• Trust, but verify.
• Design for operational efficiency at any scale.
• Build systems with components that self-improve over time.
• Take no extraordinary measures.
• Build only for current requirements.
• Build extraordinary things.

Learn faster. Move faster. Transform your team with our courses and real tech and IT practice labs in AWS, Microsoft Azure, Google Cloud, and beyond.