Identity Management Success

This post deals with a very real issue in the Identity and Access Management (IAM) space. For that matter, it is a topic that permeates all facets of IT. The term is……”best practices.” Depending on your organization, best practices may or may not be closely aligned with operational business goals and process. Can a company achieve best practices at all times and in all ways? Is there a practical trade-off between optimal best practices and the needs of business?

Consider the following:

• Governmental agencies publish many lists of “standards” and “best practices,” many of which they themselves do not follow. Fiscal responsibility, accountability, and data privacy are three that come to mind.
• Legislators like to legislate best practices, audit and accountability standards, while having no idea what form the legislation will ultimately take, or how the new laws and practices will affect national and international business
• Internally, organizations propose or create policies to be bandied about the discussion table but never truly implemented. Organizations feel they should adhere to policies and practices, or are told by their auditors that they should, so countless hours and meetings are expended to determine what practices can be followed.
• Most companies measure their compliance or adherence to “best practice” as a percentage, rather than an absolute
• Many organizations would rather accept the ongoing risks and costs of following their current models, rather than fundamentally change business operation
• Vendors position best practices as a selling point. They may say, “buy this suite/tool/package” and it will help your organization realize efficiency/reduced cost/adherence to best practices, etc.

None of this is intended to be overly critical of either best practices or business organizations — each have their role. The point is that like any other set of guidelines, guidelines are just that: guidelines. Many perhaps should be followed, and in so following, many organizations can realize tremendous efficiencies, cost savings and market credibility. However, mileage will vary widely by organization. Best practices are often in the purview of consulting agencies, vendors, and legislators. The real business world is quite different, and often a foreboding place for practices that did not organically grow in direct response to business needs.

Links Business Group, LLC has always maintained the position that one way to view Identity and Access Management tools is as a set of best practices implemented as software. IAM Programs are at their heart business process management (BPM) exercises. Modern IAM tools and technologies allow for a great realization of efficiency and business value when properly implemented; but it is a crucial success factor to understand up front how and why an organization may choose to implement IAM. Some of the more challenging areas of IAM Best Practice within an organization are:

• Password policies (Changing from weaker to stronger policies, for example, or implementing strong authentication)
• Automating application provisioning (moving from manual, silo-based practices that are people-intensive)
• Maintaining tracking of individuals and their transactions within the business
• Auditing and reporting (who, what, when, how, why)
• Which groups/departments will “own” the IAM components
• Which groups/departments will “own” the data (separation of data ownership, data protection policy, security policy, data access, etc. are key to successful end-to-end IAM deployments)
• What Service Level Agreements (SLA) must be created to accommodate new Identity Services
• Moving from centralized models of administration to delegated models (Separation of Duties)
• Defining business process in written and model form, where none currently exists
• Achieving per-resource, method, object security within applications (versus all-or-nothing access credentials to whole applications)

The preceding list is by no means exhaustive, but does cover a few salient points in regard to IAM pre-program planning. If your organization is firmly established with practices that….shall we say….do not closely align with standards and best practices, then consider:

• Starting small. Consider moving weak passwords gradually to 6 characters that change every 90 days, or really long passwords that are not complex (using mixed characters,) but are strings of data large enough to be less easily cracked. Work up from there.
• Focus on application and source-of-ID integration first. Synchronize and clean up the data, before trying to internally sell new centralized provisioning tools to administrative users.
• Focus on one, or no more than two applications that can be integrated in an end-to-end manner. Find applications that are newer, or are on the drawing board. Enlist application architects and developers that are excited about the new Identity Infrastructure. Let these applications “pilot” the new IAM infrastructure and build internal interest from there.
• Take the time to thoroughly design and test your LDAP-based Identity Repository. (Often known as the “Book of Record” or “Central Repository.”) This point is so important that it is bolded and italicized for emphasis. Data cleanup, and normalization should be a key part of your IAM Program. There are great tools such as Virtual Directories which facilitate this exercise, and allow for tactical gains while building long term strategic infrastructure. If done correctly, and the project is properly focused up front, you can build a tremendously valuable business asset.
• Provide audit reports early, to validate the new infrastructure. Managers and auditors need reports. Their livelihood and that of the business, often depend on timely and accurate entitlement reviews, security reviews, and data ownership verification.
• Require strong(er) authentication for managers and administrators. Far and away, one of the most challenging areas for a business to grapple with, is a strengthening of security policy. IAM Programs introduce a great opportunity, in that they inherently provide more security information, from a greater number of sources — including centralized password management. With increased options and flexibility comes great responsibility. Managers receiving reports from the IAM System or IdMS will be viewing potentially sensitive data on the comings and goings of employees. Administrators of the IdMS will have significantly greater control of assets and security information. Use the increased functionality and sensitive information provided by the IdMS as a vehicle to introduce security controls and compliance.
• Do not split your program focus by worrying about trendy topics such as virtualization, SOA, and Federation. These can follow later once your Identity Infrastructure is firmly established.

I will end this post with the following: never consider an IAM Program solely for the purposes of achieving “best practices” or regulatory compliance. Never consider an IAM Program as a knee-jerk reaction to a negative audit report or proposed regulation. Consider IAM because it makes sense for your business, and aligns with your strategic goals. Consider IAM because it can improve your bottom line, reduce cost, reduce application time to market, provide greater integration and synergies with partners and suppliers, increased manageability, and provide a vehicle for achieving efficiencies of scale. Another great, but often overlooked point of consideration is Identity Integration between recently acquired companies, or as the result of M&A activity. (But…this is a topic for a future post.)

Looking for more information on bridging the delta between best practices and business reality? Contact us today to schedule a consultation.

Until next time, all the best of Identity Management Success.
Corbin H. Links, President Links Business Group, LLC

©2003-2007, Links Business Group, LLC. All rights reserved.

Clients often ask us “do we need to spend the money on IAM vendor Project Management services when we already have our own?”

This is a great question, and a crucial component of IAM Program Planning.The short answer is: there is no one-size-fits-all-answer. To put the question in context, let us suppose for a moment that your organization is highly “projectized” or “matrixed.” The organization has a strong centralized PMO (Project Management Office), or perhaps PMO’s organized along line of business (LOB) or departmental lines. Or, your organization may be the exact opposite: little or no centralization, distributed project management, a lot of ad hoc resources. In either case, the important thing to know is that the right decision is not solely a matter of # of project resources, or even internal expertise. Nor is the decision absolute. In some cases for example, it may make sense to engage the IAM vendor’s project resources during certain phases of the IAM Program, and disengage in other cases.

To assist in the decision process, Links Business Group, LLC offers the following guidelines.

Engaging the vendor’s project manager may be beneficial or necessitated in the following cases:

• Internal project managers are overallocated to current projects
• Your organization has no existing enterprise-scale IAM expertise
• The vendor is adding 3 or more engineers/architects/developers to the IAM deployment
• Vendor engineers will not be tightly embedded with internal staff
• Vendor has complex time and reporting requirements
• Terms of vendor SLA
• When multiple vendors are engaged in complex deployment scenarios, with each owning a piece of the program
• When technically complex deliverables are required with very tight timelines
• When multiple concurrent deliverables are required by multiple vendor and internal teams
• Internal project plan validation
• Maintaining program continuity during internal resource shuffles or key resource losses

Vendor project managers may be redundant or less critical in the following cases:

• Ongoing maintenance
• Portions of the program that are solely internal, such as planning, determining compliance or regional requirements
• When two or less vendor engineers are deployed
• When internal project plans are tightly scoped, vetted, and agreed with vendor technical staff
• When vendor PM overhead is cost prohibitive
• When there are significant difference in project tools and document formats
• When significant internal Identity and Access Management (IAM) technical and PM expertise exists and is available

When in doubt, it is best to err on the side of safety, especially when an IAM infrastructure investment is substantial. Should you decide to test the waters with vendor PM resources, follow this checklist:

• Insist on an iron-clad Scope of Work (SOW) document
• Establish clear PM beginning, ending, and review dates prior to implementation
• Require firm delineation of what the vendor PM would do, relative to the vendor’s engagement/service manager

NOTE: May vendor PM functions may already be performed by the engagement manager.

Have more questions? We can help. Call us today at 877-769-8938, or send email to request a complimentary half hour consultation.Until next time, all the best, of Identity Management Success.

Corbin H. Links, President
Links Business Group, LLC