When a knowledge worker transitions from one enterprise job role to another -- a common occurrence in virtually all organizations -- often he or she will continue in the old role for days, weeks or longer. Often the old position goes unfilled, so an individual will perform both the old and new jobs for a time. After the worker is in his or her new role, it's often necessary to train a replacement or contribute to a long-term project that was started from the old role.
If the user account of a worker with excess privileges is compromised, an attacker would be able to access more data or perform more functions.
As workers move from position to position within a company, the typical result is an accrual of access privileges for all of the roles they have held. This common occurrence is known as "accumulation of privilege" or "privilege creep," and it is an information security risk present in many organizations today. In this technical tip, we'll discuss the risks associated with accumulation of privilege and how to successfully mitigate them.
Privilege creep: The risks
Accumulation of privilege brings with it two sources of risk: A worker who retains access privileges no longer needed may someday be tempted to use them inappropriately; also, if the user account of a worker with excess privileges is compromised, an attacker would be able to access more data or perform more functions than if the worker's account was limited to just the access that is truly needed.
IT departments are usually responsible for managing the process of receiving requests for access to systems. This process includes a review of any given request, followed by the actual provisioning. When an employee moves to a new job or department, the employee's manager typically makes a request for the access change based on the new job role of the employee.
However, because employees usually still need access to the privileges associated with his or her former position, there is no request made to remove the access rights associated with that position. For reasons stated above, it's logistically complicated to request access rights removal because they may be needed for a while. And because everyone is looking forward, the matter of those accumulated access rights is soon forgotten. IT prioritizes new access requests, because delays in fulfilling them impede business.
Privilege creep: The remedies
A separate process is needed to tackle the accumulation of privileges problem. Generally called an access rights review or an access recertification, system owners and managers are called upon to confirm each worker's need to have access to specific roles and rights. This review will discover, and remedy, those accumulated access rights.
Sometimes, when a system owner or manager is reviewing access rights for an individual worker, the question arises, "What other systems and roles does this worker have access to?" Unless the organization has a fully integrated identity and access management system (IAM), this question is often difficult to answer without asking other personnel (who manage systems beyond the control of corporate IT) to research their own systems to see what any given worker has access to. This process doesn't scale for large numbers of workers -- doing it one at a time can be hard enough.
An organization that has implemented an IAM system can perform access reviews and recertifications easily (such reviews are a core feature of mature IAM platforms), and it is just as easy to see instantly all of the systems, roles and access rights an individual worker has. This helps make an access rights review or recertification easier, since management has instant access to information needed to make decisions regarding workers' continued access.
With assistance from an IAM administrator or policy maker, it is also possible to recalibrate the IAM recertification so that the IAM system can flag high-risk user access combinations and IT can adjust access rights to meet both business and security needs.
More on enterprise IAM challenges
This month, expert Peter Gregory examines today's enterprise IAM challenges and how to overcome them.
Organizations that lack a modern or sufficiently sophisticated IAM system will probably have to resort to more manual means to conduct an access review. Essentially, someone has to "join" user accounts in an application with HR data. This can often be done with Microsoft Excel or a Microsoft Access database. What is needed is a list of application users, along with their application role(s), job titles, departments, manager's names and perhaps other fields. The simplest approach is to group users by their respective managers, and send the list of users and their roles to each manager and ask them to certify that each user still requires the listed roles. Of course, the process can be made as complex as the organization requires -- for instance, getting approval from application or data owners as well as multiple levels of approvers. It all comes down to the level of risk associated with people having access to sensitive functions and information.
Privilege creep: Automation and success
A dimension of the original business problem -- accumulation of privilege -- is also solved by newer IAM platforms: They can be configured to automatically remove a worker's access to specific roles on a predetermined future date, or send an "approval to remove access" workflow item to an appropriate system owner or manager, thereby reminding them to remove unneeded access when the time is right.
The bottom line is that every organization needs to determine the amount of risk it is willing to tolerate based on detailed knowledge of who has access to its systems, roles and data. The less detailed this knowledge, the more rigor is needed, starting with user access reviews.
About the author
Peter Gregory, C|CISO, CISA, CISSP, CRISC, PCI-ISA, is a Seattle-based enterprise information security manager. He has worked in the information security industry for more than 20 years, and has written more than 30 books on technology and security.
This was first published in April 2013