Keep Your Cloud Clean

What We’re Doing Here

This is the first in a series of short articles that will provide strategies for quickly enabling your security teams in the Cloud by designing common sense processes around inexpensive (often free) native cloud security tools.

You’ll also find advice for being a good partner with your DevOps and Business teams.The days of “security because I said so” are long gone, and good riddance! Cloud Security is about enabling your business to deliver value in the cloud securely, and your success depends on establishing and maintaining great relationships with your partner teams.

By following this practical advice you can reduce the chances of dangerous configurations in your environment while building great partnerships across your organization.

Definitions

Each cloud service provider has a unique way of describing its artifacts. In order to cover as much ground as possible, we’ll use some generic terms in this article.

“Account” will describe AWS Accounts, Google Cloud Projects, Azure Subscriptions — basically, any wrapper around a related set of cloud resources.

“Security Hub” will describe AWS Security Hub, Google Cloud Security Command Center and Azure Security Center — or any other portal that provides a single-pane-of-glass view of the security posture of your Cloud.

The Cloud Account Sprawl Problem

Cloud Account Sprawl refers to an explosion of Cloud Accounts in an organization’s environment, and is a common side-effect of executing on a cloud vision. As interest in the cloud increases, so too does experimentation, and the number of “Proofs of Concept”and “Training” cloud accounts will appear to rapidly approach infinity.

This is positive insomuch as it signals a culture of interest and learning, but it can also result in a Petri dish of bad configurations and hard-to-identify risks. It can also be invisibly expensive, as resources in these accounts are spun up and left running, only reviewed again when they appear on a later bill.

Why Sprawl Should Be Solved

Cloud Account Sprawl allows the mistakes and missteps that organizations make during the learning-and-growth phase of their cloud journey to be replicated at scale, and left behind as teams move on to the next big thing.

This can mean unprotected privileged credentials, improperly configured storage, unpatched vulnerabilites on Virtual Machines and poorly thought out network security configurations are left waiting to be exploited.

Even if these account don’t contain sensitive data you may be leaving holes in your environment that allow baddies to take a “free ride” on your cloud bill, for example by spinning up expensive coin mining operations with your resources.

To protect your bill and your organization’s reputation, Cloud Account Sprawl must be meticulously managed.

Stopping Sprawl with Cloud Account Lifecycles

The good news is that this problem can be kept in check by establishing and enforcing Cloud Account Lifecycles that clearly define what cloud accounts can be used for and how long they can live.

This approach has several benefits, including aligning to and clearly communicating what your company believes cloud should be used for and how long it should take to finish certain objectives in the cloud!

No more never-ending Proofs of Concept? Improved alignment to cloud strategy? Smaller attack surface?

How To Establish Your Cloud Account Lifecycle

To keep future problems in check, and to be a good partner to your Business, it’s imperative that you define, ratify and widely publicize a Cloud Account Lifecycle in concert with your end users.

The following process will get you there, and can be adapted for any size of organization.

First, Start with Why

First, define the “why.” Some potential objectives have been discussed already in this article, but are worth restating:

1. Appropriately managing spend.
2. Timeboxing riskier activities, like Proofs of Concept.
3. Reducing risk by keeping your attack surface only as large as necessary.

Second, Define Account Types

Next, define what “types” of accounts you’ll provide, how often they’ll be reviewed for deletion, and create a repeatable naming convention.

Some reasonable examples include:

Third, Bring Your Partners To the Table

I can’t stress this enough: Cloud moves too quickly for security teams to live by mandate.

This and every major decision Cloud Security makes must made be in partnership with your business teams, because these decisions affect the way your business will deliver value in the cloud.

Can you imagine defining account types that are totally out of sync with what the business needs? Or defining lifecycle timelines that are too short to support their standard Proof of Concept process?

That’s how you get roadblocks.

Security is a Team Sport! Don’t be a Roadblock.

Finally, Execute against Mutual Expectations

If you’re in a smaller organization or your AWS account inventory stays relatively static you may just eyeball the “Created Date” of each new account from the AWS Organizations page once a month and send an email to account holders asking them to confirm they still need those resources.

If your cloud account inventory is large and growing, you’re best off automating.

Using AWS as an example, a potential solution might use Boto3’s list_accounts method to create a living inventory of accounts and their creation times, store them in a database and use datetime comparisons to identify accounts at the end of their defined life cycles.

To really spice things up, automate the sending of affirmation emails and the capture of a “confirmation” so that it’s easy (even pleasant!) for your business users to participate in this process.

Getting To It!

The beauty of cloud isn’t just that you can easily scale up. It’s just as valuable that you can scale down hundreds of resources at a time.

Follow this approach and you’ll see significant improvements in your security posture, cloud costs and attack surface. You just might make new friends with your business lines while you’re at it!