Originally posted at https://cyral.com/blog/from-firewalls-security-groups
Several large enterprises we work with at Cyral are working on shifting to a fully cloud-native architecture, and end up leaning on us as a partner to help them fully leverage all the tools at their disposal (one of our engineers recently shared this excellent presentation he had made before a bank). One of the common themes we see is security teams worrying about firewalls becoming less effective in the cloud-native world, and we often find ourselves explaining how tools like AWS security groups are even more powerful and can be used instead. We thought it was worthwhile to write a blog post on this topic.
For decades, companies have only relied on physical network devices called firewalls to wall off and protect their digital footprint. With the meteoric rise and adoption of cloud computing, these devices have been replaced by software defined access controls that now protect increasingly complex cloud native infrastructure. In a traditional network environment, a firewall was placed at the perimeter of the trusted and untrusted zones of the network, monitoring and typically blocking most traffic. In a cloud-native world, modern applications scale up and down ephemeral resources in response to traffic. These ephemeral instances no longer solely exist in a trusted network on site at a corporate office or dedicated data center and require new controls to protect them.
Traditional firewalls were designed to parallel physical security controls. The term firewall was first used by T. Lightoler in 1764[1] in the design of buildings to separate rooms from others that would most likely have a fire such as a kitchen. Firewalls are still used in modern construction to this day. Depending on the type of construction, firewalls are used to slow the spread of a fire, between rooms in a single family home or between adjoining buildings such as in a row home or townhome in order for the occupants to be able to escape [2]. In the physical world, firewalls are rated on the length of time provided to slow down a fire [3]. In the digital world though, firewalls are often thought of as completely blocking outside threats and not merely as a temporary barrier that can eventually be breached.
Network device firewalls were implemented to function as the gate or physical walls of a castle as put forth in the Castle Model of security. This methodology called for building walls which protected the barriers but left the inside of the castle unprotected. Home networks and many corporate offices are still designed this way and still have devices acting as firewalls. These networks are generally end user computers and do not serve content to any other users. Computer network firewalls have existed “since about 1987” as detailed in A History and Survey of Network Firewalls published in 2002 by Kenneth Ingham and Stephanie Forrest. Firewalls have long been promised as the panacea for completely blocking attacks, instead though, they should be viewed as most physical firewalls are: a temporary barrier. To that end, many companies are now moving to a zero trust model where a firewall is only the first barrier protecting the outside and the inside is no longer implicitly trusted [4].
The power of a virtual firewall is that it no longer needs to only have coarse grained filters at the edges of a network. Virtual firewalls can now be assigned to groups of instances and be referenced by others in their configuration. Virtual firewalls are not beholden to network segmentation or physical location they were first set up for. In the classic three tier model, you can now create three virtual firewalls to protect the individual tiers and reference those tiers specifically. In this model, you create individual firewalls for the frontend, application and data layers. In the frontend firewall configuration, you allow https access to only those instances that are responsible for serving frontend content. At the second tier, you reference the frontend firewall only allowing it to access the application layer and block broad access to your application. Finally, at the data layer, you reference the application firewall and allow it direct access to the data layer but block all other access.
In Amazon Web Services (AWS) these virtual firewalls are called security groups. One of the key differences between AWS security groups and classic firewalls is that you can only specify rules that allow traffic. All traffic is implicitly blocked except for the rules that you define to allow. The other key feature of security groups that may differ is that all rules are stateful. When you allow traffic in on a specific port, you do not need to specify allow rules for the return traffic. Security groups function similarly to the classic network firewall model, your allow rules specify a protocol (TCP or UDP) and a port. Security groups can not perform deep packet inspection based on the type of traffic that it evaluates.
In the example below, we look at how you would configure three security groups for the classic three tier architecture. In each example, we choose either a predefined Type which will automatically fill out the Protocol and Port range, or you can choose the Protocol and Port range yourself.
Fig 1. MyWebServer security group allows access to HTTP and HTTPS from anywhere
Fig 2. MyApplicationServer security group only allows access to HTTPS directly from the MyWebServer security group. All other access is implicitly blocked
Fig 3. MyDatabaseServer security group only allows access from the MyApplicationServer security group. All other access is implicitly blocked
AWS has now consolidated security group configuration at the VPC level. In the console, you can access their configuration from the EC2 page or via the VPC page. VPC’s can also implement network access control lists (ACL) that can provide yet another layer of security that is akin to a traditional firewall device. Network ACLs follow the standard firewall convention that you are familiar with including, inbound and outbound rules as well as applying rules in order. Network ACLs are best used as an enforcement of separation of duties, use Network ACLs to enforce minimum policy and security groups for fine grained control of instances. For example, a network ACL could be used to enforce SSH only from a bastion host preventing a security group opening up direct SSH. Security groups are much more flexible, whereas Network ACLs should be used as a backup mechanism.
Fig 4. Default Network ACL giving your instances network access
As your footprint grows, your security groups can quickly grow out of hand. We’ve found that managing security groups as code with Terraform or similar helps with this issue. You should also be mindful of security group quotas. The defaults are 2500 groups per region and 60 inbound and 60 outbound rules. Inbound and outbound rules are enforced separately for IPv4 vs IPv6. If enabled, Trusted Advisor will flag security groups that have more than 50 total rules for performance reasons.
AWS has recognized many of the pitfalls associated with managing security groups per VPC per account and announced their AWS Firewall Manager service in 2018. This is an add on service to AWS Shield and AWS WAF. AWS Firewall Manager for security groups allows you to manage “security groups for your Amazon VPC across multiple AWS accounts and resources from a single place”. Read more on this service here or watch this tech talk.
AWS security groups are an incredibly powerful tool when used in the context of a cloud-native environment. Their simplicity and focus on pure network traffic are a forcing function for clear separation of infrastructure tiers. Their simplicity also gives you the guarantee that they will not interfere with the speed with which you can scale your application. A cloud-native infrastructure provides you with the flexibility to leave the old guard behind and focus on what matters most.
[1] Lightoler, T. 1764. The gentleman and farmer’s architect. A new work. Containing a great variety of ... designs. Being correct plans and elevations of parsonage and farm houses, lodges for parks, pinery, peach, hot and green houses, with the fire-wall, tan-pit, &c particularly described ... R. Sayer, London, UK
Image by Elio Reichert via the OpenIDEO Cybersecurity Visuals Challenge under a Creative Commons Attribution 4.0 International License
Top comments (0)