Names are important. They ensure appropriate communication between colleagues. It is a lot easier to call out for “Omar” or “Miriam” than it is to holler, “Hey you” and hope for the best in a crowded room. The same principle applies to the technology stack and names we assign to electronic assets. When I started out, people named assets based on their pets, their favorite movie and television characters, and a host of other memory touchstones to aid in their identification of network devices and services. And in this sea of “MickeyMouse” file servers and “DarthVader” domain controllers, we thrived.
No longer. The region’s mass migration to new cloud-based environments and obscured endpoints has led to the introduction of truckloads of systems and devices. Remembering that “TheMatrix” is a database server becomes a lot more difficult in such environments when the name is obfuscated based on the quantity of devices and automation. In the cloud, they almost appear fully randomised, and choosing names on your own can become an unforeseen problem. A colleague once told me a story of a customer receiving a legal cease and desist notice on the use of trademarked names for technology assets. Needless to say, compliance was expensive because everything had to be renamed and services reconfigured, which meant considerable downtime. Add on top of all that they needed to update entitlements and permissions for all users nearly from scratch. The theme should be clear. I repeat: Names are important.
Today, naming standards impact the way applications behave; they govern access to cloud resources; and they affect the smooth running of DevOps. The elasticity of the modern network, designed as it is for limitless growth and instant acceleration, demands more thought when coming up with naming conventions. The days of chuckling like school kids as we assign witty monikers to our servers and workstations are gone. Sensible systems for naming mean the difference between sustainable deployment and an administration nightmare. And while we are at it, we should also think long and hard about DNS, picking names that are clear and memorable will help end user accessibility. This is especially true for asset administration by solution owners. What are the names administrators and systems should have for management?
PAM — more than just a name
Privileged Access Management (PAM) is an integral part of modern governance, and it alone is reason enough to take naming conventions seriously, although good practices will also benefit everyone across the IT stack. Hostnames, credentials, DNS references, and other elements must be considered, and it is an excellent idea to include differentiators in credentials that allow the account’s role to be easily recognizable but not simply guessable like “XAdmin” or “Xroot”. For example, administrator, standard user, service, or application to application (A2A) should be identifiable but not predictable. To standardise the “thinking up” of names is to lay the groundwork for robust policy rules that control, say, automated management, onboarding, or account identification. If we use an “admin-” prefix for administrator accounts and Web host names contain “*web*” for the purposes of DNS entries, we are off to a good start but they are guessable based on a user’s role. We need to also make them not predictable.
Detractors of these naming practices will say we are making life easier for threat actors to determine the name of an asset or privileged user, but this is no different than determining a user’s email address and targeting them with spear phishing emails based on the corporate email naming format. All the threat actor needs is a sample of emails to determine the format. Therefore, we need a small touch of randomisation and obfuscation to ensure that an entire internal or cloud infrastructure does not have a predictable naming nomenclature, regardless if it is private or public.
The most successful PAM deployments happen under strict naming conventions to incorporate all of these traits. These include naming considerations for:
- Names assigned to distributed worker nodes, in on-premises deployments, or to resource brokers, in cloud deployments, must originate from the asset host name and include name attributes for location, network segmentation, and serviced client.
- Workgroup names are used to designate collective ownership of assets and users to avoid hostname and IP collision domains. Many organisations will use a single workgroup name, but if multiple worker nodes are deployed or the organisation is using a multitenant model, multiple workgroup names will be required.
- In multitenant environments, organisation names will be required to cover the various workgroups that have been implemented. Since organisation names are one-offs, it is okay (and even preferable) to use account numbers (or similar obscure naming conventions) to protect managed identities.
- Policy names — those used to denote privileged policies for context and application access by asset, identity, account, or directory service — should also be considered.
- Smart group names allow a logical grouping of assets or accounts. Their naming requires clarity because they are visible to authorised end users and provide role-based access and reporting capabilities by group.
- Any automated rules (or “smart rules”) must also be appropriately named. Controlled by asset, account, and risk, these are useful for governing the permissions of logical groups or initiating actions and workflows for control or mitigation.
- Functional account names are aliases for privileged accounts on a platform used to manage other accounts, including the enforcement of password rotation. While normally domain accounts, these may be local to a platform for the purposes of end-user account management or locally installed applications.
What’s in a name? Quite a lot, says PAM
By now, the best-practice examples above should make sense for the smooth operation of several mission-critical platforms and solutions, including PAM. Workgroup names may be based on location, VLAN, or ownership and may resemble “Ajman Workgroup”, “DIFC A1”, or “Abu Dhabi Research Lab”, and functional accounts may take the shape of “WinFunctional-Corpxyz.Domain” or “Linux-PCI-Functionalabc” where “xyz” and “abc” are a unique randomised components to support obfuscation. Robust, futureproof nomenclature standards will call for prefix, suffix, and content by word for the naming convention. If required, specifications can extend even to the number of characters and potential combinations of characters, such as the first three letters standing for OS. All of these are potential options based on your business needs.
Now that the headlines tell us just how costly compromised credentials can be, it behooves us to implement privileged access management under best-practice standards, including strong naming conventions. Standard nomenclature can drive tight privilege management and streamline its implementation while maintaining security best practices.
So, what’s in a name? Perhaps in days gone by, very little beyond a brief giggle shared among back-office IT staff. But today, amid the complexity of the multi-cloud technology stack, names may very well be the difference between longevity and sudden ruin. Getting them right for new projects and initiatives like PAM will help ensure their success.
