This morning, Dave Kearns of KuppingerCole revived an old conversation started by my friend Matt Pollicove of CTI back in 2006 about the potential need for an Identity Officer. I had some comments then, but I wanted to add another thought now that I'm older and a little wiser.
One of the things I've noticed over recent years is that big, brand name companies who are well-respected for their primary business and their ability to execute on internal IT projects have many little "messes" related to technology that nobody talks about. A mess could be a mistake (bad purchase, wrong implementer) or it could be something that started out OK and grew into a mess over time. One of the common messes out there is related to interconnectivity of various IAM solutions.
It looks like this: One group within the company bought Oracle or IBM for user account management and built a complex infrastructure around it that they're afraid to touch. Another bought SailPoint or Aveksa - maybe both - and incorporated 40% of the intended applications then the project stalled out. A third group is using Ping for Federation with partners while a fourth runs Microsoft FIM and ADFS to support other partners.
I recently spoke to the "Lead Architect for IAM" at one of the world's top banks. With a title like that, I figured he'd be in the middle of orchestrating the various interdependencies between IAM systems. When I mentioned an IAM brand name that I knew they had deployed, he said something like, "oh no, that's a different group". He knew it existed but didn't know much more about it.
In the above scenario, one obvious consideration is that there's time and money spent purchasing and implementing these technologies which have overlapping functionality. It's wasteful and inefficient. But there's a bigger problem with that scenario than cost and maintenance.
When the business wants to enable some new venture (new partnership, new regulation, M&A, etc.) it's extremely difficult to adapt to new requirements because of all the little messes that would need to be cleaned up. And which group should lead the effort? The access certification system is the newest and its owners have some political pull. But the provisioning system is larger, more established, and now supports the desired certification scenarios. Each of the four or five IAM systems has valuable data. How do you bring it all together to meet the immediate need?
I probably don't need to spell out where an Identity Officer could have made a positive impact in the above scenario. Reduced cost, reduced overhead, greater flexibility, speed to implement. I think Dave is on to something by reviving this topic. As a doctor of IAM, he's taking a holistic look at the identity needs of organizations. It's not just about technology or workflows. It's also about understanding executive ownership and aligning IAM with business needs. Organizational structure is a big part of that conversation.
2 comments:
BTW, an Identity Officer could improve security as well. Because identity data is so sensitive, the number of identity data stores should be as few as possible. Data should be redacted when appropriate and only exposed as-needed. Non-production systems should only use masked data. And identity data stores should be protected with encryption, internal access controls, etc. Encryption solutions typically have a master key that needs to be owned by someone. The Identity Officer role could own the keys and manage policies that restrict access to identity data even to the teams that build and manage the IAM systems.
Matt,
Good points, and not just because you referenced me! :)
Between Access Management, Security, User Provisioning, Compliance, Certification, Federation and all of the other issues in today's IDM/IAM space, the Identity Officer makes more sense than ever. Adding in new standards and SSO methodologies that will only blur the line between one's personal, business and other forms of identity will only make this more complicated.
Post a Comment