AWS Security: IP-Based Security Leads to Breaches which Leads to Suffering

December 21, 2016 |
AWS Data Compliance: 4 Tips for Decreasing Audit Times

This past weekend was the premier of the latest Star Wars movie. If you are a fan (and even if you are not), you’ve probably heard the famous Yoda quote: “Fear leads to anger, anger leads to hate and hate leads to suffering.” Today, I’m re-working that quote to the title of my blog: “IP-based security leads to breaches which ultimately leads to suffering”.

Here’s the problem. Managing tightly controlled user access in AWS is too complex which in turn leads to errors and sloppiness. What makes it so complex?

  1. User access is IP-centric, but their IP addresses change.

    Think office to home, to mobile, to a coffee shop, to a plane!! – Predicting where those users are going to be coming from to access the environment is a very big challenge; and somewhat impossible if you have a mobile workforce.

  1. Dynamic environment causes extra administrative burden.

    As virtual machines and services within AWS are spun up, expanded or contracted, being able to dynamically allocate security policies to these resources becomes a real challenge.

  1. Complexity leads to shortcuts.

    A lot of the time shortcuts are taken that compromise the security posture in the footprint of a particular environment.

  1. Forced use of VPN connectivity to manage access control.

    If you’re at all into the networking space within your organization, you know that the use of VPN tunnels is also not a trivial task. And it can create performance issues for your end users and force unnecessary hops from environment to environment just to ensure that people are coming at the environment from the appropriate locations.

  1. Logging correlation complexities.

    All of this hopping around and all of these different technologies lead to logging and correlation issues. So when it comes to audit and compliance, you have a tremendously difficult task on your hands to correlate these logs and figure out who is doing what, who is accessing which application, what time of day and under what context they are doing it.

  1. Shared AWS responsibility model.

    Where is it that AWS’ responsibility for the cloud ends and yours as a consumer begins?

Public Cloud is a Shared Responsibility

So what are people doing today as they try to secure their AWS environments? Well, the fact of the matter is they’re using security groups. That’s the crux of the security model. If you look at public cloud security as its defined by AWS using their shared responsibility matrix, you know that anything that’s part of the cloud, any of the infrastructure that’s required to build the cloud, including the data centers, the servers, the storage, even the hypervisor; it’s all part of Amazon’s responsibilities to lock those components down and make sure only the appropriate people have access to those components.

 AWS Shared Responsibility Model

Figure 1. AWS Shared Responsibility Model

However, anything that goes into the cloud becomes your responsibility. Anytime you take advantage of the resources (in blue in the above image) and build virtual machines, deploy data into S3 buckets or use a new feature like AWS Snowball to push data into the environment, security becomes your responsibility. That’s where this shared responsibility matrix becomes important, and the idea of controlling access to those particular resources from an end-user perspective becomes a topic of concern. So how are people doing it today?

Attempts to Secure AWS Environments: Security Groups

There are a couple of ways that you can accomplish security.

  • Wide-Open Access – One is the wide-open access concept. If you cannot predict where a user is going to be, you open up access on the security groups to allow people to access the environment from literally anywhere on the planet. And that’s okay for your trusted and known employees, but keep in mind those destinations are also open to the entire planet. So now you’re relying on services running on those virtual machines to prevent bad guys from getting into the environment. Generally speaking, the wide-open access model is a really rotten idea from a security perspective.
  • Tightly-Controlled Access – The next best option is to start thinking about tightly controlled access where you force end users to access the environment from a known location. If you have a mobile workforce something’s got to give. That’s when customers start deploying VPN capabilities and start establishing LAN-to-LAN VPN tunnels between their home offices, corporate data centers and the Amazon regions.

This again is an interesting idea. It certainly will help to enforce some security in making sure that people come at the environment from some known locations. But there are a couple of problems with this deployment option as well. First of all, you’re forcing users to use a VPN client to get into the corporate office and forcing unnecessary hops from the corporate office to the Amazon cloud before they actually get to the cloud. Wouldn’t it be better if they could just go directly to that cloud service by using the generic internet? The other problem is that if that corporate office gets compromised, it is a trusted source to the cloud. Eventually you run the very distinct possibility that your cloud resources could be compromised, coming across a trusted network connection.

These are all important challenges with both the wide-open access and the tightly-controlled model. From a security group perspective, if you think about people accessing the environment from a known location, it’s very easy to know and manage.

Typical AWS User Access Security ModelFigure 2. Typical AWS User Access Security Model


Take the above scenario. These four users are accessing the Amazon environment from a known source. Their public IP address is that source and the security groups are configured appropriately. The challenge is when the user tries to access from another location. Do you:

  • open up to allow access from anywhere?
  • force them to have a VPN tunnel into a known office and through a 73 dot IP address as you see in this example?

I would suggest there’s a better way to do it. It’s called a software‑defined perimeter.

What does a Software-Defined Perimeter Look Like?

The idea of a Software-Defined Perimeter is that every user on your network, whether an internal employee or a third-party that’s associated with doing work for you – a trusted third-party – will have an individualized perimeter around themselves and the network resources that they’re allowed to access.

Software-Defined Perimeter Defined

Figure 3: Software-Defined Perimeter – A new security model which wraps network permissions around each unique user

This perimeter provides fine-grained control for authorized access to those particular destinations, whether on-premises or in the cloud – it doesn’t matter. And that fine-grained control is driven by contextual awareness, including different access methods and authentication methods that can be used to verify that people are who they claim to be. They have proper configurations on their machines, proper toolkits and proper endpoints. It simplifies firewall deployments, giving you a single pane of glass regardless of whether those protected assets are in your data center, a colo facility, a cloud provider, or a hypervisor in a data center somewhere.

Software-Defined Perimeter gives you a single pane of glass to more easily and quickly manage user access to physical, virtual and cloud-based systems. [Tweet this] Tweet: Software-Defined Perimeter offers single pane of glass to easily & quickly manage user access to hybrid environments

Software-defined perimeters also give you the ability to dynamically adjust to new instances being built in the cloud and changes associated with different applications that are deployed there based on tags, values or even security group names. Finally, a software-defined perimeter should deliver consistent access policies across all different heterogeneous platforms regardless of whether they’re physical or virtual servers, running on private or public cloud.

Software-Defined Perimeter and Your Users

On a final note, a software-defined perimeter puts the person back into the security model by taking the source IP concept out of the equation. That is the person, their identity, the machine they’re on, the network they’re connected to and just about anything else you could think of that would make sense for you to analyze before you allow that person, that individual, to access any resources on your network.

Want to learn about Cryptzone’s approach to simplifying, securing and scaling user access for AWS? Watch our on-demand webinar where we outline how Cryptzone’s AppGate helps secure AWS.

Webinar - AWS Security - Simplify Scale and Secure User Access

Back to Blog Home

Jim Anthony

Jim Anthony is Cryptzone's Senior Director of Sales Engineering.

Leave a Reply

Your email address will not be published. Required fields are marked *