What and Why Privileged Access Management (PAM)

Privileged access management (PAM)/privileged identity management or privileged account management, concerned with controlling and auditing access obtained through the administrative accounts associated with every system.

In research commissioned by One Identity in 2018, a full two-thirds of organizations that participated in the survey had more than 50 users with access to privileged accounts and the same amount grant privileged access to third-parties and external organizations.

Table of contents

Conventions
What is privileged access management and why does it matter?
Managing and securing privileged accounts
A short detour into governance

Conventions

Throughout this article, we’ve used several conventions to help highlight important points, provide supporting evidence, or advise you of our obvious bias. Look for the following conventions:

• Real-world example: Stories of real organizations, facing real challenges, and solving their problems (often the names have been changed to protect the innocent).
• Facts and figures: Research-based information that supports the principles discussed throughout the article.
• Techie alert: Definitions and terms used in the identity and access management industry that may not be familiar to you (Then again they might.)
• Useful tip: Information that will help you easily achieve things discussed throughout the article
• Blatant sales pitch: Where we get to say why we wrote this article. It may be a little biased, but we suspect that the reason you’re reading this article is to find solutions to your challenges. This is where we give them to you.

So where does the power lie in your enterprise? Who has admin access to which resources? And how much are you relying on faith in your current security approach to ensure that the wrong person doesn’t find a weakness and exploit it?

Unfortunately, we can’t control the activities of our administrators with an invisible Vader-like grip. And if these permissions fall into the wrong hands, even the ‘ultimate power in the universe’ can’t save us. The threat of a security incident or critical error is very real, and it’s something that auditors are focused on. After all, some damage can be done through a standard user account, but the potential damage is much greater if the compromised account has ‘superuser’ access rights, as demonstrated in this news report excerpt.

• ‘A fired computer engineer for Fannie Mae has been arrested and charged with planting a malicious software script designed to permanently destroy millions of dollars worth of data from 4,000 servers operated by the mortgage giant.
• The disgruntled engineer concealed the UNIX script on Fannie Mae’s main administrative server on October 24, the same day the UNIX engineer was terminated, according to court documents. The script was programmed to remain dormant for three months, when it would greet administrators with a login message that read ‘Server Graveyard’ and systematically replace all data with zeros on every production, administrative and backup server in the company.
• ‘Despite his dismissal on October 24, the engineer’s highly privileged computer access wasn’t terminated until late into the evening because of bureaucratic procedures in Fannie’s procurement department…’

You’ve probably heard that story. It’s often highlighted as a prime example of poor privileged access management, but it’s a cautionary tale that bears repeating. Logically, much of identity and access management’s focus lies in granting, maintaining, controlling, and governing end-user access to critical resources. Most IAM initiatives are concerned with easy and unobstructed access to a large population of end-users with minimal disruption to IT operations.

But the forgotten arm of IAM remains privileged access management (PAM).

In research commissioned by One Identity in 2018, a full two-thirds of organizations that participated in the survey had more than 50 users with access to privileged accounts and the same amount grant privileged access to third-parties and external organizations.

In the Fannie Mae incident, there are a few things that went wrong, any one of which could have prevented the breach if addressed:

• Too many people shared the UNIX root account with no individual accountability
• There was no concept of ‘least-privilege access associated with the administrative account. Every administrator had access to the full power of the administrative credential, even capabilities that were far outside the scope of their responsibilities
• There was no mechanism in place to audit or watch what administrators do with their rights
• There was no concept of identity governance and administration for privileged accounts and users
• There was no mechanism to find and remove instances of permissions that exceeded those appropriate for an individual’s role

What is privileged access management and why does it matter?

Privileged access management (PAM) is also called privileged identity management or privileged account management. PAM is concerned with controlling and auditing access obtained through the administrative accounts associated with every system.

Let’s take a step back and talk about how systems, such as applications, databases, and operating systems, work. As you know, an account must be created and maintained for a user to access a system and do their job. That’s the core of IGA. But each system also has one or more accounts that are not associated with individual users, but with the system itself. These ‘superuser’ accounts contain the rights necessary to perform administratively, maintenance, and other tasks on the system. To set up an account, reset someone’s password, or install a software update, you need privileged access.

Examples of common privileged accounts include the UNIX root account, the Active Directory Administrator account, a DBA account, or the superuser accounts built into every application and system. Generally, these accounts are all-or-nothing.

Either you can do anything on a system, or you don’t have any more access than your regular user account would allow. Also, since superuser accounts are tied to the system and not the individual, they are typically shared among all administrators that may need to use them.

When something goes wrong, it’s not easy to determine the exact source. For example, you can find out that ‘root,’ ‘admin’, or ‘DBA’ was logged on at the time the damage was inflicted. But that superuser account may be shared by 20 different administrators, so there is no sure way to determine who did what to the system. Worse, as was the case with our Fannie Mae example, superusers can edit logs or cover their tracks in other ways.

In the same survey, 90 percent of admins have access to multiple privileged accounts and three-quarters of the organizations share those credentials among administrators.

In summary, there are a few problems with privileged accounts:

• They are all-powerful. If someone has the password, they can do nearly anything they want.
• They are shared. Everyone that may need to perform administrative actions on the system would need the privileged account to do it.
• They are anonymous. There is no level of individual accountability.
• They lack audit. Often the ability to watch what an administrator is doing with a privileged account is difficult at best and non-existent at worst.
• We can’t live without them. IT staff, including contractors and vendors, must be able to access the systems they manage at a deep enough level to do their jobs.

Privileged accounts are a big problem. But they’re not going anywhere and are often the prime source of security breaches. So what are we to do? Fortunately, there are solutions.

Managing and securing privileged accounts

Any remedy to these security risks must eliminate the problems that privileged accounts present without undermining the IT staff’s ability to do its job. This requires three areas of action that must be taken:

Eliminate password sharing

Simply removing the need to share administrative passwords will go a long way towards mitigating the risks inherent in privileged accounts. But that’s easier said than done. There are many times when the superuser account is needed. Rather than attempt to manually control password issuance, approvals, assignments, and rights – an arduous process – simply implementing an automated ‘privilege safe’ or ‘password vault’ will solve the problem.

A privilege safe/password vault is the software equivalent of locking a collection of passwords in a physical safe. Only the boss knows the combination and gets them out only when it’s necessary.

Privilege safe technology takes superuser passwords out of the hands of the various administrators that previously shared them. Based on a strictly defined policy, when an administrator must use a full-superuser credential, he or she must request it through the privilege safe. The privilege safe automatically checks the policy, and then issues the password for a specified amount of time, providing all conditions are met. When the password is ‘returned,’ it is automatically changed, and the entire process is logged.

For example, let’s say you’re the IT person on-call for the weekend. The policy defines that, if a server goes down while you’re on-call and it’s one of the 50 that you normally manage, the password is automatically issued to you for 30 minutes. Your superior will get notified of the event by email or SMS messenger.

But, if you request the password when you’re not on call, or if you request a password for a system that you normally don’t manage, the privilege safe will only issue the credential after a specific confirmation from your boss, and you only get it for whatever period is defined by the policy. Either way, as soon as you check the password back in, the system automatically changes it, preventing you from using it again outside of policy and approvals.

Privilege safe technology is also extremely useful for passwords hardcoded into applications because they talk to other applications, service accounts, and or databases. This application-to-application (A2A) and application-to-database (A2DB) activity is an often-overlooked privileged account security hole that can easily be closed with the right PAM technology.

Make sure that your privilege safe covers all your needs – not only shared accounts on systems, but also those embedded in applications and service accounts on infrastructure, as well as privileged accounts accessed by third-parties and outside organizations.

The privilege of safe plays a foundational role in privileged account management solutions. It offers all the security and management you need while helping you overcome the inefficiencies and risks of shared passwords and manual control processes.

These password vaults are quite prevalent (60% of surveyed organizations that have technology-assisted PAM programs report using a password vault), but should be considered a first-generation PAM approach. It is necessary, however, by no means adequate to cover all the issues that PAM is meant to address.

Enforce a least-privilege model

You may read this and ask, ‘Isn’t an administrator’s job to administer? How can that be done without the administrative credential?’ The vast majority of IT activity only uses a small portion of the superuser account capabilities. Setting up a new user, resetting a password, or backing up a system are constant tasks– more frequent than makes sense for a password vault. For that day-to-day, low-risk activities, delegating portions of the privileged account makes the most sense.

A least-privilege model means you only issue an administrative user the smallest amount of permission necessary to do the job. Anything that exceeds the least-privilege model would fall under the privilege of the safety protocol.

Natively very few systems include a delegation capability, so third-party solutions are usually required. Perhaps the best-known solution is a UNIX utility called sudo which stands for superuser do, ships every UNIX and Linux OS.

When an administrator needs to perform a task that requires elevated rights, he or she prefaces the command with ‘su.’ Sudo then checks a policy file, and if the requested command is approved, it is allowed. If it is not approved, the administrator is not allowed to execute the command. Unfortunately, there isn’t a sudo for Active Directory or Azure Active Directory, probably the most ubiquitous infrastructure at most organizations.

Watch what is done with elevated access

It isn’t enough to simply control what administrators are allowed to do through a password vault and delegation. You should also know what they do with those permissions. The ability to audit privileged sessions is as important as the ability to control access, particularly from a compliance standpoint. The best delegation and privilege safe solutions will also include the ability to track activity performed through the rights they control.

There are two alternatives for monitoring administrator activity. First are session audits, which, when combined with a privilege safe, provide a thoroughly documented view of activities performed with the issued password. Session audits also include command control to restrict actions and enforce a time limit. You can even force a session to end if desired.

Our survey revealed that the vast majority of organizations engaging in PAM programs lack confidence in their ability to audit administrator activities (70 percent report fair or worse confidence).

Session audit is also a first-generation PAM technology. Most solutions require agents that can bog down operations. However, moving these important capabilities into a transparent, low-impact, non-obstructive mode paves the way for next-generation PAM. This next-generation capability would expand the scope of auditable systems beyond common network target systems. It can include cloud resources and a growing number of additional targets, such as corporate social media accounts.

The second type is keystroke logging, which is typically available with platform-specific delegation tools. Keystroke logging records everything typed and makes it available for search afterward.

The area of PAM that is quickly becoming the best weapon on the front lines is an analytics

Privileged behavior analytics can watch the use of privileged credentials and pinpoint areas of misuse or bad behavior. The solution creates a dynamic baseline for each privileged user that records biometric data, such as keystroke patterns and mouse movement tendencies and combines them with time- and location-based information and typical command behaviors. Based on this data, it can detect anomalous activity, such as a bad-actor impersonating a legitimate privileged user.

A next-generation PAM approach would layer privileged behavior analytics on top of password vaulting and session audit.

The best approach to privileged access management would include all four of these action areas.

An international credit card processing company faced all of the classic PAM challenges. With a high volume of shared administrative passwords, the organization was unable to assign individual accountability for admin activities. They had no idea what was done since users were logged on as administrators. Also, due to a large UNIX deployment, the challenges of the root account were particularly worrisome. The company used sudo, but could not still confidently address audit needs, and feared that its attempts to enforce a least-privilege model on UNIX specifically were inconsistent and error-prone.

The company implemented a privilege safe with session-audit capabilities to eliminate password sharing, achieved individual accountability for activities, and provide an audit trail when the superuser account was in use. For the UNIX environment, the company centralized identity and policy for UNIX in Active Directory through an Active Directory bridge. It then enhanced its sudo installations with centralized policy and reporting capability, which brought a much higher level of visibility and control to the UNIX root account.

However, the company also had a subset of highly sensitive UNIX servers that could not be adequately served with sudo. For these servers, the company replaced sudo them with an extremely granular and secure root delegation and keystroke logging solution.

The result was an immediate improvement in security. The company also gained peace of mind in knowing that administrators only had access to perform approved activities. One of the barriers to the effective management of privileged accounts is the disjointed nature of available solutions. Many organizations already use sudo. They may buy an Active Directory bridge and root delegation solution from one vendor, and a privilege safe from another. Or they may have considered using some of these solutions, but are not sure if they will work well together. Sound familiar?

Approach privileged access management the same way you approach access management and identity governance. Only adopt technologies that are modular and integrated, share policy and workflows, easily plug into the larger IGA initiative, and place the power in the hands of the right people. This will ensure that the solution you buy today will be future-proof.

A short detour into governance

A key IAM prioritization principle is that you must satisfy access and security before you can address management and governance. Over the past several years, management of user access and identities has progressed so that many organizations have moved on to their governance objectives. In general, privileged accounts lag a few years behind end-user accounts in terms of evolution.

The next big thing for privileged accounts is governance. Imagine the benefits if the business was empowered to make decisions that impact privileged accounts. Imagine if a single universal policy and set of roles, and a common interface controlled both end-user and privileged-user access. (After all, privileged users are just end-users with some extra permissions anyway.) And imagine if, when a new administrator was hired, the same automated processes that set up his application accounts and access could set up the correct privileged accounts. This would include all the necessary least-privilege and password vault rights, approvals, and workflows augmented by analytics.

But above all, imagine the advantages if the most difficult IGA activities – usually attestations – could be executed with the same convenience and through the same solution already in use for IGA for both applications and unstructured data. Now that would be cool.

Source: One Identity