Identities are under attack from all sides. The risk surface is increasing exponentially, and threat actors are endlessly inventing more sophisticated and nefarious means for identity-based attacks. At the same time, digital identities are becoming more complex. Each identity can—and does—have multiple accounts, credentials, entitlements, rights, and privileges. While some accounts may be more secure than others, the truth is that, within an operational domain like work, you can only have one digital identity.
All it takes is one compromised account and the consequences can be severe for all the credentials, privileges, rights, and entitlements assigned to an identity.
This blog will explore the many attack vectors that can attach themselves to any singular identity, the consequences of poor security practices, and why it is so critical to #BeIdentitySmart.
What does it mean to have a single identity?
An Identity is typically a one-to-one relationship between a human being and their digital presence. In recent years based on digital transformation initiatives, there can also be machine-based identities, but they should have a human owner assigned, linking them back to a person. This completes the basic definition that an identity should always have human linkage. Their digital presence, however, can have multiple accounts, multiple credentials, and an infinite number of entitlements in its electronic form.
For example, consider the accounts associated with your enterprise identity. These account names might be comprised of your first initial and last name or obfuscated by using some form of patterned letters and numbers. It could also be a random alias like “JT2036”, which, unless you have a mapping back to your real identity, has no logical meaning to anyone outside of yourself.
It is considered an Identity Access Management (IAM) best practice to permanently map this identifier back to your identity. Some environments prefer this mapping to be human readable, like “John.Titor”, while others prefer to obfuscate account names. To that end, an identity and its associated accounts may deviate from a business’s standard practices, but there should always be a justification for why they are not utilizing the organization’s accepted formatting. This allows the identity-account relationship to be predicable, despite obfuscation and simplify mappings and attestations.
The consequences of a compromised identity
According to Blumira’s 2022 State of Detection & Response study, identity-based attacks were the top threat to organizations in 2021. In their 2022 Trends in Securing Digital Identities report, the Identity Defined Security Alliance (IDSA) corroborates that 84% of their survey respondents had reported an identity-related breach in the past year.
Identities are a critical attack vector, one that is becoming more pronounced as remote working and the shift to the cloud become more prevalent. However, the risk of an identity breach runs deeper than the risk of one unsecured account within an organization. The true consequence of an identity-related breach is the impact to your digital identity as a higher-level concept, and it’s one that can’t be rectified by changing the password on an account.
The following are just a few of the consequences an organization can face when dealing with a compromised identity.
One compromised account threatens all your accounts
As threat vectors increase and threat actors refine their strategies, they will begin to target all the accounts associated with an identity (human or non-human). All it takes is one compromised account associated with an identity and it could be used to compromise many more, if poor security practices are in place.
Such an attack can traverse both your personal and professional life. If that same identity continues to create new accounts, their past mistakes can continue to haunt them, and it will make it easier for a threat actor to compromise their new accounts. This attack is most prevalent based on simple poor cyber security hygiene like password reuse. Or, simply, using the same password on multiple accounts.
A compromised identity can be used for identity theft
As the news has demonstrated, threat actors are becoming more sophisticated when it comes to impersonating users. Using more advanced technologies, like DeepFake technology (DeepFake email and SMS messages, DeepFake phone calls with spoofed accents and vocal patterns, social media hijacking), coupled with malicious artificial intelligence software that can be used to impersonate an identity in ways we have not even yet conceived, identity theft will continue to increase. This is a game of leapfrog, with security teams operating in defense (blue team) and threat actors operating as offense (red team), that has been playing out over the last several decades.
Please consider that your accounts can change over time, and your name, too (i.e. during marriage, or divorce, just to be fair), but a human can only have “one identity” forever (minus extenuating circumstances, like a witness protection program).
Biometrics is one trait that can never really be changed. For safety, you must protect your unimputable identity at all reasonable costs from this offensive and defensive battle—especially when the attributes used to digitize your identity, like biometrics, can be mimicked as a part of an attack vector. Deepfakes have already proven this as a liability.
The evolving identity
Whether an identity is assigned to you, me, or a machine (or asset), it is a potential attack vector that has multiple weak points of entry, and these are expanding as each identity, and its associated accounts, is required for authentication and authorization by more and more assets on premise and in the cloud. To understand this expanding risk surface, let’s begin by breaking down the components of the identity and account relationship. Then, the risks associated with each one.
Names and Identity
For human identities, security best practices become blurred when people assume different names, including having maiden names, and may have duplicate identities referenced electronically in an organization. To be clearer, they still have only one identity, but may have electronic instantiations to multiple identities, which should not be confused with having multiple accounts.
As a security best practice, organizations should only have a single identity for a person, like an employee number—one person, one identity, and one electronic reference linking all accounts together. In reality, someone may have a name changed and be listed in different ways within the organization, until all systems are updated. While they have one identity linked by an employee number, the confusion creates the illusion of two identities since the names are different in different places.
The risk to any identity is the compromise of this top-level information (employee number), especially when it is not properly secure or based on PII (like a social security number). If a threat actor leverages this designation, then they can reference your identity across any system implemented by the organization, from payroll to human resources, regardless of whether the names match or not.
For example, if your employee number is “habmo01”, then I can deduce your name (like mine) and recognize that every system implemented by the organization recognizes me as “habmo01”, despite any accounts I may have linked. This then becomes a hacking exercise to penetrate an asset and derive information on a target based on their associated name and identity, and it makes the actual human name irrelevant. The employee number becomes the key index to find my accounts anywhere within the organization based on linkage to my identity. This is analogous to using a Windows SID to finding accounts across Windows assets without knowing the username.
Accounts
An account is an electronic representation of an identity and can have a one-to-many relationship with the identity. As we have stated, a single identity can have multiple accounts. As a security best practice, the number of accounts should be minimized and easily linkable back to the proper identity. This is needed for accountability and attestation reporting. These accounts reference a set of permissions and privileges needed for an application or asset to connect or operate within the confines of an asset. This is the basic model for authentication and authorization based on an account relationship.
Accounts can have complex relationships with identities and can be defined locally, grouped together, nested in groups, or managed via identity infrastructure, such as directory services. Accounts can have role-based access applied to them either directly, at the group level, or based on a directory entry. These roles can implement a wide range of capabilities–from disabling access to providing privileged capabilities, such as root, local administrator, or domain admin. The level of privileges and role-based access is dependent on the security model of the system implementing them and can vary significantly.
Linking accounts to identities is how we gain access to information technology assets. Technically, any account is simply a vehicle to authorize usage and control operational parameters. Excessive assignment of privileges to any given account goes against the principle of least privilege and will greatly increase an identity’s risk surface and the potential for a privileged attack vector. Simply, an account can be abused via:
- Lateral movement associated with an identity and its associated accounts
- Excessive privileges leading to asset abuse or misconfiguration
- Improper management of a joiner, mover, leaver process
- Compromise of the account itself due to improper security controls, like single-factor authentication or poor password management implementations.
All these attack vectors can ultimately lead back to an identity being compromised at the high level and exposure of every associated account. The ones with the highest privileges are the most valuable to any organization.
Credentials
A credential is an account with an associated password, passcode, certificate, or other types of secret. Credentials can have more than one security mechanism (authentication) assigned to them–this is called two, dual, or multi-factor authentication. Credentials can also be shared and used anonymously. In the case of an anonymous account, the credentials use a null password. This is different than a guest account as an example since one conceptually allows anyone and the other is trusted a “Guest” There is a difference. To expand, credentials are simply the representation of the account name and secret combination used for authentication.
They are, nonetheless, the crown jewels for any threat actor to begin an attack and subsequent privilege escalation. When someone has “hacked” an account, what it really means is that they have taken over control of the credentials associated with the account for authentication. Both the username and password are needed to successfully compromise a credential and potentially anything that credential protects.
If the compromised credentials are shared among multiple assets (that includes the same name and password), then a threat actor could laterally move between assets. If the credentials protect something of value, then the compromised account could lead to other assets and data based on entitlements and if privileged enough, additional accounts and. Ultimately, the parent identity linked to the account. Once the identity is compromised, all associate accounts are compromised. It is a matter of hierarchy and lateral movement.
Finally, once the administrative or root accounts are compromised, then it is game over. The entire environment is owned at the highest level from an identity management perspective.
Entitlements
Entitlements are any technology implementation that controls access to something we care to manage. “Entitlement” is a category name used for something that grants, resolves, enforces, revokes, reconciles, and administers fine-grained access, privileges, access rights, permissions, or rules.
An entitlement can stand apart from its eventual assignment to an identity and its associated accounts. Its purpose is to define and execute information technology access policy, regardless of resource, asset, device, or application – whether it is running in the cloud, on premise, or anywhere else, like mobile devices.
Entitlements come in many shapes and sizes and can usefully be categorized as being either simple or complex in nature. The management of entitlements can be delivered by a range of different technologies and is, by convention, designed to work across platforms, applications, networks, and devices. With such a broad definition, the risk surface for entitlements can be represented by any setting or configuration that can be abused as a part of an attack or breach. Since entitlements are associated with an account and identity relationship, it is easy to understand how something as simple as a misconfigured S3 bucket could allow data exposure.
When thinking about identity-based attack vectors, consider the entitlement as the machinery. The identity is the target.
You achieve the target by compromising accounts. Entitlements allow you to work through the gears, pullies, and circuits that make the account work with assets. If you can compromise an entitlement, it exposes the capabilities of the account. If any entitlements are misassigned, then you have an attack vector to work with.
At the heart of every identity are privileges. If you can compromise an identity, then you assume its privileges. If you can elevate your privileges to root or administrator, you can own an asset. If you own the asset, you can manipulate the data and software to conduct nefarious activities.
It is all linked together.
Why protecting identities matters
We cannot change our identity—only the attributes associated with it—and this makes it more important than ever to protect them. If a threat actor can own any association in an identity, and the entitlements and privileges assigned to them, the results can be devastating. Therefore, protect yourself and your digital identity representation. Recovering from identity theft or an identity-related breach is not as straightforward as just changing your last name.
About the Author: 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.
