By now, it has become all too common to hear stories of AWS accounts being abused to mine cryptocurrency or inadvertently leaking confidential information through unsecured S3 buckets. Awareness of the potential risks posed by rogue or abandoned AWS accounts must be taken seriously, and the necessary steps must be taken to ensure that organizations are not left exposed.

‍

One of the advantages of cloud infrastructure as a service (IaaS) is that you can create new accounts very easily, which provides a great deal of flexibility and scalability for businesses. However, this ease of creation can become an issue for IT and security teams, as it can make it difficult for them to keep an eye on new accounts being created across the organization. 

‍

This problem plagues customers of all cloud providers, but it’s especially troublesome for Amazon AWS, where a lack of visibility into the accounts being created can be a major headache for IT teams tasked with managing security and compliance. Some providers, like Google Cloud and Office 365, tie new accounts to a primary tenant, so whoever manages the tenant has visibility of all accounts. With AWS, you only need an email address to get started. Not only will AWS not transfer ownership of rogue accounts where the root user is an email address in your domain, they won't even disclose them. This means it's near impossible to find rogue, abandoned, and forgotten AWS accounts. Ultimately, this can lead to potential security risks and compliance issues that could be avoided if teams had the visibility they needed to find all accounts in their org.

‍

‍

You can’t monitor what you can’t see

Most teams do a good job of managing the cloud security posture of their AWS environments once they become aware of their existence. You can use an infrastructure as code (IaC) service or AWS Organizations to centrally govern all accounts and help ensure that security controls are correctly implemented and configured. Furthermore, you can make sure that Cloudtrail and any other sources of security-related data are configured to send events to the security analytics stack and the detection engineering team for further analysis. This process can help you to detect potential anomalies or threats and take the necessary steps to protect your system from potential malicious actors. The catch? You need to know about these accounts to be able to protect them. 

‍

Some organizations have processes in place designed to ensure that engineers don't create new AWS accounts outside of their organization. Some organizations simply circulate a spreadsheet around engineering each month (I’ve been there.) These systems are only effective, however, if all employees are familiar with the process and always adhere to the policies in place, as there is no way to technically prevent them from creating these accounts. 

‍

Inevitably, some accounts slip through the cracks. 

‍

When an employee creates an AWS account outside of your centralized governance process, it means two things: First, your IT and security teams have no idea those accounts exist, let alone what’s in them. Second, any policy you have or investment you’ve made in security tools doesn't apply to those accounts. Until you can find the accounts and configure them properly, you can’t apply any of the security controls that your company as a whole is using.

‍

Data security hinges on your AWS root user

When an employee creates an account outside of your organization, the controls in place are…the individual who created the account. And that's it. The unmonitored account’s security hinges on factors completely outside of corporate control, such as whether the employee’s credentials have been exposed, whether they configured the S3 bucket to be private or public, and what kind of data they may have stored in the account. We often see data locality issues as well, where employees store data in unauthorized accounts in regions where the data should not be. 

‍

Worst of all, if that employee leaves, there’s no changeover of ownership and you've got no controls at all. In some cases, employees leave the organization with intellectual property and customer data still in the AWS account they created. Even if someone else at your organization becomes aware of the account, they’ll need to access the root user’s corporate email to transfer ownership.

‍

The nature of SaaS and cloud accounts means that employees are foisted into security roles, whether security and IT teams like it or not. Ignoring that reality rather than accounting for it means allowing individual developers to be accidental AWS security teams of one.

‍

AWS bills may be your first sign of trouble

When you create a brand new AWS account, you typically start with a free tier, pay-as-you-go model. This means that until you reach a certain usage milestone, such as 300 hours per month, there’s nothing to pay. Until then, no bill, no fuss, no muss. 

‍

Taking advantage of free tier usage may provide an incentive for developers—and at first glance, organizations—to start new accounts outside of your AWS Organization, perhaps for experimentation, testing, or special projects. From the employee’s perspective, what’s the harm? It’s free, easy, and helps them get their work done quickly without dealing with procurement or touching the department’s budget. (Of course, since these accounts aren’t associated with your organization, any charges that do eventually accrue will not make use of your organization’s AWS credits or discounts.)

‍

Unfortunately for security and IT teams, this means there can be substantial data and activity in those accounts well before a bill arrives. If an employee’s account is compromised and used for cryptomining, for example, the first sign of trouble may be an unexpected bill that arrives well after the attacker has racked up thousands of dollars in usage. A misconfigured S3 bucket that’s exposed to the public may have been accessed by criminals weeks before enough usage accrues to result in a bill that could tip off your organization that it exists. In either case, finding out about rogue AWS accounts after the fact creates new headaches that cost time and money to address, potentially prompting incident response processes, regulatory fines, and other remediation activities. 

‍

How Nudge Security helps

Employees should be empowered to add to your organization’s security—but that doesn’t mean leaving them to be the only line of defense. Relying on individual employees to remember and follow your organization’s policy for creating AWS accounts creates too much room for error. On top of that, waiting to find out about unmonitored accounts after a problem occurs puts your organization at risk of security incidents and unexpected costs. 

‍

With Nudge Security, you can automatically detect new AWS accounts as they are created, enabling you to intervene early and nudge employees to onboard their accounts to the proper AWS organization. You can also see historical accounts, giving you a complete picture of your organization's AWS footprint, allowing you to easily track your cloud resources, ensure they fall under centralized governance, and complete cloud access reviews. 

‍

See for yourself what Nudge Security can do for you. Within the span of a free, 14-day trial, you can get visibility of all your AWS accounts and find out how many are unmonitored. What are you waiting for? Sign up for your trial today!