Security

How to successfully implement the principle of least privilege

Least privilege is a core security principle, but it's one that often meets with resistance by users. Here are tips for how to implement it and get the point across to others.

The bane of many information security pros' existence is the never-ending quest of attempting to enforce the principle of least privilege. At its core, this is a data security issue, limiting the number of people having access to more data than they should (for example, someone in marketing having access to payroll records). Generally, any attempts to rein in access levels tend to be met with disdain as they are perceived as "trust" issues. While we can't strip away all their privileges (this would grind the business to a halt, you can't be too liberal either. This leads to privilege abuse or people being too timid about their data security responsibilities.

The key is to give employees access only to what they need and when they need it, so that they can best perform their job in a safe manner. In most businesses, least privilege is wholly misunderstood by non-IT folk (this is a failing on IT pros for not properly communicating the importance of this principle). IT security has no chance of fully enforcing least privilege without complete buy-in from their non-IT colleagues (yes, this is true for all security initiatives). To maximize your chances of successfully implementing least privilege access, I suggest incorporating these critical steps:

#1 Involve all stakeholders when defining privilege access levels

To gain company wide acceptance and properly understand the access levels for the system(s) in question, you will need to fully involve all stakeholders. If it is an enterprise wide system, representatives from HR, finance, marketing, etc will need to be involved as they will be best able to articulate who will need access and to what within their specific departments. This is more effective and efficient than IT "blindly" dolling out access.

#2 Take role based approach

Where possible, allocating access to roles rather than to specific individuals is far more manageable to maintain least privilege access from an operational perspective. People are less likely to accrue additional access (access creep) over time as roles are easier to revoke. This is especially helpful when staff move within the organization frequently.

#3 Define review process

Institute a review process (once a year) to check that the roles/access permissions are still meeting least privilege and business requirements.

Making the case to others

One question remains - how can you illustrate its importance and relevance? Here's my go to metaphor for explaining least privilege to my business counterparts:

Let's say you go on vacation and give your friend/neighbour a key to your home (to feed your pets, collect mail, water indoor plants, etc.). What if you don't have any pets and you only require your friend to occasionally pick up mail? Would you give your friend the key to your house when they only require the mail key? While you may trust your friend implicitly, there is still a possibility that he/she will hold a party in your house without your consent (especially if your friend happens to be Charlie Sheen). Whether or not you trust your friend is immaterial; there is no need to put yourself at increased risk by giving more access than necessary. In a nutshell, this is what least privilege is all about. There may be times when you need your friend to go inside to your house so you temporarily give him/her your key (think temporary elevated access at work). Any length of time when someone has your house key and is not being supervised by you constitutes an exposure window. The intent is to keep such windows as short as possible.

I find that this metaphor to be extremely effective when explaining least privilege. Try using it next time you run into resistance trying to implement this principle. I would love to hear if it worked (or if you have a security metaphor you would like to share).

About

Dominic Vogel is currently a security analyst for a financial institution in beautiful Vancouver, British Columbia.

Editor's Picks