The Best Practices for AWS Security Group Naming Conventions

Getting AWS security group naming conventions right can have a major impact on cloud infrastructure security. Poor naming conventions increase the likelihood of misconfigurations and human error, while well-structured naming conventions reduce risk. To understand why it’s useful to take a step back and consider the purpose and use of security groups.

AWS Security Groups act as a firewall and control incoming and outgoing traffic from instances. The initial default security group of a VPC has an inbound rule allowing unrestricted access from itself and unrestricted outbound traffic to the Internet.

Organizations can also create security groups later for specific use cases. Security group rules contain source, destination, protocol, and port ranges.  A resource can have multiple security groups attached, and the rules are evaluated in combination to block or allow traffic.

The challenge comes when there are multiple security groups in use. Multiple security groups can have different rule sets. Human error can lead to a group being accidentally used with unintended resources. It becomes difficult to organize, filter, and use security groups without a proper naming convention.

It may also accidentally lead to modifying a security group with an over-permissive rule set (e.g., making a DB publicly accessible) because of a lack of proper naming schemas.

Having a proper AWS security group naming convention is essential to avoiding these risks and identifying, organizing, and using the appropriate security groups and resource combinations.

This article will take a deep dive into AWS security group naming conventions and provide strategies for developing naming conventions.

Executive summary

Below is an executive summary of the key areas covered in this article.

AWS Security Group Naming Convention Key Concepts

Advantages of proper AWS security group naming conventions

A well-developed naming convention promotes consistency and helps in identifying, filtering, and organizing security groups. It also helps avoid naming collisions, which leads to accidental use of security groups with similar names. A proper naming scheme also makes it easier for humans to understand security configurations.

Other benefits of well-defined AWS security group naming conventions include:

• Restricting security group modifications to the stakeholder with condition keys
• Establishing a foundation for cloud governance
• Clearly defining the role and ownership of security groups
• Streamlining the process of locating and differentiating security groups

Advantages of good naming conventions for a security group.

Defining AWS security group naming conventions

Organizations without a standardized naming convention risk creating AWS security groups with similar names. AWS security groups with similar names can lead to the unintended exposure of resources. This usually isn’t a problem for small deployments, but it can become unmanageable as the resources and environments grow.

Here is an example of AWS security groups with no naming convention.

An example of a poor AWS security group naming convention.

That’s a bad naming convention because it does not include relevant attributes, is very basic and descriptive, and may make searching and filtering difficult as an organization grows. It may also pose security risks due to the descriptive nature of names.

Self-assigned names from the AWS Console can also lead to problems. They may look like the image below.

AWS security groups using self-assigned names.

Those may result in a situation where identifying the security groups would simply become impossible without an external reference.

Defining a naming convention for security groups that follow enterprise standards helps promote consistency, streamlines searches, and simplifies organization. A good naming convention should define how organizations name new security groups. For existing security groups, a good naming convention should also clearly define the purpose, location, and point ownership to the internal teams.

Guidelines for AWS security group naming convention

While defining the naming convention, an organization should keep the following basic guidelines in mind:

• Use a simple and easy-to-follow naming pattern.
• Check for typos in security group names.
• Use automation to build the resources and security groups so that there are fewer chances of errors. You can use CloudFormation templates to create security groups that follow the standards.
• Maintain consistent naming conventions throughout the organization
• Use codes instead of the description naming convention. For example, use “P” instead of “Production” or an application code instead of a complete application name.
• Use logical order that moves from general to specific. For example, put AWS region before environment and application name code before the application version.
• Do not reveal the intent of the security group with the name, e.g., Public-SSH-securitygroup. Such patterns help predict the rules of the security groups and can be abused by attackers. We’ll review this topic in detail in the next section.
• Include all attributes in the name code that helps identify specific security groups
• If you intend to use VPC peering, do not use the same name of security groups in the VPCs you will peer. For example, don’t use the same names for a development environment and test environment in different VPCs.

Security risks associated with descriptive naming conventions

While descriptive naming conventions for security groups can be easier to understand, they come with security risks. Descriptive security group names can reveal much information about their environment. This information can result in an attacker exploiting the services offered by the environment behind the security groups.

For example, the security group name LmsProdDB-Securitygroup is descriptive and reveals information about which security group contains a production database.

Also, a naming strategy should be kept internal in the organization to avoid exposure to hackers. Hackers are always on the hunt to do reconnaissance about organizations, so they target and use any information available publicly.

Common AWS security group naming strategies

Organizations use various naming strategies for security groups. Below is an example strategy shared by the co-founder of Invisibl Cloud.

An example AWS security group naming convention. (Source)

This naming convention follows a “general to specific” pattern and uses codes instead of descriptive keywords in the naming strategy. It is an example of a good naming convention.

Below is another example of a naming convention that is somewhat descriptive and reveals information about the type of application and its streaming methodology.

Organizations should define codes for applications internally that are well understood and use them instead of using the application name. Here, A001 or a similar code is better than using’ blog’. As a prerequisite for the “A001” decision, the organization should have previously decided and written in the naming strategy that blog==A001, Gamingapplication=A002, etc.

Using automation to create AWS security groups with proper naming conventions

Once AWS security group naming conventions are defined, organizations should use automation to create compliant security groups. For example, teams can develop a CloudFormation template or Terraform script to create security groups that follow a specific naming convention.

CloudFormation templates should be peer-reviewed in order to confirm they follow the defined standards. The security groups created using automation are generally less prone to errors and are more consistent than manually created groups.

Auditing existing AWS security group naming conventions

After an organization has a well-defined naming convention in place for the security groups, it should review existing security groups. By reviewing and updating existing security groups, the organization can achieve a consistent naming convention across their environment.

The organization should also define a strategy to periodically monitor, alert and assign a ticket to the owner of the security group (if identifiable) to review the security groups that don’t follow the naming convention. Automation can be built around the process  to automatically check new security groups and alert the owner if non-compliant. For example, the CloudTrail  CrateSecurityGroup event and an alert from CloudWatch and Lambda  can help detect non-compliance. Organizations can also prevent the creation of security groups that don’t follow the naming convention using IAM condition keys.

Monitoring AWS security groups

Whether following a naming convention or not, the creation and deletion of security groups should be monitored as part of a well-established security posture. An open source Cloud Security Posture Management (CSPM) tool such as Paladin Cloud’s Open Source Community Edition uses preset security policies based on industry best practices to continuously monitor changes in your AWS and hybrid cloud environment, visualizes the status, and takes predefined auto-fix actions to remedy security exposures.

Conclusion

Following bad naming conventions can lead to security holes and accidental resource assignments. A consistent naming scheme for security groups is essential and a prerequisite for building cloud governance. Following a good naming convention can eliminate naming collisions, build a professional and clean layout of security groups, make them organized and easily searchable, and reduce the risk of accidental exposure of resources behind security groups.