Least Privilege Access – Still at the Front Lines of Security

Ever since authentication and authorization became the norm for access to computer systems, the principle of least privilege (POLP) has been the de-facto baseline for proper security. At its very core, least privilege access means granting a user just enough permissions (authorization) to access the data and systems in their company's enterprise necessary to do his or her job – nothing more, nothing less. In theory, adhering to the POLP sounds like the perfect identity and access management strategy, but often implementing least privilege is easier said than done.

Why is it so hard?

There are a number of factors to consider. First, in order to implement least privilege, there needs to be a clear understanding of what the right access actually is for each user and their role. Second, in order to enforce the defined level of access, there has to be some sort of enforcement tool. And third, the definition and enforcement of granting access should be executed in a way that doesn't get in the way of users doing their jobs. While least privilege is of value for securing all types of access, it is most critical when managing administrator access.

Some systems make it easy with well-defined roles and granular definitions of the permissions associated with those roles. But other systems aren't as cooperative, with no native utilities to define and enforce what right actually means. For those systems, organizations are often left to their own devices relying on tribal knowledge to define right and have limited tools to enforce it. The result is many organizations deeply wanting to enforce least privilege but, in practice, finding themselves only successful on a very limited scale.

From an administrative access standpoint, many organizations take the easy way out by sharing administrative (or "superuser") credentials among all individuals who might require them for their role, giving many more employees more access to data and systems than may be necessary to do their job – the polar opposite of POLP.

The classic example of least privilege for administrative access is an open source utility available for Unix and Linux systems called sudo (short for "superuser do"), which allows an organization to define a role with a certain subset of the all-powerful root credential in a sudoer file. When an administrator logs on, they must preface the command with "su." If the command in question is allowed in the sudoer policy, the user will be allowed to execute it – if not access will be denied.

Sudo works great in many instances. However, when a Unix/Linux environment hits a certain size, the fact that sudo runs independently on each Unix/Linux server makes its execution of least privilege unruly, error-prone, and counterproductive. Consequently, there are whole categories of privileged access management (PAM) solutions that either replace sudo with a single solution that covers the entire environment with one policy and enforcement set along with keystroke logging, or augment sudo with centralized policy across all instances (as opposed to multiple islands of sudoer files).

When looking at PAM, Unix/Linux is typically only a part of the overall PAM picture. There are other systems where unchecked administrator access can be just as damaging, if not worse, than Unix/Linux. For example most organizations have a significant investment in Microsoft Active Directory (AD) and Azure Active Directory (AAD) with those systems being the primary front door for the majority of end user access needs. This makes the AD/AAD Admin critical in any PAM program. The POLP should extend to these administrators as well.

The reality is that beyond the Unix/Linux and AD/AAD platforms, POLP is extremely difficult to enforce consistently in the modern heterogeneous enterprise. Some applications have the capability built in, while others make no attempt to enable the practice. It becomes a crapshoot – but is a practice that needs to be run as much as possible through all PAM programs. Here are a few tips to help you get the most from the POLP in your PAM program:

Make the most of what you can control: within Unix/Linux look for opportunities to improve on the native sudo capabilities to eliminate weaknesses and improve operational efficiency in executing least privilege. Simply augmenting or replacing sudo with a commercial solution yields significant security gains. Similarly, with the status AD/AAD enjoys it only makes sense to seek third-party assistance in removing the all-or-nothing default of administrator access.
Use a vault: privileged password vaults are a great alternative to shared administrative passwords when least privilege is not an option. With day-to-day Unix/Linux and AD/AAD admin access delegated in a least privilege model, placing security, policy, and automation around the issuance, approval, and management of other privileged passwords makes sense. It removes the anonymity that is so dangerous with unchecked administrative access and provides controls around the whole process. Vaults also provide a viable alternative to issuing the entire permission set of a delegated admin account to a single user. Delegate the day-to-day activities and vault the superuser access for firecall and other critical tasks.
Audit activities: no PAM program is complete without the ability to close the loop on what administrators actually do with their permissions. Employ session audit and keystroke logging to augment delegated administrator access, allowing you the visibility to know what is actually done with the permissions in question.
Implement analytics: the final piece of the PAM puzzle is to implement analytics. Privileged behavioral analytics will help detect anomalous and dangerous activities, while identity analytics will evaluate the rights associated with an individual administrator's permissions in both the vault and the least-privileged model. Analysis of rights and permissions across administrators in similar roles can help organizations identify weak spots in your least privilege model.

The POLP is a critical component to any effective PAM program, but it is not the only principle. A well-rounded program will also augment with POLP with vaulting, session auditing, and analytics to truly deliver on the security objectives for which the program is designed.

About the author: Jackson Shaw is senior director of product management at One Identity, an identity and access management company formerly under Dell. Jackson has been leading security, directory and identity initiatives for 25 years.