IT is really busy these days. In fact, IT’s been busy for as long as you can remember. Security issues today alone could keep you busy full-time, but there’s just not enough time in the day. Strategic initiatives and fires seem to take precedent daily, pushing some of the more necessary, but rudimentary, parts of your job continually down to the bottom of the list.
One of those is the simple act of managing permissions. With an on-premises Microsoft environment likely extending into the cloud, the permissions assigned provide access to systems, applications, resources, and data literally anywhere in the world. And, because IT is so busy tending to other important concerns, permissions assigned over the last number of years may provide more access than is necessary.
Should this be true (and we’re confident it is for most of you), your environment is in anything but a state of least privilege, putting the organization at risk of cyberattack with a relatively large threat surface.
But, is the state of permissions assigned in your environment really that bad?
The following issues plague nearly every environment leveraging Active Directory. See if these apply to your organization.
- Too Many Groups – Think about how long you’ve been at your current organization. Now think back to day 1; there were some groups then you had no idea whose purpose was unclear and so you did what most IT folks do—left them alone. Fast-forward to today and you probably still don’t know what those groups are, but no one is willing to do anything about it. And many organizations have added more groups over time without a) knowing if a group already exists to meet the need and b) not documenting the group and its purpose anywhere, thus, continuing the vicious cycle. The result is way too many groups that can be mis-purposed when assigning or managing Active Directory permissions, or groups repurposed with new permissions but still have the old permissions assigned.
- Too Many Members – When’s the last time a user called up and asked to have their access to a particular resource removed? Probably never, right? And, even if they did, would the help desk staff even know what group to remove them from? Probably not, as we’ve already established you have too many groups to begin with. The end result over time is bloated group memberships and no one in IT knowing who should and shouldn’t be members. This, by the way, is something cyberattackers count on, as they leverage group memberships to grant themselves access to additional systems or data.
- Too Many Assignments – Nobody likes not having a centralized permissions store of sorts to tell you all the permission assignments a given account has. And, unless you have some change control process in place with documenting permission assignments (and strictly adhere to populating it every time a change is made!), your current state of permissions is completely unknown to you.
The result of all this is something like, “You have an unknown set of permissions being given to a group that may or may not be the right one and whose membership isn’t verified as being correct,” but multiplied tens, hundreds, or even thousands of times over.
Sounds like being in pretty bad shape to me.
Still not convinced? Ask yourself the following questions to see if it’s likely your permissions are in bad shape. The more “No” answers equates to a higher potential for risk around your permissions.
- Do we have documentation on the purpose of every group in AD?
- Do we document changes made to group memberships?
- Do we document permissions assigned to groups?
- Do we ever remove members from groups?
- Does anyone own the process of reviewing user provisioning best practices on some kind of periodic basis?
I’m guessing there are quite a few “No” answers when thinking about your environment. It’s probably time to make one of those critical strategic initiatives be “let’s get our permissions straight.”
For more detail on the specific steps you can take to correct your mismanaged state of permissions, read the whitepaper, Mismanaged Rights: A Cyberattacker’s Greatest Ally.