The Risk of Unsecured Dev Accounts

This article was originally published on Fugue's blog here.

By Drew Wright, Co-Founder Fugue

Most organizations now recognize the importance of cloud security, likely due in large part to the sharp uptick in cloud-based data breaches resulting from cloud misconfiguration. Achieving and maintaining the secure configuration of their cloud infrastructure resources—sometimes referred to as Cloud Security Posture Management (CSPM)—is now a priority for most cloud engineering teams.

For most organizations, however, CSPM begins and ends with their production cloud accounts, with scant attention paid elsewhere in their cloud environment, particularly developer accounts. This is understandable because production accounts are where sensitive data lives, and we want developers to be able to move fast without being shackled by security. And in the datacenter, pre-production development typically happens inside secure networks, and there may be some misperception that this carries over to the cloud.

Unfortunately, the risk profile of developer cloud accounts is much different than in the datacenter due to the nature of the cloud and how cloud security works.

Ask yourself the following three questions:

• Would you be comfortable with malicious actors operating inside your developer’s cloud accounts? And if they were, would you know?
• What information might malicious actors find in developer accounts that could be useful in exploiting production accounts and data?
• Might malicious actors be able to use developer accounts to gain access to your production accounts?

I suspect your answer to the first question would be emphatically “no!” But what about the other two? Can you answer right now, or would you need time to discover what’s in them? Well, that time is now.

Let’s take a closer look at the risks posed by unsecured developer cloud accounts.

Developer cloud accounts are often unsecured

Organizations using the cloud at scale have a pretty spotty track record when it comes to assuring the secure configuration of their production cloud resources. But even cloud engineering teams that do a good job with cloud security often make the mistake of putting all their focus on security production accounts while ignoring that of dev accounts.

This mistake means gaining unauthorized access to dev accounts is a trivial matter due to common misconfigurations, including:

• Security Group rules such as SSH open to the world
• Using the Trust policy “AWS”: “*"
• Every principal has admin permissions
• Long-lived credentials (not rotating credentials); little or no password policy
• Using S3 buckets that are configured for public access
• Using old or insecure AMIs
• Orphaned resources that contain misconfigurations or go unpatched

Malicious actors can learn a lot about production from dev accounts

Once a malicious actor has access to one or more dev cloud accounts, they can discover a wealth of information that can help them achieve their larger goals, such as finding and extracting sensitive data.

Any of the following can be incredibly useful for an attacker to know:

• Resource naming conventions
• System architecture
• IAM roles
• Shared accounts
• Database schemas and EBS volumes

Malicious actors can sometimes use dev cloud accounts to gain access to production

Sometimes cloud environments include cross-account access privileges, and there are often Identity and Access Management roles and policies that can enable malicious actors to execute privilege escalation attacks. If you’re cloud environment includes these IAM misconfigurations, an attacker that gains access to a dev account may be able to jump to production in minutes.

Rhino Security Labs has done an excellent job exploring how these kinds of attacks work. You can find their posts here, here, and here.

Cloud migration sandbox accounts pose similar risks

Is your organization early in your cloud migration journey, with some sandbox accounts but nothing running in production? You probably already know where I’m heading with this one.

No organization jumps directly from the datacenter right into running production workloads in the cloud. They start off small, building and testing in sandbox environments. Once ready, they deploy one or two production applications and with actual data, and grow from there.

By nature, a sandbox cloud account is going to resemble what will be running in production—the architecture, the naming conventions, the IAM roles. But if you aren’t maintaining the security of your sandbox cloud infrastructure environment, you might as well hand the blueprints of what will be running to any outsider who’s interested. And when you put off security and compliance until you’re ready for production cloud workloads, you’re setting yourself up for a rude awakening of architecture redos, deployment delays, and potential security vulnerabilities.

The subject of security before day one in the cloud is big and important enough its own dedicated post, so stay tuned for that.

Striking the right balance with dev account security

One of the main reasons for going to the cloud is speed and agility, and we want to empower developers to innovate fast and without headaches and constraints. No developer wants to memorize a set of policies the size of War and Peace, nor can any human be expected to. And manual reviews and audits are slow and error-prone enough when employed for production environments. Doing that for dev environments is a non-starter.

If you want your developers to move fast but keep all cloud environments secure, you need to give developers tools that work the way they work. That means policy-as-code tools they can use to quickly validate their environments, identify problems, and give them useful information so they can correct them and move on. Policy as code tools mean we can finally start ditching traditional trade-offs between speed and security.