Earl PerkinsIt has been too long since we last wrote to you. During that time, we at Gartner have been discussing the trends and futures worth writing about in our respective research areas. One of the notable discussions has been around the concept we call identity and access management (IAM) intelligence– too many words, so let’s just call it IAM intelligence. So what is IAM intelligence and why should we even care about it?
We believe IAM intelligence represents the ability of IAM tools and process to (a) build effective repositories of identity information for IAM systems to use, (b) collect and correlate information about the IAM events that occur throughout the system with other important security events and information, (c) provide a means to monitor, analyze and report on what is happening within the IAM world for a number of constituents. There are perhaps other functions that could be defined under IAM intelligence, but I think you get the essence of what we believe.
Ok, that sounds pretty good, but so what? User provisioning and web access management tools have usage logs and audit reporting functionality– why do we have to have yet another collection of research papers on a group of capabilities and processes that already exist? Is it just another ploy to make the ”old look new” so you can see more research? Or is there relevance to this? Actually, there are good reasons for calling this group of capabilities out.
(1) Both we at Gartner, our colleagues at Burton, and other analyst firms have noted the maturing of IAM– its gradual acceptance in more and more enterprises as something structured, somthing that needs to be done and done well. As this maturity continues, the links between IAM and other disciplines within IT become better defined and richer– such as those in areas like security information and event management (SIEM), or governance, risk, and compliance management (GRCM). The links include exchanges of information– from historical logs of events and information (about security and IAM) to process activities. Gradually, more and more is known about the inner workings of IAM and the effect it truly has on access in the enterprise;
(2) Customer requirements are particularly acute for IAM in the regulatory and policy compliance areas. There are people to report to about who has access to what resources, when and where they had access, the nature of the access, the integrity of privacy for different types of information– all of this requires a level of transparency that good intelligence can provide. While these functions may be embedded in existing products, it is no less important that we have a plan to get that information, analyze and normalize it, and use it for a lot of different reasons;
(3) You can’t manage effectively what you can’t measure. Having insight into what’s happening in IAM systems allows those systems to be tuned, to work better, to be modified if they aren’t and to be optimized when they are. Processes ranging from account maintenance to access control benefit from the means to monitor and analyze those mechanisms that make those processes possible, particularly if they’re going to be automated in some fashion.
There are other reasons, but I hope I’ve made my point: IAM intelligence can make a difference in IAM lifecycles. Understanding how it works and what’s possible with it are tasks any IT organization should not ignore. Have a formal, inclusive planning approach to IAM intelligence when planning, building, and operating enterprise IAM– you won’t regret it.
Category: Uncategorized Tags: access governance, GRC, IAM analytics, IAM audit, IAM audit reporting, identity analytics, identity governance, identity intelligence, SIEM
1 response so far ↓
1 Frank Villavicencio February 12, 2010 at 12:05 pm
Good points Earl. I would say that this trend is being validated by what we have seen with our clients too.
I would also PACS integrated requirements to your point 2 above. Industry vertical regulations, such as NERC CIP and FERC in energy, are bringing forth the need to demonstrate consistent physical and logical access control, and these are now requirements for IAM integration with PACS systems.
To your point 3 above, I would emphasize that metrics are not just technical or instrumentation ones, businesses are looking to measure costs and ROI — how long it takes to complete a particular workflow could have direct financial implications, how often are you not meeting your desired SLAs. This demands a greater degree of sophistication on the IAM solution, and how it is being operated (note that this combines both technology and procedures)