When I first started in information technology, one of the more humorous aspects was the naming convention customers chose for servers. 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 that “Enterprise” was a file and print server, and “Hercules” was a Domain Controller.
Unfortunately, as we began adding dozens, hundreds, and thousands of systems we ran out of names, and figuring out that DS9 was a web server became less intuitive. In addition, I remember one customer actually being served a legal notice to stop using trademarked names within their organization to designate assets. That was a disaster in itself 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 at the time), and rejoining them to the domain. This was completely 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.
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.
For a privileged access management (PAM) deployment, there is a need to honor 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 Voyager), 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.
For a successful BeyondTrust PAM deployment, however, there are up to eight additional new traits that will need a standardized nomenclature developed. These include:
- Workernode Name – The agent name assigned to a distributed worker node. This is inherited from asset host name and may require its own nomenclature schema per location and per serviced client.
- Workgroup Name – The unique ownership classification assigned to assets and users to distinguish 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.
- 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.
- Policy Name – The name designated to any privileged policy for context and application access by asset (computer) or user (account).
- Smart Group Name – The name logically grouping assets or accounts within BeyondInsight, BeyondTrust’s centralized console. This name is visible to end users with the proper permissions and provides role-based access and reporting capabilities by group.
- 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 vulnerabilities within the solution.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.
- Scanner Agent Name – The reference name displayed in BeyondInsight for a Retina Network Security Scanner or Retina Host agent. The name is manually set (like the workgroup) and does not need to equal the hostname.
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.
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.
Morey J. Haber, Chief Security Officer at BeyondTrust
Morey J. Haber is the Chief Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored three books: Privileged Attack Vectors, Asset Attack Vectors, and Identity Attack Vectors. He is a founding member of the industry group Transparency in Cyber, and in 2020 was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board. Morey currently oversees BeyondTrust security and governance for corporate and cloud based solutions and regularly consults for global periodicals and media. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition where he served as a Product Owner and Solutions Engineer since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.