Security and DevOps teams aren't natural allies. DevOps chafes when security puts up speed bumps. Cloud security teams look at DevOps and see chaos and risk. Sometimes the two disciplines seem to be on completely different planets.

But if your business is moving to AWS, you can't pick sides. Rapid innovation and risk management are both essential. So how can cloud security and DevOps teams come together to forge a more unified DevSecOps model?

A way forward is using configuration management as a driver for collaboration, if not integration, between DevOps and security. Focusing on configuration management is a pragmatic, win-win approach. Security teams gain control over a significant source of vulnerability and DevOps teams get some much-needed help with complex AWS configurations.

So, if your aim is to deliver both speedy innovation and security, a configuration-centric model is the surest first step to AWS security success. Here are three AWS configuration must-dos that pay huge dividends:

• Storage configuration - S3 misconfigurations have contributed to major data breaches
• Cloud accounts - the AWS console is a high-value threat surface
• Entity configuration - AWS entities (like EC2 instances, Docker containers and DevOps tools) each have their own access and operational permissions
  

S3 Storage

Data is the most sensitive aspect of many AWS implementations. Misconfigured S3 buckets that are left unintentionally open to external access will cause serious data leaks. As DevOps teams instantiate or modify these buckets, your security posture can take a quick turn for the worse if you're not careful.

Here's some advice:

• Pick a configuration framework and stick with it. Access to S3 buckets can be controlled with ACLs, policies, or even using web authorization frameworks. They can be configured by object, by bucket or using IAM. If you don't settle on one approach S3 misconfigurations are a real risk.
• Use policies instead of ACLs. If you want Amazon's take, read "IAM Policies and Bucket Policies and ACLs! Oh, My! (Controlling Access to S3 Resources)".
• Monitor changes to S3 bucket policies at all times, make sure you know which buckets house sensitive information, and follow up on unexpected permissions changes to prevent S3 data leaks.
  

To get a more complete picture of S3 configuration issues, check out "Avoiding Holes In Your S3 Buckets."

AWS Privileged Accounts

Accounts are the cornerstone of your AWS security posture. When AWS Console accounts are compromised, attacks can cause major damage. So, what should you do?

• Create accounts in IAM for administrative access, and design those accounts carefully. In all likelihood, you don't need many console accounts so keep them to a minimum.
• Use AWS Organizations and templatized roles to limit each account to the bare minimum needed for the job.
• Monitor these accounts and investigate unusual activity.
• Use multi-factor authentication.
  

AWS Entities

The applications, containers, processes, and virtual network components that make up your AWS implementation each have their own configuration. The AWS services you use - EC2, RDS, KMS - also have their own configurations. A typical implementation may have thousands of entities to worry about. Which means...

• Templatize configurations for entities. IAM offers dozens of pre-built templates for their own services.
• Use orchestration tools to automate entity configurations for consistency and scale.
• Adopt an entity configuration approach based on a least-privileges framework. That'll make it tough for attackers to work unnoticed.
• Monitor for anomalies, both in configurations and entity behaviors.
  

DevOps is all about speed, but speed pressures can lead to tempting shortcuts. Configuration challenges can be frustrating. Too often the solution is simply to open up permissions and move on. That's why a strong partnership between DevOps and security - focused on configurations - can lead to faster innovation and better security. For a more in depth discussion of AWS configuration issues, see "Driving Towards Least Privilege in AWS: A Baker's Dozen" from Dan Hubbard, Chief Security Officer at Lacework.

##

About the Author

Sanjay Kalra is co-founder and CPO at Lacework, leading the company's product strategy, drawing on more than 20 years of success and innovation in the cloud, networking, analytics, and security industries. Prior to Lacework, Sanjay was GM of the Application Services Group at Guavus, where he guided the company to market leadership and a successful exit. Sanjay also served as Senior Director of Security Product Management for Juniper Networks, and spearheaded continued innovations in the company's various security markets. Sanjay has also held senior positions at Cisco and ACC. He holds 12 patents in networking and security.