The Power of Good Server and Endpoint Naming Conventions

Endpoint & Server Naming - Standards Needed

Link copied

When I first started in information technology, one of the more humorous aspects was the host naming conventions customers chose for endpoints – servers and workstations alike. For example, one customer chose starship names from Star Trek, and another customer picked characters from Disney movies. While silly, it was easy to remember “Enterprise” was a file and print server, and “Hercules” was a Domain Controller.

Unfortunately, for many organizations as they began to add dozens, hundreds, and thousands of systems naming conventions became less intuitive, there where fewer names to choose from, and figuring out DS9 was a database server became more obtuse.

I remember one customer being served a legal notice to stop using trademarked names within their organization to designate assets. This was a disaster because, as a consultant, we needed to rename everything – including taking systems off the domain. This entailed renaming them, fixing broken applications (like MS SQL one at the time), and rejoining them to the domain. This was separate from all the entitlement and permission problems. As a result, the customer had to adopt a new naming standard for host names and user accounts and nearly start over.

Today, as information technology has evolved, naming standards are critical and impact everything from unique traits in applications to cloud resources and DevOps. Picking a good naming convention that has longevity for future growth is a crucial first step in any deployment and initial design. Getting it right can be the difference between having a sustainable deployment or a management nightmare. This includes considerations for DNS as well, and names that are readable and able to be remembered by humans.

For a privileged access management (PAM) deployment (and many other information technology disciplines), there is a need to stabilize and solidify the nomenclature chosen for hostnames and credentials. This includes DNS references and differentiators in credentials that designate administrators, standard users, service accounts, and application to application (A2A) accounts. If these are standardized, and not random names (Spock, Wreck_it_Ralph, or Prometheus), rules for automated management, onboarding, and account identification are relatively straightforward. For example, all administrator accounts are designated with a “admin-“prefix or all web servers contain “*web*” in their hostnames and DNS entries.

The downside of an explicit naming is easy identification to threat actors. However, this risk is offset by the consistent application of security best practices and internal ease of use.

IT Server, Endpoint, & Account Naming Conventions - Best Practices for Privileged Access Management (PAM)

Link copied

For a successful BeyondTrust PAM deployment, there are up to eight additional naming convention traits that need standardization for PAM architectural components. Some examples are:

1. Workernode or Resource Broker Name: The agent name assigned to a distributed worker node (on premise deployment) or resource broker (cloud deployment) . This is inherited from the asset host name and may require its own nomenclature schema per location, network segmentation, and per serviced client.

2. Workgroup Name: The unique ownership classification assigned to assets and users to distinguish IP or hostname collision domains. For a single organization, there is typically only one workgroup name, but if multiple worker nodes are implemented or a multitenant deployment is configured, multiple workgroup names will be required.

3. Organization Name: A collection of workgroup names to designate an organization. This is only designated in a multitenant implementation and organization names may be obfuscated to account numbers or other designations to protect the managed identities.

4. Policy Name: The name designated to any privileged policy for context and application access by asset (computer),user (account), or directory services.

5. Smart Group Name: The name logically grouping assets or accounts within BeyondInsight and Password Safe Cloud. This name is visible to end users with the proper permissions and provides role-based access and reporting capabilities by group.

6. Smart Rule Name: The name assigned to an automated rule. Smart Rules can drive automated actions or logical groups (Smart Groups) and be designated for assets, accounts, or risk within the solution.

7. Functional Account Name (Alias): The privileged account on a platform used for management of other accounts, including password rotation. Typically, these are domain accounts, but may exist locally per platform for the management of end user accounts

8. Privileged Account Discovery: This reference name is displayed in BeyondInsight, Password Safe Cloud, and the BeyondTrust Platform for asset, account, and attribute discovery.

From a solution best-practice perspective, keeping this in line with existing standards just makes sense. For example, Workgroup names may be geolocation, VLANs, or ownership-based and may look like “New York Workgroup”, “DMZ X1”, or “Boca Raton Development Lab”, and functional accounts may look like “WinFunctional-Corp.Domain” or “Linux-PCI-Functional”.

A good nomenclature standard specifies any prefix, suffix, and content by word for the naming convention. This can include granularity down to the number of characters and potential combinations of the characters, like the first three letters designating the operating system or the containing solution owner information in a rule or group name. If you are looking for additional guidance, consider the NIST document from 1989 (oldie but relevant goodie), Choosing a Name for Your Computer - https://tsapps.nist.gov/public...

While we consider what a successful privileged access management deployment may look like in your environment, it is important to consider what policies and procedures may need to be enhanced to deploy a sustainable solution. Having standard nomenclature for the unique traits of privilege management will certainly help to streamline the implementation and management beyond your initial deployment.

For assistance in planning your privilege management deployment, contact us today for a strategy session.