Overcome AWS security vulnerabilities with VPCs, IAM

The devil is in the details.

Anyone responsible for managing Amazon Virtual Private Clouds and subnets to secure network access to the cloud must possess an intimate knowledge of how the services work. The same goes for those who oversee the creation of identity and access management policies and rules.

"That's because they are very easy to misconfigure," said Dylan Shields, software engineer at Google and author of AWS Security. In his work at AWS, Shields observed that most security vulnerabilities could be attributed to misconfiguring IAM and VPC network services. He also realized these could be avoided if only security teams knew more about the security tools at their disposal.

Here, Shields draws on his experience with AWS security tools to explain how VPC security fundamentals can help prevent the most common cloud attacks.

Editor's note: This transcript has been edited for length and clarity.

What was the impetus for writing AWS Security, and what do you hope software and security engineers will take away from it?

Dylan Shields: When I was working with customers on AWS Security Hub, I realized they didn't really know about the security tools available to aggregate security data that we were showing them. I felt it necessary to outline the different ways software engineers and AWS customers can leverage these security tools for their enterprise infrastructure. In the book, I wanted to dive deeper into each tool to show how they work and what value they provide, as well as detailed information on how to set them up in a customer environment.

In Chapter 4 of AWS Security you identified denial-of-service attacks, database exfiltration and SSH access to a web server as the top AWS network security risks. Can these be prevented by creating the right network rules? What other measures could be taken to prevent them?

Dylan Shields

Shields: Properly setting up Virtual Private Clouds, subnets and security groups in a secure way is the best way to prevent these risks. Chapter 4 explains the process of creating Virtual Private Clouds, subnets and security groups to create rules for network access.

There are additional ways to secure your AWS networks. For example, AWS provides customers with firewalls, including AWS Web Application Firewall, which enables AWS administrators to protect networks in ways they could not do with simple rules in security groups.

Third-party firewalls are another measure organizations can use [to bolster network security]. Companies such as Barracuda and Palo Alto Networks offer firewalls that are extremely easy to integrate with AWS environments through the marketplace.

From your vantage point as a software engineer, what do you see as the top cloud security issues?

Click to learn more about
AWS Security by
Dylan Shields.

Shields: Some of the things that I see -- and that commonly end up in the news -- include S3 buckets that are left open and other very basic security misconfigurations. This is something I would like people to take away from the book especially: Organizations need to understand how to reconfigure services such as IAM and Virtual Private Cloud. They need to make sure they're not missing these glaring holes into their network or logical access.

I can think of cases where a MongoDB or an ElasticSearch cluster is left completely open and just found by a researcher scanning over the whole AWS network -- or not even specific to AWS but any provider that you are running your infrastructure on.

Did you have conversations with security researchers while writing AWS Security, and if so, how did they inform the book?

Shields: Yes, I have spoken to researchers about the various attacks [that they observe in the wild]. The data that I have received from them [confirmed what I have seen in my work]. They concluded that most attacks they see can be attributed to some of the more basic security vulnerabilities. They have seen wide scanning over IP [addresses] in the AWS range, as well as simply searching the S3 bucket namespaces.

In your experience working with AWS customers, have you noticed any glaring security misconceptions that companies have when they transition to the cloud? How would you respond to those concerns?

Shields: One of the common misconceptions I see is that the cloud is less secure because your instances are on the same physical servers as other customers. I would respond by saying how I've witnessed companies like AWS, Google Cloud and Azure improve at hardening hosts from attacks between clusters on the same server. They are doing better than some of the on-prem and colocated networks that you'll see if you were to use a third-party data center.

What questions should they ask their prospective cloud provider before switching from on-premises to the cloud?

Shields: Before transitioning to cloud, I would want to ask my cloud provider for educational resources on how to configure security for their services. I think there is a lot of training that needs to happen before a security team can understand how to best secure an infrastructure in the cloud.

Like I mentioned, the most common security issues do not go away simply by switching from on prem to cloud. The security incidents will not differ all that much. But it is still critical for organizations to pursue an education [on cloud security best practices] so infosec practitioners can provide the same level of protection as they could securing on-prem environments.

Can you point to the most common causes of cloud security issues, i.e., handing out too many privileges?

Shields: In terms of logical access, granting too many privileges is one of the biggest cloud security issues. Again, I think it stems from operators not knowing exactly how IAM works. Sometimes, the easiest way to get their job done is to grant administrator access or another overly permissive existing policy to a user or role.

IAM is the core identity service in AWS. This is how you provide any person or application with access to any of the AWS APIs. But it is dangerous if IAM is executed incorrectly because you can open yourself up to a lot of vulnerabilities, such as accidentally giving access out to your entire infrastructure.

Also, privilege escalation of this kind creates a massive blast radius of credential attacks. This means that, when a user is unnecessarily granted administrator access, for example, they can affect things they were not intended to work on. They can potentially put anything else in the AWS account at risk.

What kind of cloud security trends are you most optimistic about that could improve enterprise cloud resiliency?

Shields: I'm very excited about DevSecOps. This is part of what I try to do at AWS -- we are making tools available that can help achieve this goal of shifting security left. Automated testing of security issues is another technology trend that can be very beneficial to infosec teams, particularly if used early on in the development lifecycle. This way, developers and engineers can catch security issues before the production stage. This would be a significant improvement from what I've seen at some organizations where a product gets pushed out and a pen test [penetration test] is performed every few months afterward.