I find myself being asked this question, indirectly or directly, by clients and prospective clients alike. With all the demands on IT infrastructure spending and business application development (and integration), and with all the information security risks out there waiting for solutions to be implemented, why should an investment in IAM be a priority?
From the well-respected Kuppinger Cole blog comes this view:
Part of IAM’s job is protecting data, either directly or by protecting the systems that use and store data. That is also the backdrop against which compliance regulation, both internal and external, must be viewed. That also means that it is much easier to talk with business people about “access” rather than about “identity”. The big question is how do we control and monitor access to information and systems? To do that, we need to know who is allowed to do what – and who isn’t. The only way to achieve that goal is through true digital Identity Management. Anyone who thinks he can do it by granting rights and approvals based on IP addresses or MAC numbers is seriously kidding himself.
It strikes me as odd that there are still IT and information security professionals that believe IP and MAC access controls are sufficient, but it appears that this myth persists in enterprises.
Worse, I believe, is the view that the home-spun access control that has been built into legacy applications is ‘good enough’. Why replumb our existing enterprise and customer-facing systems with a new-fangled IAM solution when we have the problem solved already?
This is a powerful myth that can be hard to overcome. But compared to application-specific controls, IAM has some significant advantages:
Compliance — Organizations today must comply with legislation and their own policies. The access control sub-systems built-in to many legacy applications are simply not compliant, and it may require significant rework and duplicated processes to remedy. Conversely, an enterprise IAM solution can be implemented to be compliant from the start, and a single set of processes can be created to maintain identity and access information.
Example: Privacy Impact Assessments (required in Canada for all projects that deal with personal information) can be done once and shared across all applications.
Audit Support — ‘Siloed’ access control systems are very difficult to report on at audit time. With IAM, consolidating information is much easier and correlating a user’s access through multiple systems can be achieved.
Example: A single reporting tool or sub-system can meet most (if not all) auditor reporting needs.
Help Desk Efficiency — With IAM, a single console for Help Desk agents can be implemented for end-user support purposes. Naturally, a single system will offer improved efficiency and better service to end-users than multiple, application-based systems.
Example: Help Desk lookup tools can be standardized and easily learned by new staff. Password policies become consistent. Access to multiple systems can be suspended or revoked from a central point. Service to end-users improves.
Leverage and Speed — New applications, especially e-business and e-government systems that have to deal with privacy and security issues, can be readily designed around a common IAM solution. Deployments can be rapid due to standardized interfaces and re-use of common templates. Processes can be leveraged, not rewritten from scratch, making the transition to a production environment more seamless.
Example: Strategic applications that need to be implemented ‘right now’ can be rolled-out quickly with high security, advanced features and appropriate user privacy protection. Decisions can be made with confidence that the common IAM solution will meet both enterprise and line-of-business requirements.
Real IAM solutions offer real value, making business case development easier and more compelling. However, widely-held myths about the effectiveness of network and application-specific controls need to be dealt with if broader IAM implementations are to be approved, funded and supported.
In 2006, after three years of working with an inflexible vendor to implement immature identity and access management technology, my client asked me to document some lessons learned from the projects. I’ve done a couple of talks with these findings over the past few years and these lessons have influenced my approach to IAM project delivery ever since.
In the past few months, I’ve come across blog posts related to identity management best practices and lessons learned, such as this one from Mark Dixon. These observations mirrored my own in some ways, and differed in others, so I thought I’d put together a top 10 list things I’ve learned, including some useful advice on identity.
The only problem is that in preparing the list I cruised past 10, then 20 — and before long I had itemized 72 things that I’ve learned about IAM since I entered this niche seven years ago.
In keeping with the fashion of today, each entry will be 140 characters or less…
IAM is a tool for business; it has little to do with technology.
Business people are frequently shielded from making IAM decisions. It is not clear why this is so.
Develop an IAM strategy in 2010.
If you aren’t ready for a strategy, consider an IAM assessment so you at least know where you are at.