With identity management staff becoming increasingly overworked, many organizations are looking at a self-service...
user identity management model that leverages IT-aware end users to take charge of managing their own identity management profiles and access.
Without a thorough understanding of all the decisions necessary for granting access, inadvertent mistakes can be made, especially in large user populations or complicated business structures.
But, like fast food restaurants that will allow their customers to get their drinks but not step behind the counter to cook their own hamburgers , there should be limits to the extent that employees are able to manage their identity experience. This causes organizations to ask, "How much self-service is too much when it comes to identity and access management (IAM)?"
In IAM, there are two overwhelming risks in utilizing a self-service model. The first is that, without strict controls, the quality of the data that's input via self-service IAM interfaces will suffer. When this information is used for business systems, bad data can have huge repercussions on the organization's operations and projects. The second is the risk that unauthorized users will gain access to sensitive information. As might be expected, this danger can cause an organization to become non-compliant with regulations and cause undue risk to the organization. So let's explore each of these in turn.
IAM data quality
One area where self-service is extensively used is in the management of user business and personal profiles in white page applications. In this case, a portion of the end user's profile is pre-loaded into an application from his or her initial HR record. Of course, when recognizing that this information is incomplete and may have become outdated, organizations will implement self-service, allowing end users to alter and/or update their records, usually through some sort of Web interface. Most often, information that is modifiable includes: contact information, company address (including internal location code), work phone and mobile numbers, title and other business information like job code, department information, home contact information, etc. These sorts of updates are generally allowed because the information may not be readily available in the organization's enterprise repositories; there may be issues with tracking changes to these fields, and, invariably, the end user is the only one that can verify the information is completely correct. If this information is used strictly for internal white pages , for instance, then normally this is a good use of self-service.
But organizations must understand that, like fast food fountain drinks, self-service should be used where there are cost savings and business opportunities to be gained by it, with a low amount of risk. Using self-service can be risky if organizations attempt to use employee-input information for business purposes without end-user awareness training or strict controls. Giving individuals the responsibility to manage information used for important business purposes without giving them the proper understanding of the inherent dangers to the corporation could leave the company in a position where emergency services might be needed to handle a fire, physical or non-physical. For example, employees or managers who are members of a corporate red team -- the team contacted in emergencies for incidents like fires, floods and disasters -- may fail to keep their contact information up to date. This risk can be demonstrated in the real case of a major corporation that had to evacuate its building due to a reported fire. The executive team was seen roaming through a crowd of nearly 1,000 people looking for the chief of physical security. It turned out that he was the only person with authority to grant access to the local fire department to get into the sensitive area where the fire was reported, but they couldn't call him because he hadn't updated his mobile number in the corporate white pages.
Another example of issues with self-service is the company that used employee-maintained white pages "Title" information as part of the input in determining user access for its roles-based access (RBAC) system. As the RBAC system was creating a series of access services, it returned an error because a software engineer changed his title from "Web-engineering Analyst" to "Emperor of the Universe." While a lofty goal, such a title could not be mapped to access services, creating a delay in the process.
Another example of how self-service has caused issues involves a company's HR department that wanted to do a large mailing of benefits information to its employees' home addresses. Since the company extensively used automatic deposit, most employees didn't bother to contact HR with changes to their local residences. The HR department decided that since the company used self-service for its corporate email directory for personal information, they'd use the more "up-to-date" information from this source instead of the employee information they had, which they knew was outdated. However, when the information was extracted from the corporate email system, HR reps found that many of the personal home address information fields were either not filled out or incomplete. For example, people left out their zip codes, streets were accidentally misspelled, and state information was sometimes missing. This required the HR department to execute a comparative analysis between its information and the information derived from the corporate email system. Even after this extensive project was completed, 5% of the employee population's home information was still incorrect or incomplete, and the HR department had to contact these employees directly to get their information before the mailing could go out.
While these are just three examples of how data quality can affect an organization, they're only a few of many problems that can arise if self-service is not managed correctly. Poor data quality can be one of the arrows in the heart of any IAM architecture: Without good identity data, the processes and controls that use this information for the use and configuration of downstream applications, service errors will be compounded many fold.
While self-service can be injurious to an organization when a user maintains his or her own identity information, self-service for access control can be disastrous if done incorrectly. In an IAM architecture, self-service takes the form of a user requesting access to a set of services, usually through a self-service access portal. The user identifies him or herself using a set of known criteria, or credentials, which then kick off workflow processes to create appropriate access. The problem arises when the workflows are not well thought-out. Many organizations have taken existing manual workflows and automated them. While this may be appropriate, in many cases there was a human behind the legacy, manual workflow that had the ability to determine if the access was appropriate or not. However, when these processes are automated, the human logic driving decisions often isn't carried over to the self-service application.
For example, a customer may be going through a divorce and his or her estranged spouse wants to see how much money is in their life insurance policy as a negotiation point of the proceedings. The spouse has knowledge of the customer's Social Security number, birth date and other sensitive information. The spouse can then go to the insurance site's customer portal and request access to the customer's account by filling out a registration form with the knowledge he or she has on the customer. Since the information is correct (and the logic doesn't check to see if an account already exists), the portal grants the spouse access. Before the company went to a self-service model, the spouse would have had to contact a service representative to get access and it would have been much easier to distinguish that the spouse was not the one listed on the account. The service representative would have then questioned the spouse, or outright denied access.
Without a thorough understanding of all the decisions necessary for granting access, inadvertent mistakes can be made, especially in large user populations or complicated business structures. Since the normal administrative oversight doesn't occur when self-service requests are initiated, the "check" in the check-and-balance is missing.
Making self-service safe
It doesn't take many horror stories to understand there's a lot of risk in implementing self-service IAM services. So what can be done to mitigate the risks to acceptable limits? Here are some recommendations:
- Understand what's being self-serviced: Just because something can be self-serviced doesn't mean it should be. IAM professionals need to consider what happens to their processes and procedures when the end user becomes the owner of the process.
- Make education part of your plan: People make mistakes, and just because you understand the value of complete, accurate and timely information doesn't mean your users do. Ensure you educate them not only on what fields will affect your business operations, but also make sure they're aware, and accept, that they have the responsibility to maintain good data.
- Put in checks and balance processes and procedures: You can't always ensure that an access request or self-service data stewardship is being handled correctly. Self-service doesn't equal self-management. While the operational aspects of IAM may be delegated to end users, management of these systems must still be maintained.
- Just because you've implemented self-service doesn't mean you've reduced cost: In many cases self-service doesn't mean costs will go down. With the overhead of managing and monitoring these services, costs may actually go up in the short-run. So don't reallocate those administrative budgets until you see what the actual costs will be. The good news: While self-service doesn't necessarily reduce costs, it does reduce future spending. It's generally accepted that self-service IAM deployments tend to flatten costs over time by way of cost avoidance, due to their ability to manage large user populations with a small number of staff.
- Transition carefully: As you move from your traditional IAM services to a self-service model, pay attention to how it's affecting the overall architecture. Additional unplanned controls or education may be needed upon the identification of data quality erosion or denied access requests.
Self-service can be a great aid or great hindrance to an IAM infrastructure. With the promise of reduced staffing efforts and empowerment to the business at large, self-service can be attractive to an organization. But, as it's been said, with great power comes great responsibility. Ensure those who are granted this responsibility use it wisely.
About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 20 years. He specializes in security/identity management strategies, methodologies and architectures.
Dig Deeper on Enterprise User Provisioning Tools