Getting Started with Network Security from AWS, Azure and Google

All public cloud vendors provide the notion of a software defined data center with its own resources and secure networks. A strict separation exists between the various customers’ environments on a common and flexible infrastructure.

Over the last two years, competition has increased as Azure and Google joined the AWS led IaaS cloud market. As a result, IT organizations have started to plan and adopt multi-cloud strategies. However, as with every aspect of cloud management, IT organizations have been facing the challenge of figuring out which network security capabilities were offered by each provider.

I’ve created this two part series as a contribution to those who wish to better grasp the options and differences between the leading public cloud providers’ network security capabilities. In this post, we will focus on network security management, the terminologies each of the three leading cloud vendors use, their core features, and key differences.

Amazon Web Services (AWS)

To be clear, this section is oriented towards VPC technology and doesn’t cover the deprecated EC2-classic. Amazon offers the two leading network security concepts: Security Groups and NACLs.

Security Groups
AWS security groups enable you to model network security policies into logical groups of servers, then apply a policy at scale. A security group policy (whether of inbound [ingress] or outbound [egress] rules) can be modified at any time, and automatically be applied to the instances associated with the security group. An instance can be a member of up to five security groups and each security group can have up to 50 rules.

As a key AWS functionality, elasticity is an integral part of the cloud and therefore of a security group’s behavior. New instances that are assigned to a security group inherit the group’s pre-defined rules. With security groups, you can apply policies to groups of instances that have the same role such as database servers, front end servers or even operational monitoring servers. There is no need to create specific rules for individual instances.

Another core feature is that AWS provides the ability to create one security group as a source of another security group, to control group-to-group communication. This ability further reduces the friction associated with maintaining hard-coded IP addresses in security group rules. For example, if a database tier were set up to automatically connect to a web tier, when more web servers are added, they will connect to the database servers automatically. It is important to note that a security group can only reference other groups when they are in the same VPC network. And since a single VPC cannot span multiple regions, the network setup is limited to a specific region, which might become problematic in a large network that needs to span multiple geographies.

The concept of having elastic security groups that can be used as a source was one of AWS’ main innovations back in 2006. Though similar mechanisms were implemented by other vendors, AWS network security capabilities stand out in the crowd due to their level of maturity. This can be seen in VPC Flow Logs, for example, the firewall logging feature that was announced a few weeks ago. Once enabled, network activity traffic is logged and stored for further analysis.

source:AWS documentation

Network Access Control List (NACL)
Another approach to network security is via NACLs. Amazon regards NACLs as an optional layer of security regulating the inbound and outbound traffic of a subnet. As shown in the diagram below, NACLs are assigned to network elements and subnets, whereas security groups are assigned to instances. NACLs are used to model high-level network topology while the fine-grained policy is left to security groups. In short, NACLs enable you to describe whether a network is private or public as well as the data flow between separate networks.

Another important characteristic is that NACLs are stateless. Return traffic must be explicitly allowed by rules. Security groups, on the other hand, are stateful, so return traffic is allowed based on the state of the connection (the initial traffic).

Unlike security groups, which can only be defined by positive (accept) rules, NACLs can be defined by negative (drop) rules. This characteristic requires NACL rules to be ordered, which is of importance when it comes to regulating traffic. For example, if a drop rule is defined before an accept rule, traffic would not flow. When rules are solely positive (as in security groups), the order in which they are written is of no significance.

Microsoft Azure

In 2013, Azure introduced its IaaS offering to compete with the growth of AWS. At that time, Azure introduced Virtual Networks (VNet), isolated private networks. As Azure matured, so did its network security capabilities, including the Azure NACL and Network Security Groups (NSGs):

Network Access Control Lists (NACLs)
Initially, Azure approached network security using NACLs. They were solely used to define network policies for ‘endpoints’, which are port mappings between the internet and instances (port-forwarding)

As opposed to AWS security groups, Azure NACLs did not allow you to configure and segregate internal networks. This created a significant distinction between AWS and Azure until Azure security groups were brought into the picture, ultimately replacing Azure NACLs.

Network Security Groups (NSGs)
Towards the end of last year, the Azure team announced their new security groups capability. While Azure’s security groups resemble those of AWS, there are three major differences:
1. Each instance can only be a member of a single security group.
2. An Azure account can have up to 100 security groups and each security group can contain up to 200 rules.
3. There is no notion of a security group as an element in a security policy. Azure requires members’ IP addresses to be defined in detail.

Unlike AWS, the Azure NSGs can be assigned to a network element or to an instance. The diagram below shows how NSG1 is applied to a specific VM (VM1), while NSG2 applies to the entire subnet:

source: Azure blog

For more information, check out the latest Azure Network Security white paper.

Google Compute Engine (GCE)

Google has yet a different approach to network security. The basic construct is simply named ‘firewall’, which is a container for a single rule. This tag-based security control is similar to AWS security groups insofar as it groups certain elements together.

Unlike AWS, the tags Google uses are the same generic ones that are used for other means such as grouping resources, automation, and so on. This could actually be a disadvantage for organizations that prefer a clear separation of concerns—meaning only network security engineers should be allowed to configure the firewall. This goal is more challenging to accomplish, however, when a wider audience in the organization can manage tags (e.g., the billing department).

Specifying ’targetTags’ means that the associated firewall rule applies to all instances that share the tag-—much like specifying a rule for a specific AWS security group. If not specified, the associated firewall rule applies to all instances on the network—similar to Azure NSGs.

Like AWS (and unlike Azure), you can specify ‘sourceTags’ to control which instances are allowed to access a rule’s targets (again, without hard-coding IP addresses).

As GCE firewalls only regulate incoming (ingress) traffic to an instance, egress filtering should be applied by alternate technologies such as host firewalls (iptables, Windows Firewall or the Dome9 agent).

Summary

For a breakdown of each cloud, see the table below:

In the next post, we will create a virtual web application from various security components (i.e., firewall, load-balancer, subnet and VPN), model it according to the vendors listed above and learn how to secure an entire web application network.

Roy Feintuch
Roy Feintuch is Co-founder and CTO of Dome9 Security, a cloud security leader that works across all 3 cloud platforms mentioned in this blog post.