One of the greatest faults in the architecture of AD is the complete lack of documenting when someone assigns permissions to it. You know what I’m talking about – you’re in SharePoint, or on a file server and you add some permissions to a resource. You grab a list of users and groups from AD, select the group desired and BAM! Just like that, you’ve assigned permissions… permissions that no one else in your entire organization knows even exist.
In a perfect security-focused world, AD would have some mechanism where anytime someone assigns permissions, a parameter (which I’ll call AssignedPermissions) is updated to include details on the security assigned.
So, as in my last blog, let’s put your security expertise to the test. Pick a group in AD at random and tell me… what are all the permissions assigned to that group? The answer is, of course, you have no idea. And, truthfully, without auditing the permissions assigned in every file, folder, application, databased, service, security platform, and more, no one can refute your answer if you were to say “oh, this group only has permissions to <insert answer here>”
In this third blog in a four-part series on each of the major tenets of the AD Group Management Lifecycle, we’re focusing on the need for IT organizations to certify permissions assigned to groups.
Unlike the challenge of managing group memberships, which is more an issue of IT being inattentive to keeping them updated, keeping permissions straight is a greater problem. With most IT organizations not documenting changes made to security, it’s nearly impossible to know your current state of security.
And this puts your organization clearly in a state of insecurity.
What needed is a new model of management where IT is accountable for its actions, ensuring all assignments of permissions are both sanctioned and documented. There are a few steps to accomplish this.
- Assign a permissions owner – I spoke about this also being needed when certifying group membership. But, when it comes to permissions, it may be necessary to assign a separate Here’s why: someone being responsible for group members can be just about anyone outside of IT – after all, it’s just a list of users that align to people. Nothing technical about that. But, when it comes to permissions, I don’t think any of us are that confident that a non-IT person can fully understand the ramifications of permission assignments, particularly if they get more granular than something like “Full Control.” So, this owner may be either an application owner, or someone in IT.
- Change the process of how permissions are assigned – Because permissions are usually granted by an IT pro closest to the application or resource in question, if they don’t report those assignments to the group owner, no ability exists for the owner to know what permissions have been granted. So, the challenge here is to get all of IT to understand that, before they grant a single permissions to a group, they must first inform the group owner of the impending assignment and get permissions to do so from the owner. That’s a tall order, but here’s why. In many IT organizations the original purpose of a group is forgotten and, based on membership alone, groups can get repurposed. That creates a permissions scope creep, where that group now has “old” and “new” permissions – and anyone newly added to the repurposed group has access to the “old” resources. That’s bad. With the ownership model in place, the reason for IT checking with the group owner is to ensure the purpose of the group remains as assumed by IT. This way IT grants permissions to the correct
- Require periodic certification of the group’s permissions – Equally tough (as the possibility exists that IT has gone rogue and assigned permissions to put out a fire, etc.), the intent is to have the owner go through the (reported) permissions assigned, and certify they are still needed for the members of the group to do their job. This should be done at least quarterly, if not monthly.
As with the certifying of AD group memberships, this needs to be done for every group in AD. This ensures the intended security IT puts in place is actually the current security in place throughout a group’s existence.
In the last blog in this four-part series, I’ll take a look at the need for attestation – and how it plays a role in both creating and deleting groups.
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.