privilege creep

The slow accumulation of access rights by a person or an account as jobs change and old permissions are never withdrawn, until what they can do bears no relation to what they need to do.

Nobody grants privilege creep; it is what happens when permissions are added for each new task, project or transfer and removed for none, so that a ten-year employee can still reach the systems of every team they have passed through. NIST's control catalogue names the dynamic without the slang: in AC-6(7) it says that "the need for certain assigned user privileges may change over time to reflect changes in organizational mission and business functions, environments of operation, technologies, or threats", and requires a periodic review of assigned privileges to "validate the need for such privileges" and to "reassign or remove privileges, if necessary". Microsoft's documentation on access reviews asks the same two questions of every organisation: "As people move teams or leave the company, how do you make sure that their old access is removed?" and warns that "excessive access rights can lead to compromises" and "can also lead to audit findings as they indicate a lack of control over access". The cure is procedural, not technical: joiner, mover and leaver processes tied to the HR record, roles instead of individual grants, time-bounded exceptions, and reviews in which an owner has to say yes to each entitlement again or it is removed.

Privilege creep is the name practitioners give to a drift rather than a decision. A person is hired into one job and given the access it needs; they help on a project and are added to its systems; they move to another team and gain that team's groups; they cover for a colleague on leave and inherit an administrator role for the duration; and at no point does anyone remove what the previous step granted, because removal has no deadline and no requester. After a few years the account can reach systems of every team it has passed through, and the picture an access control model paints of who may do what has quietly stopped being true. Service accounts creep the same way, with the difference that nobody is ever transferred away from them.

The standards describe the condition without using the slang. NIST's control catalogue, in the enhancement AC-6(7) Review of User Privileges, says that "the need for certain assigned user privileges may change over time to reflect changes in organizational mission and business functions, environments of operation, technologies, or threats", that "a periodic review of assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid", and that "if the need cannot be revalidated, organizations take appropriate corrective actions"; the control itself requires organisations to review assigned privileges at a defined frequency "to validate the need for such privileges" and to "reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs". The account management control AC-2 attacks the sources of the drift: it requires notification when accounts are no longer required, "when users are terminated or transferred" and "when system usage or need-to-know changes for an individual", and asks organisations to "align account management processes with personnel termination and transfer processes", which is the joiner-mover-leaver discipline in regulatory prose.

The vendors who sell the remedy describe the symptom in the same words. Microsoft's overview of access reviews in its identity governance product opens with the questions "As new employees join, how do you ensure they have the access they need to be productive?" and "As people move teams or leave the company, how do you make sure that their old access is removed?", and gives the two consequences: "Excessive access rights can lead to compromises" and "excessive access rights can also lead to audit findings as they indicate a lack of control over access". The product's answer is the one the control describes, recurring reviews, weekly to annual, in which the owners of a group, an application or a role are told to approve or deny each person's continued access, with denial removing it.

Why it matters is the blast radius. An attacker who compromises a crept account inherits years of accumulated reach, and the lateral movement that makes up most of a breach narrative is often not escalation at all but the ordinary use of permissions a person should have lost long ago. The insider case is the same account used by its owner, and the separation of duties entry explains why a single person who has accumulated both halves of a controlled process is a control failure even when no harm has happened. Auditors therefore treat accumulated access as evidence of absent control, which is the second consequence Microsoft names.

The cure is procedural, and the technical measures only make the procedure cheap. Roles rather than individual grants, so that a transfer is a change of role and the old role's permissions leave with it; exceptions granted with an expiry date rather than permanently; account management tied to the personnel record so that transfers and departures trigger removal automatically; reviews in which an owner must positively re-approve each entitlement or it lapses; and logging of privileged actions, which the catalogue's AC-6(9) requires, so that the privileges an account actually uses can be compared with the ones it holds. Least privilege is the principle, RBAC and ABAC are the models, and privilege creep is what happens to any of them without a schedule.

Also known as: access creep, permission creep, entitlement creep, privilege accumulation, authorization creep

Sources

← All glossary entries