Can’t we just enjoy the moment? Change management in IAM

One of the first things that comes to mind when you mention the term “identity management” is a list of names kept in a directory. Another one is provisioning. When a new employee onboards, you have to give him some stuff, so he can do his job and earn his check. The natural progression of thought moves to de-provisioning, or taking away that same stuff when that employee leaves. So we have Day One, and Day N. But what’s often left unthunk of is Days 2 through N-1.

Sure, a lot of RFP’s include use cases for transfers, but even these leaves out half the details. It’s more complex than “lose your old stuff, gain your new stuff.”

• Do you lose your old stuff right away? Or do you keep it, or even just some of it, as you transition?
• Will your old boss need you to take calls and troubleshoot for another month while he trains your replacement?
• Do you have to be certified for your new duties? Do they have to verify that you turned in your key to the bathroom?
• Are there any possible Segregation of Duties violations to be dealt with, based on your new entitlements?
• What are the audit and reporting requirements to be accounted for, with the change?

The number of changes in an organization will always outnumber the volume of ins and outs. More people will change positions, locations, duties, and access than will be onboarded or terminated. If this level of change isn’t handled correctly, bad stuff happens. Like what?

• You’ll never pass an audit, because you can’t show a nice audit trail
• Your reporting will look like garbage for the same reason
• You won’t be able to readily tell who has what
• When you finally figure out who has what, you won’t be able to tell WHY
• You will have that bane of auditors and security guys, over-provisioned users. “Why does Uncle Ted have a million entitlements?” “Well, Billy, it’s like this. Whenever he gained new ones, they never took away the old ones. Now go get me a beer.”
• You break your user modeling procedures (if you use that for provisioning). Here’s what I mean by that. A lot of places use the tired enablement paradigm, “Make Bob like Tom.” We hired Bob, his duties will pretty much match Tom’s, so just give him whatever Tom has by way of access. But if Tom’s been around long enough, he has privileges you don’t even know about anymore. Thus Bob gets stuff he shouldn’t have.

So how do you fix this? Easy. First off, bake change into your policies. Transfers should have their own workflow definitions. If you’ve got a dynamic enough framework in place (and sure, here I’ll plug Oracle Identity Manager), you can say, “We’re moving Bob from Accounts Payable to Collections,” and all the proper changes and notifications will take place automatically. To account for all the possibilities, this could even be more than one workflow, one to kick him out, and one to put him in. You may even future date the stuff he loses, so that he can handle transitional duties while he’s being replaced. Or if the audit requirements are strict enough, he just plain loses his old stuff immediately.

What I just outlined, in simplified form, is the CORRECT way to handle this. However, you have safety nets you should employ. For example:

Reconciliation. This is an automated, scheduled process that periodically snakes around your user entitlements and compares them to policy. When it finds (not IF it finds) users with improper access, it can take that access away, notify the user and his manager, or both. If it’s an ugly one, like involving sensitive data, you might very well do both. In many cases, notification is the right thing to do, because simply taking something away may interrupt vital duties. In most cases, users with out of band access got that access for a very good reason, albeit an undocumented one.

Attestation. This has become a de rigeur compliance process. A resource is put on a schedule, and when it’s time comes, lists of all its users are routed to the appropriate managers for review. It might be the owner of that app (not likely) or the actual managers for those users (very likely). If you’re one of those managers, you get notified that you need to certify your users for a particular resource. When you enter the interface for this process, it gives you the option for each user to:

• Certify the user keeps access to the resource
• Deny the user that access, and when you hit the button, they lose it
• Delegate that user to another manager who should actually perform the job, because that user doesn’t really belong to you and ended up on your list by mistake
• Punt that user back to the process owner, because you have no idea who they are

Resources get scheduled based on their criticality. SOX-based resources should be done quarterly. Email? Maybe annually, if at all.

Oracle supports additional certification processes, including certifying entitlements contained within a role, through Oracle Identity Analytics (formerly Sun Role Manager).

But of course you start with the policies. If you’re catching a lot of unchanged changes, as it were, with reconciliation and attestation, then your policies are stinkers. You NEED to bake the change processes into your policies, your workflows, your business processes. The auditors will create very ugly reports on you when they find enough users with aged entitlements and roles, or admins with hundreds of thousands of entitlements.

And remember this little gem: termination is really just another change, except that you have those little extras, like loss of email, benefits, and access card. There are a few extra checkoffs, because of the finality. Some terminations are planned, and some are instant.

It would be nice to set things up and just sit on them. But if your organization is so static that it doesn’t have to sweat change management, you’re in the wrong place anyway.