What are the New Attack Vectors in AWS?

By 2021, Cisco expects 94 percent of workloads and compute instances to be processed by cloud data centers. Attackers are already starting to focus and targeting cloud accounts, moving away from traditional data centers.

Earlier this week, Security Boulevard published my article on new challenges for security teams, and how they are modeling their security very differently from traditional data centers.

For an attacker, breaching a system is about exploiting its weaker spots. Cloud environments shift these weaknesses dramatically. Some traditional attack vectors become very difficult to exploit and thus less important, while many new vectors open up. This presents new challenges for security teams, as they have to model their security very differently from traditional data centers.

Let’s take a deeper look (I am using AWS as an example here, but things apply equally well to Azure and Google Cloud). Let’s break things into different categories:

  • What aspect of security is improved by a move to the cloud
  • Security strategies that have become less effective and need rethinking
  • New attack vectors that did not exist earlier


Prevention of Physical Attacks on the Hardware

All public cloud providers have strong controls in place for physical access. Since everything is virtualized and distributed across multiple physical sites, this is very difficult to exploit by attackers. Examples of these attacks include the use of USB drives or simply taking the hard drive. You are trusting your cloud provider with this risk.

Maintaining a Perimeter Around Your Machines 

EC2 lets you define a perimeter for virtual machines (VMs) quite easily. AWS VPC defines an excellent perimeter that provides security groups for firewalling. Security groups are easy to define and work more or less like traditional firewalls. (Here is a good read from AWS if you are not convinced that AWS security groups act as a firewall). Teams no longer have to spend time or money in implementing firewalls or microsegmentation products; just use security groups.


Perimeter-based Strategies

Historically, security has relied foremost on defining and controlling perimeters. The cloud simply breaks this model. Cloud resources come in two categories:

  • EC2 instances, RDS, Amazon Redshift, etc.: customers can control on which VPC or subnet to launch these resources, thus controlling access to the resources. Security groups do work for these resources as we discussed above, if permission is granted.
  • For many other resources, no perimeter can be implemented at all. One of the most important examples is AWS S3 buckets. S3 buckets are global resources and, if permission is granted, anybody can access the resources from anywhere in the world. Granting privilege is an API call away. Similarly, for many other services, such as KMS, IAM, Kinesis, SES, SQS or SNS, there is no perimeter. These can be accessed by an attacker if permission is granted.

Given that for a large portion of AWS, no perimeter can be defined, perimeter-based security is less effective.

Deep Packet Network Traffic Analysis

Deep packet analysis is increasingly inefficient in the cloud for two main reasons: Traffic is almost always encrypted, and for new technologies such as Kubernetes, Docker and Mesos, ports do not have much meaning and change all the time. IPs also change frequently as VMs auto-scale. There is no easy way to tie a TCP netflow session to a user or application in the VM.

The above two strategies are the bedrock of traditional data center security. The cloud makes them less relevant and effective.


Everything is an API call away, aka, “if permission is granted.”

This is a good time to talk about the “shared responsibility model.” Everything on the cloud is provisioned via an API call, including permissions. This means one way for an attacker to compromise your resources is to bypass your security settings simply by making a call to the right APIs to open any doors they want.

Hence, watching what is happening at the API level is super-critical for cloud security. You could have the best-designed s3 bucket policy, but all it takes is gaining control of your admin’s AWS keys and an attacker can simply go change the bucket policy, thereby gaining access.

Don’t make your cloud resources vulnerable to attack. Understand the cloud needs a different security model than on-premises infrastructures.


Suggested for you