11. Privileged Access Management
Privileged access management (PAM) is often referred to as privileged account management (also PAM), privileged identity management (PIM), or privileged user management (PUM). The differences are subtle, and PAM (using access) is favored over the other in the analyst community. The discipline is considered a subset of the identity and access management (IAM) or identity and access governance (IAG) market, as defined by leading standards organizations and analysts.
PAM’s primary goal is to keep your organization safe from accidental or deliberate misuse of privileged credentials and access, regardless of whether the system is being accessed remotely or a user is sitting directly in front of the keyboard and monitor. (Hopefully, you understand all of the risks which now have been clearly defined). Privileged access threats are particularly relevant if your organization is evolving and experiencing change due to growth, new markets, and other business expansion initiatives. The larger and more complex your environment’s information technology systems become, the more privileged users you have. In the last several years, organizations have been experiencing an explosion of privileged user accounts and a new universe for privilege management. These new accounts include employees, contractors, vendors, auditors, and even automated users utilizing solutions on-premise, in the cloud, and in complex hybrid environments that may include multiple business-to-business connections. This does not diminish the need for small organizations to embrace PAM, but rather that security professionals have a more difficult time scoping the problem and conducting mitigation exercises at larger scales. Every business and every consumer is potentially at risk from privileges being used as an attack vector. This fact alone necessitates the need for PAM everywhere, even though only portions may be needed to mitigate relevant risks. Therefore, a successful strategy for privileges as an attack vector does not require all of PAM’s disciplines to be implemented to mitigate the risk—only the ones that are relevant to your business. Generally speaking, the larger and more complex the business, the more PAM use cases you will need to implement.
Grant privileges to users only for resources on which they are authorized (least privilege).
Grant secure privileged access from resources to resources brokered by an authorized third party (zero trust).
Grant access only for those instances when appropriate and revoke access when the need expires (just-in-time administration).
Eliminate the need for privileged users to have or need knowledge of system passwords (password management).
Manage privileged remote access sessions for appropriate activity with credential management (secure remote access).
Ensure all privileged activities can be associated with an account and, when accounts are shared, enforce mappings to an identity (certification reporting).
Centrally and quickly manage access of all physical and virtual resources, on-premise or in the cloud, accommodating any set of heterogeneous resources that require privileged access (asset discovery).
Create a sustainable audit trail for any privileged usage via session recordings, keystroke logging, and application monitoring (attestation reporting).
Empower organizations to readily respond to breaches by logging privileged activity that provides indicators of compromise (reporting, analytics, and alerting).
Privileged Access Management Challenges
Lack of Visibility and Awareness: Discovery and Documentation of all the privileged accounts and credentials across an enterprise pose a monolithic challenge, especially for those companies that rely on manual processes and homegrown scripts. Privileged accounts, many long forgotten, are sprawled across most organizations in legacy systems and one-off systems performing functions that are overlooked daily. Different teams may be separately managing (if managing at all) their own set of credentials, making it difficult to track all the passwords, let alone who has access to them and who uses them. A typical user may have access to hundreds of systems, possibly disposing them to take shortcuts in maintaining the credentials. Beyond this, as elaborated in the sections that follow, some types of credentials are virtually impossible to find, let alone bring under management, without third-party tools.
Lack of Privileged Credential Oversight and Auditability: Even if IT successfully identifies all the privileged credentials strewn across the enterprise, this does not by default translate into knowing what specific activities are performed during a privileged session (i.e., the period during which elevated privileges are granted to an account, service, or process). Providing privileged access to a user or administrator should not amount to ceding carte blanche to use the credentials anytime nor for any activity. Moreover, regulatory controls like PCI and HIPAA require organizations not just to secure and protect data, but be capable of proving the effectiveness of those measures. So, for both compliance and security reasons, IT needs visibility into the activities performed during the privileged session. Ideally, IT should also have the ability to seize control over a session should inappropriate use of the credentials occur. But, with potentially hundreds of concurrent privileged sessions running across an enterprise, how does IT expeditiously detect and halt malicious activity? This is why automation is so important. While some applications and services (such as Active Directory) can track logon/logoff events and high-level application activity, only a privileged access management solution can enable you to determine if the activity was appropriate.
Sharing of Privileged Accounts for Convenience: IT teams commonly share root, Windows Administrator, and many other privileged passwords so workloads and duties can be seamlessly shared as needed. However, with multiple people sharing credentials, it may be impossible to trace actions performed with an account to a single individual (identity), complicating auditing and accountability.
Hard-Coded and Embedded Credentials: Privileged credentials are needed to facilitate authentication for app-to-app (A2A), application-to-database (A2D), and Development Operations (DevOps) communications and automation. Applications, systems, and Internet of Things (IoT) devices are commonly shipped, and often deployed, with embedded, default credentials that are easily guessable and pose a formidable risk until they are brought under management. These privileged credentials are frequently stored in plain text, perhaps within a script, code, or a file. Securing embedded passwords requires separating the password from the code so that when it’s not in use, it’s securely stored in a centralized secret store, as opposed to being constantly exposed as plain text in a file.
SSH Keys: IT teams commonly rely on SSH keys to automate secure access to servers, bypassing the need to enter login credentials manually. SSH key sprawl presents a substantive risk for thousands of organizations, which may have upward of a million SSH keys . With this staggering quantity of keys, many of them may be long dormant and forgotten, but still viable backdoors for a threat actor to infiltrate critical servers. SSH keys are standard, and more prevalent, in Unix and Linux environments but are also used across Windows environments. Administrators leverage SSH keys to manage operating systems, networks, file transfers, data tunneling, and more. As with other privileged credentials, SSH keys are not necessarily tied to a single user; multiple people may share the private key and passphrase to a server, which holds the public key. As with other types of privileged credentials, when organizations rely on manual processes, there is a pronounced tendency to reuse a passphrase across many SSH keys or to reuse the same public SSH key in the form of a wildcard per domain. This means that one compromised key can then be harnessed to infiltrate multiple servers.
Privileged Credentials and the Cloud: The challenges of visibility and auditability are generally exacerbated in cloud and virtualized environments. Cloud (SaaS, IaaS, and PaaS) and virtualization administrator consoles (as with AWS, Office 365, Azure, Salesforce, LinkedIn, etc.) provide a vast amount of superuser capabilities, enabling users to rapidly provision, configure, and delete servers and services at a massive scale. For example, cloud-based virtualization services allow for users to potentially spin up and manage thousands of virtual machines (each with its own set of privileges and privileged accounts) with just a few clicks. One predicament then arises around how to onboard and manage all of these newly created privileged accounts and credentials. On top of this, cloud platforms frequently lack the native capability to audit user activity with granularity needed to determine if the session was appropriate. And, even for those organizations that have implemented some degree of automation for their password management (either through in-house, or third-party solutions), if not architected with the cloud in mind, there’s no guarantee a password management solution will be able to adequately manage cloud credentials outside of basic check-in and checkout processes, exposing the actual passwords to the end user.
Third-Party Vendor Accounts and Remote Access: Finally, another quandary for organizations is how to extend privileged access and credential management best practices to third-party users, such as consultants or other vendors that may perform a variety of activities. How do you ensure that the authorization provided via remote access or to a third party is appropriately used? What communication tools do you provide to allow them to securely access only the resources you have deemed appropriate? How do you ensure that the third-party organization is not sharing credentials, or otherwise exercising poor password hygiene, such as by failing to terminate authorization credentials when an employee departs from the company? These are the compelling questions requiring remote access to be a part of your privileged access management strategy.
Password management is a simple security function that helps a user store and organize passwords. Password storage solutions (commonly referred to as password managers, password safes, password vaults, or secret stores) store passwords encrypted and require the user to authenticate to the solution to retrieve stored secrets or begin a session. This assumes the solution is designed for direct business end-user password management and potentially supplemental personal usage. As with any solution, administrative credentials manage the configuration of the password manager, but they should not have access to the database or password keychain for retrieval of unauthorized credentials.
For a business environment to successfully implement a password management solution, these concepts need to be expanded to a different level. Solutions need to have role-based access to the storage and retrieval of shared passwords, automatically rotate the passwords, provide APIs for programmatic password access, and provide enterprise auditing, encryption, and logging capabilities for multiple users and applications across an entire enterprise. Also, the architecture cannot be monolithic—it must be able to accommodate network segmentation, firewalls, and even cloud resources securely to manage a modern environment. These features cover everything from session recordings to password attestation reporting. These capabilities are necessary to mitigate privileged threats, but also to demonstrate regulatory compliance, not just within one network zone, but across an entire infrastructure.
Password management solutions can also be implemented in a wide variety of formats based on an organization’s needs. This can include software, appliances, virtual instances, or even hosting in the cloud. Regardless of the deployment philosophy, the goal is still the same: secure privileged account passwords, and most importantly, make sure the password manager itself does not become a liability to the business. For example, decrypting passwords and unrestricted access to the password manager’s database itself, at any time, would be like finding the Rosetta stone for access to any resource managed by the business. Organizations are willing to trade off the risk of storing all their sensitive passwords in one highly secure, fault-tolerant location vs. the threats posed by unmanaged privileged access. Businesses just need to be aware of the Tier-1 critical system nature of a password manager and the policies and procedures necessary to facilitate its successful deployment. This includes making sure that cybersecurity hygiene basics like vulnerability, patch, and configuration management are operating perfectly and that high availability, disaster recovery, and break glass are periodically tested.
Least Privilege Management
The concept of least privilege has its foundation in mainframe security. Any user, when first instantiated, has absolutely no privileges to do anything. It is considered a fully closed security model. As a user needs to perform functions, privileges are added to their account to perform specific tasks. Hopefully, the privileges (permissions) are the bare minimum required to perform the specific task, and nothing more that could lead to privileged abuse.
Least privilege on every other platform operates the same way regardless of whether it’s Unix, Linux, Windows, or MacOS. Unfortunately, the default model for Windows and MacOS is the opposite; default initial users are administrators. To facilitate least privilege, new or existing users are assigned basic (reduced) login rights, and the applications, tasks, and even operating system functions, are granted on an as-needed basis. The basic account assigned in this model is considered a Standard User. The basic user rights allow for interaction with the operating system, limited applications, but not the ability to perform any changes that could be a liability for the environment.
The problem with this model is that many tasks, applications, and configurations need higher permissions than a standard user. Traditionally, users have been granted a secondary account as an administrator to perform these tasks (dash admin accounts), but that introduces a privileged attack vector and risk. Every identity would have at least two accounts, one privileged and one not, and a threat actor can successfully move laterally between accounts operating on the same asset when used simultaneously by the same identity.
In a least privilege model, technology provides a solution. Via policy and rules, individual commands, applications, and operating system functions are granted the permissions they need to operate and nothing more. They have least-privilege rights. The users themselves are not granted the rights; this is critical in mitigating privilege risks that could breach the user’s runtime. Only the application is elevated based on administrator-specified criteria. Thus, the application runs correctly, a user can interact with it, and excessive privileges are removed from the user to prevent a threat actor from leveraging them and executing lateral movement. The end goal is therefore achieved; the end user is never given privileged rights to perform their job functions.
Secure Remote Access
While we have touched on remote access in a variety of places, we really have not justified why it is a part of privileged access management. Let’s consider our initial assumptions about threat actors. They are either internal or external. If you consider the fact that the majority of privileged attacks are external, they must be connecting to resources remotely. They are located somewhere else and are performing some form of remote session to gain access and to conduct their nefarious activities. Therefore, an external threat actor leverages some form of remote access to breach an environment. Logical, right? If you consider how many remote access sessions your organization needs to support vendors, contractors, auditors, professional services, managed service providers, and remote employees, then a threat actor has multiple attack vectors to hijack any one of them, or create a communication path of their own. Protecting the business is more important than anything else at this point. This contradicts Spock’s quote in Star Trek II: The Wrath of Khan, “The needs of the many outweigh the needs of the few or the one.” There is no justification for accepting an external threat of this nature over the security of the business.
Provide the ability to securely connect to a resource internally or externally within an organization
Encrypt all communications end-to-end for each session and each organization
Provide strong authentication and integration into common directory stores and multi-factor authentication solutions
Allow for privileged access point-to-point without the need for virtual private network (VPN) technology, client-based dedicated software, or protocol routing
Support all major protocols for remote access: RDP, SSH, VNV, and HTTP(S)
Support all major operating systems, including mobile devices as clients
Integrate into password management and least privilege solutions to eliminate the need for credential exposure
Provide complete privilege monitoring capabilities from session recording to keystroke logging and automated session auditing
While this list may expand based on your individual use cases, remote access does have one trait that must be called out specifically. Remote access is after all “remote.” Any time you grant access, you may not have any control or management of the resource used to perform a remote connection. It may be an employee’s home computer, a vendor’s laptop, or even a mobile device owned by a contractor. Installing software on their device to make the connection may violate your licensing agreement, have compatibility issues with another organization's baseline configuration, or even open a routable network path from your organization to another company (VPN). It is, therefore, in the best interest of everyone to make sure remote access never requires (optional of course) any special dedicated software to facilitate the use cases listed previously. That is, keep remote access remote, and provide access within all the confines we have been addressing throughout this book.
Application-to-Application Privilege Automation
Application-to-application (A2A) privilege automation utilizes an application programming interface (API) to allow stored credentials to be managed automatically from an on-premise or cloud-based implementation between applications. If you are a commercial application developer or create custom applications for your business, the primary benefit allows applications to authenticate without an end user intervening, hard-coding credentials in a script, providing your own secret store for credentials, compiling secrets in code, or trying to obfuscate them in a file. Team members, like database administrators, never need administrator rights to access a database if the tools they use automatically retrieve stored credentials and apply them with little user interaction (low friction and no impact for the observer effect). Also, when applications are properly coded to the API, they can make additional database connections, communicate with other applications and instances, and perform their own functions without the risk of them maintaining their own credential storage.
Secure Credential Management: Instead of entering static credentials, developers call on a PAM API to retrieve the latest credentials for the user, application, infrastructure, cloud solution, or database to authenticate and then release the credentials at the end of the session. This triggers automatic, randomized cycling of the password. The end user is never exposed to the username or password. All authentication is performed silently behind the scenes with complete activity auditing, if desired. This is a foundational component for zero trust.
Simplified Developer Access: Improve the agility and responsiveness of IT by never requiring the entry of a username and password for connectivity to custom applications. End users, like database administrators, never need administrator credentials to access a database if the tools retrieve stored credentials automatically. Management tools for services, remote access, and infrastructure automatically recognize the logged-on user and the asset they are on, and seamlessly request and pass credentials for the application. This is a foundational component for Just-in-Time privilege management.
Protection from Password Reuse Attacks: Since credentials can be passed within the application itself, directly from the API, IT can secure runtime and avoid hacking techniques like pass-the-hash and keystroke logging, making this approach far more secure than traditional single sign-on (SSO) technology.
Vendor-Agnostic: To enable developers to access the API and help secure their applications, PAM vendors offer samples and support for a wide variety of programming languages including C# (.NET), PowerShell, Ruby, Python, Java, and Bash shell and automation languages like Ansible, Puppet, and Chef.
The retrieval of the current password for an asset or application.
Force the rotation of a password change.
Register or decommission a resource for password management, including the technology owning the account (operating system, database, application, cloud resource, social media, etc.).
Automate policy and criteria for password management, including retrieval.
Access session monitoring details and events.
Define groups of users and resources for simplified management and reporting.
Privileged SSH Keys
SSH keys are tied to accounts on a Unix server, not to an individual. What happens when you need to prove for an audit that a specific user accessed a server using SSH keys? This is where privilege monitoring helps solve the problem.
Replacing and managing SSH keys typically requires manual effort. As they’re used on Unix servers, and there are typically a handful of Unix administrators, it can be easy to “set it and forget it.” The significant operational risk here is obvious—the older the key, the more it is shared, the greater the chance of unauthorized access and a breach. Automating the inventorying and management of SSH keys helps mitigate these problems.
As a result of the risk stated in #2, managing and rotating SSH keys manually typically results in IT teams reusing the same passphrase for different SSH keys. Otherwise, you need a storage solution for all the passphrases themselves. As a result, IT teams are unwittingly putting their enterprise security at risk. If the passphrase falls into the wrong hands, a threat actor has a way to move laterally through your environment or potentially make their own keys.
Like passwords, organizations should automate the life cycle of SSH keys—from discovery to onboarding, rotating, distributing, managing, and finally destroying them. This is all another use case for privileged access management.
Applications and operating systems can have local, role-based access security models or integrate into directory services like Active Directory (AD) or LDAP. Unfortunately, many operating systems do not natively allow cross-directory authentication from ∗nix platforms to Microsoft Windows. This means that a user account on Windows cannot be used to authenticate against Unix and Linux, and that an alias account needs to be created to provide authentication.
When dealing with complex environments, this can lead to thousands of accounts, across thousands of systems, all potentially having slightly different aliases for the same user. This represents a management nightmare, a password headache, and an auditing disaster to link aliases with a single physical human user, a robotic identity, or even a shared account.
A single account for all users, regardless of platform, with the same credentials or multi-factor requirements.
Minimize the need for alias accounts, their management, and correlation of user accounts for activity monitoring.
Simplified attestation reporting for any single user across all platforms since all the account names are now the same.
Simplified account discovery and identity management for non-Windows platforms via Active Directory.
Directory bridging is such a basic function with so many benefits; it can help minimize insider threats to rogue account usage simply by eliminating all the additional accounts created for users on non-Windows systems. A threat actor would have few account backdoor options since all the aliases have been eliminated. This essentially forces a threat actor to have to attack accounts that are managed, potentially used daily, and no longer unique per resource (flying under the radar). When this is combined with data analytics, user behavior analysis, and good old-fashioned logging, finding malicious activity is much easier since all privileged accounts are associated with a single directory store.
Auditing and Reporting
Without the ability to audit changes, report on events and findings, and provide an actionable trail of activity, privileged access management projects only succeed in mitigating privileged attack vectors and their associated risks. While that is a huge accomplishment, it does nothing to help document regulatory compliance to auditors or identify intentional or unintentional mistakes that could lead to a data breach.
Provide a report for all rules, policies, and role-based access granted to an account for privileged access. This also includes documentation for any changes made to these resources.
Utilize File Integrity Monitoring (FIM) across all your operating systems to identify unauthorized privileged changes to sensitive operating system files, critical applications, and unstructured data containing business-sensitive information.
Provide certification reporting of all privileged session activity with complete details, including timestamps, keystroke logging, and application monitoring.
Provide attestation reporting for all credential checkouts, check-ins, and rotation.
Document all applications requesting and utilizing privileged elevation per asset, application, and user.
Report on the health of managed credentials, including password age, managed accounts, and rotation schedule (including faults) for credentials and keys being managed.
Once these concepts are implemented, demonstrating privileged access management as a function of compliance becomes rather elementary. The output from reports, command filtering, privileged session review, and so on, all become collateral to support your standard operating procedures and, more importantly, provide, the security needed to stop privileges from being used as an attack vector.
Privileged Threat Analytics
While reducing permissions and embracing the concept of least privilege will minimize both the attack surface and potential impact of a breach, some employees and authorized third parties will, at some point, require elevated access to perform job functions. It is these users that pose a significant risk to organizations. These users have been authorized to perform sensitive tasks and to have access to delicate data repositories. The control and detailed auditing of these accounts fall outside of the scope of typical identity and access management and user provisioning solutions. So, how does one determine when an approved account is misusing their given privileges, or if these accounts have indeed been compromised? This is what we have been describing as appropriate or inappropriate behavior. For this, we need to start at the bottom and work our way up.
One of the strangest words in the English language is datum (not data from Star Trek, although that would make sense here). It is, by definition, the singular form of data, but is rarely used in conversation or written documentation. It generally refers to a single point of information or a fixed starting point of a scale or operation. When we review security or debugging information, we often refer to single entries in a log as “data” when it should be correctly referred to as “datum.” While the term may be considered obsolete when it comes to security, there are many times we make critical decisions based on the datum and not data. This is where discussions on analytics, artificial intelligence (AI), machine learning (ML), and user behavior become essential. It would be a mistake to base a decision on user behavior strictly on datum. Analytics, AI, ML, and user behavior require data. For the sake of this discussion, however, we will focus on analytics.
Any analytics solution that makes a recommendation based on a single piece of information is more in tune with an event monitoring solution, or security information and event manager, than an analytics engine. For example, a single event based on user, time, date, and location is not analytics—it’s datum. That information correlated with other event data, and processed via correlation, is not analytics either. That is just a correlation engine reviewing multiple events in a logical order. This technology has been around for decades.
If the events are unique, processed via cluster analysis, adaptive correlation engines, and so on, then we could potentially have analytics. It takes more than just a single event and event matching to create analytics based on variable event data. Being mindful of the analytics claim and data absorption model is key in understanding whether an analytics solution can really help you detect and resolve security anomalies.
An effective threat actor attempts to erase or eliminate any traces of their movement, surveillance, or actions within an organization. The primary point of privilege as an attack vector is to document any time the threat actor tries or has access to privileged accounts. This produces data of their activities based on unusual behavior and using data analytics provides an analytical automation engine to detect even the most skilled threat actors as they infiltrate an environment.
The trend is to implement advanced threat and behavior analytics to identify suspect behavior for sensitive accounts. However, many of these solutions require significant historical analysis, are not trusted given their “black box” approach, and only analyze high-level data elements , such as logs or data forwarded to a SIEM. Furthermore, these solutions are focused on identification, but not containment. This is an area in which integrated PAM capabilities can provide significant benefits. PAM is an inline solution that can grant or deny access for sensitive access. PAM is not restricted to rigid all or nothing access policies, but can rather dynamically adjust access policies and approval workflows to sensitive systems, applications, and data. This is an area that organizations and security professionals should continue to monitor as advancements will help automate the security within organizations.