Security optimize

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.

6 comments
o_p_i
o_p_i

As I am used to from my own experience as a "consumer" of security restrictions, I miss in this article the explanation how in "what they need and when they need it" the "when" is addressed. It happens twice a year to me that, because of sudden demand of our board, or sickness of some person, I have to jump into and, not quickly, but immediately are expected to start moving things. Of course the board expects immediate satisfaction. The customer does this. But security processes never seem to be defined to satisfy the real life needs of "access now". Either the person to grant the rights is not in or available, or the person who technically needs to do some settings somewhere in the IT infrastructure is not reachable, or... Working with this approach of "least privileges" requires a process which makes clear to all persons involved in granting rights, that they MUST be available at all times, either in person, or by naming a (really) available substitute.

idallen
idallen

Leaset privilege isn't just about trust; it's also about minimizing the damage a person can do by accident. Let people be human and make mistakes occasionally, but limit the damage they can do to be just in their area of responsibility. "Ooops, I scrambled the office printer passwords" is better than "Ooops, I scrambled passwords for everyone in the entire enterprise". Design systems so that people can be human - know that mistakes will happen and make it easy to recover. Of course your top sysadmin will likely need privilege to do almost anything, but even they can choose roles that limit the damage they can do. (And keep good backups!)

andrew232006
andrew232006

If you don't you're setting yourself up for trouble. People do not like having power taken away from them and there will be some who hate you for doing it no matter how you explain it. And sometimes when they find a problem and let others know things snowball. "Well I had access before" when they didn't "I can't access anything" when they can't access one thing "No one can open the folder" when one person can't "The server is offline again" when their monitor is off Unfortunately some don't see why it is necessary until it becomes necessary and the system is compromised.

ed
ed

I was in what I regarded as a line position in an organization and out of curiosity tried to get access to something I really didn't think I needed. I got right in. Didn't try creating or deleting anything for fear it would work. I went to the IT guy responsible and told him what had happened and he said, "Yeah, [somebody decided] that [all people in that position] need to be administrators." Oh, my. Believe me, I was careful after that. Then I retired and I emailed the IT guy (still there and still a great guy who helped a lot of people a lot) asking to be sure my administrator permissions had been revoked. He told me they go through them twice a year, so that would have been fixed twice before I thought of it. Yes, maybe I'm at the other end of the trust spectrum, not wanting to cause a problem. But I sure was surprised they didn't make doing that closer to idiot-proof. And then there was the time I came in and found my network access cut off. Went to the tech and said he had received an email about me and to see Debi. She told me I was the lucky one of two or three that had managed to get infected with a malware about six hours before the automatic update would have stopped it. Then she made my day and said only a complete wipe and reformat would fix it. I asked if somebody needed to check it and she said if it was a reformat, it would be caught and just let her know. I was happy when she told me my data files were all okay and just copy them to a USB hard drive. I have some software only I use, so there wasn't an image that could be downloaded.

joay
joay

I never think like that......amazing for me.

mikewor
mikewor

One size does not fit all, and neither do strict role based privileges. In the real world, there are always exceptions, some of them for a short time or for the duration of a project, some because of the special role (e.g. the CEO's PA usually needs more rights than the any other PA, even on the C floor). But when trying to gain the additional privileges, one is often treated like a criminal, or forced to wade through rooms fiull of red tape. This is, I believe, the key reason for people trying to get more privileges than the would normally need 'just in case'. So when implementing or revising privileges, please make sure there is an easy (this does not mean uncontrolled) way for exceptions to be made to the standard role based privileges.