Guest Users

As a Guest User, your privileges are strictly limited to specific functions and tasks you can perform. In many organizations, guests are restricted to isolated network segments with basic access—perhaps access to the Internet for visiting vendors. If these unmanaged computers are, or become, compromised, the risk is mitigated by limiting access to the organization’s resources, especially via lateral movement. For example, a network scan from a compromised guest machine will not (or at least should not) provide the attacker direct access to corporate systems and data, regardless of whether they are connected via Ethernet or wirelessly.

Standard Users

As a Standard User, you have select privileges beyond that of a Guest to perform additional tasks and to fulfill the mission that is associated with your job and role. While organizations may forego implementing Guest Users, it is typical to have granular levels between a Standard User and a Full Administrator. These are often referred to as power users. Typical organizations may have 100s or 1000s of different standard user roles designed to balance access and efficiency with risk. Each role has been granted access to specific systems, applications, resources, and data required for their specific job. In many cases, a user may be a member of multiple groups, depending on their specific job requirements. For example, low-access roles (also called basic roles, basic entitlements, and birth rights when discussing identity governance) are typically provided to each organizational user (employee, contractor) to provide basic access. As an example, this could provide access to email and the corporate intranet. Next would be specific roles that would add more access based on the job function or role itself. See Figure 2-1 for a very basic example of a role hierarchy in a typical environment.

In this example, the banding and nesting of granular permissions within business roles may allow specific users access to a web server, but not access to a database, or vice versa. From the perspective of a threat actor, compromising accounts with elevated privileged rights is typically the target as these credentials are the ones that have access to sought-after systems and data. As a rule of thumb, the more administrative functions you are required to perform, the more administrative privileges you have. In addition, as you go up the hierarchy from sole contributor to executive, the fewer privileges you should have. Unfortunately, in many organizations, that is not always the case, and it is bad security practice when navigating on your PAM journey.

With this in mind, malicious activity does not require full-domain administrative or root rights (even though that reduces technical barriers and makes it easier for them to conduct nefarious activity). For example, if the user is a manufacturing floor worker, their potential privileges are limited by their job role (barring a vulnerability and successful exploit). If the target user is an information technology administrator, such as a server administrator, desktop administrator, database administrator, or application administrator, the associated privilege risk will be higher as these employees have been granted additional access as defined by their role. This makes them desirable targets for a threat actor. Take, for example, a threat actor who wants to gain access to a corporate database or file system with sensitive unstructured data (see Figure 2-2).

Having privileged access to an application, its database, or supporting file system is all that is needed to extract information once an internal beachhead has been established. This attack vector can also potentially allow the threat actor to execute commands, perform lateral movement, and exfiltrate the data regardless of whether they are an external or internal threat.

Additionally, many organizations grant more privileges than are required for a specific job, which leads to increased risk from both hackers and attackers. For example, many organizations still allow users to have administrative control over their desktops simply for convenience or due to legacy applications that require administrative rights.

It is also important to note that recent attacks are beginning to focus on nontraditional assets that may lack the flexibility and control required in today’s sophisticated threat environment. With some systems, the access options are very Boolean. You have access, or you do not. When you do, you are an administrator and have complete control. This is primarily true for consumer devices that do not have any concept of role-based access, but it’s also true for many Internet of Things (IoT) devices, legacy systems, and even next-generation technologies used for manufacturing, automation, and robotic control.

Power User

A power user is an elevated use case of a standard user that engages with applications and resources that need unique, sensitive, or advanced features that are not entitled to be used by the average standard user. A power user may not have extensive technical knowledge of the resources they operate, but have the competence or role to operate within privileged guidelines to perform specific tasks.

Also, within an organization, a power user may be a formal role given to an individual, and they may be considered the specialist for a particular software, role, or resource. Often, these are people who are trained to perform advanced functions above their typical job role, and, thus, given privileges to do so. Power users represent the universe between standard users and full-blown administrators based on explicit privileges granted to perform specific tasks. Again, they are not administrators, but based on the privileges they have been granted, they can be a source of privileged attack vectors. This is especially true if they are overprovisioned, unmonitored, or the entitlements they have been granted abused since their privileges allow them access to potentially sensitive tasks.

Finally, some common roles that are associated with power users are typically found within development, help desk staff, application and database administrators (even though they are not granted administrative or root privileges), and even engineering.

Administrators

As an Administrator or Root User, you “own” the system and all its resources. All functions, tasks, and capabilities are potentially within your control, and even if technology is deployed to block an administrator, being an administrator means there is still likely a way, or backdoor, around the restrictions. This leads to the premise that once you are an administrator, the security game is over. An administrator can circumvent any protection designed to protect against an administrator, even if the results are destructive to the processes themselves.

Obtaining administrator or root access represents privileged access that is considered the crown jewels to a threat actor. Once the threat actor has root access and can operate undetected, then any system, application, or data is potentially within their reach. Gaining privileges is the ultimate attack vector for breaching an organization, government, or even end-user–based computing device. Again, in this case, organizations tend to grant too many unmanaged administrator privileges, which leads to significant risk posed by threat actors and insiders. One of the primary use cases for PAM is to remove these unnecessary privileges and only grant the ones that are explicitly needed, and just for the moments in time they are required. This will be discussed in more detail later in the book.

Identity Management

The process of defining, managing, and assigning these roles to ensure that the “right” people have the “right” access at the “right” time is known as identity and access management (IAM). It is a specific solution family within identity governance. These “rights,” including role-based access and permissions, are called entitlements. Privileged access management (PAM) typically complements traditional IAM processes and solutions with additional layers of control and auditing for “privileged” accounts. These are the accounts that pose the greatest risk to the organization. Figure 2-3 shows the relationship of PAM to identity governance as defined by the Identity Defined Security Alliance (IDSA).

To better understand the scope of privilege risks, please reference Figure 2-4. In many situations, a lack of visibility and control over privileged accounts, users, and assets could leave you exposed to a damaging data breach. That visibility often begins with a simple discovery exercise through all assets within an organization. Ergo, let’s first take a look at where these privileged accounts exist. Then, once we get a complete picture of the scope of the challenge, we can discuss some strategies to address it.

Although this perspective of privileges is at a macro-user level (identity management), it is imperative to understand the micro-level of permissions down to the token and file to formulate a proper defense. It is again a mistake to consider privileges are only a part of the application you are executing. Privileges must be built into the operating system, file system, application, and even network via segmentation (often zero trust) to be effective for a user and application-to-application communications. The resource interpretation of the privileges cannot be just at any one layer to be truly effective. Thus, identity management only provides access to the resource by scope or role. In contrast, privileged access management provides the granular permissions needed when the operating system or application is incapable of providing these privileges itself. It is fair to state that PAM is a subset of IAM and an extension to protect privileges at every level.

Identities

For the sake of definitions, and commonly misused within the industry, an identity is simply a carbon-based life form (and a quick shout-out to all my fellow Star Trek fans. Spoiler alert—Decker and V’ger created the Borg, and it was all Kirk’s fault for allowing it to happen). It is any human being or user that interacts with resources, from applications to operating systems. This includes physical and electronic access and is a convenient way of saying I am a person. “I think; therefore, I am,” and I have an identity. A user should only have a single identity.

In addition, in modern computing environments, an identity can also be assigned to a piece of information technology. These are typically devices like mail robots or other technology that interacts with the real world in a physical nature. Electronic identities are not software or applications, but rather devices that can take on human traits. It is important to note that any technology assigned an identity can have multiple accounts, just like a human identity, but they also have a unique attribute to designate its owner. That is the human identity (or group) that is responsible for the electronic identity by reference of an owner tag.

For human identities, security best practices become blurred when people assume different names, including having maiden names, and they 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. Organizations should only have one identity for a person, like their social security number (which is a bad practice due to personally identifiable information), or preferably an employee number—one person, one identity, and one electronic reference linking them. Then, they can have multiple accounts. As an additional security best practice, the number of accounts should be minimized and easily linkable back to the proper identity.

Accounts

An account is an electronic representation of an identity or reference for a set of permissions and privileges needed for an application or resource to connect or operate within the confines of the system. While the definition of an account is evident for an identity, it can take on a variety of forms when used electronically for services, impersonations, and application-to-application functions. Accounts can have a one-to-many relationship with identities, be defined locally, grouped, or managed via directory services. Accounts can have role-based access applied at the account level, group level, within a directory, and these can range from disabled (denied access) to privileged accounts 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 from one implementation to another.

Therefore, accounts linked to identities are how we gain access to information technology resources. For technology itself, accounts are a vehicle to authorize their usage, provide development automation, and supply operational parameters. Too much privilege given to any type of account can introduce risk, and accounts can literally be named and referenced to almost anything, and are subject to limitations within any system. For example, some systems may not allow the renaming of an administrator account even though it is a security best practice to do so. Accounts are literally a reference field to provide authentication, and an account may or may not have a password or key. When a password is assigned, regardless of its strength, type, or security, it becomes a credential.

Credentials

A credential is an account with an associated password, passcode, certificate, or other type of potentially secret key. Credentials can have more than one security mechanism assigned for dual or multi-factor authentication, or be basic Guest credentials for anyone to access—without the need for a secret key or by using a common, known key. Credentials are just a mere representation of the account-password combination needed for authentication. They are, nonetheless, the crown jewels for any threat actor to begin an escalation of privileges.

When an attacker indicates that they have “hacked” an account, what they mean is that they have hacked the credentials associated with the account. Literally hacking an account would only yield a username. Both the username and password are needed to compromise a system, and potentially its data, successfully. Thus, for the sake of simplicity in the remainder of this book, hacking an account means the same thing as hacking credentials. It is difficult enough to manage privileges in an environment rather than worrying about the semantics used every day in describing the threat. Security professionals and the press will probably never change in saying one million accounts were compromised, when, in fact, one million credentials were compromised. See the difference? (And another shout-out to sci-fi fans, what credentials did R2-D2 use to hack the Death Star?)

Default Credentials

If the default passwords are not changed, it’s just a matter of time before the device, application, or resource will be owned. These are the basics for privileged management: changing the predictable or easily obtained to something that requires knowledge to access.

Note that the California Consumer Privacy Act implemented in 2020 requires scenarios 4 and 6 to be implemented on all new consumer devices to prevent privileged attacks. All other methods are now considered illegal for consumer device sales. This does not necessarily hold true for devices targeting businesses or noncommercial sales, and it is still unclear how adoption will be enforced across all network-enabled devices. In addition, even though this is a California state law, all geolocations will benefit from this legislation since it is highly unlikely device manufacturers will produce two versions targeting the rest of the world and the fifth largest economy in the world, the state of California.

Anonymous Access

Anonymous access is simple and absolute. No authentication is needed to begin the setup of the resource, including advanced settings that may be used to secure the asset from future attacks. While this method seems completely ludicrous in today’s security climate, it is often the only way to configure a resource for the first time. Consider the purchase of a new cell phone or mainstream tablet with either iOS or Android. Its initial configuration allows for anonymous access to set up Wi-Fi. The initial user can connect to any Wi-Fi network, including ones for which they may have WPA2 keys. This is typically not required to complete the configuration, but if misconfigured, initially or not, it could lead to a man-in-the-middle attack if the setup is not performed in a secure location.

In addition, the primary administrator user account on the device can be set with a null password, basically allowing full, unrestricted access to the device at any time. This even holds true for devices that have biometrics, like facial identification or fingerprint recognition. These devices can be configured to not enforce a password even though it is recommended, and it may be required later to access corporate resources via a mobile device management solution or management profile. If the device was compromised in the first place, adding these restrictions later is a moot point.

What makes anonymous access an absolutely horrible security threat are the instances when it is not disabled or changed after the initial configuration. Surprisingly, there are plenty of information technology resources that only support anonymous access. These include, but are not limited to, SCADA sensors like thermocouples, children’s IoT toys, and digital home assistants (after their configuration) that rely on voice commands. In the end, these are devices that have minimal-to-no programmatic concept of accounts or role-based access, and every user that interacts with the device has the same level of privileges. To that point, Figure 2-5 displays how even a file share can be granted anonymous access for anyone, at any time, to gain access.

Blank Password

Blank passwords are commonly used in resources that have multiple accounts but have a null password by default. The security and initial configuration of the resource may require that a password be assigned; however, many technologies, including older databases, do not even prompt for a password assignment after the solution is installed and operating. The risks are apparent. Accounts are present, not properly configured, and, depending on the privileges, are easy targets for a threat actor. Figure 2-6 illustrates this for a website where the credentials have not been set.

Blank passwords (credentials) are not anonymous accounts but rather credentials that have not been assigned and, in many cases, just a bad misconfiguration that should be mitigated when hardening the device. People commonly confuse accounts that have blank passwords with anonymous access. However, two significant differences should be well understood. With anonymous access, the identity of the user is not considered, and such access is typically reserved for low-risk activities. With an account with a blank password, the identity of the user is considered, but the security of the authentication process is diminished, usually an oversight that creates undue risk. The most common, and widely used, blank password solutions are systems that support Guest accounts. Anonymous access is independent of whether the guest account is enabled and is typically reserved for all to access. My point is that unauthenticated access is typically purposeful and required for operations, while a blank password is usually an indicator of a privilege vulnerability and bad configuration.

Default Password

For many years, manufacturers released solutions with default passwords. Every model series of the device had a unique password, and, for some manufacturers, the default password is the same for every new resource they produce. Although this is a common practice, it is a glaring security issue. There are volumes of lists publicly accessible on the Internet of these default passwords for every vendor, and all a threat actor needs to do is try them. Also, regulatory mandates (discussed later) prohibit the existence of default passwords (of any type) to be used in production due to the risk. These devices are susceptible to an attack as soon as they are connected to a network or the Internet. This is particularly dangerous if the device is not properly configured and still has the default credential after the resource is placed in production. However, some devices may not actually allow for the default password to be changed. This represents a privileged attack vector that is extremely vulnerable, just like anonymous or blank password access to the root account.

However, blank passwords (as defaults) are not just a threat to endpoints and networking devices. In many cases, application vendors will place the onus of implementing security controls on the application users and developers. For example, MongoDB is a popular NoSQL database used by organizations to perform big data and heavy analytics workloads. The default installation of MongoDB on older releases does not actually require authentication to access the database. This resulted in a widespread attack in early 2017 in which application and database administrators were not enabling authentication to the database. To make matters worse, many of these databases were directly accessible to the Internet. For these reasons, the importance of communicating security best practices at all levels of the organizations, including secured coding by the development and application teams, is critical. Figures 2-7 and 2-8 illustrate real-world, commercially available technologies that have poor default password implementations.

Default Randomized Password

In today’s world, the most secure default password is one that is unique and randomized for every single resource that is produced, licensed, or sold. This password needs to be securely conveyed to the administrator or organization for the initial setup and should be changed upon the initial configuration. Unfortunately, some manufacturers have taken this concept to a level that makes the devices unsecure if physical access to the device is available. Along with the serial number, these vendors have printed the default passwords on the device for anyone to retrieve (see Figure 2-9). A simple press and hold of the reset button restores the password to the default and, depending on the device, the configuration too. Once reset, a threat actor now has access to compromise the asset. Mitigation for this type of threat is relatively simple. Copy (photo, scan, or type) the default password documented on the resource, securely store it, and then destroy, mask, or remove the label. In addition, physical access to any device that allows for a soft or hard reset, or password reset remotely, should be secured to prevent this threat. Most compliance regulations mandate this as well. Randomized passwords are currently one of the most secure methods to distribute default passwords, but they also may present risks depending on how that password is initially distributed.

Pattern-Generated Passwords

Identity governance requires sound, documented, and repeatable processes for onboarding new users, creating new identities and accounts, deleting identities and accounts, providing certification reports for access, and providing access for them to perform their jobs. When not managed properly, these accounts can create a significant security risk.

Have you ever worked for a company where an automated system creates the default login account and password based on something that everyone knows—like your name? Often, this is how an IT/help desk sets up the default access for new employees or reset passwords upon some form of authentication or login failure. For them, it is easy to document, potentially automated, and can be similarly communicated to users as a password for them to gain access.

Of course, to overcome these issues, more secure best practices can be implemented to reduce these risks, including the enforcement of “change password on next login” and multi-factor authentication. Figure 2-10 shows how to enforce a password reset during the next logon. This should be used regardless of whether or not you use a pattern-generated password to keep the password secured only to the account and the appropriate user.

Forced Password Change