If I was to ask you who are the members of a given group with permissions to some sensitive application or data set (one other than, say, Domain Admins), you probably don’t know the answer to that. It’s a bit of an unfair question, as none of us strive to memorize the membership of any group. So, let’s make it a bit fairer a challenge. Go look at the membership of a group that fits my description above and scroll through the list. Go ahead… take you time.
Now, how many of those group members should be there?
It’s more than likely that you may be able to ascertain whether a few of the members are correctly tied to a group, but not all of them. So, in the end, the security of the data that group provides access to is in question, right?
And that’s a huge problem. Are the members even current employees? How about any groups as members? If there are any, the issue becomes recursive in nature, as you need to look at each group (and any nested within those) and ask the very same initial question I raised.
In this second blog in a four-part series, we’re taking a look at each of the major tenets of the AD Group Management Lifecycle. In today’s blog, we’re centering in on the need to certify group memberships.
The problems above with little more than a few unknown members in a group demonstrates the inattentive state that most groups are in today – one of disorganization and insecurity.
What’s needed is a mandate that group members be certified by a group owner on an on-going basis. This is accomplished by putting a few things in place:
- The group needs a membership owner – you can start with the Managed By field in AD, but we’re talking about actually selecting someone in the organization and telling them “it is now your responsibility to know the membership of this group intimately.” Your best served by having the owner not be you (the lack of attention you’ve paid to groups in the past clearly demonstrates – if we’re being honest with ourselves – that you have little time or desire to manage groups). So, who should be the owner? Ideally, it should be someone close to the groups purpose – a department head, line of business owner, an application owner; someone who understands the daily personnel changes that will impact the group’s membership.
- Require the owner’s approval – Either put a manual (but enforced) process or a third-party solution in place that puts the Owner smack dab in the middle of any changes to group membership. While the intent is for the owner to approve both additions and deletions, we all know no one ever deletes users from a group. Which brings us to the next part of the plan.
- Require periodic certification of the group’s members – because none of us wakes up thinking “Gee, I hope I get to delete some users from groups today!” there needs to be an official process that IT mandates each group owner go through at a minimum quarterly, if not monthly. This process should involve the group owner certifying to IT that the right users are, indeed, members of the group.
Remember, these steps need to be done for each and every group – and not just the really important ones; all of them. Otherwise, you can have users left in a purportedly low-level group that may be added as a member of a group with privileged access. Top-to-bottom, your groups need an owner.
By implementing these steps as part of your AD Group Management Lifecycle, you ensure that throughout a group’s existence, only those users that should be members (and therefore, enjoy in the privileges granted the group) are as such. It’s also a key step in ensuring a state of least privilege.
In my next blog, we’ll take a look at certifying group permissions – and why they’re so completely out of control.