Privilege creep is the slow and often unsupervised process of unnecessary privileges and rights be granted to users and identities. These accounts, with privileges greater than may be necessary and documented, pose a grave risk to the enterprise. Whereas the user himself may not utilize the privileges that he may have – an attacker who overtakes the account – certainly will.
What Risk Does Privilege Creep Pose?
User accounts should be kept to minimal rights and privileges. (NIST Control AC-6)
- AC-6(1) Least Privilege | Authorize Access to Security Functions
- AC-6(2) Least Privilege | Non-Privileged Access for NonSecurity Functions
- AC-6(3) Least Privilege | Network Access to Privilege Commands
- AC-6(4) Least Privilege | Separate Processing Domains
- AC-6(5) Least Privilege | Privileged Accounts
- AC-6(6) Least Privilege | Privilege Access By Non-Organizational Users
- AC-6(7) Least Privilege | Review of Users Privileges
- AC-6(8) Least Privilege | Privilege Levels for Code Execution
- AC-6(9) Least Privilege | Auditing Use of Privilege Functions
- AC-6(10) Least privilege | Prohibit Non-Privilege Users from Executing Privileged Functions
Once additional privileges are given identities, as NIST spells out, information security and privacy is difficult if not impossible to manage.
Privilege creep can not only be harmful to the security of your enterprise, it also can put your enterprise out of compliance. The concept of “least privilege” is written into most compliance standards including SOX, PCI DSS, HITRUST, SOC 2 Type 2 and ISO 27001.
In addition, account take-over is always a worry. User accounts are notoriously easy to overtake given weak passwords and easily compromised via social mechanisms – thus an over-privileged user account is a risk to the entire enterprise.
How does privilege creep occur and why is it so common?
Users and entities are always in flux on requirements for application, network and data access. Because of this, “quick fixes” and “spot changes” are common. These are done without the proper authorization and proper account review.
NIST PR.AC-1 calls out explicitly that account permissions should be reviewed upon new access requirements. NIST of course, nor does any other regulation spell out how this actually to be done. (Exercise left to the reader, of course.)
Not only are most access changes not immediately reviewed, the “temporary” changes are often permanent.
What Can Be Done to Stop Access Creep?
Triggers and Process – that’s what is needed.
Triggers
Triggers on the key groups, as denoted above by the NIST itemization of resources. Access control to these groups is usually done by groups in a directory of record, like AD or LDAP. Security groups are noted as the best practice to keep track of users and identities and their assigned privileges. (See Webinar: AD Best Practices for Audit)
Process
Once a change in these groups is enacted, either legitimately by a hacker – their should be an auto-attestation of the change by predetermined stake holders. People who should know and care about access being changed to this group.
These changes should be approved or revoked by these team members and their reasons noted at the time of attestation.
Privilege Creep can be address in the enterprise, with best security practices and with YouAttest – probably deployed and an active part in and enterprise’s identity governance.
–
YouAttest is the only cloud-based IGA platform that deploys in minutes via application SSO to platforms like Okta. Register for the October 28th Okta|YouAttest webinar on event triggers to learn how to stop identity problems like privilege creep.
