My colleague Bob Bentley wrote a blog post suggesting that identity management systems are actually compliance management systems. I have a slightly different take on things and would argue instead that, in the ideal world, identity management systems should in fact be access governance systems.
It is true that over the last few years compliance has played an ever larger role in the decision to buy and implement identity management systems. However, IT directors and VPs understand the benefits of identity management from a purely operational standpoint because the automation they provide solves some very tactical problems.
Unfortunately, since these systems can be expensive, it’s hard to get the business support needed to fund them. So IT folks end up jumping on the compliance bandwagon because then they can show how “Auditors are going to like us better if we have this in place” and that frees up money.
In other words, businesses buy identity management for the strategic purpose of regulatory compliance, but their initial implementation focuses on more tactical purposes of business agility, efficiency, and cost reduction, with a secondary benefit of providing a sustainable compliance infrastructure.
Still, thinking about identity management in terms of compliance is a step in the right direction because we can’t think of identity in a silo. Identity matters in a much broader context and that’s why we should think of it in terms of access governance.
Access governance means that you are not only setting policies as to who should have access to what inside the enterprise - that is, assigning access based on identity and role - but that you are also monitoring and reporting on policy compliance and, more importantly, ensuring that things don’t happen outside of policy.
That last point is key. Up till now, the available tools have allowed you to automate certain processes like password reassignment or user provisioning, but they have not necessarily allowed you to automate policies.
For example, it’s quite often the case that access to certain systems are granted based on group membership. Now let’s say that someone wants to get into a certain app or database, even for legitimate reasons, but they aren’t part of the group and they don’t want to go through regular channels so they get their friend in IT to make them a member.
These guys aren’t necessarily trying to do a security breach, but that’s the net effect of their actions and, frankly, a traditional identity management system can’t stop what they did; it can’t force them to run the process.
That’s why you need to be able to monitor what’s happening in enterprise, detect in real time when something has happened out of policy (“Jerry is now a member of this group but based on his system credentials he shouldn’t be”), and do something about it (block Jerry’s privileges, alert the IT manager of the issue, etc.).
In other words, identity management needs to be integrated into a broader array of functions that not only allow you to automate compliance but also to enforce it. When that happens, you are not simply managing identity, but you are actively governing access.
I’m sure that you’ve got identity management covered in your organization, but are you really governing access from policy to oversight to enforcement?
Posted
Apr 12 2010, 11:09 AM
by
David Shephard