Privilege Account Management: How It Works and Top Challenges for Businesses

In the past, companies have kept track of dozens, if not hundreds, of privileged accounts to allow necessary administrative functions in the IT environment. The fact that these privileged identities might be exploited by their owners, unintentionally or on purpose, or be stolen by hackers, poses a severe security concern. To tackle these security issues, companies use privileged account management (PAM). This article covers what PAM is, how it functions, and the difficulties companies face in containing security risks.

All IT resource accounts are not created equal. Some are used for everyday tasks, and some are given privileged permissions that enable changes to security and system configurations. Some can also provide access to highly classified/categorized data. These privileged accounts require strict management processes and activity monitoring. This is the purpose of the privileged account and session management (PASM) solutions. 

Implementing these solutions requires understanding what constitutes a privileged account and planning, including a thorough understanding of where privileged accounts (PAs) live and what they can do.

See More: Ten Common IAM Deployment Challenges and Their Solutions

What Are Privileged Accounts?

Let’s start by looking at what is NOT a PA. A non-PA is any standard account needed to perform daily business tasks. Every business user is assigned a non-PA account with access based on the user’s role. Access is limited to what the user needs to perform business tasks associated with their role. These limitations are often provided by RBAC and ABAC authorization solutions.

For example, an accounts payable clerk, Alice, is assigned a role with access approved by the relevant data owner, as shown in Figure 1. She can log into the AP application and then is limited to what she can do by permissions set in the AP application.

Figure 1: Privileged Access

The AP application permissions are adjusted so Alice can only see the information she needs to enter incoming invoices and answer vendor questions. Because her employer enforces separation of duties,  she cannot pay the invoices.

Mary also has access to the AP application, but she can also adjust permissions for user roles. She can do this because her account has elevated rights and permissions: a privileged account.

The big questions, which are not usually readily answerable without a PASM program, are what exactly can Mary do, and what does she actually do with the privileges she is given?

Mary’s ability to change permissions to access an application is just one example of a privileged account. Figure 2 shows other examples of privileged accounts.

Figure 2: Privileged Account Short List

• Superuser: A superuser account, like Linux root or Windows Administrator, provides complete access to a device, including content, rights, and permissions. Because many network devices today run Linux, superuser access is something that must be strongly controlled.
• Network Administrators: Another large category of privileged accounts includes those used to manage network routers, switches, firewalls, and other network appliances.
• Domain Administrator: An administrator account for directory services, like an Active Directory, this type of account might have complete control over the general network and resource access, also enabling management of standard and privileged accounts, including integration of devices into the network. It is the “superuser” account for a network and potentially for all resources on the network, providing full access, access only restricted by locally defined fine-grained authorization settings. However, organizations can finely tune domain admin tasks to control how much a single admin can do. For example, Microsoft explains in Appendix E: Securing Enterprise Admins Groups in Active Directory how to control access with group policies.
• Local Administrator: The local administrator is a privilege we usually associate with an account with full access to content, rights, and permissions only on a single server or end-user device. It is often used as an alternative name for a superuser account. However, local administrator privilege can be limited to only specific privileged tasks, such as performing backups.  
• Service/Application Accounts: Accounts used to run processes are known as service accounts, enabling access to needed resources, including on-premise or cloud processes that run “under the hood.” Application accounts are used to access databases, other applications, and services to resolve user and application requests.
• Emergency Accounts: Quick access is often needed for reconfiguring devices or device isolation when an incident occurs. To expedite this access, emergency accounts may exist, accounts that have elevated privileges and are not used for daily administrative or business activities.
• Privileged Business Users: In today’s environments, permission assignment is often distributed. Distributed administration of business applications enables data owners to manage roles directly and quickly make needed changes using privileged business user accounts. Further, some organizations do not enforce need-to-know, least privilege, and separation of duties for high-level management, essentially making these management accounts privileged accounts that provide broad access to classified data.
• Vendor Accounts: Most organizations have some service, like HVAC or IIoT devices, for which vendor access is allowed for support. In addition, vendors are often allowed access to applications or data-bearing devices for various reasons, access that can bypass safeguards applied to standard business accounts.
• Miscellaneous: Organizations might have many other account types not listed here. The thing to remember is that a privileged account is usually any account with privileges elevated above what is absolutely needed to perform tasks associated with daily business operations. Whether or not an account is treated as privileged generally depends on the risk associated with its use.

Privileged Account Management Challenges

PAs are often mismanaged. Seven general PA management challenges many organizations face are discussed below.

Expanding Privileged Access

Those who have worked in IT for many years understand the frustration of logging into multiple accounts to perform daily network or system management tasks. Because of this, it is common to provide complete, privileged access to systems or network devices, enabling quick but poorly managed access. 

Over time, this often gradual permissions creep can provide unfettered access across most, if not all, network and system resources, enabling a single point of attack for the elevated privilege to an organization’s most valued assets.

Another reason for privileged access expansion is the temporary privileged access granted by a data owner to a role for a project or other tasks. However, the temporary access is not managed correctly, making the additional access permanent.

Security teams can identify permissions creep via regular reviews of accounts, but because this is difficult, it is often skipped or done haphazardly. Further, unneeded access remains between reviews.

Removing unnecessary access

One of the biggest challenges is role change management. When a user changes roles, as shown in Figure 3, permissions granted to the user, in addition to what is provided by role assignment, can remain, causing permissions creep. When a user changes roles, all permissions from his previous role, permissions that might include privileged access, must be removed. Then the user is given a fresh set of permissions for his new role.

Figure 3: Role Change

Again, removing role-based permissions is not enough because one or more data owners might have granted the user exceptions. The admin must also remove these additional permissions.

Removing orphaned (zombie) accounts

When any employee leaves an organization, a policy-identified team should disable all her accounts within a short period, usually 24 hours or less. RBAC and ABAC solutions can do this automatically, fed by a source of truth like the HR system. Like any process, automated or not, this is not perfect, potentially resulting in orphaned PAs no longer using privileged accounts.

Organizations might no longer monitor orphaned accounts or include them in account reviews because they have fallen off the access control radar. It is possible to periodically run scripts looking for orphaned accounts, as I directed at my last employer, but this leaves these portals to malicious access available between scans.

Default service account configurations

Service accounts come with many solutions that organizations insert into their operational environments, accounts that come pre configured with default access-controlled with default passwords.

Many, if not all, of these default configurations, are available at vendor sites or on the dark web, making them glaring opportunities for threat actors. Change management processes integrated into an overall ITAM solution should eliminate the use of defaults. Still, nothing is perfect, especially with the plethora of IoT and IIoT devices finding their way onto highly classified/categorized network segments.

Static credentials

Changing the password for a privileged account can be challenging. Many privileged accounts exist, and support processes are required for business operations. Changing these passwords can be manually intensive and prone to errors, resulting in missed changes or system failures. Consequently, many organizations simply do not change privileged account passwords used by services and applications.

Password sharing

Users with privileged accounts are busy people, often overworked and pressured to achieve business objectives within constricted timelines. Credential sharing is sometimes mandated by a manager who is also under pressure to show project progress. These conditions can cause the sharing of privileged account credentials, achieving business goals, but spreading elevated access to individuals who should not have them and who are not recorded as having them.

Poor or no monitoring capabilities

Most organizations today understand the need for log management solutions like SIEM. However, log management is not enough. Threat actors are experts at bypassing or altering logging, hiding their presence. Further, logging will not usually show anomalous use of authorized access credentials that have been compromised.

Organizations must monitor the behavior of privileged accounts, looking for behavior that passes beyond statistical norms for each account.

Role of PASM In Managing PA Challenges

Privileged Account and Session Management (PASM) consists of two components: privileged account management and privileged session management. Both are needed to ensure the right people gain elevated rights and permissions and appropriately use those rights and permissions.

Privileged account management (PAM)

Gartner Research recommends two primary goals for PAM: least privilege with limited scope accounts and implementation of zero standing privileges (ZSP), granting just in time (JIT) access. 

Account scope addresses what permissions are granted, where they are applicable, and the duration of account usability (when the account becomes available and for how long it is active). Examples of limited scope accounts – accounts with change management oversight and separation of duties enforcement, including

• Web server admin
• Middleware admin
• System admin 
• Virtualization admin 

Organizations, where possible, should endeavor to ensure each PA does not have more than a limited set of rights and permissions, clearly defined by policy and managed to enable narrow capabilities. Administrative rights might be granular to a specific device level for highly classified systems. However, the restrictions on account scope should allow for risk-based reasonable, and proper business operation. 

The limited PAs are not standing accounts. Instead, they are “checked out” when needed (as shown in Figure 4), are active for a period defined in the PAM solution, and have a non-static password that is automatically changed after the account becomes inactive. The PAM’s control of the accounts is known as credential vaulting.    

The issuance of time-to-live restricted accounts is known as just-in-time access, an approach that helps eliminate orphaned accounts reduces password-sharing risk, mitigates the impact of threat actor compromise of privilege credentials, and helps prevent rogue admin activities after termination.

Figure 4: High-level PAM Operation

Figure 4 is a very simple PAM example. JIT access and credential vaulting are handled in various ways across multiple solutions. An organization’s approach depends on its operating environment, regulatory and risk environment, and budgetary constraints.

Privileged session management

Once a PA is active and issued, it is available to both the authorized user and any threat actor who might have compromised that user’s device. While JIT access and credential vaulting significantly reduce risk, they cannot eliminate unwanted PA activity during its time to live. This is the role of privileged session management (PSM).

Part of PSM is user and entity behavior analytics (UEBA). UEBA often uses machine learning to get better over time.

From when a PA becomes active to the point at which it reaches its time-to-live limit, a PASM or other solution should monitor all PA activity, alerting when behavior moves beyond established baselines. When an unwanted user or device behavior is detected, the monitoring system should alert security, require reauthentication, or block further access.

One example of session management is BeyondTrust’s Password Safe, with capabilities including

• Capturing everything, including keystrokes and video of PA activities, watching for unwanted entry strings, and blocking specific commands or command line sequences
• Building reports on PA usage for auditing, forensics, and regulatory compliance purposes
• Ensuring a PA session complies with business policies that ensure regulatory compliance

Password Safe is just one example of a growing number of PASM solutions available.

Implementing PASM

Implementation of a PASM solution requires policy, planning, training, and ongoing oversight. The following is one recommended approach.

• Create a PA management and use policy

1. The relevant data owners must approve PA creation and access.
2. All PAs will be vaulted with regular password changes.
3. Automatic logout after a specified period of account inactivity, the time-out period depending on PA capabilities and associated risk; when the account is no longer in use, or after a specified time-to-live, an active PA is disabled, and the password changed; password complexity is based on access risk and the use of additional authentication factors.
4. PA access is only enabled with multi-factor authentication.
5. The scope of access for each PA must be limited to a specific set of tasks.
6. All PA use must be continuously monitored.

• Inventory and assess risk, identifying all existing PAs and evaluate the associated risk across IoT, IIoT, applications, services, and elevated user accounts; each PA is evaluated based on the user/service/application requesting access, what is being accessed, when, and why access is needed
• Redefine PA roles, where necessary and possible, to restrict privileged access to only what is needed to perform a specific task or set of related tasks
• Select a PASM solution that enables policy compliance and adequate reduction of risk and that meets requirements based on inventories and assessments
• Create granular vaulted PAs 
• Remove all privileged access from day-to-day accounts
• Ensure PA visibility

1. 1. Log who/when/why information when a PA is requested and enabled
   2. Use video recording for access to highly classified information
   3. Use keystroke and behavior analysis to prevent the use of unwanted commands or other anomalous activity 

• Establish a baseline of behavior for each PA created

This is a high-level, general list of what is needed to implement a solution. The exact steps and the order in which they are performed depend on the organization’s operational environment and the PASM vendor recommendations.

See More: Top 10 Identity and Access Management (IAM) Solutions

Final thoughts

Privileged account and session management is essential to ensuring confidentiality, integrity, and availability of information assets. PAs have enough access to do significant damage via corporate or government espionage, system or data sabotage, theft, or anything else a creative threat actor can concoct.

PAs cannot be managed or monitored like other accounts. They need particular focus and oversight, including limiting what has traditionally been broad PA access.

Small organizations might not have the budget for a PASM solution, but they can still take steps to strengthen PA use. Infosavvy provides a set of guidelines applicable and achievable by organizations of any size, and they can also be interim steps for larger organizations planning for a more comprehensive solution.

Which of the PA challenges has your company faced the most? Comment below or let us know on LinkedIn, Twitter, or Facebook. We would love to hear from you!

MORE ON PRIVILEGED ACCESS MANAGEMENT