In typical computing environments, an identity represents a one-to-one relationship between a carbon-based life and their digital presence. Their digital presence, however, can have multiple accounts, multiple credentials, and an infinite number of entitlements in electronic format.
Consider the accounts associated with your personal identity and the myriad accounts associated with your corporate identity. These account names may be easily guessable if they are based on a simple template of your first initial and last name. On the other hand, they could be better obfuscated from a threat actor by using some form of patterned letters and numbers.
An account name could also be a predefined alias like “administrator” and have a logical meaning to a resource, but not intrinsically known to anyone outside of yourself unless an audit or IGA certification is performed. It is considered an identity governance best practice to permanently map this identifier back to your identity by including you in a group like “administrators” versus you being the “administrator” itself.
Top Overlooked Identity Management Problems
With that intro aside, let's now consider the top 6 problems a CISO may experience.
1. Employees with the Same (or Similar) Names
If you have a common name (i.e. John Smith), you have inevitably encountered someone with the same name, or at least the same initials. Most corporate email addresses are based on first name and last name, in some combination.
As an organization grows, it is likely you will have account name collisions. While most businesses avoid this by adding a middle initial or a number as a suffix, multiple entries in your global address list can make it difficult to find someone. A sender needs to inspect a user’s title and location to determine if they are the correct individual.
Thus, truncating a person’s name for an account or email address can become a problem. And, the more you truncate the reference to their identity, the more problematic it becomes.
Therefore, consider adopting an account nomenclature based on full names, including middle initial or based on an obfuscated identity nomenclature, to avoid this conflict. This will help stop emails being mistakenly sent to the wrong people, which could, in some instances, result in the inappropriate divulging of sensitive information to the wrong individual, possibly create data privacy issues. Avoiding this conflict in the manner I suggest can also help eliminate confusion when trying to perform an identity attestation report by identity.
2. Floating Employees
If your organization has resources that “float” (change departments frequently, like floating nurses or consultants), then you could have an identity classification problem.
How do you register these identities in your identity governance solution and directory stores? Do you change the permissions, privileges, and role every time they float? Technically, you should, but often organizations grant access entitlements and fail to revoke them when a role changes.
Floating employees generally have broad entitlements and, at any given time, it is hard to report what their proper access rights should be. Many times, these identities are over-provisioned to accommodate their roles, and this contributes to the problem covered in #3 below.
3. Over-Provisioning
As we alluded to earlier, an administrator account potentially represents an over-provisioning of rights and fails to adhere to best practices, like the principle of least privilege. Few if any admin accounts should realistically exist across an enterprise. Admin/superuser types of accounts (i.e. root, administrator, etc.) simply present far too high risk. When assigned to an identity, an admin account can provide complete control over an environment.
A challenge for most environments is the certification of who has administrative rights and determining whether that access is appropriate. If a user knows the administrator credentials, but is not assigned to an administrator’s group, then you definitely have a problem.
Teams need to scrupulously consider how they provision access for administrators. The administrator (or root) account credentials should never be shared. An appropriate admin user should be a member of administrator groups in order to properly report who potentially has access. Then, the access itself can be gated using a privileged access management (PAM) solution, or even throttled using a just-in-time access management approach.
Over-provisioning of privileged access is a common problem. Frequently, over-provisioning occurs because we share accounts without associating those accounts with the appropriate identities. After all, it is so much easier to give users high level of privileges and resource access so everything “just works” versus implementing a closed security model based on least privilege. Unfortunately, this is a dangerous identity and security practice that can allow a threat actor to move laterally and quickly expand access across an environment.
4. Mergers and Acquisitions
Mergers and acquisitions can stress even the most seasoned professionals.
When plans are implemented to consolidate technology like domains, identities, applications, and policies, best practices can be furloughed to achieve the desired business goals. This can lead to identity problems ranging from over-provisioning, to multiple accounts and domain names that do not follow an established pattern. This can lead to a cascade of additional identity-related problems, including applications that only work in some domains and inconsistent implementations for existing and new implementations. After all, if businesses do not merge standard operating procedures and establish technology baselines first, any subsequent project and identity management initiatives will suffer.
For the above reasons, it’s essential to establish security, identity policies, and provisioning baselines during the outset of any merger and acquisition. Then, any subsequent tasks have a guide to follow.
5. Non-Human Identities
Historically, identities in computing have been primarily associated with human users. However, modern computing environments involve many types of non-human identities (also called machine identities) as well. Forrester Research has stated that, “our clients tell us that machine identities are growing at twice the rate of human identities.” Non-human identity management quickly becomes a complicated topic.
Service accounts, application pools, and accounts used in CI/CD initiatives are not identities. Make no mistake, they are accounts associated with an owner—but not identities themselves. Such accounts are only used to authenticate an application or transaction. A non-human identity interacts with the physical world as well. That is why they are special. They need to be treated for the functions they perform and how they interact with humans.
Organizations typically fail to correctly classify the identities for robotics, automation, industrial control systems, etc. and thus, these types of machine identities can be leveraged by a threat actor.
Moreover, machine identities often have inconsistent attestation reporting because their ownership and access rights are not properly documented. To resolve this problem, all machine-based identities should have ownership assigned, just like having identity account relationships.
6. Vendor / Third-Party Identities
Rarely, if ever, does a business have all the employees necessary to perform all tasks. Almost every organization, albeit to varying degrees, relies on vendors, auditors, contractors, and temporary workers to pitch in with various functions.
When third-party staff require access to an enterprise’s environment, there must be special controls to manage these vendor identities and validate that all their activity is appropriate. If the workers change frequently, then the overhead of managing their identities can place an onerous burden on the organization too.
For third-party / vendor identity management use cases, organizations should consider creating controls to manage these identities outside of typical directory services and avoid assigning generic accounts like “Contractor1” or “Vendor_XYZ”. The users should have actual account names for the duration of their services, while allowing for a management paradigm that reflects the simplicity and often transient nature of their access.
In other words, whether you actually place the identities for third-party users in a directory service or as a group in a dedicated vendor remote access solution all depends on the amount of entitlements needed to complete their mission. However, the group or solution should follow the model of least privilege, have strong monitoring capabilities, and be simple enough to administer that the burden of management is nowhere near as complex as managing employees. This includes managing the entire lifecycle from joiner, mover, and leaver, and ensuring that there are no orphan accounts present after an identity has expired.
Addressing Identity Challenges Head On
Some identity security problems may not easily fixable, meaning an organization may have to continue to live with exceptions, and inconsistency in order not to interrupt business operations. However, the more of these challenges you can solve, the better your organization’s identity security posture and resistance to cyberthreats. One thing is certain, if you build a new environment from scratch, you certainly should consider these problems at the outset so they do not escalate as your organization grows.
Related Reading
Securing Machine (Non-Human) Identities (blog)
How to Manage and Secure Service Accounts: Best Practices (blog)
The Most Important Privileged Accounts to Discover & Why (blog)
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.