In practice, credentials are the evidence of authority to rights, entitlements, privileges, or similar permissions. They are usually presented in written or typed form like an account name and password, and only those accounts, applications, services, scripts, and the like with properly validated credentials are permitted to proceed.
Shared Credentials
One of the cardinal rules in cybersecurity is never to share your password (credentials) with anyone. Whether it is a colleague or contractor, there are no sound use cases when it should be done, ever! That said, many employees continue to share passwords in times of emergency, due to simplicity and ignorance, to delegate tasks, or to overcome issues in planning with sick leave and vacation.
The problem with shared credentials is that once they are out of your control, how fast and far could they propagate before they are in the hands of a threat actor? This could be anything from a real hacker with malicious intent, to a suspicious spouse or memory-scraping malware. If multiple users are using the same credential, for example, a local or domain administrative account, how can an organization reliably associate access and change events to an individual identity? Unfortunately, even though these risks and challenges exist, there are real-world use cases where shared credentials are absolutely required for an application to work in a multitier architecture, for devices to connect to a network, and multiple users to administer the same resources. Shared credentials, or the act of sharing credentials, is a real privilege problem because once the information is shared, limiting its exposure and measuring the risk of that exposure becomes a difficult threat to quantify. Minimizing privilege risk, or privileges as an attack vector, requires knowledge of all the different places shared credentials can exist. And, what can be done to mitigate inadvertent propagation of them? It includes documenting any time that shared credentials are used, which individual requested them, what actions they performed, and changing the password periodically to ensure it does not become stale. Shared credentials should also be rotated when organizational events occur, such as employee changes and contractor access. The concept of credentials to provide access and the intentional or unintentional sharing of them is a core use case for privileged access management.
Account Credentials
- 1.
Mentally: Only memorized in the human brain.
- 2.
Documentation: Written on paper. These can be secured in a physical safe or inappropriately written on paper like a Post-it note or bulletin board.
- 3.
Flat File: Documented in an electronic file like a spreadsheet. These can be secured on a file system or encrypted with a password to prevent basic tampering.
- 4.
Password Manager: A technology solution for the storage and retrieval of credentials and their associated passwords. Advanced versions of this technology can also randomize the passwords and automatically rotate them according to policies.
While storing the information solely within your head is presumably the most secure, it has risks that degrade this as a best practice. This is where the expression, “If you got hit by a bus,” becomes painfully relevant. Documenting and creating specific accounts for emergency privileged access is a good method for Break Glass and for use case–based sharing, but represents risks if the files are shared, copied, or placed in an unsecure location. In this case, a threat actor could have unhindered access to your password, and to resources you have access to as well. To reduce this risk, many end users utilize password managers for storage and retrieval of passwords. This represents one of the best solutions for managing privileged access to mitigate this attack vector.
It is important to note that there are two classes of password managers. One class is strictly for personal password storage and the other for enterprise password storage. Neither should be used across both use cases. In other words, do not use a personal password manager to store business credentials and vice versa. A business should never store your personal credentials, like for banking or personal social media accounts, and a personal password manager is inadequate to manage and audit business privileged access. As a rule of thumb, keep the two classes of password management solutions separate unless the solution and strategy your organization chooses has distinct provisions for both use cases. This will be discussed in detail later in this chapter and has special relevance for users that tend to use the same passwords both at home and at work (“I have a bad feeling about this”—Han Solo).
Shared Administrator Credentials
Most applications, embedded solutions, networking devices, Internet of Things (IoT) , and appliance-based solutions ship with and rely on local accounts to perform management functions. In traditional environments, multiple system administrators will use these accounts (shared credentials) to perform specific tasks for configuration and maintenance. The sharing of these accounts and their related passwords, vs. creating a unique login for each administrator, may be due to the limitation of the device and/or application. Therefore, these credentials may be shared across administrators due to management overhead, complexity, and cost of implementing unique credentials across the environment for a system that natively does not support it.
Administrator Environment, Number of Credentials Mapped Against Complexity and Security
- 1.
Using the same account on each system with each system account using the same password is the easiest solution, from an operational perspective, as administrators only need to share and coordinate a single password. However, this option is clearly the most insecure approach. If an administrator’s password is compromised, the hacker can easily gain access to all 1000 systems via lateral movement.
- 2.
If the managed systems each had a unique password for the shared account, it reduces the risk and impact of a potential breach. In this case, if an administrator’s password was compromised, it would only grant the hacker access to that one system. All other systems would have their own unique password. The only challenge with this approach, as with all shared accounts, is that you cannot isolate specific account activity to an individual. In this example, all activities across all administrators would be tracked as “administrator” and not tied to the particular person who performed the action. Also, note that when using a shared account, the password can only be changed if such updates are efficiently coordinated and communicated with everyone that uses the account. The more accounts and passwords, the more complicated this coordination exercise can become. In this example, we need to update 1000 passwords across 1000 systems and appropriately notify the ten administrators when these password updates occur. The result is that, many times, in addition to sharing these passwords, they are infrequently updated, which further increases the risk of compromise. Of course, an automated Password Management solution provides an effective and efficient way to frequently update these 1000 local accounts with unique and complex passwords.
- 3.
The third option is the most complex option. In this option, users do not use a shared local account. Instead, each user is granted access through their own account. This enables all activities to be logged and tied to a specific user for accountability. However, in our example, that would either require that ten accounts (one for each admin, if possible) be created on each local system or that each local system relies on a directory service or centralized identity solutions to perform the authentication process. We will discuss identity solutions and directory services later in this book.
- 4.
The fourth option is the most common for a privileged access management solution, and local accounts on the system are leveraged in the design. The systems are managed and have unique passwords that are automatically managed and rotated by an enterprise password management solution. Access control lists (ACLs) are implemented on the system or network to limit lateral communications and rogue session requests. All activity is performed through an authorized bastion host or gateway that authenticates the user first for auditing and reporting and then brokers the connection. This translated into 1000 managed passwords and unlimited administrators that are provisioned through the password management solution. In today’s world, this is currently the best approach.
Temporary Accounts
Lack of accountability over who performed which task with the accounts (if shared).
Workers may end up having access for longer than they should have if the accounts are not disabled or removed after their tasks are complete.
Uncontrolled access in environments where these passwords are not frequently changed, or the accounts use a patterned password template model.
Accounts not managed or disabled, allowing for unsanctioned access after an appropriate time period has ended. These are gaps in the deprovisioning process.
SSH Keys
Secure Socket Shell (SSH) keys are a special network protocol leveraging public-key cryptography to enable authorized users to remotely access a computer or other device via access credentials called SSH keys. Normally, SSH keys are used to access sensitive resources and perform critical, highly privileged activities. It’s vital to manage SSH keys as you would other sensitive credentials correctly. While SSH keys are standard, and more frequently used, in Unix and Linux environments, they are also used in Windows systems.
Overview of SSH Key Security Authentication
Logging into remote systems and resources for support and maintenance
Transferring of files from computer to computer
Remote execution of commands
Offering support and updates
Authorizing devices to participate in network communications (Wi-Fi as an example)
Today, Telnet, one of the Internet’s first remote login protocols and in use since the 1960s, has largely been supplanted by SSH, owing to the latter protocol’s enhanced security and encryption features. Telnet, for example, performs all communication in clear text and is an easy target for threat actors.
Benefits of SSH Key Authentication
The SSH network protocol encrypts all traffic between the client and the server while it is in transit. This means that anyone eavesdropping on the traffic, such as by packet sniffing, would not be able to access and decrypt transmitted data properly. SSH is also resistant to brute force attacks and protects against specific attack vectors being used to gain access to remote machines. Public-key encryption ensures that passwords need not be sent over the network, providing an additional layer of security. Due to the massive number of SSH keys that may be in use or exist across an enterprise at any time, SSH key management in the form of privileged access management can significantly lower the overhead and risk of manually managing and updating keys.
Generating SSH Keys
SSH keys are always generated in pairs. These pairs consist of one “public” SSH key and one “private” SSH key. These keys are paired using powerful algorithms, making it infeasible to guess or “fake” a private key, even if you know the public key. While private keys should be kept secret by the authorized person wishing to gain access to a system, public keys may be freely shared. SSH keys are usually generated by a user entering a passphrase or other information. Typically, public and private keys will be generated from phrases of a few words.
SSH Key Access
A remote computer identifies itself to a user using its public key. When an account attempts to connect, the remote system issues a “challenge” derived from the public key, for which only someone possessing the paired private key could correctly decrypt and respond. Once the challenge is correctly answered, the remote system provides access. In almost all cases, generating keys, sharing public keys, issuing challenges, answering them, and gaining access can be automated such that the process is transparent to end users.
SSH Key Sprawl Poses Security and Operational Risk
SSH key sprawl exposes organizations to considerable risk in the form of privileged attack vectors, especially considering that they can provide such a high level of privileged access, such as root. With typically 50–200 SSH keys per server, organizations may have upward of a million SSH keys deployed within their environment. While many of these SSH keys are long dormant and forgotten, they can provide a backdoor for threat actors to infiltrate critical servers. And once one the server and SSH key is compromised, a threat actor could move laterally and find more hidden keys. As with other types of privileged credentials (or passwords in general), when organizations rely on manual processes, there is a proclivity to reuse a passphrase across many SSH keys or to reuse the same public SSH key. This means that one compromised key can then be harnessed to infiltrate multiple servers. It is the same problem as a reused password.
SSH Key Security Best Practices
As with any other security protocols, it is imperative to maintain strong standards and best practices around SSH network protocols, keys, and passphrases. NIST IR 79661 offers guidance for government organizations, businesses, and auditors on proper security controls for SSH implementations. The NIST recommendations emphasize SSH key discovery, rotation, usage, and monitoring. In even modestly complex environments, manual SSH key rotation is infeasible. For instance, you could identify accounts set up to use SSH keys, you could manually scan through authorized keys file in the hidden.SSH user folder, but this falls short of helping you identify who has the private key matching any of the public keys in the file. Organizations who recognize the risks posed by SSH key sprawl typically take a proactive cybersecurity posture, use a dedicated SSH key management or automated privileged access management solution, and generate unique key pairs for each system to perform frequent key rotation. Automated solutions dramatically simplify the process of creating and rotating SSH keys, eliminating SSH key sprawl, and ensuring SSH keys enable productivity without compromising security.
Personal and Work Passwords
We all have dozens of passwords to remember, and forgetting them seems to be commonplace. To reduce the risks and frustrations of forgotten passwords, many users have turned to Password Management solutions, which inventory and secure all their passwords, requiring that they only remember the master password to gain entry. As discussed earlier, there are personal password managers and enterprise password management solutions. Both are good strategies. What is not a good strategy is to reuse the same password for multiple applications, services, and other resources across home and work, nor to cross-use personal and enterprise password solutions for each other’s use cases. Recent breaches in which millions of consumer passwords were disclosed to hackers are not damaging just because they allow access to the already compromised system, but the impact has a multiplier because they can often be reused in other attacks. Those passwords could also unlock access to your other email accounts, banking applications, social media, and more. If the same password was present at work and home, the ramifications could be devastating to your identity in both realms.
Don’t share and reuse passwords across both personal and corporate accounts, as a compromise in either one could put yourself, employer, and business partners at risk too.
Never use the same account name for personal and business functions. If work has standardized on first initial and last name for your account (i.e., “jtitor“), do not use it for accounts at home or even personal email. It is an easy way for a threat actor to link personal and business accounts to your identity.
If you use social media for work, consider creating multiple accounts for personal and professional posts. If this is undesirable because you are considered a public figure, then learn how to set up groups in social media to target your postings to family, friends, and the public at large. Obviously, the account names and passwords should be sufficiently different too.
Do not use a personal password manager to store business passwords and do not use an enterprise management solution to store personal passwords. This is true for any use case, including Break Glass (covered in detail later in this book) or any type of vendor, backdoor, or unique accounts.
Applications
Another cardinal rule of cybersecurity is that users should have a unique password for every application, and no two distinct applications should share the same credentials unless required to communicate. This is another form of password reuse and presents one of the largest privilege problems in information technology security today. People use the same password among multiple applications, systems, resources, infrastructure, and others. Should any one of them be compromised, the same reused password can be leveraged against any other device, application, resource, etc. with the same password. This is why centralized directory stores, single sign-on, password management, and multi-factor authentication are so important to mitigate the risk. This is true for standard user accounts as well as for privileged administrative accounts.
Do not hard-code passwords in scripts, applications, or driver connections—even if the application compiles the source for runtime.
Map all services, applications, and accounts that use shared credentials for visibility and risk management.
Never place passwords in clear text files or files that can be easily decrypted. If a legacy application requires passwords in a file, make sure they are properly hashed, and the keys are not stored on the same system for decryption.
For end-user interaction, authenticate users against a directory store like Active Directory when possible.
To minimize the observer effect for end users, consider using multi-factor authentication with single sign-on.
For applications that can only use local role-based access, enforce periodic password rotation.
Educate team members on the risk and importance of not reusing passwords.
While this short list may sound daunting and exhausting to implement, mitigating these risks is not unsurmountable. Enterprise password management solutions provide a vehicle to remediate these risks via an application programming interface (API). In lieu of hard-coding the password, an API call is made to a password safe, or password manager, as a part of a privileged access management (PAM) solution to retrieve the correct password. The PAM solution understands the linkage and mapping of solutions that need the same passwords and either distributes them correctly upon an API call or automatically changes them based on the same relationships. In addition, for end-user interaction, the same API can drive unique credentials per application and per user using single sign-on technology to make the end-user experience frictionless. This entire process is secured from a threat actor using its own authentication mechanisms, covered later in this book.
Static Credentials for Secure Storage Authentication Between Two Applications
Devices
If WEP (hopefully not) or WPA2 is used for Wi-Fi, the shared key or passphrase may be the same for all devices to connect.
Unmanaged credentials on a device that the help desk or an administrator may possess as a legitimate backdoor to gain administrative access.
Tools like appliance-based vulnerability assessment scanners, network management solutions, and security solutions may share the same credentials and passwords across all deployments to connect or perform maintenance like auto-updates.
Management of infrastructure devices, such as routers and switches using the same root password for either configuration management or synchronized network management functions.
Devices that are natively capable of sending emails or Simple Network Management Protocol (SNMP) traps and store credentials locally for automated notifications.
Therefore, device passwords represent another vector for privileged attacks. The passwords, or certificates, are rarely changed and, once obtained by a threat actor, represent an easy and persistent method to penetrate an environment until they are detected, the services stopped, and all the device passwords changed. Also, these credentials are often initially configured during the setup of the network, frequently by a third-party vendor, and exposed to nonemployees, introducing yet another unnecessary risk.
Segment all wireless networks from production access.
Require all wireless devices have a certificate installed by IT to prove it is a managed device.
Require centralized authentication against a directory store before granting access to a corporate wireless network. This should also include multi-factor authentication when appropriate.
And note, this is not necessarily true for properly segmented, monitored, and approved Guest wireless networks.
A Sample Obfuscate Spreadsheet of Serial Numbers and Password
Device Serial Number | Help Desk Password | Asset Tag |
|---|---|---|
XDM7GT | 1503VaBm@! | 2036 |
PL00HG3 | 9802PbWd^% | 2020 |
LKJ678 | PbUl7650!! | 2049 |
LM7WQ4 | RnSs1209)* | 3069 |
Aliases
As a reader of this book, you are a human being. You are unique, have an identity, and have subtle differences from other humans, even if you have a twin. Today’s biometric technology cannot necessarily distinguish you from someone else (i.e., think twins and facial recognition technology). When we translate the human aspect of our identities into the digital world, we can have more aliases, avatars, profiles, and, therefore, privileges. Information technology users can have multiple aliases, just like having more than one email address. This is different than accounts. Aliases are a representation of an account and its credentials using an alternative name. For example, John Titor may have an account named “jtitor,” but his alias could be “TimeTraveler2036”. We may have multiple aliases for home accounts, but we are less likely to have separate ones for work. Typically, account names in businesses can easily be translated back to an identity, and that is our alias. They are unique identifiers for who we are, but ultimately, they are just another description for the account and its potential role. And, surprisingly, they can exist for both human and nonhuman identities.
Aliases, and their associated accounts, can have a variety of privileges assigned to them. If we expand this concept a little further, they can be referenced as the actual usernames for our accounts. We may have an everyday account based on our name (Standard User). We may also have an administrative (or elevated privileges account) based on the same name with a prefix or suffix to indicate it is a privileged account. For example, my Standard User account could be “jtitor”, and my administrative account is “jtitor-admin”. These are both aliases for my identity in the form of accounts and, again, should never share the same password.
This concept becomes exceptionally important when we work with multiple operating systems and directory services. We can easily encounter instances where these accounts do not inherently sync, have different criteria for complexity and naming conventions, and will not work on foreign applications or incompatible operating systems. This can leave us with multiple aliases for Unix, Linux, Windows, Mac, iOS, Android, social media, applications, and so on. I think you get the perspective.
From a threat actor’s perspective, aliases are a hindrance to their goals, especially if all the alias schemas are different and the passwords are different too. For example, on Windows, John’s account may be [email protected], but on Linux, his account may be “johntitor.” Laterally moving from one resource to another is complicated since the threat actor needs to determine the proper cross-platform aliases to properly navigate through the environment. This is actually a good thing, but the problem lies with development and operations. The mapping of all the aliases (accounts) to the proper identities is potentially a nightmare, and having potentially hundreds or thousands of local, nonsynchronized accounts across multiple users could leave gaping holes in security from rogue or dormant accounts. It is the same reason security best practices prefer domain accounts over local accounts to manage systems. They are easier to control, manage, log, audit, track, and maintain. Having every identity instantiated as a local, nonlinked account on every foreign operating system is worsened if the alias schema used to create them is different per resource. That is, John could have multiple permutations of his name created as accounts, depending on the resource. It is, therefore, best to keep the alias schema the same across all resources and, if possible, use technology to bridge authentication across platforms to consolidate directory stores. This minimizes the management overhead for accounts and the potential for sprawl in alias derivations.
From a privileged attack vector standpoint, the fewer the accounts and associated aliases, the better visibility into user activity. This is where directory services bridging comes into play. This capability allows one directory store, like Active Directory, to be the authentication store of authority for all supported platforms and applications. It can be leveraged for authentication and privileges using the same alias name (i.e., jtitor-admin) and the same password (or 2FA—two-factor authentication) everywhere. This means that one administrative alias works everywhere and authenticates against one directory store (the password is not stored locally in this model), and attestation reporting on an identity can occur anywhere and at any time. This is because all you need to do is query for the same alias name across all resources without having to deal with multiple derivations from nonstandard schemas. Without a directory bridge, with multiple aliases everywhere, each resource needs to store a password locally for authentication. That presents yet another attack vector for a threat actor to crack passwords. With a directory bridge, that risk is mitigated.
Minimizing the number of aliases per “human user” is strategically a best practice for any organization. It could then be easily inferred that minimizing the number of accounts per identity is also a good security practice too. Removing administrative accounts, and only keeping standard users, is even better and will be covered later.
Assigning an Administrator Alias Name to a Batch User
Email Addresses as Account Usernames
Identity-based attack vectors represent the next biggest risk for consumers and businesses over the ensuing decade. One aspect of this risk is associated with an identity, or user, having a single account username leveraged for many different roles. In basic terms, if a person implements their account username using their email address for everything that they access, the risks are higher for an incident. Based on an attack using a single account, a threat actor can reuse that same account name based on an email address against other resources and apply a variety of techniques—such as brute force, spray attacks, and credential stuffing—to attempt to compromise the account (covered in Chapter 4). If the user has different email addresses for logging on to different types of resources, then a breach in one type of resource cannot necessarily be used against another. The threat actor has no email address or account username as a reference point to start from unless they can link all your email addresses back to your identity.
The first email address should be associated with any type of sensitive accounts (in business, a privileged account). These can be banking or financial applications and should have a unique email address used for authentication, dedicated only for their access. In addition to logging on, this will help determine whether any correspondence sent to this address is legitimate. Any phishing emails that someone would receive in a different account can automatically be discounted as fake. You would have no accounts associated with another email address. For the highly security-conscious, it may be necessary to create an email account associated with each one of these sensitive systems, depending on the data contained within.
The second email address should only be used for all personal correspondence (in business, a standard user account). This includes any type of emails that may be exchanged with family members, friends, or involved in other social activities. This email address should never be used for anything outside of sending or receiving email—that is, it should never be used as the logon (authentication) for any account on the Internet. Any rogue correspondence to this address will make it is easy to identify as spam targeting you.
The third account should be for junk email or shopping (there is no corresponding business account, but loosely follows generic email addresses for a company like [email protected] or [email protected]). For the sake of this section, we classify junk mail as a very broad term for websites that might frequently send you sales offers or nonmalicious spam. It should be for all of the applications and websites that send frequent coupons, event notifications, sales promotions, or other types of merchandise. It is not recommended to use this account for any other activities nor to use this email address for actually shopping on a website. Unless it is an eCommerce site you visit frequently (then it is a sensitive account since it has your credit card number), consider always shopping as a Guest patron to prevent the website from potentially storing your credentials, credit card number, and address. This email address should be dedicated solely for spam or junk and should never be associated with any sensitive information.
Finally, the fourth email address is relatively straightforward. It should be used for any correspondence associated with your employment or interactions with state, local, or federal government (this is analogous to domain or local administrators). This is a dedicated email account for which you share the address with your employer or other government entities so that they can correspond to you regarding healthcare, taxes, utility bills, or other official information. This email address should not be shared outside of these specific use cases, and any correspondence that deviates from its intended usage is definitely spam.
While having four email accounts may seem extreme for consumers, it helps separate the different use cases that you might perform for correspondence and sensitive authentication on the Web. Its roots (pun intended) are founded in privileged and standard user accounts present in businesses today. Modern applications can easily support multiple email addresses to separate correspondence, including Microsoft Outlook, Gmail on an Android, and Mail on an Apple device. Knowing what email should come into which category will help you avoid spam, phishing attacks, and other types of compromised credential attacks that could lead to your identity being compromised. Because if your personal identity is compromised, it is not hard for a threat actor to leverage you, and your assets, to compromise any shared resources (like bring your own device (BYOD)—Chapter 16) to gain access to your business. And, depending on your engagement with online resources, including social media or other types of high-risk applications like dating websites, you may choose to create even more email accounts to achieve further separation of roles. This will continue to isolate any additional communications coming from high-risk sites and make it much easier for an end user to delete or disable an account if the website or correspondence are compromised or become a burden. Essentially, the rule of thumb to follow here is to not use one account (email address) for everything, just like at work. Your email account should not be the same for banking as well as dating sites, social media, and work.
Finally, if your Internet-based resources allow you to create a unique username for logging on in place of an email address, take advantage of this too. This is just an alias. This provides an additional layer of obfuscation, and the remaining threat is based on email correspondence and not having the same logon username for every web-based service. Essentially, keep all your account usernames separated, unique when possible, and monitor emails based on account name to help you safeguard against phishing attacks and modern identity-based attack vectors. And, it goes without saying (and I will say it over and over again in this book) that the passwords for each account should be unique, complex, and never reused or recycled!
Privileged access management is so much more than just password management, regardless of how credentials are implemented. We are now in an era of universal privilege management. Wherever and whenever privilege accounts exist (even ephemerally) and are being used, they must be tightly managed and monitored.