Implementation Problems and Pitfalls

Let us be very clear: any program related to identity and access management belongs under the ownership of the information security department—not the IT engineers, not the IT architects, not HR, not the directory services team. User management is inherently a security function and must therefore be driven by the security strategy. However, an identity and access management solution truly touches every system and every user in the enterprise. Therefore, collaboration and participation will be required from most or all other IT teams, HR, and most or all business units.
It will therefore be crucial to obtain buy-in and representation from a very large audience. In particular, participation is needed from other departments to get a clear and detailed understanding of how user management works today, to help you determine what needs to happen to streamline it. You also need to ensure that you select a solution that will effectively interoperate with the rest of your infrastructure because the technology components of a user management system will be embedded so deeply into your company's architecture.
The following subsections discuss some considerations and problems in implementing a user management solution.

Multiple-User Stores
Many companies, whether through the process of acquisition or as a result of being decentralized regionally, have more than one HR system. Even worse, a lot of companies do not have a centralized repository (or any repository, really) for keeping track of nonemployees such as temps and contractors. As a result, it is very difficult to determine accurately what has happened to a user. For example, most companies with two or more HR systems handle users that transfer between systems as a termination in the old system and a new hire in the new system. From an access perspective, that user should not be terminated, although his or her privileges may need to change. Therefore, if you rely on reports from your HR systems to inform you about who has left the company, and you are unable to correlate a termination in one system with a new hire in another, you may inappropriately terminate a valid user. Conversely, if you have no accurate way of tracking the comings and goings of your nonemployee users, you could be left with active IDs that have not had valid owners for a very long time.
Even if you do have several accurate stores, correlation could still be a challenge and will always leave room for error in an area where error is not well tolerated. Although it is outside the scope of an identity and access management program per se, it is strongly recommended that, as part of this effort, you consider consolidating your user stores into (ideally) one, or at most two (one for employees, one for nonemployees). This will ensure the most accurate view of information and will also make it easier to synchronize that information with other relevant sources, such as your directory and your provisioning tool. If you need to maintain users manually for a while longer, it will save your team a lot of time and effort in trying to correlate information and research the exact status of users so they can go about the job of simply keeping accounts clean.
Clearly, the effort to consolidate HR databases or create nonemployee repositories is a significant undertaking that must have the buy-in of the HR department and executive management. Information security can add value to this initiative by raising it as a requirement. Many HR organizations would like to undertake projects of this nature, but have not had sufficient reason to justify the budget and resources required. By throwing the information security hat into the ring and demonstrating how database consolidation and nonemployee tracking can reduce the costs of implementing an identity and access management system—as well as make the company more compliant for audit purposes—you may be able to help HR tip the scales in its favor and get funding approved.

Inadequate User Information
Whether your HR stores are consolidated or distributed, you may also have the additional problem of inadequate or inaccurate user information. Inadequate information really stems from the use of an HR system versus the needs of a user management program. From an HR perspective, it is sufficient to know a person's grade, job title, department, and manager to train and pay him or her. From a user management perspective, that manager could lead several functions and, even though the people under him or her have the same HR title, they may actually require different system permissions. Also, HR systems typically do not store user IDs because HR uses other identifiers such as employee number or Social Security number. This can cause problems for users with common names if there is a disconnect between their HR records and their user IDs.
For example, suppose a user is registered in the HR database as Thomas Smith, but his ID is created as tom.smith because he commonly goes by Tom. There is also a Tom Smith registered in the HR database. How do you determine to whom the ID tom.smith belongs? If you do not even have synchrony of user IDs across systems, the problem becomes even more dire. A company once had three users with last name Nguyen, and first initial H. The company's user ID format was first initial plus last name. A digit was appended at the end to avoid duplicates. The three users had IDs of hnguyen, hnguyen1, and hnguyen2. However, their IDs were not synchronized across systems, so they were each hnguyen in some places, hnguyen1 in other places, and hnguyen2 in still other places. It was impossible to distinguish who owned which ID on any given system without physically contacting the users and asking (and hoping they remembered accurately). To make matters worse, in the HR system, they all showed as being part of the same department (IT).
The conclusion that most companies reach is that the full user store must reside in the directory. The directory must be carefully architected to pull various bits of information from the appropriate system of record and be updated frequently enough to keep it accurate, while not bringing down the network or other systems. The directory should also have the authority to populate other systems with information from the system of record. For example, there are a variety of reasons why you might want to have the HR database store a user's ID. The directory could receive this information from the authoritative source (in this case, the user provisioning tool) and pass it on to the HR database. However, the directory would need to be configured never to populate user IDs from HR back into the user provisioning tool. Similarly, relevant user information from HR would be propagated to the user provisioning tool, to assist the tool in determining the appropriate role to assign or rules to apply.
The directory might be the authoritative source for still more information. Users may use the directory as an input mechanism to update their mobile phone number or home address. This information would get propagated to HR. For user management to be accurate and sufficiently granular, it is necessary for data from all of these sources, and possibly others, to be amassed in a single location and accessible on demand.
Similar to the HR consolidation project, architecting an adequate directory structure will require the buy-in and participation of your directory services department, as well as from HR and other groups that may be required to interface with the directory to provide or obtain information. A sound directory structure is the foundation of the identity and access management enterprise. If your directory is not clean, accurate, and thoroughly populated or if it is inadequately secured to protect this wealth of information, it does not make any sense to build additional components. Address the issues with your directory first.

Incorrect User Information
Incorrect information about a user is perhaps more damaging than lack of information. If you are basing access decisions for a user based on data from two years ago, you have a problem. This is again a mandatory cleanup project that is a prerequisite to the main identity and access management program and is the responsibility of the departments owning the systems of record. Maintaining accurate data is largely a procedural concern. Work with HR (or other departments as needed) to develop efficient processes for keeping data up to date. You may also need to retrain personnel in the use of certain system fields. If you need to transfer data from one system to another, the receiving system will expect a certain format. If someone has input data into that field that is not in the expected format, the data transfer will fail.
The problem of outdated information is of course much more prevalent in large companies, where it is not trivial to track the intradepartmental or even interdepartmental movements of individuals accurately. One effective solution to this is to build a workflow mechanism that is driven by HR. On a monthly basis an automated process could run against the HR databases and generate a listing of all users reporting to each manager. The managers could then be contacted via a workflow tool, presented with their list of employees, and asked to validate whether it is still accurate.
The manager should be able to respond directly within the tool with any changes that may have occurred. The manager's changes could be populated directly back into the HR database or could be submitted for manual review by an HR representative. An enforcement process could be implemented to ensure that managers perform this task within a certain number of days of receiving the notice; reports could be generated to executive management to demonstrate compliance (or lack thereof).

Selecting a Solution—Suite versus Best of Breed
As of the writing of this book, Thor Technologies has recently been acquired by Oracle, eliminating the last of the major provisioning tools as a point solution. All of the top provisioning, single sign-on, and Web access control (WAC) tools are now part of vendor suites. However, most vendors price the components of their products somewhat individually, so there is still an option to pick and choose various components from different vendors.
The debate between suite solution versus best-of-breed point solution has been raging in the identity and access management space for a while now. Despite the consolidation in the marketplace narrowing the choices down to pretty much just suites, the argument is still valid because it all boils down to cost. The theory is that if you purchase a suite of products, all of the components of your identity and access management solution will already interoperate, saving you time and money on integration. But, if all of the components in the suite do not adequately meet your requirements, the money you save (and more) on integration could end up being spent on customizing the product to meet your needs.
The solution to this conundrum will vary by company, but your decision must be clear and well substantiated. As previously mentioned, any identity and access management solution will be deeply embedded into your infrastructure and touch (theoretically) every system and user in your enterprise. The solutions are extremely expensive, and the amount of time and effort it takes to get them working is substantial. This is not a decision you want to botch or something you want to rip out half way into the implementation.
The best way to ensure that you are making the right decision is to establish a core team of technically savvy people to do a good, old-fashioned, consulting-style requirements analysis. The team of people should include:
§  Your security architect, who should be familiar with identity and access management architectures, both generally, and as they apply to the specific vendors you wish to consider
§  A member of your IT architecture or infrastructure team who can add additional input into integration considerations
§  Someone from your user management team who can speak to the day-to-day pain points, issues, and needs as related to user provisioning and de-provisioning
§  A member of your directory services team because the directory is a key integration point with the provisioning tool
Once you have your core team and they have had a chance to interview key stakeholders to get their input, they should create a detailed listing of requirements based on stakeholder input as well as their expertise. You may choose to break down your requirements into a variety of areas for readability. Some suggestions of areas to consider include:
§  Functional. What must the tool be able to accomplish? For example, to what level of detail do you need the provisioning component to be able to provision or deprovision a user on a particular system? To which systems would you like to apply the WAC component? To what extent do you want single sign-on to work in your environment? What characteristics do you want the password self-service tool to possess?
§  Integration. What are the key systems in your environment that the tool must support out of the box? What other important systems do you know no tool will support out of the box for which you expect to build custom interfaces? What are the industry standard protocols that you use in your environment and that you expect the tool to use?
§  Architectural. Most vendors run their suite on a handful of platforms. For example, they may run on Windows or AIX operating system and on Oracle or Sybase database. What combinations of operating system, database, directory, and other components would be acceptable to run in your environment?
§  Compliance. What reports do you need the product to be able to produce? What are your reconciliation and introspection requirements? Do you expect the product to be "SOX certified"? If you are a government agency, do you expect the product to be able to handle mandatory access control (MAC) as well as discretionary access control (DAC)? Do you need the tool to have certification and accreditation (C&A) to a certain level (e.g., C2 or B1)?
§  Stability. Do you have requirements in terms of the vendor company's size, whether it is publicly traded or private, investments, and length in business? Would you be terribly concerned if it got acquired by another company?
§  Performance. What type of throughput does the product need to be able to sustain? What are your uptime requirements?
§  Security. Because we are discussing the evaluation of a security solution, you might think that security is adequately built into the product. But that is not always the case. Be sure to list your security requirements in terms of encryption, authentication to the product, recoverability, and whatever else concerns you.
When you list each protocol, each system, and each functional requirement in part, you will end up with a list that is hundreds of line items long. It is not unusual for a detailed requirements document to exceed 100 pages. As a brainstorming exercise, ending up with lots of line items means that you have carefully considered your environment and your needs. But you cannot expect to evaluate products reasonably based on so many detailed requirements. Therefore, the next step is to prioritize your requirements on a usable scale. The easiest scale to use is one to three. Any more than that and you introduce a level of granularity that makes the ranking process more arduous, without measurable value. The most common and useful way to set up your importance scale is as follows:
§  3 = Mandatory. This feature is absolutely necessary for your environment. If a product does not have this feature, it is a show stopper and the product should no longer be considered.
§  2 = Desirable. This feature would greatly enhance the usability of the system or would otherwise significantly add value. If this one feature is missing, it would not be the end of the world, but if multiple features ranked 2 were missing, that could aggregate into a show stopper.
§  1 = Luxury. It would be nice if this feature were available, but chances are most products do not offer it and not having it does not present any substantial problem. Of course, vendors that offer this feature should get some bonus points for it.
Your importance ranking should not be done with any specific product in mind. Rather, it should be done with your environment in mind. Focus solely on what is most important and relevant to you in the context of your company. In terms of ranking realistically, you should have a handful of items ranked 3 and a handful ranked 1. Most items will be ranked 2.
Once you have completed your requirements-gathering and -ranking exercise, you are ready to compare the vendors to it. First, select the vendors you wish to assess. For this initial exercise, you may want to consider all vendors who have a product that would be adequate for your company's size and needs. You may want to make some preliminary decisions based on the reports from research companies such as Forrester, Burton Group, IDC, Gartner, or others. Once you have selected your initial list of vendors, have one of your core team members schedule a call with one of the vendor's engineers and run through the list of questions. At this point, you should not divulge what the requirements mean to you in terms of importance. Simply have the individual answer your questions to the degree necessary for you to provide a scoring. A useful scoring mechanism for vendor capability is:
§  0 = This feature is not offered or the product cannot meet this requirement.
§  1 = This requirement can be met with some customization.
§  2 = This requirement can be met out of the box and only requires configuration to achieve.
§  If you are concerned about vendors scoring very similarly, you may choose to have a ranking of 3 = the product exceeds the specifications of this requirement. Basically, allow the vendor to earn "extra credit" if your expectations are exceeded.
Finally, for each vendor, generate the line-item scores and total score. The line-item score is simply the importance value times the capability value. For example, if you rank an item as having an importance of 3 (mandatory) and the vendor can meet that requirement (capability score 2), the line-item score would be 3 × 2 = 6. If you use the 0 to 2 capability scoring mechanism, 6 is the maximum score possible. If you allow the extra credit capability score of 3, 9 would be the maximum line-item score. Of course, 0 would be the minimum capability score possible. The vendor should not receive any credit for that which it cannot do.
After you have determined the line-item scores for each vendor, add them up to come up with a total vendor score. The vendor with the highest score is theoretically the most compatible with your environment. However, unless there is a very large and very clear discrepancy between the top two or three vendors, you may wish to do some further analysis here. Take a look and determine why one vendor scored better than another; is it because it was good across the board or because it got very high marks in just one area and mediocre marks everywhere else? Such a vendor may not be as beneficial for your long-term use as a vendor who did not score exceptionally well anywhere, but scored reasonably well across the board.
Irrespective of how variant the scores, it is imperative that you have your top choice and at least the runner-up come in and demonstrate their products in your environment. Take the top requirements that you documented and convert them into testing criteria and have the vendor demonstrate how those requirements are met. You may find that the vendor looks better on paper than in-house.
After you have done your paper-based assessment of prospective vendors and you have seen them perform live, you are ready to make the suite versus best-of-breed decision. If you have followed all of the steps outlined here, carefully documenting decisions that were made along the way and letting the requirements and not politics or personal preferences choose the product, chances are your selection will be the right one for your organization and you can implement with confidence knowing that you are doing the right thing and will not need to backtrack later. If, after a year or two, the requirements change drastically in a way that you could not have foreseen and someone questions your decision, you will have all of the evidence you need to demonstrate that, at the time, it was the best possible decision you could have made.
This section has been focused on the selection of an identity and access management solution. However, the methodology applies to any product selection and is a good way to ensure that you are making the right decision before issuing a purchase order.

Key Control Points | Identity and Access Management

Add a note hereThree critical controls are embodied in identity and access management: properly managing new hires, controlling access for users who transfer, and promptly terminating access for users who have left the company. These components are further described in the following subsections.

Add a note hereStarting Off on the Right Foot—New Hires and the "Least Privilege" Principle
Add a note hereIt is very important to ensure that access is appropriately granted to new users in your organization so that they do not exceed the "least privilege" principle from day one. This principle specifies that a user should only have as much access as minimally needed to perform his or her assigned job functions—nothing more. Initially, as new users are learning the job or in training, it is conceivable that they require even less access than they will ultimately have. Certain unionized functions base privileges on tenure: users must complete a certain number of hours of work to obtain additional authority on the system.
Add a note hereThe challenge for most companies with new hires is that there are not adequately defined roles and rules dictating what access the new person should be granted. Some companies also struggle with the concept of authorization and approval. Should a user's manager approve his or her access or should that fall to the data owner? 

Add a note hereMaintaining Control over Time—Managing Transfers and Segregation of Duties
Add a note hereControlling access as individuals move through the organization is the most problematic area for most companies; this is where the most violations of segregation of duties occur. Segregation of duties is the concept that a person cannot perform two complementary job functions that could lead to the individual's ability to defraud the company. For example, someone who has functions in accounts payable should not also have functions in accounts receivable. Likewise, on the IT side, a system administrator charged with granting access to a system should not also be the one charged with approving that access.
Add a note hereOver time, a person who moves from position to position within the company could amass permissions that end up violating segregation of duties or the least-privilege principle. An important part of user management to ensure that old access is removed if no longer needed is the verification of access each time an individual transfers from one department to another, gets promoted, or otherwise makes a move within the company.
Add a note hereBut how do you know when someone has transferred? Most companies struggle tremendously with this challenge. The problem is that most organizations do not manage job functions at the granularity level that could distinguish differences among all transferees. For example, if in your HR system a user's department is denoted as "Accounting," there is no way to determine from the HR record whether the user is part of the Accounts Payable team or the Accounts Receivable team. If the user transfers from the former to the latter, clearly an access change is needed, but a review of HR department changes will not identify this user as a transferee.
Add a note hereEven if you can identify that someone has transferred, there is the additional problem of identifying what access the individual previously had and what access is now needed. This is similar to the problem described earlier with new hires. Some policy-level decisions also need to be made on overlapping duties for a user who is in transition. Is it acceptable in your organization for someone to violate segregation of duties for a period of time while he or she transfers from the old position to the new one? If not, how will such transitions be handled? 

Add a note hereTerminations—Is That Person Really Gone?
Add a note herePromptly removing access when a user leaves the company is considered critical to the auditors. If someone is no longer employed, he or she should no longer have access—period. But the process of accurately terminating a user can be daunting if you are unsure when a user leaves the company, if it is unclear what access he or she had in his or her job function, or if you did not have a strong transfer process to help you with access cleanups through the course of that person's career. Additionally, in some scenarios the person's termination date is different from his or her last day of employment. Nevertheless, an audit finding in the area of terminations is more serious than an audit finding in any other area of user management; whereas a small number of exceptions is acceptable in other areas, in the area of terminations it really is not. Therefore, you have two choices: mount a very serious effort to clean up terminations and tighten your processes or implement additional "mitigating" controls.