Privileged user access management: How to avoid access creep

One of the most difficult areas of privileged user access management is avoiding access creep. John Burke covers how to keep privileged users in check.

This tip is part of SearchSecurity.com's Data Protection Security School lesson, "Watching the Watchers." Click the lesson link for additional material on how to monitor the activities of your most trusted insiders with a combination of policy, process and technology to keep unauthorized access and data loss to a minimum.

OK, let’s make the assumption your directory is lean, mean and correct: It contains all and only those users with a current, sanctioned role in your organization.  This happy state of affairs falls out of a robust account management lifecycle.  Have you reached the point where you get to rest on your laurels? No.

Though IT is getting steadily (if slowly) better at having the directory reflect the reality of the organization with respect to who should be in there, it is not as good at making sure those active identities have all and only the privileges they need in order to do the work they have to do.  Whether because their directories don’t support granular enough privileges, or because they have small staff and therefore have to grant broad access to lots of people, or because they have a large staff and people change jobs and tend to accumulate the sum of all the privileges they’ve ever had -- called access creep -- controlling privileged system access is a significant challenge.

One key discipline in properly controlling access privileges and how they are used is role-based access control (RBAC).  RBAC says, don’t manage user account privileges directly; instead, define the privileges that users fulfilling a specific role require, and assign roles as appropriate to user accounts.  When a user’s role changes, their access rights change too. This mitigates access creep; when someone’s role changes from being a DBA to being a Unix sys admin, they would lose the database privileges they needed for the former role while gaining OS-level privileges they previously did not need.

To make role-based management work robustly, and to the satisfaction of auditors, IT needs to keep the role set as simple as possible; minimize the number of exceptions required to make it work practically, and have some backstop for managing the use of account privileges.  Basically, identity management systems can help you do role-based management, and some can help you do a good job of minimizing the set of roles you use and the exceptions you grant; far fewer can help you robustly track how privileges are used or give you additional fine-grain control of them. 

Note, when we speak of privileges it is with the understanding that IT (and the auditors) mostly want tracking of privileges associated with system, database and network administration; the skeleton keys that give wide-ranging, even unfettered access to otherwise fiercely protected data.  However, it should be noted that other privileges might be of great interest to other parts of the business, e.g. the ability to create or remove document images from a storage array holding images of scanned paper forms.

Privilege management tools (AKA privileged account management, super user privilege management, or privileged user management tools) help you go beyond accounts and roles.  They go beyond what traditional tools support to help fill the gaps in privileged user access management, granting an additional level of visibility into the use of privileges and additional granularity in the granting of access to users or systems.

An ideal privilege management tool:

  • Can be more granular than standard account privilege groups: For example, a PM tool might grant or limit access to specific components within applications (e.g. selectively allowing or disallowing “Save As” or “Print”); filter the set of privileges granted along with a role based on a variety of factors, including where someone has logged in from and what else they have recently done; grant specific elevated privileges to otherwise non-privileged roles or processes.
  • Can easily work with non-directory accounts, e.g. the local administrative accounts on servers and desktops.
  • Can manage privileged accounts not only in your directory or directories, but also on all the platforms you care about: your mix of Windows, Linux, Unix or others.  Management includes change management, e.g. making sure that one privileged user making changes can’t unexpectedly hurt the ability of others to work, as when one changes the local admin account password on a server to which several need access.
  • Can audit use of privileges: For example, the privilege management tool might force admins to check access (perhaps via a one-time password) out and in again, and so track each time sensitive access rights are used, as well as track which actual person is using a shared account.

If IT is to have any hope of making management of privileged accounts at least as successful as management of identities, such capabilities will increasingly be seen as a necessity.

About the author:
John Burke is a principal research analyst with Nemertes Research, where he advises key enterprise and vendor clients, conducts and analyzes primary research, and writes thought-leadership pieces across a wide variety of topics.

This was first published in December 2011
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close