How to Leverage a Comprehensive Privileged Access Management Security Approach

Effectively managing privileged access has become a top priority for many organizations seeking to protect their data and systems from unauthorized users. That’s because inappropriate access can expose valuable organizational data, compromise sensitive information, and adversely affect system reliability. The latest Verizon Data Breach Investigations Report found that the majority of data breaches leverage privileged accounts directly. Further, the average cost of a data breach today is $3.9 million, according to the Cost of a Data Breach Report by the Ponemon Institute. What’s more is that the effects of a data breach can last for years—and in a worst-case scenario—completely destroy a business.

With compromised credentials considered a leading cause of data breaches, organizations cannot afford to ignore the importance of privileged access management (PAM). And more than ever before, companies are looking for more effective and efficient ways to protect their data with PAM solutions. During this blog, we will examine what privileged accounts are, explore how the need for privileged access management has evolved, analyze two leading approaches for managing privileged access, and demonstrate how a leading alternative to password vaulting can help ensure your organization leverages a more comprehensive security approach.

What Are Privileged Accounts?

Privileged accounts are typically shared accounts that inherently possess elevated access to data or services. Examples of elevated privileges include the ability to change system configuration, to install or remove software, or to add, remove or modify user accounts. Elevated privileges can also just simply be access to sensitive data. Below are three specific types of privileged accounts:

• Root/Administrator Accounts: These accounts possess full authority to systems and have no restriction for accessing services or data residing on a server. They are considered the most valuable targets for threat actors.

• System Accounts: These accounts are used for running operating system services and can modify the relevant files and configurations. They are typically provisioned with the operating system.

• Service/Application Accounts: These accounts are used for running processes and applications through automated, often unattended, tasks. They frequently own or have access to data, resources, or configurations not available to non-privileged users.

Non-privileged accounts differ from privileged accounts in that they do not have elevated access levels in the organization. Compared to privileged accounts, user accounts, such as employee accounts, should not have elevated privileges directly assigned.

How the Need for Privileged Access Management Has Evolved

Now that we’ve outlined what privileged accounts are, let’s examine how organizations have managed elevated privileges in the past. When server numbers were fairly low, it was feasible to manage passwords for these types of accounts manually. It wasn't uncommon to periodically have an administrator reset passwords on a per-server basis, and then share those new passwords with appropriate personnel. Unfortunately, it was also common for passwords to go beyond scheduled change rotation, or sometimes never be changed at all, simply to make things more convenient operationally.  

Over time, a few things happened. Server numbers started to grow dramatically, fueled by virtualization, or creating a virtual version of an application, server, network, or storage device, and more recently with cloud adoption, or the move to hosted servers. From an operational perspective, it became much harder to maintain best practice in updating and maintaining privileged credentials.

At the same time, as technology evolved both from a hardware and software perspective, it was becoming easier for threat actors to attack passwords directly, and with increasing success. Weak passwords, coupled with overdue change rotation, made them easy targets, resulting in significant risk to the organization.

The Complexity of Early Privileged Access Management

To illustrate the complexity of early privileged access management, let’s explore an analogy. Imagine a room with file cabinets that contain sensitive information. The room has a door on which a padlock is placed. Entry to this room for the privileged access requires a key. Using the initial password model, which was commonly deployed in the early days of privileged access management, organizations would make copies of a key, which represents the password, and hand them out to authorized users. To manage the operational burden, the organization may even decide to use the same key for multiple rooms. Making matters worse, individuals with this access could make additional copies of the keys, share them with colleagues, or simply leave them laying around unattended. Periodically, the padlocks would be changed and new keys would be distributed.  

This system became harder and harder to manage with an exponentially growing number of rooms. An increasing number of locks and keys would have to be changed regularly and distributed to administrators to keep up with more stringent compliance regulations. Over time, organizations realized that this approach was weak and increasingly easier and easier to break—a better solution was needed.

The Movement to Password Vaulting

The initial password scenario described here highlighted the need for a different solution. Password vaulting was introduced as a way to address the weaknesses of managing privileged account passwords directly. A password vault is a central repository for securely maintaining privileged account credentials. The vault can automatically update the credentials on target systems based on a scheduled basis or based on an event, such as the password being exposed to a user. In our analogy, a security service is hired to provide access to the password vault.

Capabilities initially allowed an administrator, with proper authentication and authorization, to access the password vault to ‘check-out’ the password for a specified privileged account, and then use that password to gain access to the privileged account on a target system. This provided a number of benefits, including allowing the organization to keep track of who had checked out passwords to maintain an audit trail. It ensured that as password rotation became automated, passwords could be rotated more frequently and more reliably. Password policies could also be configured to guarantee that strong passwords would be generated.

The Rise of Privileged Account and Session Management

As password vault solutions matured, new features in these solutions became available, resembling Privileged Account and Session Management, or PASM, that we know today. Instead of users 'checking-out' passwords, the user would authenticate to the vault, and again with proper authorization, the vault would make the connection to the target server and present the input controls and output to the user.

The password never needed to be exposed to the administrator, increasing security. Some vault solutions could also inject credentials into an application authentication stream as opposed to having plain-text passwords buried in scripts. Brokering a server connection in this way would also allow recording of the session.

The Limitations of a PASM Approach

The PASM solution is relatively easy and quick to deploy, and therefore, is a good first step in moving an organization closer to their security goals. However, there are limitations associated with PASM. Privileged Account and Session Management is an all-or-nothing approach. In the PASM model, outside of the privileged access request, the privileged access is not really monitored. In the analogy described earlier, the room remains protected only by the padlock and there is no one onsite to monitor the door. 

If users show up with a key, regardless if they got it from the security service, as in the password vault or PASM approach, or through some 'alternate' means, they could gain access to the room. The lock would also remain available for any anyone, including bad actors, to attempt to break at their leisure. In other words, the solution is still highly vulnerable to password-based attacks. So is there a more comprehensive solution for organizations that need it? Let’s take a look at another approach to privileged access management.

The Evolution Toward PEDM: A More Comprehensive Approach to Managing Privileged Access

Privilege Elevation and Delegation Management, commonly referred to as PEDM, offers a more sophisticated and comprehensive approach by using host-based agents to grant privileged users access on a granular basis. In this model, access and privilege could be maintained with a least-privilege, role-based approach.

Let's go back to our analogy to understand what we're talking about here. With the PEDM model, the security service still exists, but they've decided to get away from the lock and key business. They do continue to maintain policies and ledgers, but instead of dealing with locks and keys, they coordinate with local security agents located at each room—the host-based agents.

With PEDM, organizations can have security onsite at all times. When a user needs access to the room, the local security agent makes a call to the centralized security service. The security service could look up the information for the user, examine their role in the organization and any other privileges granted to the user, and let the local security agent know what—if anything—the user is allowed to do. This approach scales much better, centralizes management, and enhances overall security.

The Leading PEDM Solution for UNIX and Linux Environments

Core Security provides a leading PEDM solution designed specifically for UNIX and Linux environments. Core Privileged Access Manager (BoKS) transforms a multi-vendor Linux and UNIX server environment into one centrally managed security domain, enabling organizations to centralize user and group provisioning, manage access control, and leverage single sign-on and strong authentication, common password policies, and audit all login access. BoKS simplifies the ability to enforce security policies, and control access to critical systems and information. With full control over accounts, access, and privilege, IT and security teams can proactively prevent internal and external attacks on critical systems before they start.