One of the most critical elements of an organization’s security posture in AWS, is the configuration of security groups. In some of my architectural reviews, I often see rules that are confusing, overly-permissive and without any clear business justification for the access allowed. Basically, the result is a big, steaming pile of security turds.
While I understand many shops don’t have dedicated network or infrastructure engineers to help configure their VPCs, AWS has created some excellent documentation to make it a bit easier to deploy services there. You can and should plow through the entirety of this information. But for those with short attention spans or very little time, I’ll point out some key principles and “best practices” that you must grasp when configuring security groups.
- A VPC automatically comes with a default security group and each instance created in that VPC will be associated with it, unless you create a new security group.
- “Allow” rules are explicit, “deny” rules are implicit. With no rules, the default behavior is “deny.” If you want to authorize ingress or egress access you add a rule, if you remove a rule, you’re revoking access.
- The default rule for a security group denies all inbound traffic and permits all outbound traffic. It is a “best practice” to remove this default rule, replacing it with more granular rules that allow outbound traffic specifically needed for the functionality of the systems and services in the VPC.
- Security groups are stateful. This means that if you allow inbound traffic to an instance on a specific port, the return traffic is automatically allowed, regardless of outbound rules.
- The use-cases requiring inbound and outbound rules for application functionality would be:
- ELB/ALBs – If the default outbound rule has been removed from the security group containing an ELB/ALB, an outbound rule must be configured to forward traffic to the instances hosting the service(s) being load balanced.
- If the instance must forward traffic to a system/service outside the configured security group.
AWS documentation, including security group templates, covering multiple use-cases:
There’s also an first-rate article on visualizing and cleaning up security groups using AWS Elastic Search with Kibana.
Security groups are more effective when layered with Network ACLs, providing an additional control to help protect your resources in the event of a misconfiguration. But there are some important differences to keep in mind according to AWS:
|
Security Group
|
Network ACL
|
|
Operates at the instance level (first layer of defense)
|
Operates at the subnet level (second layer of defense)
|
|
Supports allow rules only
|
Supports allow rules and deny rules
|
|
Is stateful: Return traffic is automatically allowed, regardless of any rules
|
Is stateless: Return traffic must be explicitly allowed by rules
|
|
We evaluate all rules before deciding whether to allow traffic
|
We process rules in number order when deciding whether to allow traffic
|
|
Applies to an instance only if someone specifies the security group when launching the instance, or associates the security group with the instance later on
|
Automatically applies to all instances in the subnets it’s associated with (backup layer of defense, so you don’t have to rely on someone specifying the security group)
|
Additionally, the AWS Security Best Practices document, makes the following recommendations:
- Always use security groups: They provide stateful firewalls for Amazon EC2 instances at the hypervisor level. You can apply multiple security groups to a single instance, and to a single ENI.
- Augment security groups with Network ACLs: They are stateless but they provide fast and efficient controls. Network ACLs are not instance-specific so they can provide another layer of control in addition to security groups. You can apply separation of duties to ACLs management and security group management.
- For large-scale deployments, design network security in layers. Instead of creating a single layer of network security protection, apply network security at external, DMZ, and internal layers.
For those who believe the purchase of some vendor magic beans (i.e. a product) will instantly fix the problem, get ready for disappointment. You’re not going to be able to configure that tool properly for enforcement until you comprehend how security groups work and what the rules should be for your environment.
Postmodern Security 
There is a recipe to solve some of what you describe in the book, Infrastructure-as Code (IAC) Cookbook called “Using AWS Security Groups with Terraform” and more. Many options, but any preferred?
Thank you especially for the discussion and the Kibana link.