AWS Security Group Best Practices

Security Groups are an essential part of security within the AWS ecosystem and likely one of the first resources deployed by people using the EC2 Launch Wizard during their initial steps using the platform. When configured correctly, they provide security by restricting network access based on a combination of IP address(es), and TCP/IP protocols and ports. Unfortunately, the default options presented are often inherently insecure.

As described in the AWS Shared Responsibility Model, customers are responsible for the security of their applications and their data “in the cloud”. It is extremely important therefore that AWS customers understand how and when to use security groups, and be aware of their limitations.

AWS Shared Responsibility Model (source).

Executive summary

Below is an overview of common mistakes and misconfigurations made when using AWS security groups, brief explanations of the issue, and the corresponding best practice to resolve or mitigate it. You can find more detail on the best practices themselves later in this article.

Background

In order to maximise an appreciation of the best practices, it is important to know what security groups are and how they work.

• Security groups are access control lists (ACLs) that allow network traffic inbound and outbound from an Elastic Network Interface (ENI) – they act as a basic firewall for all AWS resources they are attached to
• Security groups implicitly deny traffic, but their rules are permissive. They only have “allow” rules, not “deny” rules. Therefore, the absence of an “allow” rule denies access
• Security group rules are “stateful” – this means that if a server can communicate outbound to a service, the return traffic is also, automatically permitted. This is in contrast to Network ACLs (another AWS security tool applied at the subnet level) which are “stateless”
• Security groups are VPC specific (and therefore region-specific) – they can only be used within the VPC they are created. The exception is where there is a peering connection to another VPC, in which case they can be referred to in the peered VPC.
• Security groups can be applied to multiple instances within a VPC, and work across subnets within that VPC.

Security groups assigned to EC2 and RDS instances across subnets in a VPC

• When a VPC is created, a “default” security group is created within it. This has no inbound rules and a single outbound rule, which allows all traffic to any destination (0.0.0.0/0). If a new resource is launched within the VPC without association to a security group, it will automatically be assigned to this “default” group.
• By default, a new security group attached to a group of instances will not allow these to communicate with each other. To allow this, create new inbound and outbound rules, then set the source and destination as the security group itself.

Screenshot from the AWS console showing a security group with both inbound and outbound rules allowing SMB traffic to itself

• Security groups are assigned to the Elastic Network Interface (ENI) attached to an instance, as opposed to the EC2 / RDS instance itself
• You can assign up to five security groups to each Elastic Network Interface. An EC2 instance with multiple ENIs could therefore have more than five security groups assigned to it, though this is not recommended

AI-powered Continuous Cloud Governance

Platform	Provisioning Automation	Security Management	Cost Management	Regulatory Compliance	Powered by Artificial Intelligence	Native Hybrid Cloud Support
AWS Native Tools	✔	✔	✔
CoreStack	✔	✔	✔	✔	✔	✔

Best Practices

While security groups are one of the more basic resources available within AWS, due care and consideration should be taken to ensure that they are configured correctly. Here are six best practices to assist in that process.

Avoid the use of the “default” security group

The “default” security group should not be used for active resources. This is because new AWS resources could be inadvertently assigned to it and thus allowed inappropriate access to confidential material. Since it cannot be deleted, delete all inbound and outbound rules in the “default” group instead. Then,  create new security groups for your AWS resources. This also ensures thay any new AWS resources must be assigned to the correct security group(s), as no communication would be possible via the default group.

Keep the number of security groups to a minimum

By default, the AWS EC2 Launch Wizard will encourage you to create a new security group for each EC2 instance. The problem here, is that it eventually leads to the creation of numerous security groups, which subsequently become hard to manage and track. Instead, employ a strategy that creates security groups based on application access requirements, and then assign them accordingly.

Restrict, restrict, restrict

Ensure that all new security groups apply the principle of least privilege:

• don’t open inbound traffic for the entire VPC CIDR range or subnet unless absolutely required and avoid allowing all IP addresses (0.0.0.0/0) unless completely necessary. For example, if allowing inbound SSH access to a Linux instance for management purposes, restrict this traffic to the public IPs of those specific sources
• ensure outbound traffic is restricted where possible e.g. do not open all ports to the internet, instead, use only HTTP/HTTPS to allow internet browsing. If allowing a specific service, only open the ports and protocols relevant to that service. For example, for DNS, open port 53 for both TCP and UDP, and only to the external DNS provider (E.g. 8.8.8.8/32 for Google)
• open relevant ports and protocols to other security groups, rather than IP addresses/subnets. This is because AWS prefers and recommends dynamic IP addresses. See the below example where a load balancer has been allowed to talk to all web servers in an auto-scaling group using HTTP, which in turn have been allowed to talk to all MySQL databases in the cluster, on port 3306/TCP

Security group rules allowing traffic from and to another security group

Screenshot from the AWS console showing resource groups with access to and from other resource groups

Develop a security group strategy

Decide on a clear strategy for creating and using security groups based on your application requirements. Then, use AWS tools to aid enforcement. Examples of options to consider for your strategy are:

• establish the best way to set up your security groups. For example:
  1. one security group per service type, such as “rdp-access”, “ssh-access”, “web”, “active-directory”, “mysql-db”, and then assign the relevant inbound and outbound ports for that service
  2. one security group per application type, such as “web-servers”, “db-servers”, “file-servers”, and then assign the relevant ports for that application
  3. one security group per operating system, such as “windows” or “ubuntu-linux”, and then assign ports common to that OS.

💡 Pro-tip: you could further sub-divide these into internally and externally facing systems, providing even more flexibility.

• create one or two default groups that cover access requirements common to all servers in the VPC. Then, enforce the assignment of these to all resources created within that VPC (NB – these should be new groups and not confused with the automatically created AWS “default” group discussed earlier). This helps minimise the total number of security groups required. For example:
  1. if all instances need to talk outbound using HTTP / HTTPS to browse the internet
  2. if all instances need to allow an inbound port for a monitoring system. This could be linked to a “monitoring” security group that has outbound access to the custom VPC default group(s)
• the strategy should aim to minimise the number of security groups created and assigned to AWS resources. Otherwise, excessive security group sprawl will make management and troubleshooting difficult
• use a naming strategy that provides clarity and avoids confusion. Remember, it is possible to have multiple peered VPCs. As such, if each VPC has a security group called “web-servers”, it will become difficult to keep track of which one is which

Simplify management

As time progresses and the environment becomes more complex, the management of security groups can become increasingly demanding. It is important to put into place strategies and toolsets as early as possible, to ensure that security is not compromised from administrative errors. Below are some recommended approaches:

• as with other cloud resources, it is a best practice to deploy and manage security groups using an Infrastructure as Code solution, such as AWS CloudFormation or Hashicorp Terraform. These tools make it easier to conduct complex changes to deployments and simplify compliance enforcement. Non-approved changes can now be quickly identified and reverted
• use Managed Prefix Lists to group IPv4 / IPv6 address ranges to simplify security rules. AWS themselves use these lists to allow traffic to AWS services, such as S3. For example, a managed prefix list can be created to maintain a list of internal subnets used within a large corporation, or to provide access to trusted third-party external clients

Screenshot showing AWS S3 IPs in a Managed Prefix List in the AWS console

• AWS Firewall Manager is a tool that can be used to create security group policies and associate them with accounts and resources. It can also monitor, manage and maintain the policies against all linked accounts

Develop and enforce a security group monitoring and compliance solution

It is not enough to just simply develop a security group strategy based on best practices. It is also necessary to enact monitoring and remediation steps that ensure that best practices are maintained. Below are examples of supporting tools that can help:

• AWS Security Hub works with CloudTrail and CloudWatch to monitor and trigger alarms based on security best practice alerts. One thing to look out for is the rate of change within security group rules – flag suspicious activity for investigation, such as ports being opened and closed again within a short timeframe
• AWS Config is used to ensure compliance with key best practices. Config Rules can be created to check and alert for non compliance, and then perform automated remediation steps. Examples are, checking for unrestricted security group rules and ensuring that the “default” security group has no inbound or outbound rules
• for complex environments, use Infrastructure as Code along with AWS Lambda and AWS Developer Tools (CodeCommit / CodeBuild / CodePipelines) to automatically remediate unauthorised changes made within the AWS console.
• finally, ensure that IAM security policies are configured to limit an administrator’s accessibility to make these changes. For example, restrict access to amend security group rules to a programmatic role, that an IAM user must then assume. This activity can be tracked and monitored to ensure compliance.

Challenges

The use of Infrastructure as Code is mentioned a few times within the above best practices, as well as monitoring and tracking for unauthorised changes. Even with these implemented, if these processes are manual they become time consuming and unscalable.

To mitigate this, end to end automation of the process is crucial. Automated continuous integration and development (CI/CD) pipelines provide a mandatory approval process for new code when committed post initial code reviews. Automated unit and  tests, as well as security vulnerability checks ensure the code is correct and safe to implement. For production environments, pipelines can introduce manual approval checks for extra peace of mind. Once approved, the pipeline then automatically triggers the deployment of the new infrastructure. Additional automated pipelines can be built to periodically monitor for unauthorised changes that deviate from the current codebase stored in the repository and either notify of these, or automatically back out these changes.

AI-powered Continuous Cloud Governance

Platform	Provisioning Automation	Security Management	Cost Management	Regulatory Compliance	Powered by Artificial Intelligence	Native Hybrid Cloud Support
AWS Native Tools	✔	✔	✔
CoreStack	✔	✔	✔	✔	✔	✔

Conclusion

Security groups are an essential part of securing incoming and outgoing network traffic within a VPC. However, they have limitations and should not be your only line of defence. AWS provides a host of additional networking security tools, such as Network ACLs, AWS Network Firewall, DNS Firewall, AWS WAF (Web Access Firewall), and AWS Shield, as well as monitoring and compliance tools such as AWS Security Hub, GuardDuty, and Network Access Analyzer. When used collectively, these tools will help to protect your applications and data from being compromised.