Cleaning up identity management and access certification

Very often the focus, or driver, of an identity and access management (IAM) solution is to get employees the access that they require quickly, accurately, and without having to make multiple separate requests. That's a great idea, and what I spend a lot of time working on. However, just as important would be removing access from employees who have been transferred or left the company. Unfortunately, this gets less attention.

A major component of a sound IAM program is an access certification piece. This is where managers, designated approvers, or oversight groups review employee access. Typically, this type of review should happen at least annually. During the access certification, the person responsible for approving the employee's access should also be able to remove access where it is no longer appropriate or necessary. That sounds easy enough. However, it’s not so easy if the certification tool doesn’t present clear and understandable data about the user’s access. People working outside of the information technology department -- the majority of most companies -- don't understand the components presented. Active Directory group names can be cryptic, web portal application group names can be misleading, and mainframe transaction codes are meaningless to almost everyone, yet those are the types of entitlements that could define employee access.

Ideally, you'll address this issue during your initial implementation. You'll provide clear, business friendly descriptions to go along with the specific access entitlements. If you've already got an IAM program running in your company, it's not too late. You just need to get back into your data and clean it up! Most likely, you'll need to enlist the help of the application and system owners to provide those descriptions. The good news is that it shouldn't be too difficult on their end, since they're the ones responsible for making sure the entitlements do what they're supposed to be doing, and they're probably the people who set those entitlements up in the first place.

You might question what the point of all of this is. Why jump through hoops for something that is working fine, as far as you can tell? Well, the "as far as you can tell" part is why. Access certification is only as valid and efficient as the approvers/managers performing the certifications. What happens when that manager doesn't understand what they're certifying because, to them, all of the access information might as well be written in Klingon? Rubber stamps happen, lots of them. Those approvers, who don't understand, take the easy way out of a task that they most likely view as a nuisance, anyway. The approver just clicks "certify" or "approve" and they're done. The annoying reminder emails stop coming and they don't have to think about access certification again until next year. The other scenario is that they don't even perform the certification, continue to ignore all of the reminder notifications, and hope that the compliance team doesn't come after them. Either way, the access certification process that you have built is entirely fruitless, at that point.

I'm not saying that once you improve the descriptions in your access reports for access certification that every single approver is going to honestly review each employee they're responsible for, there will always be some rubber stamps out there. The majority of approvers should find it interesting to see what access people have, once they can understand it. They'll also be more likely to clean up the access that the employee, who has transferred around the company for the past 20 years, has collected along the way. Clean up your access entitlement data with business friendly descriptions and you'll also be cleaning up your company's stale, or inappropriate, user access, as well!