Top 9 Biggest AWS Security Mistakes To Avoid

From failing to address the spread of shadow IT to losing or having credentials stolen to treating containers like traditional appliances or VMs, here are nine of the most common AWS security mistakes seen by technical experts.

Learning From Other's Mistakes

Amazon Web Services (AWS) provides organizations with a plethora of ways to increase their speed and performance while reducing costs, but businesses need to be wary of potential protection pitfalls that have tripped up less security-savvy organizations.

Some of the most common mistakes technical experts have seen around AWS include misconfiguring or failing to properly secure S3 (simple storage services) buckets, providing administrative access to way too many users or situations, and failing to equip the security team with the necessary oversight around the application development and engineering process.

From failing to address the spread of shadow IT to losing or having credentials stolen to treating containers like traditional appliances or virtual machines, here are nine of the most common AWS security mistakes.

9. Overly Permissive Administrator Access

Organizations often go the easy route and give administrative privileges broadly to avoid help desk tickets, and these behaviors have carried over to the public cloud, according to Matt Chiodi, Palo Alto Networks' chief security officer, public cloud. But overly permissive access leads to a wider blast radius in the event of successful account compromise, Chiodi said, resulting in more harm being done.

The best practice is that public cloud configurations comply with the principle of least privilege, and Chiodi said companies should rely on their identity and access management systems for role-based access control.

Chiodi also recommended that companies apply rule-based access control so that top administrators have global access only when the credentials are absolutely necessary and not when merely completing daily activities. All told, Chiodi said companies should create limited-scope roles, and apply just the necessary level of access and nothing more.

8. Lack Of Understanding Around Configuration

AWS has provided a lot of functionality to companies that are sophisticated enough to use and make sense of it properly, according to Ryan Kalember, Proofpoint's EVP of cybersecurity strategy. However, given the complications associated with configuration from an identity and access management standpoint, Kalember said that only a minority of companies have that level of sophistication.

The configuration involves turning a lot of dials, Kalember said, as well as potential interactions between products that are extremely hard to model. A simple misconfiguration can lead to S3 buckets getting exposed on the internet even though they're set to private by default, Kalember said.

Cloud access security broker (CASB) tools are doing a better job of identifying misconfigurations these days, according to Kalember.

7. Treating Containers Like Traditional Appliances Or VMs

Kubernetes is having a massive influence on both AWS and Microsoft Azure, with containerization forcing organizations to flip cybersecurity best practices on their ears, according to Tim Mackey, principal security strategist with the Synopsys Cybersecurity Research Center.

Business spinning up a virtual machine or deploying a traditional appliance onto the Amazon Elastic Compute Cloud (EC2) own it the same way as a server, Mackey said. But the traditional advice security teams provide doesn't work with containers since having an interactive shell or running access to a container exposes it to so much more risk, according to Mackey.

Organizations need to shift their paradigms and figure out which security components in their tech stack best capitalize on the immutability of container images to patch damage. Solution providers will be most successful if they give their customers tools to better manage and secure container infrastructure at scale on a run-time basis, Mackey said.

6. Lack Of Cooperation Between Security, Engineering Teams

Companies need to treat infrastructure like code, and use APIs, DevOps, and continuous integration as part of their core security strategy, according to Bill Shinn, AWS's senior principal for the Office of the CISO. This will make it possible for security organizations to keep up faster and maintain protection without compromising performance, Shinn said.

Software in the cloud isn't deployed like in a traditional data center, Shinn said, with development teams handing off scripts and runbooks to the operations team. Given that the engineering team typically manages the entire lifecycle in the cloud, Shinn said it's hugely important that the security team be at the table with the coders so that it's taken into account as part of the development pipeline.

Similarly, Shinn said organizations should incorporate legal, audit and compliance functions must earlier in the development cycle. Businesses need to take advantage of single template automation to move more quickly in areas like implementing security controls and providing monitoring and access control, according to Shinn.

5. Lost Or Stolen Credentials

Lost or stolen credentials are typically the leading cause of cloud security incidents, said Palo Alto Networks' Chiodi. From time to time, Chiodi said developers will inadvertently embed access keys in their code, making it possible for adversaries to use scanning tools to find access keys in public cloud accounts.

Organizations need a way to detect account compromise and baseline what typically administrative or user activity looks like, Chiodi said. From there, Chiodi said businesses can use pattern analysis to identify abnormal behavior.

4. Exposure Of Sensitive Data, Applications

One of the risks seen over and over again in AWS is the unintended exposure of sensitive data, which is happening in production every day, according to Reuven Harrison, Tufin's co-founder and CTO. Lots of cloud applications end up exposed for one reason or another, Harrison said, with ports and endpoints unintentionally exposed to vulnerabilities and possible attack on the cloud and internet.

Most cloud deployments to date have been happening in AWS, Harrison said, and as a result, most of the exposures have been happening there as well. AWS is a very develop-centric platform, Harrison said, and has been created by and for developers so that they can spin up applications with agility.

As a result, Harrison said AWS lacks the processes, controls, checks and balances that would be found in a more traditional network.

3. Uncontrolled S3 Buckets

Enterprises today often have some or lots of their cloud managed by developers, and security teams often haven't gotten their hands around it yet, said Tufin's Harrison. The cloud doesn't have the same tooling as traditional environments, Harrison said, and the visibility and controls often just aren't there.

Developers often deploy stuff in the cloud in a way that's overly permissive and forget to lock things down, Harrison said. Hackers can get their hands on corporate data without any effort whatsoever if a business puts sensitive data in an Amazon AWS S3 (simple storage service) bucket that's unintentionally exposed to the internet, according to Harrison.

Businesses need new tools and processes to match the cloud since traditional safeguards like firewalls can't block S3 buckets since they don't have an IP address, Harrison said. Mature cloud and development teams are using DevOps and continuous integration and deployment (CI/CD) approaches to automate processes and account for the lack of traditional reviews, according to Harrison.

2. Insufficient Separation Of Duties

Security in organizations has traditionally been built around the separation of duties, but with an AWS account, development teams can spin up their own applications and servers without having to talk to any other departments, said Bitglass CTO Anurag Kahol. Development teams are measured on putting out apps as quickly as possible that are accessible and usable, which he said is creating security issues.

For instance, Kahol said a lack of separation of duties has resulted in developers being able to leave MongoDB buckets, S3 buckets, or other types of databases or machines open for all to access, Kahol said. As a result, Kahol strongly advises against having AWS account owned by application teams.

Kahol recommended that an organization's infrastructure team be responsible for brining up AWS servers, and a team independent of the developers should control the security policies on servers and databases. And application teams should only be permitted to use AWS servers that have been provisioned to them by other teams, Kahol said.

1. Allowing Shadow IT To Fester

The IT department often isn't aware of AWS use within its own organization since it's so easy to spin up accounts, which has resulted in developers copying production data to an AWS account to test it without any prior approval, said Kaushik Narayan, CTO of McAfee's cloud business unit.

The flexibility of AWS and its ability to allow developers to get testing done contributes to being used for shadow IT, said John Dodds, McAfee's director of product management. The data center almost relied on security by bureaucracy, Dodds said, with the time required to get things done contributing to a reduction in risk.

Security organizations have fewer things to investigative on-premises since there are fewer variables than in the cloud, Dodds said. Given the surface area on the cloud, Dodds said it can be challenging to put effort into defending against something that only targets one specific system.