Names are an integral part of our society. When individuals name a child or pet, they tend to put a lot of thought into the decision. When a manufacturer creates a new product, they spend a great deal of energy to select a brand name that will both accurately represent their offering and resonate with the market. A name allows individuals to tie memories and attributes to a person or object.
The importance of a name does not change in the world of IT. The name of an object on a local server or in the cloud can hold a great deal of meaning or association. Inversely, a hastily chosen name can lead to incorrect associations.
Some IT professionals give little to no thought to the names they assign to objects in their environments, or even worse, they leave the object to be named “default.” This doesn’t help anyone in their organization create important associations with this asset. In a worst-case scenario, these poorly named assets, or misconfiguration, could create a serious security incident. Because let’s be honest, naming an asset incorrectly is indeed a misconfiguration.
Consider this scenario: an administrator in an Amazon Web Services (AWS) virtual private cloud tags two security groups with the following names: DevServer1 and DevServer2.
DevServer1 is appropriately locked down to the correct ports and access to restrict access to these Elastic Compute Cloud (EC2) servers.
DevServer2, however, is completely open to the world for testing purposes.
A second admin, who frankly has put in way too many hours this week, sees both security groups and assumes that the 1 and the 2 appended to the name are referencing the phases of the project, and applies DevServer2 to the new instance they are utilizing to store company confidential information. The confidential information is suddenly much easier for bad actors to access.
Now, the first thing you may be thinking is that the second administrator should have looked at the parameters of the security group before applying it, and you aren’t wrong – they should have. However, the likelihood of this mistake being made would have been reduced significantly if the second security group had been named TEST_DevServer, denoting it as an irregular security group.
The point to all this is, think about what you name things and how the naming convention used will affect others you work with or who operate in the same environment. A naming policy that dictates how to appropriately name objects in your environment will not only reduce mistakes but can reduce time troubleshooting and even during system implementation.
I find that diagrams can often help users more easily grasp naming conventions. Here’s a diagram I created that helps a user decide on an appropriate approach to naming their assets:
Here is an example of the diagram being used to name a role that allows an EC2 instance access to RDS Instance DevTest2:
A last thought: if you have an asset that will operate outside your normal operating procedures, name it so that others will know that is the case. An example would be putting TEST in all caps at the beginning of the name of any object operating outside of normal parameters or a NOT-FOR-USE to warn others. Simply make sure others know the intended use for anything you create and make it easier to grasp that intent by naming things properly from the start.