arrow Created with Sketch. Insights Blog

Jan 25 / 2017

The Principle of Least Privilege

christian.duvall@workstate.com (Christian Duvall, Group Vice President, Enterprise Services)


An Identity and Access Management Best Practice

When it comes to Identity and Access Management (IAM), there are many ways to build a great solution. You can choose from cloud, on-premise, or hybrid platform. You can use a major user directory, like Microsoft's Active Directory, or roll your own from a database. You can even define the most elegant policies and procedures imaginable.

However, none of these decisions matter if a user can access something that they should not be accessing. This is where the “Principle of Least Privilege” (PoLP) comes into play. The principle states:

A user should only be granted the smallest possible set of privileges necessary to fulfill their required function.

More simply put, don’t give people access that they should not have.

Back in 1995, convicted felon Daniel Heiss escaped from prison without the aid of any classic movie tropes. No blueprints, no dummy stand-ins, and no secret tunnels made with a spoon. Daniel simply used a key to walk right out.

You see, on the prisoners’ handbook was printed a photograph of a key. After duplicating the key, Heiss discovered that it was not only a working key, but one that worked on all the locks in the prison where he was residing.

Let’s ignore the amazing oversight of putting a real key on the front of a guide, freely distributed to all prisoners. If the key only worked for the cells, or for a specific door between blocks, then the plan would not have got Heiss very far. But the key was the master key, and it landed in the wrong hands.

This is a great analog to the PoLP – and in the IAM world, an unfortunate, but all-too-common one. Over 75% of all intrusions come from compromised credentials.

It's not just unauthorized access that we should be concerned with. Consider a few other scenarios:

  • A user is granted too much access and intentionally accesses, tampers with, or distributes sensitive information.
  • A user is granted too much access, is untrained on the features, and makes a costly mistake.
  • A service account controlled by a process has a bug, causing it to impact parts of the system that it wasn’t written to handle.

The amount of disaster recovery, pain and damage control could be largely reduced by following some Identity and Access Management best practices.

Here are four critical steps that we feel should always be performed to ensure “least privilege” is not only effective for your access management, but also for your users.

1. Take Inventory

Understanding what your users can access, and how they gain that access, is an important first step to any identity-related activity. This is more than just an audit – this is developing a baseline and end game. Make sure that each decision is weighed against the PoLP and craft a reference architecture that defines your ideal outcomes.

This process can then feed into a gap analysis and remediation plan, which will inform you on what it will take to get to the goal line.


2. Build a Flexible Authorization Framework

The number one reason that users end up with more access than required is due to the lack of options.

Let's say you're the manager of an important cross-functional application, which has two roles: User and Power User.

The User role is granted access to basic transactional actions, while the Power User gets access to reports, task assignments, and most critically – management of the system's master data.

You're called out of town at the last minute, but your boss needs a report for the shareholder's meeting by tomorrow. Panic! Luckily, your best employee is ready to save the day.

So what can you do?

  • Loan the employee your account for the evening. You trust them, what could go wrong? Ok, so that's probably not a great idea. (Note: for the love of puppies and rainbows, don't do it)
  • Grant the employee Power User access, just until the report is finished. What if you forget to revoke it? What if they accidentally do or see the wrong thing?
  • Request a new role to be created that only gives access to the specific report. That's a lot better, but it's might take too long to happen. Plus, this situation doesn't happen just once – it happens all. of. the. time. Your simple two-role system becomes one with 50 special roles, partitioning Power User into untethered fragments of insanity.

This is why your framework should be carefully crafted to handle situations like these, especially across the useful life (years) of your system. It is good to note this truism:

When the options aren't available, people will choose least resistance over least privilege.


3. Assign Ownership

IT should not decide who gets access to a (non-IT) system. Read that sentence again. Tell it to the next person you see. Go tweet it. It's fine – I'll wait.

Now that it's fully internalized, it should be fairly obvious to say – the business should own all access rights management for any IAM-controlled system. If the system has multiple owners, a steward must be assigned per function. This level of accountability combined with domain knowledge will be a major component in ensuring that the PoLP isn't violated. Some of the steward's core activities will include:

  • Remaining well versed on the authorization framework and what each access level grants.
  • Being the gatekeeper for whether all, some, or none of the requested access is granted.
  • Keeping a finger on the pulse of what access is appropriate and curate the assigned rights appropriately.


4. Perform Routine Audits and Triggered Access Reviews

Things change. Employees leave, change roles, or otherwise lose the privilege to perform activities they once could. You can't expect a steward to keep track of all individuals real-time, so two key processes need to be established:

  • A periodic audit of everyone and everything that accesses the secured system. These reviews should be scheduled based on the business risk and value of the secured information/activities.
  • A triggered access review, when specific events occur, such as: an employee changes departments, changes role (title), goes on an extended leave, or is no longer with the company.

These process should be a matter of absolute policy and require completion within a pre-defined amount of time from the event.

If you’re interested in learning more about the fundamentals of Identity and Access Management, sign up to receive our FREE Primer on IAM Terminology and Concepts.


Get IAM Primed Now!