Effective Strategies to Stop Privilege Creep for Employee Accounts

Effective Strategies to Stop Privilege Creep for Employee Accounts

0 Flares 0 Flares ×

The vast majority of us have worked in organizations where employee churn, unaccounted for privileges, bloated access rights etc. have been a very real thing that IT and Ops has to deal with. In the case of employees being added to a fast moving Silicon Valley based Unicorn or a slower moving, but massive Fortune 500 enterprise, privilege creep is a very real issue. In this article we will discuss what is privilege creep, why it manifests itself and how to beat back the creeping monster. The Onion ID team is at AWS:Reinvent 2016 and Gartner IAM 2016 Summit – Please feel free to schedule a time to talk with us.

What is Privilege Creep

Simply put, privilege creep is defined as the increase in unnecessary and un-audited rights to SaaS applications and infrastructure. Sounds simple right? But wait, there is way more under the hood. Privilege creep is actually a pretty slippery issue to nail down. Why so? Here is some rationale:

  • Privileges are granted to various apps and infrastructure by multiple people
  • Privileges grants are not always tracked in a single location
  • It is hard to audit Privilege grants, most apps and servers do not provide easy fine grained reporting capabilities
  • Privilege creep happens over a period of time, as group association changes, this moving timeline complicates the auditing process
  • Privilege management is not tightly tied to employee off boarding

Why does Privilege Creep happen

To understand why privilege creep happens we need to understand what is privilege and how is it requested and how is it granted. Privilege is defined as targeted authorization to perform certain tasks on a SaaS app or infrastructure. As an example: employee 1 can login to Bill.com and generate an invoice, but cannot modify the date of payment for the invoice. Another example: employee 2 can get access to production cluster servers and can run gcc and gdb but not cat /etc/password.

Privilege is usually requested in two ways: Using some kind of ticket tracking system, Jira, even Zendesk or a tool thats built to record events and requests with an email chain for audit ability. The second day is more ad hoc – going directly to Active Directory, LDAP and making the changes from the domain controller box without necessarily logging the request. Both of these are not optimal, there is scope for improvement on both fronts – more so for the latter.

Privilege is usually granted by selected group of IT teams, security teams, GRC teams and more. There is hardly ever the case where there is one central authority that is in charge of delegating access. When granting access rights and privileges your team might provide access rights by changing the role of the employee, changing the group membership, changing other parameters and if you do use a sophisticated system – provide time limits for privilege expiration.

Privilege Creep happens because of a couple of simple reasons:

  • No single group is centrally managing all privileges, which leads to fragmented privilege rights. This means that no one team has a list of all privileges for an employee.
  • Employee churn and Off Boarding processes don’t always clean out all privileges

Ways to control Privilege Creep

Privilege creep can be controlled using some simple workflows. You will need to invest a bit of time and effort in streamlining the way privileges are granted, logged, audited and cleaned. The good news is that you can do that with existing open source tools and in case you would like to purchase a commercial solution, that is also a good option.

  • Use tools like script runner for Jira and similar ticketing systems to tie in email requests for access to automated provisioning, modifications on AD.
  • Use your SIEM to ingest syslog events as access is granted and used. This helps close the loop for a complete audit of a request-grant-access workflow.
  • Use alerting tools like Pagerduty, twilio to make sure IT admins get updates when high risk Jira tickets for access get created.
  • Use a daily cron job or service that analyzes user accounts on AD, what apps they have access to and devices, and present a list of changes from (1) last day (2) last week (3) last month.
  • Use a cron job to parse the logs from the SIEM to SOX applications to identify who has access rights but is not using the access for the last 30/60/90 days.
  • Use automation tools to alert and identify when someone is deleted from AD (Off boarding) to check apps that they had access to and servers they had access to are actually sanitized.

Final thoughts

In this article we’ve talked about privilege creep, what is it, how it can spread through an organization and how to stop it. It is definitely not going to be a 2 day process to stop privilege creep, in reality things like this which increase the security posture of an organization significantly need a lot of thought and planning before hand. The silver lining is the benefits of investing in stopping privilege creep are enormous: Radically lower risk surface, time savings for IT and DevOps, easier and faster time to compliance and more.

We’d love to meet you and chat – The Onion ID team is at AWS:Reinvent 2016 and Gartner IAM 2016 Summit – Please feel free to schedule a time to talk with us!

(Visited 1,827 times, 1 visits today)

Also published on Medium.

Share this post

0 Flares Twitter 0 Facebook 0 Google+ 0 Reddit 0 LinkedIn 0 Buffer 0 0 Flares ×