Mar 30 Five spring cleaning tips for your Identity and Access Management program

Spring is in the air, and for many of us, that means the annual ritual of spring cleaning. In my household, it is an opportunity to look through the boxes in the back of our storage area to see if there are any we have not opened in the past year. It is a time to go through closets and find clothes that either no longer fit the children or that will never come back in style. It is a chance to assess those novelty Christmas gifts like a Bluetooth-enabled set of woolen gloves and decide if it would be better to donate them to charity or to save them for white elephant gift exchanges. After a thorough spring cleaning, it’s easier to find things, which saves time. It also means we’re not keeping things around, “just in case”.

Despite this being a tradition for millions of families, most companies lack the same tradition in the long-term management of their Identity and Access Management (IAM) programs. This is not benign neglect, but rather an underlying fear that the IAM program resembles that shaky tower of cardboard boxes in the garage. It is tolerable to look at infrequently, but you will need to sign a change control order before adding another box containing a singing fish, an indoor grill, and a spinning mop to the pile. Often, companies only uncover these tangled messes and curious provisioning logic rules when considering upgrading or replacing their IAM vendor’s product. In this article, we will examine how to clean up the five most common messes you will find as you air out the storage unit of your IAM program.

A useful annual technique for assessing individual components of IAM programs is ADR:

Approach: Interview the personnel most knowledgeable about each portion of the IAM program, and have them explain how and why it works.

Deployment: Ask the staff you interviewed to provide you with the written documentation describing their portion of the IAM program.

Results: Ask them to show you the results of a live transaction. This might be adding a user to an application or privilege revocation. Check that the results match what was verbally described and the written documentation. Often, people will apologize at this point, explaining that either the documentation is out of date, that they forgot to mention a step, or that there’s now a manual step required to achieve the desired end state. The gulf between the results and the approach or deployment are a leading indicator of trouble spots such as these:

The provisioning rules refer to outdated business processes

A shipping company that I worked with in New Mexico had an elegant provisioning system with several levels of approvals when a user requested access to production systems. Emails were routed to appropriate personnel, approvals were granted or denied, and the request would then be processed automatically. At least, that is how it was supposed to work. The company had several reductions in force over the years resulting in approval emails being routed to managers and VPs who were no longer with the company. The emails would bounce, and this initially had caused chaos in the approvals process. The IAM provisioning lead had developed a workaround, however. Instead of finding new approvers or disabling the invalid approvers, they instead had modified the provisioning logic to accept an email ‘bounce’ notification as an approval.

This curious implementation was not done maliciously – it was put in place when no one on the IAM program knew who would be responsible for approving access to production after the reduction in force. However, it had potential regulatory compliance consequences, as the requestor would be granted production access with no human oversight if all three emails in an approval bounced. The solution was to first identify the right managers and VPs for production-level access approval. This was done through a series of meetings before anyone sat down to modify the provisioning logic. Additionally, the logic to accept a ‘bounce’ email as an acceptance was changed to be instead treated as a rejection.

There are multiple duplicate and identical rules

A colleague of mine was on a project with a media company in Southern California. As part of a planned consolidation of their IAM program, they envisioned importing authorization rules from their privilege systems into a centralized repository. This was a common enough project at the time that my colleague had built some automated scripts to expedite the import process. What she had not considered was the implications of a client that did not understand using groups for managing privileges. As such, the client had a set of 63,000 authorization rules, many of which were rather granular, such as the ability to reboot a production server. However, instead of creating a group of servers and a group of users, the client had instead created a rule for each user on each server. As such, every time they hired a new system administrator they had to add about 500 new authorization rules to the set.

The solution to these excessive rules was to review the privileges that were granted to each user to find common elements. For example, it was a standard privilege that a systems administrator could install updates on the systems. Identifying the standard role of ‘systems administrator’ was essential, because then additional privileges could be assigned to that role, such as restoring files from backup or rebooting a system. After much analysis, there were four primary roles defined. The result of consolidating the roles and privileges was that it was considerably easier to produce audit reports showing who had privileges across the computing estate.

The rules refer to outdated systems

A pharmaceutical company that I worked with in the Northeastern United States had a project to centralize user authentication and authorization under a single source. One of the more surprising findings during the analysis phase was that this company was using Network Information Service (NIS) netgroups to control access to file shares on dedicated file-sharing appliances. By itself, this was not surprising, as NIS and file sharing were conventional technologies years ago. What was surprising was that the client’s team had decommissioned the use of NIS, and the dedicated file-sharing appliances were long gone. The provisioning system would throw an error when attempting to edit the NIS netgroups file, and the development team had written error handling code that discarded the error.

Migrating from one IAM product to another is a good time to identify and remove references to systems that no longer exist. However, the best practice when shutting down a component of an IAM program is to ensure that all connectors are disconnected, and all programmatic logic is disabled. Keeping those around just adds operational complexity for the next team responsible for the IAM program.

No one understands the security implications of the rule

When I was offered the opportunity to work on a project for three weeks in Amsterdam, I accepted, thinking the hardest challenge would be finding a good cup of black coffee with no specials. The client was a financial services firm that had a permissive stance on security that had led to several breaches and unauthorized trades in rapid succession. They were considering starting an IAM program so that they could limit user access. Before arriving, I’d asked them to produce a list of users and for each system, so that we could review who had access to critical business systems. When I arrived, they explained that the traders on the floor logged in with the default user account on Linux and then opened their trading program. Unfortunately, the ‘default’ user account was named “root.” For convenience, it was the same password on all systems, and it was posted on signs near the terminals in case new hires forgot. (If you are unfamiliar with Linux, the root account is the equivalent of the Administrator account on Windows).

The trading firm had initially started on Windows terminals, before hiring a talented team of Linux developers who helped build and maintain an efficient trading platform. The development testing was conducted as the root account, and consequently, all documentation for the system indicated using the root account to log in to the production systems. As the IT staff at the financial services firm had a background in Windows, they saw no initial concerns with this operational model, as they did not understand the significance of the root account.

Although there was no quick solution, the project was based on having users log in with their own credentials. They already used Windows computers with distinct logins for access to their office software and their email. After several meetings, the CIO understood that the same model could be successfully applied to the Linux trading environment with no loss of functionality and a considerable improvement to security. The longer-term solution was to create a dedicated security analyst role within the firm so that all new systems could be examined for potential security implications.

Additional manual steps are required

Software vendors will periodically mark their software as ‘end of life.' While the original vendor may offer an upgrade path and competitors may offer competitive migration tools, not all customers migrate. At Integral Partners, we have encountered numerous clients over the years whose IAM programs include software that’s no longer covered by extended maintenance and has been abandoned. One client we worked with was a manufacturing company in the Midwestern United States who used an LDAP Directory and an Identity Management platform from a vendor that had ceased operations. Although the original hardware and software was still running, they had developed a duct-tape patchwork of scripts and programs that ran after each provisioning operation. Most of these were to provision systems that did not exist when the original vendor had stopped supporting their platform, though some were to keep the older software running. Many of the scripts were undocumented and had been written and modified by multiple authors, further increasing the complexity.

The solution in cases like this is to take an inventory of which systems need to be provisioned, which roles and privileges need to be assigned, and who’s responsible for approvals. Next, build the same logic, transactions, and approvals on a new system that can connect to lab instances of the endpoints being provisioned. As each transaction runs in production, have it also run in the lab to confirm that there’s parity in the end state on each transaction, whether it is for granting a privilege or for removing a user account. The next step is the most difficult – stop running operations through the old system and start running all IAM transactions through the new system, and wait to see what was missed. Often, this takes days to find an unusual edge case scenario that the team had not initially identified and migrated to the new IAM system. Only until the new system has been operational for about six months with no ‘missing’ transactions should anyone consider decommissioning the legacy system, as the advantage of leaving it running ensures that it will be accessible as a reference point for unusual IAM transactions.

The alternative would be to review and attempt to port the spaghetti code from the older platform. However, this carries the risk of porting logic errors and hacks that were put in place solely to sustain the older software. Competitive migration toolkits from vendors often perpetuate poor design decisions and should be approached warily as a result.

Although this is not an exhaustive list, the five IAM messes described in this article are the most frequently encountered today. Spring is a good time for organizations to start an annual tradition of reviewing their IAM program for junk that can be removed. The Approach – Deployment – Results method will help open the storage bins and find potential areas for improvement, as well as unmanaged risks to the IAM program. Applied regularly, this approach can reduce the possibility of clutter and keep your IAM program running smoothly for years to come.