The world is up in the cloud, and with over a million active users, AWS is winning the cloud game. While AWS is generally safe and secure, the configurations and security settings often let organizations down. 

73% of businesses have at least one critical security misconfiguration. When a data breach occurs, it's not due to the integrity of AWS but rather human error due to a lack of auditing and proper security posturing.

AWS is a shared responsibility model. While AWS is responsible for the security of the underlying infrastructure, you are responsible for the security of your data and applications. This is where security groups come in. This article guides you through some essential best practices to adopt when using AWS security groups, the backbone to securing your data and applications running on AWS. 

What are AWS Security Groups?

AWS security groups are tools used to manage network access to AWS resources. They act as a virtual firewall for your AWS account, controlling inbound and outbound traffic. Security groups are made up of rules that define what traffic is allowed in or out of an AWS resource. When you create a new AWS resource, you can specify which security group it should belong to. You can also add and remove resources from security groups as needed.

‍

How do AWS Security Groups work?

AWS Security Groups are a set of networking security rules that can be applied to AWS resources. They act as a virtual firewall for your AWS account and can be used to control inbound and outbound traffic to and from your AWS resources. Security groups can allow or deny traffic based on various criteria, such as IP addresses, port numbers, and protocols.

You can create multiple security groups for each VPC and add rules to each group based on your security needs. For example, you could create a security group for your web servers that allow inbound traffic on port 80 (for HTTP traffic) and port 443 (for HTTPS traffic) and another security group for your database servers that allow inbound traffic on port 3306 (for MySQL traffic).

When you create an AWS resource (such as an EC2 instance or an RDS database), you can specify which security group(s) to assign to that resource. All traffic to and from that resource will be subject to the rules of the security group(s).

You can also change the security groups assigned to a resource at any time. For example, if you need to allow access to your database servers from a new IP address range, you can add a rule to the security group for your database servers.

Which services need Security Groups?

All AWS services require security groups in some way, although they are most commonly associated with EC2 compute instances. Amazon EC2 is also one of the most widely used AWS services. AWS operates a Shared Responsibility Model, meaning that security responsibilities are shared between AWS and the client. While AWS offers some level of cloud protection, you are still responsible for managing the configurations of your security groups.

‍

8  Best Practices When Using AWS Security Groups

AWS is a complex platform with over 200 different types of services, so it can be challenging to navigate. Best practices when using AWS security groups reduces this complexity into a checklist guide, helping your organization to keep track of different security settings and options comprehensively and predictably.

While open-source security tools exist to help mitigate problems, starting from the bottom up with AWS security rules can significantly reduce potential threats to your servers and services. Here are eight best practices when using AWS security groups.

1. Authorize only specific IAM principals and IP address ranges to access groups

If left unchecked, anybody with access to the IAM console could modify access groups and potentially grant themselves unauthorized access to sensitive resources. To prevent this, users can restrict permissions to the IAM console to specific IAM principals and IP address ranges. This way, only authorized users can modify access groups, and unauthorized access attempts can be easily detected and blocked.

2. Avoid using "default" security groups

Default security groups can be harmful because they allow all inbound and outbound traffic. Anyone with access to the default security group can access all of the resources in your account. To manage default security groups, you should create a new security group and add only the specific rules you need.

3. Restrict inbound and outbound access

Any malicious user who gains access to the network can cause harm if all inbound access to some or all ports is allowed. By restricting inbound access, you can help to prevent unauthorized users from gaining access to the network.

Similarly, if all outbound access is allowed, then any user on the network can send malicious data out to the internet. By restricting outbound access, you can help to prevent users from sending out malicious data.

‍

4. Simplify the management of security groups

The complexity involved in managing and monitoring various security groups can be daunting. By adding a short description to individual security group rules, you can avoid tracking this information using spreadsheets or other documents that can easily be misplaced. You can add details to each rule, such as when or why it was created, making it easy to find information within AWS VPC and AWS EC2-Classic security groups.

5. Minimize the number of security groups

It is generally considered best practice to minimize the number of security groups to simplify auditing and managing errors. Too many security groups can also lead to excessive permissions and access to resources. Make sure you use each security group to manage resources that have similar functions or security requirements - this will make it easier to reduce the number of security groups and prevent errors.  

6. Delete all unused security groups

You shouldn't keep unused groups because they can be a security risk. If someone gains access to an unused group, they could use it to gain access to resources that they shouldn't have access to. You can use the AWS console or the AWS CLI to delete an unused group.

7. Avoid using large port ranges

Avoiding large port ranges is essential when configuring security groups because doing so enlarges the system's attack surface. Attackers can target any open port within the range, making it more likely that they will be able to find a way into the system.

To avoid this, you should configure security groups with only the necessary ports. This way, if an attacker does find an open port, they will not be able to access any other parts of the system.

8. Enable VPC flow logs on inter-VPC flows and internet flows

VPC flow logs can help debug and troubleshoot inter-VPC communication and internet connectivity issues. By default, VPC flow logs do not capture traffic within the same VPC. However, you can enable VPC flow logs on inter-VPC flows by creating a flow log with the selected desired traffic type. For internet flows, you can allow VPC flow logs on the internet gateway attached to your VPC.

Continuous AWS Security for your DevOps

AWS security groups are indispensable for securing your AWS environment, but there should be other security measures you take. Security posturing and implementation shouldn't happen after a breach or event has occurred but rather throughout the entire CI/CD pipeline. 

Combining security groups with other application security tools, such as Gitleaks and OWASP ZAP, is vital to create a comprehensive DevSecOps strategy. Jit makes it simple to embed security controls across the DevOps workflow. Help your teams be proactive rather than reactive. Jit enables you to integrate with various security tools that cover all layers of your cloud app— code, CI/CD pipeline, cloud, APIs, and more.