• Provisioning and deprovisioning (which I abbreviate as de/provisioning)
• Non-employee management
• User or access recertification

This segment explores the first of these, de/provisioning)

De/provisioning is the most common of IAM workflows. Done right, this workflow delivers tremendous ROI, improved audit results and improved customer satisfaction by significantly speeding up the de/provisioning process. It is also the most complex, as a workflow has to be identified for each access or equipment type. Furthermore, for those access items that will be automated, instructions may have to be provided to the IAM system on how it needs to grant or remove access.

Let’s now run through the objectives outlined in this month’s Introduction segment for this set of workflows.

Objective 1: Determine the appropriate scope

A workflow can be created for just about anything, but does it make sense to create one?

To begin answering this question, refer back to the previous lists of systems (created about seven months ago). Begin with the primary systems and move on to the secondary systems. Chances are, some degree of workflow will be needed for each one of these systems.

Also consider what manual workflows might be appropriate – for example, for computers, mobile devices, application licenses, etc.

Another important input here is the company’s service catalog. If one exists and it has built-in workflow, a good portion of the work is already done. Not all of it, since the service catalog triggers tasks for manual de/provisioning only. But at least the workflows in the service catalog should give some sense of order of operations (i.e., which tasks can be performed concurrently and which must occur sequentially), and it should contain the names of the teams involved in each workflow.

For equipment workflows that will stay manual, the services in the service catalog may be replaced by or augmented with similar workflows in identity manager. For access workflows that will be automated, those teams will need to be engaged to better understand the technical details.

A note of caution – be careful when approaching teams with an offer of automation. Those teams that are overwhelmed with work will very likely welcome the offer, but those that are less busy or if they perceive that their entire job will be automated will be understandably reticent to participate. They will perceive that you’re coming in to eliminate their jobs. And yes, it will be that personal – anyone on the IAM team will become persona non grata, bringer of pink slips.

It is worth spending time understanding how the IAM team’s efforts will be received, and engage management appropriately. This may also impact the scope of work, as items that should normally be included in scope or fully automated may have their scope reduced or be eliminated from scope if the political situation gets too volatile.

The questions that need to be answered for this objective are:

1. Is a workflow going to be created for this item?
2. If yes, will there be automation, or manual task assignments?
3. What are the teams involved?
4. How will the teams receive our efforts?
5. Is there an existing workflow that can be leveraged?

Objective 2: Populate the requirements list

The requirements list must be clear based on the determined scope. If full integrations are expected with any systems, the technical expectations should be documented (if they haven’t been already). Remember, not all IAM products are created equal, so selecting the one that best meets the requirements is vitally important.

Objective 3: Identify prep-work

There is quite a bit of prep-work that can be done to speed up implementation once a tool is selected. For example:

• Working with the people familiar with the de/provisioning processes to understand and streamline those processes – are the processes usable as-is, or are they a mess or outdated?
  • In particular, it’s important to understand the deprovisioning process: can an account simply be deleted, or does it first need to be disabled for a time (e.g., to allow for data backups)? If there is a disabled status, what will be the duration for that one week? two weeks? a month?
  • Similarly, can a piece of equipment be taken away directly, or are there data backup needs there too?
• Cleaning up existing service catalog workflows so they can be more easily transitioned (if applicable)
• Preparing target systems – this is especially important on UNIX. Integrating UNIX systems will be much easier if the UIDs are already syncrhonized across the enterprise. If not, this is a good time to begin the cleanup effort. If this already got done as part of the March activity, great job!
  • Also consider if directly integrating each UNIX box with IAM is optimal, or if an intermediary tool will be used to manage UNIX access via LDAP, Active Directory, or the mainframe.

In the next segment, we’ll explore the user/access recertification workflow set.

This month, we continue down the workflow path by considering the more traditional workflows:

• Provisioning and de-provisioning (I like to abbreviate this as “de/provisioning”)
• Non-employee management
• User or access recertification

These workflows can be significantly more complex than the vacancy management workflows described last month. But as with vacancy management, decisions need to be made as to the level of automation that will be implemented as this may impact product selection. For example, if the organization relies heavily on mainframe applications and a high degree of automation is desired for mainframe de/provisioning, then this should be front and center on the requirements list, as not all products handle mainframe integration equally.

Workflows, if designed and implemented correctly, can also provide significant ROI in terms of de/provisioning speed, reduced effort for audits, elimination of future user cleanups, and decreased costs for things like licenses and equipment.

Let’s look at the benefits of each workflow type in a little more detail.

De/provisioning

As discussed before, there are two categories of “things” when it comes to de/provisioning: those things that can be automated (e.g., access – it just depends how much money and effort you’re willing to spend on the automation), and those things that can’t be automated (e.g., equipment – a new laptop will never float down the hall to the waiting hands of a new employee, someone has to deliver it or at least call the employee to come pick it up).

Clearly, any de/provisionable items that are automated save time and effort if the system can automatically do something in a few seconds that might take a human being minutes to do. The trade-off is the complexity of the integration as compared with the expected usage. An application with ten users will likely never have de/provisioning automated – it’s probably too expensive. Then again, if it’s a critical application and likely to get overlooked since the access changes rarely, maybe it’s a prime candidate.

Items that can’t be automated are still great candidates for inclusion into a workflow, because it builds accountability and helps with tracking. The workflow would simply trigger manual tasks in this case, but by requiring the person completing the task to mark the item done in the system and tracking that, it helps with the following:

• Identification of what equipment was provided (or collected back)
• Monitoring of Service Level Agreements (SLAs)
• Accountability – the individual is less likely to mark the task complete if it isn’t, since they know it could come back to haunt them.

Although out of scope of this series, consideration should be given to integrating IAM with the asset management system to help with tracking of equipment and licenses over time.

Non-employee management

There are two types of non-employees at most companies: those that are there for a limited time (such as temps, consultants, etc.) to provide specific expertise on a project or act in a staff augmentation capacity, and those that are there indefinitely, because they are some sort of business partner (supplier, outsourcer, vendor technical support, etc). As such, workflows must be designed to support both conditions.

Ultimately, non-employee management is a special-case user recertification, which is discussed below. It’s helpful to begin with non-employee management for two reasons:

• It’s a relatively small and simple sub-set of user recertification, so it’s a good place to start and get some experience
• It’s a valuable quick-win, since non-employees tend to be a significant blind spot because non-employees are typically not centrally managed in an HR-like system as employees are.

In fact, managing non-employees will be of value not only to the access services or security group because it provides better control over a group of users that is generally less trusted, but it will also be of value to other groups – like HR if they’re trying to reign in management of non-employees from a presence perspective, and finance if they’re having trouble determining when non-employees come and go (to ensure they’re being paid – or not – appropriately).

User/Access Recertification

Many companies still do user or access recertification by hand – generating and emailing unintelligible spreadsheets to business managers asking them if the people on the list still report to them and if the access on the list is still appropriate. Not only is the initial data collection and distribution arduous, but the effort increases dramatically when the managers come back with countless questions in their attempt to understand the access listed, or when their frustration with the process leads them to become unresponsive, requiring repeated follow-up.

Many IAM products offer automation for recertification, but not all solutions are equally elegant. The top systems offer a variety of benefits:

• Web-based view of individuals and their access
• Individuals have already been compared against HR to ensure that they’re current (and if vacancy management is already in place, then the HR records can be trusted and “user” recertification is no longer necessary)
• Access is presented in business terms, not as technical permissions, so that reviewers understand what they’re certifying
• Whatever changes are indicated by the reviewer automatically trigger automated or manual implementation tasks which are tracked to completion and logged for easy reporting
• Non-responsive reviewers are reminded automatically, and the line management hierarchy is used for automated escalations
• Reports for the auditors are easy to generate

Sounds great, doesn’t it? At a large company, this workflow set can easily save several FTEs worth of work for several months each year.

Approach

This month, we’ll discuss each workflow set in part, with three objectives in mind:

1. Identifying ways in which the workflow set could be developed. There aren’t any right answers here. The goal is to ensure that some thought has been put into what the right answer is for your specific situation
2. Populating the requirements list accordingly – this is where a lot of ROI can be found, if the right product is selected that can support the requirements. It’s critical to make sure that the requirements list is well-updated this month
3. Considering some prep-work that could be done in advance of obtaining a system.

We’ll begin in the next segment by working on the de/provisioning workflows.

In either case, the process is the same.

Implementation

There are two parts to implementing the new access for all applicable role members:

1. applying the new access (it’s sometimes easier to just delete what’s there and start over rather than trying to compare as-is vs. to-be and adjust), and
2. removing any extraneous access.

Care should be taken here – is that extraneous access indicative of another role, or just a relic from a past job function? Hopefully these situations have already been caught, but it might be useful to develop a process to handle issues like this – to ensure consistency and quality despite the 11^th hour discovery. But it’s very important to do something about the extraneous access – if it really is just a relic, revoke it!

Before making any access changes, it is critical to clearly communicate with impacted users – let them know when the changes are going to be made, and whom to contact for help if anything goes wrong. Also be sure to pick a time that is convenient to the users (the week before year-end close activities is not a good time).

Setting up for future access requests

Applying role- and rule-basing to a group of people may change the way they request access in the future. Be sure to make the necessary changes to access request processes, and communicate this information clearly to the users.

The best approach is to post information about the changes in the same place where users request access. This is especially important when implementing IT roles only, and not full enterprise roles. The more clear the end-users are on what they need to request and what will come to them automagically, the better it will be for them in terms of satisfaction, and for the access services team in terms of workload.

Role and rule maintenance

Although roles will not change as frequently as the users who need them, they will change over time. At a minimum, a process should be put in place to review each role once per year or more often if something major happens, like a significant organizational change or a replacement or upgrade of a system. This is something that should be specified in the access control policy or standard. Ownership of this process should fall on the information security department, on a senior access administrator or (better yet) a role engineer. It’s also a good idea to maintain a network of business liaisons in each department that can alert the process owner if a change is needed off-cycle. Depending on the bandwidth of the people involved, this could be done all at once as a yearly effort, or a few at a time as part of a perpetual calendar.

Cleanup of obsolete permissions

When all of the IT roles and rules have been defined for all enterprise roles needing to use a particular system, there may be some leftover permissions that aren’t assigned to any individual or any role. It’s a good idea to remove those.

Extra credit (and waaaayyy out of scope)

One of the reasons why systems with really granular permissions end up with such a huge repository of permissions and groups is that new permissions and groups are created without any analysis of what’s already there.

To really do this right (time permitting, of course – yeah right!) the permissions assigned to each IT role should be analyzed for redundancy or excessive access and adjusted accordingly. Whether or not this is worth the time and effort will again depend on your specific circumstances, but if it’s a system that attracts audit and no one seems to know how the permissions work or what exactly they give, it’s a good idea. Also, if you’ve got mainframe users who require two or three IDs because their permissions won’t all fit on a single ID (I’ve seen this!), it’s definitely a good idea.

Action recap

This month’s exercise was to begin role- and rule-basing the organization to facilitate access request and granting:

• Prioritize departments and identify enterprise roles in the target departments
• Develop a strategy for designing IT roles (depth vs. breadth), and get to the to-be from the as-is, with help from the power users; remember to test each role thoroughly
• Clearly document and obtain proper approvals for implementing the roles
• Implement the roles carefully, ensuring proper communication with the affected users. Also set up processes for maintaining the roles going forward, and adjust request processes as needed.
• Remove any leftover permissions that are not in use.

Next month, we’ll talk about hierarchies of information, and rules for maintaining those hierarchies.

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

Documentation and approval

Once testing is complete, the final roles should be clearly documented. This defines which permissions apply to which IT roles, and which IT roles apply to which enterprise roles. It is important to make sure the documentation is clear and detailed, leaving no question as to what is or isn’t included in a given role, all the way down to the granular permission level. Documenting roles in visual ways such as matrices is encouraged. In the case of rules, consider documenting the decision process as a flowchart.

Initially, roles may be captured in a spreadsheet, but that spreadsheet may quickly get very large and unwieldy. In the absence of a role management system, consider setting up a simple database to store the information.

This is where normalization becomes important.

It’s best to define IT roles as the lowest common denominator, and build out from there. For example, there might be two levels of accounts payable clerk – junior and senior. The junior level gets the basic access needed for that job function. The senior level gets the junior access plus some extra. This reduces role maintenance over time because if there is a change in the basic level access permissions, it only has to be changed in one role instead of two. This also explains why some enterprise roles will have more than one IT role on a given system.

When the documentation is complete, it is important to circle back and get approval of the roles from the appropriate parties – the department head(s) and/or the system owner(s). Consider this part of the running dialogue and relationship building that is essential to success of this process. This can be used as pre-approval when applying the access to new users in the future – since the access was already approved for the job function, as long as the correct role(s) are applied to the user, re-approval from the department head or system owner for each individual user’s request is not needed, shortening the delivery time for obtaining access, and also saving approvers time ongoing. Conveniently, this practice is also acceptable to auditors.

In the final segment, we’ll wrap up the month’s activity with implementing the roles and doing a cleanup of extraneous access.

Developing a Strategy: Depth vs. Breadth

As with enterprise roles (and departments, for that matter), IT roles may require some prioritization, because:

Each enterprise role can have many (possibly dozens) of IT roles.

This means there are a LOT of roles to define, document, test and implement, which raises an important question: is it better to spend a lot of time on each enterprise role, identifying it end-to-end before moving on (depth), or is it better to tackle the priority IT roles in each enterprise role, and touch each enterprise role multiple times (breadth)?

There is no right or wrong answer to this question and in fact the answer could be different for different enterprise roles.

The strategy is ultimately driven by whatever is going on in the organization – such as complaints that the access services team is taking too long to grant access (or making too many mistakes), an impending audit, or a process improvement project. It also makes sense to use this opportunity to successfully address a current challenge to curry favor for subsequent steps.

The argument for breadth is security – go for the sensitive/complex access first across all systems to stop the need for copying access and reduce or eliminate the mistakes when implementing access. Many companies employ a “model ID” system: “Jane needs the same access as John.” This is dangerous if John actually has more (or different) access than Jane needs – it’s bad for security. Interestingly, it can also be bad for customer service if John’s access doesn’t give Jane everything she needs.

The argument for depth is customer service – fill out each enterprise role in its entirety before rolling it out to the end-users to avoid confusion. This isn’t about implementing the roles – it’s about end-users requesting them. If each enterprise role is only partially filled out with its IT roles, the communication to the end-user might look something like this: “Going forward, you no longer need to request access for email, internet, shared folders, and UNIX applications because these are now included in your role. But you do need to request access for mainframe and Windows applications.” How many users will understand this?? None! So either they will not submit the correct individual requests, leading to missing access, or they submit requests that they didn’t need to submit, causing duplication of work for the access services team. In this case, not only has the workload for the access services team not been alleviated, but it’s caused a customer service nightmare, too.

In a perfect situation, each enterprise role is fully fleshed out with all of its IT roles, enabling a one-time cutover of all users in that role with flawless communications and an easy transition to the new process for requests. More often, however, the situation will be a bit less “perfect” and require a stepped or phased approach. The more planned, mapped, and understood the process, the more effective the communication and the less friction experienced in the process.

Once the strategy is mapped out and commitment to communication made, it’s time to begin defining roles.

Discovery: as-is access

The first step in defining IT role(s) is determining the as-is permissions for the members.

For any given system, obtain a report that specifies what each user in a particular enterprise role has. Theoretically, all users in the same enterprise role should have the exact same access on any given system. Practically, they probably don’t. Newer users may have less access than they should, while users that have been around for a long time may have accumulated a bunch of permissions that they should no longer have.

It’s also important to verify the enterprise role at this stage – if the group of users that should have had the same access seem to have two different groupings of permissions, maybe the original assumption was wrong and the users should actually belong to two different enterprise roles. Validate this with the department head – not by just saying that some users have different access, but by naming names: “John and Mary have these extra three permissions that the rest of the team doesn’t have. Do they do something special/different that the others don’t do as part of their job, or is this access a relic because they both held the same prior job?” Whereas a department head may not think anything of the extra permissions, if they’re put in the context of the specific team members, it will resonate, and they should be able to say exactly why that access exists. If the users do perform an additional job function, an extra enterprise role should be added to the list – this is where normalizing is helpful (e.g., finance analyst, senior finance analyst). If the users don’t perform any additional job functions, be sure that that access is removed from their accounts – more on this in part 4.

The discovery process is a great place to engage someone with scripting skills. There’s nothing worse than collating and analyzing data by hand, or trying to run manual reports. A decent scripter can significantly decrease the discovery workload, and it’s likely that the effort put into creating the scripts will come in handy later as well – when the identity management system needs to be trained how to obtain the same data.

Design: to-be access

The next step is to identify what permissions the given group of users *should* have. For some systems, this is very simple. Take internet access for example – either it’s allowed, or it’s not. Email might have a couple tiers, like standard access and executive access (with more mailbox space). A lot of systems have a small number of canned permissions that can’t be modified, like read only, update, and administrator. When these types of systems come up, rejoice in the ease of defining the IT roles.

Then there are the systems with a TON of permissions – relational databases and mainframes are notorious for this. This is where that power user will really come in handy – they hopefully know how permissions map to access, or at least they know enough about the system that they can help with the business side of that mapping if they get some help with the permissions side from an access administrator.

Coming up with the right IT roles on these systems can take much iteration. Remember to begin with the as-is access and eliminate from there, rather than trying to build the roles from scratch (although some people’s access may be so bad that a full rebuild is necessary).

There’s also another element here: level of detail.

Some IT roles will not be permissions, per se. Rather, they will be an indication of ownership – like “cost center manager” or “xyz data owner.” In cases like these, smart design decisions need to be made to ensure that the number of roles does not explode.

For example, a large organization may have literally thousands of cost centers, and they change all the time for administrative reasons that only the finance people can explain. Having a separate IT role for each cost center would be a maintenance nightmare, but having just a single role called “cost center manager” is too high-level. In this case, the right middle ground needs to be determined – maybe each department, business unit, or division has its own separate role. But such a middle ground will require some workflow design to get additional information on-the-fly when it’s needed. We’ll talk about this more next month when we talk about hierarchies and vacancy management.

Testing

In the previous article, I mentioned that department heads can get very uncomfortable about changing an entire team’s access, for fear of interrupting business function. In addition to building a good relationship with them, another way to alleviate those fears is by thoroughly testing the new IT roles with one or two users (in a test environment if possible) prior to rolling out the changes to the entire team.

This might seem obvious, but it can actually be pretty challenging to get someone to remember what all they do on a system at any given time. Special care needs to be taken when working with users that have periodic tasks – ones that only occur monthly, quarterly, semi-annually, or annually. Typically, periodic tasks are time-sensitive and critical to the organization (e.g., finance people who have to “close the books” on time) – that is not a good time for a user to find out that they no longer have the right access to do their job.

Non-access roles

Remember that roles and rules can apply to non-access items as well – like equipment and facilities. Although provisioning of these things will never be automated, having a quick and easy reference for the people that provide these services will make their jobs easier and allow them to provide better customer service. Consider defining IT roles for computer hardware, computer software, communication devices (phones, pagers, etc.), facilities (cube vs. office), badge access, and so on.

Other resistance

When designing enterprise roles, everyone is willing to play along because it’s very esoteric. No one thinks twice about categorizing who does what. In fact, other groups may find their own uses for the information, since you’re putting all the time and effort into gathering it for them anyway.

When designing IT roles, unless the access management function is already highly centralized, some (possibly significant) resistance may be encountered – mostly by the people who administer the access today. If they are completely buried in work, the thought of automating some of it will be welcomed. If granting access is all they do, they will likely interpret the automation of their job as a pending pink slip for them. Of course they won’t put it this way, but when you hear, “my application can’t be role-based – there are too many special circumstances that need analysis” or simply, “automation won’t work with my system” what they’re really saying is, “I think your project is a threat to my job and I don’t want to participate.”

This is definitely a problem, but not one that the identity management team should be saddled with. Early in the process, it’s easy enough to skip these groups and keep going – there are plenty of other systems and applications to role-base, so the luxury of deferring the “problem children” certainly exists. But for those that can’t/can no longer be deferred, escalate the issue to management and let them deal with it.

Next, we’ll discuss documenting the roles and getting approval for their use.

Identifying the roles in the organization is like writing an outline for a book and helps with three things:

• Determining and documenting departments (similar to defining how many chapters in the book)
• Understanding which departments need to be addressed first (similar to organizing the chapters into a logical sequence)
• Defining which roles need to be addressed first within the department (similar to detailing the order of points in each chapter)

Prioritizing Departments

Consider that organizations with many departments and diverse access possibilities it may not be feasible to try to list out all of the enterprise roles in one shot. As mentioned in the introduction, an enterprise role may or may not have a one-to-one correlation with an HR job code, so it’s not as easy as asking the HR team to run a report. It begins with HR data, but then requires conversations with department heads to understand the details of their particular department. In many cases, it requires follow-ups, since the initial conversations develop new ideas – and provide an opportunity to make improvements. Remember, this is an iterative process, not a point-in-time activity.

If there are too many departments for a big-bang approach, start with a prioritized list to identify the most important ones – from an identity management perspective, that is. In this case, “important” boils down to three things (in any combination):

• High turn-over of users
• Complexity of access (more complex is higher priority because this is where access granting mistakes get made)
• Sensitivity of access (i.e., anything that’s likely to be audited; higher sensitivity is higher priority)

How many is too many, you ask? That depends on how many people will be working on this task, how long they have, and how complex the access is. The answer will be different for each organization, and it’s up to you to determine how many is too many in your situation.

Identifying Enterprise Roles

The process of identifying enterprise roles for each department begins with an analysis of the HR report: determine what job codes/titles are already stored in the HR system. This is followed by a working session with each department head. Notice I said working session, not meeting or “send an email.” Take this opportunity to build a relationship with each department head, and help them understand what you’re trying to do. Most will welcome the opportunity to set up roles and rules, because this greatly simplifies the process of requesting access for them (and probably receiving access too) – that’s all good.

There may be some resistance in anticipation of implementing the roles. This is normal (most people resist change); a common concern is people not being able to do their jobs in the transition to the new roles. By building the relationship now, it’s possible to understand and alleviate their angst before implementation begins.

This is also a working session because it will take time to educate the department heads and their direct reports on what needs to be identified. It’ll be hard for them to think of roles in terms of access – there will be vocabulary hang-ups with these individuals just like there were with the HR team. This will be very new and foreign to them, so start slow. Spend some time introducing the idea of role-basing, and helping them understand how it works and why it benefits them. Then engage them in the process of reviewing the HR output and filling in the blanks between HR’s reality and their own.

Identifying the roles with the department heads is only half the battle. After working with the department heads, it’s back to the HR system to figure out how those roles can be represented clearly, accurately, and uniquely. Typically, the HR representation of an enterprise role will be some combination of other factors – like job code + location (if you’re trying to distinguish between a clerk at Store A and a clerk at Store B), job code + manager (if you’re trying to distinguish a finance analyst in Accounts Payable and a finance analyst in Accounts Receivable), or job code + pre-defined rules (which get coded into identity management if there isn’t enough information in HR).

Although this information won’t be truly useful until the role management system is in place, starting to figure this out now will ensure that the roles are all built on the proper foundation for easy upload into the role manager.

It’s also important to start now in case the HR system cannot currently provide the information needed to get to an appropriate level of granularity of roles for access. If the HR system cannot provide the needed information, more research will be necessary:

• Can the information be pulled from some other source, like the recruiting system?
• Will a workflow be required to have a manager specify the missing information?
• Can the HR system be modified to contain more information?

Clearly, if system modifications are needed, it could take some time to get it done.

Prioritizing Enterprise Roles

Some departments are very large, and as such contain a large number of roles. But just as not all departments are created equal from an identity management perspective, not all roles are created equal, either. When faced with too many roles and not enough time, prioritize the roles using the same criteria that were used for prioritizing departments.

In the next article we’ll continue by discussing IT roles.

It’s taken this long to get here for a few reasons:

1. The initial user cleanups provided information on who’s who in the organization, and ensured that unused accounts were eliminated – no sense in role-basing users who aren’t around anymore, right?
2. The secondary user cleanups hopefully gave some ideas of what access users have, and provided the baseline data to do the discovery work that we’ll discuss this month.
3. The HR work set expectations of what’s available in the HR system, and also allowed the IDM team and the HR administrators to build a relationship and a common vocabulary. This will help the IDM team to ask questions in the right way, and the HR team to know how to interpret and answer those questions.

In the event the above exercises are still ongoing, I suggest you complete those as much as possible before starting on this one as they build the foundation for continued success.

Ready for roles and rules? Let’s get started!

But first, a little technical accuracy: Enterprise Roles and IT Roles

There are two different levels of roles – enterprise roles and IT roles.

An enterprise role is a high-level entity, like “accounts payable clerk.” The enterprise role generally corresponds to the person’s job title and is a larger bucket which contains multiple IT roles. However, since the enterprise role is a construct of identity management, it may not correspond exactly to a job code in the HR system. For example, the HR system may have a job code for “finance analyst,” which might contain the enterprise roles “accounts payable clerk” and “accounts receivable clerk.” More on this later.

An IT role is the set of permissions assigned to a particular enterprise role on a specific system. So using our previous example, the enterprise role called “accounts payable clerk” might contain all of the following IT roles:

• Email role of “standard email access”
• Internet role of “internet access denied”
• Financial system role of “accounts payable clerk”

In many cases, there will only be one IT role on each system that corresponds to an enterprise role, but that’s not always true. Similarly, multiple enterprise roles can contain the same IT role.

For the purposes of this blog, it’s not necessary to be quite so technically accurate. I will generally use the term “role” to mean enterprise role, and “permissions” to refer to whatever IT roles may apply. Where better accuracy is needed, I’ll be specific.

Roles vs. Rules

Rules transcend roles and either help the decision process of who gets what, or they provide caveats. For example:

• All roles in the IT department get “standard email access” except VPs, who get “executive email access.”
• The following Accounts Payable permissions may not be granted if the user is already assigned Accounts Receivable permissions
• Anyone above manager is entitled to “internet access permitted.”

The bulk of the work is actually in identifying the roles, so that will be the focus of this blog. Rules generally come after the fact, to plug holes and normalize permissions (i.e., they’re a higher level of maturity).

Approach

As with everything else we’ve done to date, this exercise is largely about brute-force effort coupled with some intelligent data analysis. At the end of the day the steps are as follows:

• Identify the enterprise roles (based on a combination of HR data)
• Design and test the IT roles/rules needed by each enterprise role
• Implement new IT roles (or full enterprise roles), and clean up old access

We’ll continue in the next segment by identifying enterprise roles.

At a minimum, you should know what to expect (or not) from the HR system, and how to get to the data that identity management will need. In some cases, changes may be needed to the HR system to really make identity management work.

Reliability

I’ve touched on reliability already in the context of new hires, transfers, and terminations. At a minimum, the identity management team needs to be clear on how quickly (or not) an employment event gets entered into the HR system. Questions also need to be asked about how quickly administrative events get entered into the HR system. For example, in August, we’ll discuss user recertification. In order to automate user recertification, accurate line manager information must be available for each employee at any time. Does said accuracy exist?

Any problems with the reliability of HR data are not the problem of the identity management team. Actually, it becomes their problem, but it’s not theirs to fix.

This is where the identity management team may need to influence (or guide) HR through the process of improving their own processes. This could be tough for a variety of reasons, but mainly because there won’t be any intrinsic incentive for HR to optimize their system in ways that don’t benefit them directly.

The good news is that in most cases, the HR system will be good enough for starters, and a lot more work will be needed on the identity management side to fully use what the HR system can initially offer.

If there is executive commitment to the maturity of identity management, there may come a time when identity management becomes limited by the HR system. The beauty here is that when identity management takes hold, various business units will start lining up to leverage identity management to do one thing or another. When they find out that identity management can’t meet their requirements because the HR data isn’t good enough, the issue of HR data reliability stops being the problem of the identity management team and starts being the problem of HR.

So my advice – don’t try to fix this problem from the get-go. Get your own house clean, and let others fix HR for you later.

Accessibility

Even if the HR data exists, where is it?

If the interface between identity management and the HR system has to go looking in every field and every table in the HR system to find what it needs, it’ll make for one complicated interface. More likely, the interface will rely on one or more audit tables to alert it when something has changed on the HR side. But does the audit table track everything that changes? Hopefully, the answer is yes, but definitely ask the question. I once discovered the hard way that the answer was no. It’s important to have the HR team confirm that every change made hits the audit table – including bulk loaded data.

Updating the requirements list

This month’s exercise should feed the requirements list with a few items:

• After identifying which HR system(s) will be interfaced with identity management, identify which protocols can be used (this may have already been done back in January, but I’m repeating it here just in case)
• If there are plans to interface with the recruiting system/module, identify those protocols, too
• List which HR tables contain information that’s needed by identity management, and begin laying out the data map
• Specify any requirements that identity management will need to address based on the reliability of the HR data

Action recap

This month’s exercise was primarily to build a relationship with the HR team that administers the HR system that will integrate with identity management (remember, there could be multiple systems, but for the sake of clean writing, I’m trying to keep it simple). The goal of the relationship is to:

• Build an understanding of how the HR system works and how identity management will leverage HR data to automate provisioning and task assignments for new hires, transfers, and terminations
• Understand the potential limitations of the HR data and feed that into additional requirements for identity management
• Clarify the nuances in terminology and data usage between the HR system and identity management.

Next month, we’ll talk about creating access roles and rules to populate into role manager, and do a permissions cleanup.

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

Compared to transfers, terminations are pretty easy, but there are a couple of gotchas, as mentioned in this month’s introduction. A termination in the HR system means the employee is no longer getting paid. However, the termination date for getting paid may or may not coincide with the date the employee should stop having access to the company’s systems.

As with transfers, removing terminated users’ access in a timely fashion is a key control for a variety of audit regulations, including SOX and PCI. On the other hand, it’s also a customer service issue – remove the user’s access too soon and it’s disruptive to the business (and can cause significant turmoil if the employee has not yet been notified of their termination).

Here are the key considerations for how HR data can be manipulated to feed identity management the right information to handle terminations.

“Last Day Worked”

If your HR system has a Last Day Worked field and it is actively populated and used, you’re home free – 99.9% of the time last day worked = last day access is needed. In this case, there is one possible gotcha: if the employee stays on in their current job function, but as a contactor.

Remember, the HR system focuses on payroll. Because of this, if an employee changes status from “employee” to “contractor” they may still be terminated from an HR perspective – especially if non-employees are stored in a different HR system. From an access perspective, it’s business as usual, although such individuals might need to be run through the transfer process to re-approve their access.

There are three ways to handle an employee becoming a contractor in the same job function; by handle I mean ensuring that the user does not experience an access interruption:

1. Find out if this is even a possibility at your company. If it isn’t, you’re done.
2. Find out if the HR system has some sort of flag (e.g., a termination reason – see below) that will identify this situation. If they don’t, see if this can be added to the system – that would be ideal.
3. Accept that this is a rare occurrence and not worth handling with technology. In this case, consider launching an awareness campaign with hiring managers and HR so that they remember to notify your access services team when this situation arises.

Analyzing termination reasons

If Last Day Worked is not a field that is reliable, an analysis must be done on termination reasons. Typically, the HR system will provide some sort of drop-down menu where the reason for termination is specified – things like “got another job,” “retired,” “reduction in force” (i.e., laid off) – although these are typically represented as codes, not text.

There is usually an indication if the termination was voluntary or involuntary. The list of reasons isn’t trivial – there can be a couple dozen reasons including things you might not expect like “deceased,” “going to active military duty,” and “didn’t like the dress code.” As an aside, I was amused to see one HR system in which military duty was considered an involuntary termination, while deceased was considered a voluntary termination.

It is important to analyze all of the termination reasons and determine (with the help of the HR experts) which termination reasons would normally correspond with the last day of work, and which might not.

The terminations reasons that most likely need to be flagged are listed here, but there may well be others – make sure that the HR team clearly explains any of the more ambiguous reasons:

• Reduction in force
• Retirement
• Leave of absence (this is one that might need to be looked at even when there isn’t a termination associated with it, but that’s outside of our current scope)
• Becoming a contractor (if that’s an option)

You may also want to discuss executive termination with the HR team. Although this may not be flagged specifically in the termination reasons, executives are the most likely to keep getting paid for a long time even when they’ve stopped needing access. Additional workflows may be needed to handle this situation, or simply an awareness campaign with the HR department so that they remember to notify the access services team when an executive gives notice.

“Termination Date” and “Action Date”

In the identity management world, we typically consider the termination date to be the last day that someone works. In the HR world, termination date is usually the first day that the user doesn’t get paid – in most cases this would be the day after the last day worked. This is an important distinction, and one that should be confirmed for your HR system, because you don’t want to cut off someone’s access on the last day they work – this is the day when they’re trying to wrap things up and get going. There’s no telling if they’ll be done by 10am or 10pm, and it can have a pretty negative business impact if a premature loss of access keeps them from finishing their work.

If HR termination date = last day the person works, make a note to configure identity management to begin the auto-deprovisioning processes on HR termination date + 1. If HR termination date = first day the person isn’t getting paid anymore, it can safely be used as the date to start auto-deprovisioning.

For those termination reasons where the access termination date is before the HR termination date, the action date might be useful. The action date is the date on which the information is entered into the system. For example, it’s common practice to enter a termination into the system for someone being laid off after they’ve been notified of the layoff. If laid off = escorted out right away, identity management could use the action date (or action date + 1) to trigger auto-deprovisioning. In this case, action date would be before termination date.

In the case of a vacation or leave of absence before termination, there may not be usable data in the system. These scenarios should be discussed with the HR team, and a workflow or awareness campaign might be warranted.

In the next article, we’ll wrap up this month’s activities with a general discussion of HR data cleanliness, and how identity manager can find the HR data it needs and pull it.

Employees are, by definition, only hired and terminated once, but they can undergo many transfers during their employment at a company. Transfers are the biggest part of the employee lifecycle because a transfer can happen at any time for any reason.

In many cases, transfers can’t be predicted. Sure, there are union jobs where step increases happen like clockwork, but in non-union jobs, promotions, demotions, and outright job changes can happen pretty much any time.

As I mentioned in this month’s introduction, there are two key challenges with transfers:

• The HR system can’t notify identity management if the old access will still be needed in the new role (maybe just temporarily)
• What’s considered a transfer from an access perspective may not register as a transfer from an HR perspective (I gave the example of Accounts Payable and Accounts Receivable both being positions in the same Accounting department).

These challenges are compounded by the fact that properly managing transferred users’ access is a key control for a variety of audit regulations, including SOX and PCI.

So let’s take a look at how HR data can be manipulated to feed identity management the right information to handle transfers.

Timing of transfer vs. timing of access change

Ultimately, to fully automate the transition from old job access to new job access, the user recertification workflows have to be in place in identity manager (we’ll talk about this in August), and roles and rules have to be properly defined in role manager (we’ll talk about this next month).

The groundwork laid now will make it easier is to spend time learning how transfer information is entered into the HR system. How does the system find out about transferred users, and when is the information typically entered into the system (consistently before or after the actual transfer date, and if after, how long after)?

HR *should* care about the accuracy and timeliness of transfer data since this could impact pay. If they’re sloppy about this, hopefully they’re working to fix it. Maybe the questions of the identity management team will provide extra incentive to get their cleanup done.

Another proactive step that can be taken, although it is not related to the HR system, is to find out what is acceptable in terms of access retention. For example, if there are segregation of duties concerns with a transfer, are there allowances for job transfer, or are there absolute rules that one type of access may never be granted while another type of access is in place? If a clean break is expected most or all of the time, this actually simplifies the workflows tremendously.

HR transfer vs. access transfer

This is the hard part, and what makes it so hard is that it requires the identity management team to become knowledgeable about the inner-workings of the HR database structure and data flows.  But for that to happen, the identity management team needs to get the HR administrators up to speed on how identity management needs to use their data. You will be talking in access terms, they will be talking in HR terms. You’ll be using the same words, but they have different meanings. So when you think you’ve come to an understanding, you may well find out that you didn’t. The best way to avoid such misunderstandings is by conducting a series of good old-fashioned whiteboard sessions – in person (if possible), with sleeves rolled up and some snacks to keep the energy flowing.

The goal of this exercise is to identify how to accurately flag transfers to minimize both false positives and false negatives.

For example, if a user’s job code changes, that’s a clear indication of a transfer. But, clerks in Accounts Payable and Accounts Receivable might have the same job code because from a payroll perspective it’s the same job level in the same department. So if the only criterion is job code change, critical access transfers could be missed.

But what if you add manager to that? Then, a user with an unchanged job code might be flagged as transferred because their manager has changed. But is that because the previous manager quit and the employee got a new manager, or is that because the employee moved from Accounts Payable to Accounts Receivable?

There are two HR elements that always indicate an access transfer, but each can lead to false negatives on their own because access transfers can happen within these elements:

• Job code change
• Department change

There are three additional HR elements that *could* indicate an access transfer, but each can lead to false positives – sometimes these elements change administratively without affecting the employee’s access needs:

• Manager change
• Cost center change
• Location/facility change

The trick is working with the HR team to figure out what combination of the above attributes will yield the most accurate results on a consistent basis. Leverage their expertise to understand what could happen in the system, and work through the scenarios. If as an organization you’ve already mapped out segregation of duties rules, be sure to walk through those specific job functions and determine how transfers between them can be identified in terms of the HR data.

In complex organizations, there will be a subset of HR transfers that cannot be accurately addressed from an access perspective in an automated fashion. At a minimum, if the underlying transfer-to or transfer-from job functions can be identified in some way (as a combination of attributes), workflows could be designed to trigger a task to HR to manually indicate whether a transfer really occurred or not.

The good news in all of this is that not *all* job functions need to be analyzed here – only the ones with relevant access. By relevant I mean either complex access for large systems with high turnover (this is where automation brings ROI), or access that the auditors care about (so it has to be right).

Make no mistake – it’s a lot of work to get transfers set up, and we haven’t even gotten to the part about configuring identity manager. We’re still in the data mapping stage. But, this work has a big payoff – being able to automate transfers saves end users and their managers time (from not having to manually submit transfer requests, getting access cut off too soon, or getting the wrong new access), it saves the access services team time when the auditors come knocking (in terms of providing evidence), and it will definitely make for cleaner audit results (which could save money in terms of fines and penalties).

In the next article, we’ll end the lifecycle by looking at terminations.

This underscores the importance of engaging in this conversation now. Large organizations often find it may take months to build the inter-team relationships and map the data.

So let’s start at the beginning of the employee lifecycle – new hires.

But before we begin – was that HR system, or systems?

I keep using the term “HR system” implying that there is only one. The reality is that many large organizations have more than one. Worse, organizations that have multiple HR systems don’t always have multiple instances of the same product – they actually have different products.

If you find yourself in the multiple HR system boat there’s actually an organizational decision that needs to be made, and it will depend on HR’s technology roadmap: should identity management be integrated with all HR systems, or is there any plan to consolidate the HR systems?

The rest of this month’s articles should apply to the HR system(s) that will be integrated with identity management. If there are multiple systems, hopefully they’re set up kinda sorta similarly so that there’s at least a lot of reuse in the processes and data mappings.

What about recruiting?

Something else to consider: are job candidates tracked within the HR system, or is there a separate recruiting system? If it’s separate, does it interface with the HR system?

More on this in a minute.

And non-employees?

Some companies track their non-employees through the same HR system as employees. Others have a separate database. Still others have nothing.

If your non-employees are tracked through the same HR system as employees, consider if it’s easy enough to include non-employees in the first round of effort, or if it’s best put off for a release 2 effort.

If there is a separate database, it should definitely be a release 2 effort. If there’s no repository, this is a can of worms that we’ll discuss later this year – leave it alone for now.

Getting back to new hires

Getting a new user set up can be pretty complicated – computer, access, cube/office, desk phone, wireless device(s), badge… If there is a standard request process, it’s at best a long consolidated form to fill out and at worst a ton of phone calls. There is added complexity from things like:

• Knowing the correct spelling of the new person’s name, as well as their preferred name(s)
• Knowing exactly what access they need
• Knowing what “things” they’re entitled to (do they get a cube or an office? laptop or desktop? buy the computer new, or use the one that was turned in by the previous employee? cell phone or pager?)

Submitting new user requests is a time-consuming process that can waste cycles for others if the wrong things are requested. Having new users sit around and wait for their stuff (either because a request didn’t get submitted soon enough or because the wrong request was submitted) is also a waste of time – and money!

As such, new user provisioning is a great opportunity for automation – auto-provisioning what can be auto-provisioned and auto-assigning tasks to teams for whatever manual provisioning needs to be done.

How much auto-provisioning and auto-assignment of initial access and equipment can be done for new hires will depend on how much information can be made available to identity management on or before the person’s first day of work.

Is the employee entered into the HR system on or before the first day of work?

If yes, great! When exactly?

• If it’s as soon as the employee accepts the offer, that’s ideal – normally that will be enough time for all manual tasks to be completed comfortably.
• If it’s on the first day of work and the employee is expected to go through some sort of orientation, the teams that do manual provisioning may have to scramble, but there’s still an opportunity to get initial access and equipment provisioned before the user needs them.

If no (or it happens on the first day of work but the employee doesn’t go to orientation), there are two options:

1. Create a new (or use an existing) request process that will allow identity management to  manually receive the new user’s information, and let the workflows kick in from there
2. Consider leveraging the recruiting system (whether it’s a module of the HR system or a separate system) to get the information sooner. Since identity management will need to know some information that does not normally pertain to HR, it might also be beneficial to look into adding some fields that will facilitate auto-provisioning, like what the user’s cube/office or phone number will be.

Both options have their pros and cons:

• Option 1 is easier to set up, but it requires manual intervention from the end-users submitting the requests, which can be error-prone. It also results in orphaned accounts in identity manager that then need to be linked with the corresponding HR record. The linking process can also be error-prone, with potentially disastrous results.
• Option 2 takes a lot more up-front effort, both in terms of adding fields to the recruiting module or system to accommodate identity management needs (if applicable) and certainly in terms of interfacing the recruiting module/system to identity management in addition to the HR system to automate the linking process. Updates may also need to be made to the interface between the HR system and the recruiting system, if they’re separate. On the other hand, the accuracy of linking is guaranteed, and user error and time are eliminated from the process.

Of course, I’m omitting a big piece here – for any of this to work, there need to be roles and rules created for identity management to ensure that the right auto-provisioning and auto-assignments happen. But that’s next month’s topic.

In summary

To be able to manage new hires in an automated fashion, some pre-work needs to be done with the HR system and administrators, as follows:

1. Build the relationship, but expect resistance – HR functions are so highly regulated that they won’t jump at the opportunity to change their processes or data
2. Determine if identity management will interface with one HR system, or several
3. Determine if employees are entered into the HR system in a usable timeframe for auto-provisioning/auto-assignment
   1. If not, determine how the recruiting module or system could be leveraged to fill the gap
4. Decide if non-employees could and should be handled as part of the initial implementation, or if they come later
5. Determine if it’s possible to add fields to the recruiting module/system that can drive auto-provisioning/auto-assignment

In the next article, we’ll cover the largest and most complex part of the employment lifecycle: transfers.

Developing user training

Unless you’ve already worked with Michael, chances are that the users at your organization don’t get passwords. This is common: users don’t understand why passwords have to be so complicated or how to effectively transform the rules they are taught into memorable, usable passwords. Go straight to automation with this type of user base and the help desk calls will increase – guaranteed.

The reality is, users will do what’s most convenient to them. If accessing a self-service website is faster and easier than calling the help desk and sitting on hold for a few minutes, they’ll do it. If they have to spend time looking for the site, or if they get frustrated trying to figure out their initial password or how to register questions, they’ll call the help desk instead.

The only way to be successful with a password self-service implementation is to thoroughly train the users, and make it easy for them to use the system. This means:

-        Making sure everyone knows what the password rules are

-        Putting links to the self-service page everywhere you can so users know how to find the page

-        Communicating how the challenge questions work and how to answer them

-        Testing the site on all browser types that might be used to access the self-service site (or clearly communicating which browser types are supported)

-        Helping users understand the limitations of the system (e.g., will the tool be available outside of the corporate network or not?)

Also consider the overall computer literacy of your end-users. Are you rolling out password complexity to some of your users for the first time as part of this implementation? Have those users ever used a computer in a corporate environment? Are they likely to be a computer user at home? If the answer is no, consider a basic computer literacy course first – if they don’t even know how to use a mouse, asking them to come up with an 8-character password with a choice of upper- and lower-case letters, numbers, and punctuation marks will throw them for a loop.

Delivering user training

Spend time delivering the training you’ve developed in ways that work for the users. This may include in-person sessions as well as web-based training. Get management involved – make them early adopters of the system, and have them encourage their departments to participate. Establish a process to ensure that new hires receive this information as part of the standard onboarding sessions. Make sure the training is easily accessible to anyone who needs a refresher. Above all, make sure that end users get the support they need to transition to the new way of doing things – this may entail a little extra up-front work from the help desk, but whomever provides that support needs to be well-versed and make it easy for the users to understand.

Populating the requirements list

At a minimum, this month’s exercise should feed some requirements around challenge questions – how important are selectable questions to the organization? Are one-size-fits-all questions acceptable?

If there are plans to auto-populate the challenge questions from HR, there may be some requirements around the HR integration with identity manager. There may also be requirements on how to get even transient HR data to auto-create initial passwords, if that’s desired.

There may also be some implementation notes – fields that need to be accessible from HR, final challenge questions agreed-upon by the focus group, etc.

Action Recap

This month’s actions are focused on preparing for a successful password self-service implementation:

1. Review and update the password governance documents to ensure that the same password rules apply to all systems and all users
2. Determine how to handle challenge questions and come up with appropriate questions (if needed)
3. Develop and begin to use an initial password formula
4. Develop and thoroughly deliver end-user training, taking the level of computer literacy into consideration
5. Keep the users in the loop – communicate the changes, explain why they are being made, and begin using the new materials (e.g., initial password formula) as soon as possible so they get used to it

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

Initial passwords

All users are assigned an initial password of some sort, which must be reset at the first login (our systems are all configured to force the user to reset their password at first login, right?). How the challenge questions are implemented will determine how the initial password is set up. There are two choices:

-        If users are required to register answers to challenge questions, they need to know their initial password

-        If users’ answers to challenge questions are auto-populated from the HR system, they don’t need to know their initial passsword.

Let’s take a look at both options…

Auto-populated answers to challenge questions

Let’s start with the easy one. If HR elements will be used to auto-populate the challenge questions for the user, then a completely random password can be generated and assigned to each user. The user should then be directed to the self-service site to reset their own password.

Clearly, the auto-populated answers option is the best choice, if it is possible. Not only does it avoid the need for mass communications and compliance to get users to answer their challenge questions, but it eliminates the need to communicate an initial password. The organization also has somewhat more control over the quality of the answers. All of these things help on the security front.

User-answered challenge questions

Now for the next best option, which may be the only option for many organizations (sorry). When users are required to register challenge questions before using the self-service system, then they need to know their initial password. While it may seem like a recipe for disaster, there is benefit and time savings to automating the initial password (especially if you have a very large workforce with a high turnover, as we do at our retail stores).

Consider creating a formula consisting of HR elements so that a unique password can be auto-generated and communicated to users via rules. Elements such as date of birth, initials, date of employment, and middle two digits of social security number (among others) can be used to create the formula (special characters or capitalization can be added if needed to ensure the proper level of password complexity). Since the initial password will be used soon after it is generated, elements with long-term risk of change such as street number of current address could also be used. That’s what makes automated initial passwords easier than automated challenge question responses – because the passwords are used soon after time of hire, and only once, you can get away with using data elements that might not be appropriate for answers that persist indefinitely.

The generated password should be cumbersome and unfriendly enough to encourage the user to register on the self-service system and use it to change their password to something more memorable and desirable, but not so complicated that they can’t get it right and end up calling the help desk. Regrettably, this is much easier said than done – more on that in the next article.

If a formulaic initial password is new to the organization, begin using it as soon as possible to get users in the habit. Have your access services team being assigning the initial password per the formula on all new access requests submitted by the users – getting them used to seeing the formula and resultant password will help them transition to the self-service tool. Of course, what I’m describing here may require some work with HR or others to make the necessary data elements available to the people or system that will be auto-generating these passwords.

Now that we have updated password governance, appropriate challenge questions, and a strategy for setting initial passwords, we are ready to start training the users and wrap up the month’s activity. That is the topic for the next article.

Challenge questions – definitely a double-edged sword

A key benefit of any password self-service system is the “forgot password” feature. If a user forgets their password, they click on the link, provide their userID, and are prompted to answer some personal questions to authenticate themselves. If they can answer the questions correctly, they are allowed to reset their password.

This is a big cost savings for most organizations – and a big convenience for users when implemented properly.

It’s a simple concept, but coming up with the right questions can be surprisingly tricky. Here are a few things I have learned while implementing password self-service:

• In reality, users can answer whatever they want to the questions, as long as they remember the answer. Most users don’t realize that and assume they have to answer truthfully, so if they are presented with sensitive questions like mother’s maiden name, they may choose to not use the system rather than make something up.
• It is human nature to remember things that are meaningful more than things that aren’t. If the user is presented with a question that doesn’t have meaning to them – or whose meaning changes over time – they could probably make up an answer, but they might not remember it later.
• If the answers can be easily researched or guessed, the system can be readily compromised. Unfortunately, easy to remember is often synonymous with easy to guess, socially engineer, or research.

Picking the right questions

So what is the best way to develop the questions?

First, determine if there is enough information in the HR system to eliminate the need for developing questions. The easiest way to handle password self-service setup is to auto-populate answers from an HR system so that users don’t have to register answers to questions before using the system. Also, the HR system can continue to update the answers if any of them change over time, allowing for less confusion on point-in-time questions. In this case, care should be taken to avoid asking questions that coworkers would easily know the answer to – such as employee numbers, email addresses, and birthdays. Also keep in mind that the full social security number (or even last four digits thereof) is considered to be a restricted data element that should not be stored in an identity management system.

Although using HR data can be a very simple and effective way to set up the challenge questions, many companies will find that there is not enough usable information in the HR system to make this work – the answers have to be private enough so that others can’t guess them or look them up, but common enough so that the users themselves will know and remember them.

So back to our original question – what is the best way to develop the questions?

Answer: Set up focus groups. Engage HR, InfoSec, management from various areas of the organization, and a sampling of different types of end users to help create questions, and to test their usability. It will be the job of InfoSec to make sure that the questions aren’t too easy to guess or research, and HR will ensure that the questions aren’t offensive to anyone (or violate union-related restrictions, if that applies).

Hopefully, the self-service system allows users to select questions they feel comfortable answering from a larger list. If that’s the case, it greatly simplifies things for the design team because it allows for the creation of a number of questions, and each user can select the subset that they feel is most appropriate for their experience. In fact, organizations that do not yet have a technology selected should add “user-selectable challenge questions” to the requirements list and weight the importance on the higher end.

Some systems, however, don’t allow for question selection – all users have to answer all of the questions presented, which creates an additional layer of complexity:

• The popular questions (mother’s maiden name, city of birth, etc.) are also available as public record – if someone wanted to know that information badly enough, they could find it (this is true regardless of the selectability of questions to answer)
• “Favorites” (favorite movie, favorite food, etc.) can change over time, or they might not apply to all users (e.g., I don’t have a favorite sport so when I’m asked that, it’s hard for me to come up with a memorable answer)
• Family questions can be problematic in this day and age: not everyone has a spouse or a child and increasingly, not everyone has two parents
• Residence questions are more difficult these days: people move around a lot more than they used to
• Education questions can also be problematic. For example, I work in retail and we have a fixed-question system. Some of our employees are high school students, so we can’t ask about high school graduation. Many of our employees have never gone to college even if they are old enough, so we can’t ask questions about that, either.

When faced with a fixed question set, guide the focus group to come up with point-in-time questions that avoid the problems above. For example:

• On what street were you living when you turned 16 years old? (Rarely will there be an employee younger than 16, this level of detail is hard to research, and it allows for multiple residences at that age, but it may also be difficult for the user to remember)
• What is the name of the first high school you attended? (Doesn’t imply graduation, and also allows for attending multiple schools)
• What is the first name of the person who primarily took care of you as a child? (Could be confusing for someone who had two engaged parents, but this question does not imply parents, and it is hard to research. It could be easy to guess by coworkers who get to know the person)

Once the questions are finalized, communicate them to the end-users so they become familiar with the concept. Even if the self-service tool implementation is a few months out, it’s never too early to engage the end users

In the next article, we’ll develop a strategy for creating initial passwords.

But before we jump in on the password self-service technology, let’s set the people/process foundation. The first step is effective password governance via policy and standards. I hear the groans, but no worries – I promise it won’t be that bad.

Governance Primer

The terms “policy,” “standard,” and “guideline” are often misused. In an effort to set the record straight and make sure that for the purposes of this series we’re all on the same page, let’s review the terms and their definitions.

A policy is a terse, high-level document that specifies what must be done, but not how. A company typically has one all-encompassing security policy that covers a variety of topics: identification, authentication, authorization, etc. The security policy should be fairly short and refer significantly to other documents for details. It also uses authoritative words like “shall” and “must” and avoids conditional words like  “should” and “guideline.” Since policies are high-level, they should stand the test of time without requiring much revision.

A standard is a prescriptive document that explains how the policy statements will be implemented given certain conditions. While they can be short, they tend to be longer than policy documents (since there is often a lot more ground to cover).  For example, if the policy specifies the need for system hardening, the organization might need to create hardening standards for each of the platforms in use (e.g., Windows, UNIX, etc.), and/or for the specific usage of each platform (e.g., hardening standards for DMZ systems, hardening standards for financial systems, etc.). Standards are often technology- or concept-specific, and require more frequent update over time to keep up with changing needs and upgraded system versions.

A guideline is a primer that can help users or administrators apply the standards. It provides educational guidance, and sometimes also includes “nice to haves” that can’t be supported technically.

There is one other document type: a procedure. Procedures simply provide step-by-step instructions on how to implement a particular instruction that is set forth in the standard – for example, there may be a procedure on how to access and configure the UNIX password settings.

Guidelines are suggested, procedures are mandatory.

Building password governance

The growing list of compliance requirements (PCI, SOX, HIPAA, etc), combined with the varying capabilities of an organization’s technologies (those legacy dinosaurs probably have a lot of limitations) have often translated into different password settings on different systems. For an effective password self-service implementation, this has to be reversed – consistency across systems is imperative.

So let’s work through the governance hierarchy as it pertains to passwords, starting at the top.

First, review the corporate password policy and ensure it covers these concepts with appropriate wording:

• Password standards are enforced consistently across the enterprise (i.e., although the system may not be able to technically enforce an element, it can accept use of the element)
• Password standards shall comply with the corporate policy and also ensure compliance as required by applicable external regulations
• Where technically feasible, centralized authentication must be used (e.g., directory authentication) – this will bring the organization closer to SSO over time

Next, review the corporate password standard(s) (note – some password elements may be part of hardening or other system standards) and ensure that the following elements are clearly specified:

• Minimum length must be lowest common denominator that is applicable to all systems and that still complies with regulatory requirements
• Complexity must comply with regulatory requirements and be supportable by all systems (if not enforcible, at least usable)
• Minimum/maximum age and history – including non-technical enforcement mechanisms for those legacy systems that do not support these elements
• Password rules don’t vary for different user types (e.g., employees, administrators, contractors)

Finally, ensure that any guidelines or procedures related to passwords align with whatever updates are made to the policy and standard(s).

If updates were made to any of the governance documents, be sure to communicate the changes to the user base and help them understand why the changes are being made. Although some may balk at the change, most will recognize that the move to consistency will actually make their lives easier. Also be sure to explain that the changes were made to prepare them for the new features that will come, which will further improve their experience.

In the next article, we’ll discuss developing challenge questions.

By now, you’re so sick of userID cleanup that you’re probably wondering why you didn’t select a more pleasant career – like tax collector. The good news is that if you’ve made it this far, your userID cleanup days are over! Congratulations on defeating that monster – it was a big one! As long as processes are in place and being followed to keep the data clean until identity management takes over, you’re home free on userID management. Unfortunately, there are other types of cleanups yet to be done, but those come later so let’s not spoil the moment.

Why all the painful and tedious cleaning and prep with no apparent return? In my experience, the organizations that avoid instant gratification syndrome by taking the time to build a solid foundation run smoother and faster during the balance of the implementation. It all boils down to investment – and paying some dues.

Having a clean user base sets the needed foundation on which to build productive functionality like password self service, which is this month’s topic.

Introducing password self-service

Password self-service is identity management functionality that enables end-users to reset their own password should they forget it. This is done by having the user register (or pre-populating from HR records) answers to some personal questions. If the user forgets their password, they simply click on the “forgot password” link, which takes them to the self-service page. The user supplies their userID and then they are prompted to answer a subset of the questions. If they answer correctly, they are allowed to reset their password. This is common practice on most banking sites, so most of us are familiar with this technology – at least from an end-user perspective.

Password self-service is considered by many to be a good first step in the identity management journey since it promises a significant return on investment (ROI) – done right, it can reduce calls to the help desk by as much as 40%. But only if it’s done right. Proper planning and implementation are critical to successful password self-service. Fail here, and the number of calls to the help desk can actually increase!

The dream of Single Sign-On; the realities of passwords

Let’s talk for a moment about Single Sign-On (SSO) – the holy grail of passwords. Conceptually, SSO means that a user logs in once in the morning, and then all other logins that they’d normally have to perform throughout the day are handled magically (and hopefully securely) in the background to save the user a lot of brain cells in remembering various passwords, and time in typing them. Nice idea, but in practice single sign-on simply does not exist.

Today’s reality is reduced sign-on – meaning, there is some background magic, but the biggest part is just having synchronized passwords across the environment, and/or encouraging/enforcing the use of directory-based authentication. Both of these practices achieve the same result: only one password to remember instead of many. Users still have to type their password in when prompted, but they only have to remember the one password.

As we focus on password self-service – which allows for synchronization and resets on the primary directories – it is natural to be lured by the sweet song of SSO, but resist the urge – believe it or not, SSO has little or no ROI.

How is that possible?

What costs money is the time spent by help desk personnel in resetting passwords – on average it may take three minutes for a help desk representative to reset one password, and a large company may get thousands of calls per month. Actually typing in known passwords takes very little time – let’s call it five seconds per typing. If a user has to type in their password 10 times per day, as long as they know the password this amounts to less than one minute per day of effort. Unless the organization is just that high-performing that an extra minute per day matters, the ROI is negligible when compared to the cost and effort it takes to fully integrate the systems to enable SSO.

Now, if a full integration is warranted for other reasons – like auto provisioning/deprovisioning and user recertification, which have a positive ROI – SSO can be a nice added bonus. More on this in August.

Approach

The key to a successful password self-service implementation is having underlying processes that can handle being automated, and also making sure that end-users understand what to do, why, and how. This means:

1. Having an appropriate password policy
2. Determining usable challenge questions
3. Creating an initial password formula that works
4. Developing a robust training plan for your users
5. Training the users

Each of these processes has some nuances and gotchas that – if properly handled – can really ease the implementation. We’ll get started with password policies in the next article and cover all five processes over the course of the month.

Did last month’s exercise of mapping primary userIDs kill you?

Is it still killing you?

Unless a number of full-time resources were allocated on a project basis, the cleanup for a large organization can easily take months to complete so if you’re still working on it, don’t worry – you’re not alone!

That said, we need to move on so join us when you’re ready.

The Purpose of Secondary userIDs

Once the primary userIDs are mapped, it is time to continue on with all of the other userIDs in the organization – the ones for the systems that were identified as “secondary” (Priority 2) in January’s exercise.

Secondary systems are systems that need to be integrated to some degree with identity management, but they were deemed “secondary” because the integration might be complex, the system is important but doesn’t have that many users, or the system may be too old to integrate.

There is also another type of secondary account – one most often associated with mainframe or administrative accounts: additional IDs belonging to the same person on a single system.

There are a variety of reasons for this: in some cases, a user of a system may also be an administrator, and there is a security requirement to keep the permissions separate. In mainframe environments, multiple IDs may be needed either because a user has too many permissions to “fit” on a single ID (there are ways to fix this, but that’s outside of the scope of this discussion), or because users need access to the same data for different regions, and switching “views” within one ID is too cumbersome.

There could be other reasons for having multiple IDs on a single system, but the end result is the same: if any user has more than one ID on any key system, that ID needs to identified and linked to the user’s primary account. Otherwise, there will be gaps in the integrity of the identity data.

The task at hand

Cleaning up and mapping secondary userIDs is similar to cleaning up and mapping primary userIDs. The only difference is that the target systems are different. As a result, this effort may be easier…  or harder than the previous one.

Here’s why:

Smaller systems might be easier to map

Systems with fewer users are generally easier to keep clean, and they’re maintained by fewer administrators. There is also the possibility that the administrators know the users personally. If the Priority 2 systems on the list fall into this category, expect this effort to go a lot faster than the one for primary userIDs.

More obscure systems may not be as well-maintained

When cleaning up and mapping primary accounts, the email system is generally the best place to start because it tends to be one of the best-maintained, and for good reason(s):

1. People use their email all the time, if it’s not working correctly and their name isn’t right, they’re very vocal about it. So users’ email data tends to be very clean
2. Mailboxes take up precious disk space and disk space costs money. Email administrators tend to notice and act on inactive accounts in the interest of saving the company some money

The more obscure systems don’t have these luxuries. They tend to be more loosely maintained. Administrators may not be as rigorous about following up on inactive accounts or configuring the system to auto-disable/auto-delete unused IDs. They may also not follow the company’s naming standard when creating userIDs. The worst part is they likely don’t populate much – or any! – personally identifiable information with the userID.

If the Priority 2 systems on the list fall into this category, expect this task to be as painful as the one for primary userIDs – or worse.

The UNIX environment is a can of worms

(For ease of expression, I’ll use the term UNIX here, but this applies to Linux and really any *NIX environment)

The UNIX environment can be one of the most difficult to clean up – especially at large companies with many UNIX servers – because of the tendency for UNIX environments to lack central user administration facilities. Unlike in an Active Directory or mainframe environment, users are typically added to each UNIX server (or cluster) to which they need access. This causes a user administration nightmare – trying to figure out which users are on which systems – especially when access needs to be identified or terminated. This problem is compounded if there is little or no identifying information with the ID, or if the IDs were created on a first-come, first-served basis.

Here’s a true story to illustrate the point:

I helped a client clean up their UNIX IDs on one of my first identity management projects. At the company, there were (among others) three UNIX developers named Trong Nguyen, Trung Nguyen, and Tran Nguyen. Their IDs were tnguyen, tnguyen1, and tnguyen2. They requested access to different UNIX servers at different times, depending on their project needs. The UNIX administrators were in the habit of assigning the next available userID on each server to users as they requested access. As a result, my mapping matrix looked something like this:

In reality, each developer had access to over 25 servers, and they themselves didn’t know which ID they were assigned on which system. To make things worse, their names were not registered with the userIDs, so the only way to figure it out was by trial and error.

UserID correlation is just one problem in the UNIX environment – identifying unused accounts is another. Many n-tiered applications that run on a UNIX infrastructure require the user to have a UNIX account on the underlying servers for the application access to work, but the user only ever logs into the application – not into the server. As a result of this, the UNIX account is never used, nor is the password ever changed. This necessitates changes to the password expiration configurations on those servers, and it precludes auto-disabling/auto-deleting inactive accounts. As a result, it is much easier to accumulate old accounts, and much harder to identify truly inactive IDs.

UNIX also seems to be an environment where developers use their own ID to run batch jobs (instead of requesting a system account for that purpose). The developer leaves the company, but the batch job persists. Disable the ID, break a business function. So then there’s the added work of identifying the job and what permissions it needs to run, creating an appropriate system account, changing the script to reference the new ID, and then finally doing what really needed to be done – cleaning up the userID.

In all fairness, this happens in all environments, not just UNIX, but this is where this information fit in the grand scheme of things.

Did I mention UNIX UIDs?

In addition to an administrator-assigned userID, UNIX systems also automatically generate a numeric UID for each user. What many companies realize too late is that if UIDs aren’t expressly managed, each user will be assigned the next available UID on each server, much like the tnguyen situation I describe above. Having different UIDs on different systems significantly complicates the integration between identity management and the UNIX environment. This situation must be rectified before the integration can occur.

The solution is fairly simple to design but tedious to implement – just like everything else in this process. Basically, you pick a high-enough UID that there is space between any existing UIDs and it, and use that as the starting point. Then you assign a new UID to each user and ensure that that UID “sticks” across all servers. You also design a process to ensure that once a user gets assigned a UID, each UID becomes reserved for the assigned user across all servers.

The details of this process need to be discussed with a good UNIX engineer and the implementation – although it will take time and planning – should be transparent to the end users.

Another note on UNIX integration

Although it’s entirely possible to integrate identity manager directly with the UNIX farm, it’s not the most efficient or cost-effective way to go about it as it would require a separate integration with each server. There are products out there (the one I’m familiar with is Likewise) that will LDAP- or AD-enable UNIX user management so that the existing integration between LDAP or AD and identity manager can be used. There are also products that allow similar functionality between UNIX and mainframe tools such as RACF.

If UNIX is a large component of your environment, start looking into products that will facilitate the integration with identity manager now.

Approach

The approach for cleaning up secondary userIDs is the same as what was outlined last month for primary userIDs. Remember to communicate frequently and clearly with the impacted users and their management, and don’t be afraid to disable IDs (in an organized way, of course) if all other avenues of research have failed.

Parking Lot

There’s a good chance that this second round of cleanups will uncover more interesting issues – as I advised last month, take the time to do something about it.

Updating the requirements list

If a UNIX-identity manager integration is in scope, start planning now. Research integration products and determine if they are appropriate to implement. If not, be sure to update the requirements list to ensure that UNIX integration requirements are captured.

Action Recap

This month’s actions are very similar to last month’s, just on different systems:

1. Identify the secondary IDs, and determine who owns each ID
2. Identify and retire obsolete IDs
3. Connect secondary IDs to the primary IDs
4. Develop (and use!) a process for keeping the IDs clean until identity management can take over

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

clean the data

So roll up the sleeves, find the glasses, and brew a lot of extra-strong coffee – it’s time to tackle those primary userIDs.

Primary userIDs – what are they?

A primary userID is the main ID that each user has in an organization. This is the one ID that they *should* have on all systems, although that is often not the case. Typically, the primary ID is the user’s network ID – that is, the ID that each person uses to log into their computer in the morning, and probably also to log into their email. Many organizations call this the LDAP ID or (for Windows-heavy shops) the Active Directory ID. Organizations that are mainframe-heavy might store their primary IDs on the mainframe.

The task at hand

On the surface, this month’s activity is simple: correlate each user’s primary ID with their name and other identity information, as this will be the basis for the identity repository going forward. Hopefully everyone’s primary ID is already stored electronically somewhere (at least in a spreadsheet) and there is some useful data already associated with each ID – like a name, an employee number, or other identifying information. If not, well, that’s where the extra-strong coffee comes in (or maybe decaf would be better?).

The task may be easy to describe, but there are three significant challenges in this cleanup process:

Challenge #1: mapping primary IDs to people

It is likely that the list of primary IDs (assuming it exists) is missing information, or has data that’s so outdated as to be useless. Worse still is a list of IDs without any information (who are bassfisher68 and jedimaster84?). Equally frustrating is the same-name problem: how many John Smiths, Trong Nguyens, and Juan Gonzalezes are in your organization… and whose name goes with which ID?

Challenge #2: are they even still here?

It is often hard to map IDs to people when the ID has persisted, but the person is long gone. Even more doubt is created when the ID belongs to someone with a common name.

Does jsmith3 belong to that contractor that was in here 2 years ago, or does it belong to the guy downstairs in accounting?

A nasty – but necessary – part of cleaning up primary IDs is identifying orphaned accounts that should no longer be active. On the upside, this is a healthy security exercise that often gets put off – after all, who wants to deal with the screaming users when the wrong IDs get disabled? But for identity management to work, this HAS to be done – no more excuses or avoidance!

Challenge #3: mapping primary IDs to primary sources of record

Once the IDs are mapped to the correct names/people and orphaned accounts are retired, it’s time to map the IDs to the corresponding accounts in the sources of record that were identified in last month’s exercise. Remember, identity management is just a facilitator of actions. A key integration is between identity management and the HR system, as that enables the automation of access creation and removal based on hire, transfer, and termination events in the HR system. Identity management can also facilitate the auto-provisioning or password self-service of a user’s other accounts (like email) based on proper linking.

The biggest difficulty in this exercise is typically matching the userID with the right HR record, due to potential differences in legal vs. preferred name. Very often, email addresses and userIDs are set up based on the individual’s preferred name (e.g., Mike, Trish, Betsy), whereas the HR record will contain their legal name (e.g., Michael, Patricia, Elizabeth).

Is Mike Smith the same guy as Michael Smith – or not?

Guessing is not allowed here – matching up the wrong user with the wrong HR record can have very serious consequences. HR doesn’t take kindly to people seeing each other’s salary information. Getting someone else’s email is generally frowned upon as well, especially if some new junior analyst was confused with a senior VP (believe me, this has happened more than once!)

Approach

There is no *right* or *easy* way to execute this cleanup.

With little starting information and/or a large user base, this will be a painful and time-consuming process, but here are some things to help get organized:

-        Determine the data set that is needed. Make sure it is the bare minimum to start because once identity management is implemented and the records are linked, a lot of additional information will populate automatically. The goal here is to identify which data points are needed to accurately link records between systems – nothing more

-        Start with the cleanest source of record to build some momentum. While this is often the HR record, sometimes email is the best bet. Other sources may also be appropriate (like the mainframe). In general, the cleanest sources of record are ones that are carefully controlled and well automated in a database or a repository.

-        Enlist the help of someone good at scripting to automate some of the searches and comparisons. Done right, this saves immeasurable time!

-        Communication is key!

• Make sure the user base knows a cleanup is underway and why it benefits them
• Solicit assistance from department heads – they can help identify users and their correct/current information
• Ask the leadership to alert their people that they may be polled for information, and specify the name of the team that will do the polling (provide the names of individuals if possible). Users need to know that these requests are legitimate and not a phishing attempt (especially if they just attended training on phishing or Michael has already worked to improve your awareness program)
• Communicate the cleanup process to the leadership so they know the who, what, where, when and why of the effort. This is especially important when the team ends up with a pool of orphaned IDs and no other means of research. The only remaining option is to deactivate those accounts and see if anyone complains. Management needs to understand and support this decision before it can be executed

-        Don’t be afraid to disable IDs if reasonable research has not yielded results. Researching identities is extremely time consuming – there is a point where enough is enough, and the security risk to the company should outweigh the brief inconvenience that a handful of users may experience

-        Engage HR representatives and local technical support personnel. They tend to know the users personally, and can be of great help identifying them

If existing records are already in pretty good shape, sit back and smile smugly while everyone else beats their head against the wall for a while.

Keeping it clean

If there is no current identity management system in place, it is important to keep the new repository of primary userIDs reasonably clean until the new system is in place. Otherwise this fun exercise will need to be repeated.

Staying up-to-date manually requires a process to keep user data in good repair but the process should not be complex or labor intensive. Do the bare minimum necessary to keep the data decently clean. It’s OK if it’s not perfect – a small final cleanup is inevitable.

A word about userID naming standards

If this process reveals the lack of a userID naming standard, or a standard that no longer makes sense for the organization, this is the right time to establish a new, sensible one. This is a large and painful exercise in and of itself, but it is far better to enter into an identity management implementation with a solid and appropriate naming standard than to try to fix it later.

Here are the things to consider:

-        Grandfathering existing users vs. making them change their ID to match the new standard

• Unless there are specific technical reasons for converting everyone, I recommend grandfathering. A primary ID can be created in identity management in the new format and mapped to the untouched existing IDs. This meets the needs of identity management while minimizing impact on the users

-        Helping users with multiple ID formats across various systems consolidate to one ID format

• Although this can be a little painful, many users are happy to undergo the initial challenge in exchange for not having to remember which ID to use on which system

-        Having different ID formats for employees vs. non-employees

• I recommend not doing this. Having visual segregation of ID is much more important in a manual paradigm. With identity management there are many ways to identify a user’s employment status without segregating by ID, and having different ID formats causes more problems than it solves

-        Make sure that the selected format will work on all systems – including those legacy dinosaurs with all their length and character limitations

-        If you choose to have userIDs based on name, establish a clear policy about changing the ID in the case of marriage, divorce, sex change, etc.

• Changing someone’s display name is easy. Changing their userID can be tricky, because on many systems this isn’t possible –the old ID has to be deleted and a new one created, which leaves a lot of room for error in copying permissions, files, scripts, etc. However, some people feel very strongly about their name, especially after a nasty divorce or a sex change, so there has to be a provision for this

-        Make sure the new naming standard scales adequately for the expected growth of the company, and that it addresses situations where users may need more than one ID, or where individuals have the exact same name (possibly even same middle name or middle initial)

Parking Lot

Doing a userID cleanup of this nature can uncover all kinds of interesting issues – like fields being used to store data that they were not meant to store, IDs being created through unofficial channels that probably shouldn’t’ve been created, etc. Some of these discoveries might be security risks, some might just be sloppy administration, and still others might impact the identity management implementation down the road. In any case, it is important to document these discoveries along the way and do something about it – even if that something is just notifying the responsible manager.

Action Recap

This month, we covered the following key actions:

1. Identify the primary ID, and determine who owns each ID
2. Identify and retire obsolete IDs
3. Connect primary IDs to the appropriate records in the target systems identified in last month’s exercise
4. Develop (and use!) a process for keeping the IDs clean until identity management can take over
5. Make sure the current ID naming standard is adequate and fix it if it isn’t

None of these actions is quick and easy, but getting them done sets a firm foundation for a successful identity management implementation.

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

A common statement an auditor hears is, “our IT department is mature; we have everything we need for an IT Audit.”

A common thought an auditor thinks is, “yeah, right.”

So which of these statements is more accurate? More importantly, which one increases or decreases risk?

Without creating a laundry list, let’s take a look from the auditors’ perspective by breaking down the components of compliance into five main domains:

• Logical Access
• Physical Access
• Operations
• Change Management
• System Development

In my last article, I introduced the concept of developing a “Culture of Compliance”  — something to keep in mind as we delve deeper into each section.

Logical Access

Logical access is the way people (employees, contractors, partners) gain access to the systems that process information. An auditor looks for clearly defined and followed processes.

In my experience, this is where IT needs to work with the whole organization on the core of logical access: user provisioning (my fellow contributor Ioana Bazavan Justus is authoring a great series on Identity Management).

Once defined, logical access must be certified with established tools or a manual effort. The ideal approach is a preventive control that flags segregation of duty access across application systems. Few organizations use this today, but I strongly urge the consideration and adoption of this capability. The more common approach is a “detective” control that works, but requires a significant budget and hours to complete. To be clear, “complete” means re-testing!

Access reviews need to include identification of administrative accounts (including who has access to these accounts) and validation if the level of access is actually required. I recommend not taking anyone’s word for this, test and document it. It is important to have a documented methodology of monitoring administrative accounts and logs to prove it.

Physical Access

Physical access covers access to buildings, data centers and other sensitive areas. The appropriate policies and reviews need to cover the entire process for new hire, transfers, terminations, contractors, vendors, etc. To be effective, this often requires cooperation with Human Resources (HR), Legal, and Compliance and possibly some business units.

Think like an auditor: once access to the data center is documented, reviewed (quarterly) and signed, the auditor(s) will generally pick a terminated IT staff member to audit.

This is where the “culture of compliance” comes in – rather than hoping the process works, it pays to establish an environment where employees take the right actions as a course of action. In this case, it means they log all entry by contractors, vendors and other guests and validate this list against an electronic record of entrance.

A quick sign of success is when even escorted coworkers are asked to sign a log file for entrance into the Data Center.

Operations

Operations are the lifeblood of the organization.

Many organizations have a facilities department separate from IT, which requires cooperation between teams. This is also a reason to have a single person drive the compliance and audit process – to streamline these connections and provide a measure of continuity.

Make sure vendor contracts are in order for the facilities/physical equipment such as fire suppression, heating/cooling and other support systems. When the culture understands the importance of protecting this information, each department will notify others of changes and work together to ensure updates and “coverage.”

Good auditors look to assess if the team has a handle on inventory or manages by incomplete spreadsheets with a hope of accuracy. This is an area where the use of automated discovery tools pays dividends.

Much ground to be covered here, and it must include the details of who, what, where and when of Job Scheduling. Changes to job scheduling is  a process, whether it is for changing frequencies, adding, deleting, and even emergency procedures.

Another area of focus: ensure backup processes are documented, reviewed,  and followed.

Think like an auditor: provide logging details, be ready to explain the job failures and how they are handled! If an auditor asks about failures and the response is “we have none,” it triggers (or should) a lot more questions.

Change Management

In general the key to change management/development is authorizations.

This starts from the top with project approval forums all the way down to and including authorization to put code into production. Each phase, QA, testing, and CM should define requirements, necessary documentations and authorizations. Where appropriate several levels of approvals is required.

Change control is not limited to applications.

Include network configuration (port address) changes and changes to OS configurations need to follow  the change control process. Emergency changes often fall through the cracks of standard procedures. Establish a process that allows flexibility to get the task completed but make sure you have post documentation, and verbal approvals documented after the fact.

System Development

Time to really consider, implement and/or follow SDLC documentation (need a starting point, check out:  http://www.shellmethod.com/refs/SDLC.pdf). Pay close attention to the two primary parties, the end user and developer parties and their responsibilities.

A simple question to start the process: does the current process, what people are actually doing, match what is documented?

In many cases – maybe even most – the answer is either no, or worse, “documentation, we don’t have documentation!” Larger, more mature organizations tend to have a dedicated quality assurance (QA) department that often engages in auditing or assessing the system development process.

In general, workflow applications are great but avoid the concept of “assumed authorizations”. The workflow better meet the documented levels of authorization.

Some people may sneer at the concept of “culture of compliance,” but their personal experiences don’t diminish the importance of engaging people in every aspect of the process – to the point where it is ingrained in the very culture of the organization. The reality is that compliance becomes a process, and the organizations that are focused on engaging their people are able to meet compliance goals without imposing (too many) additional burdens.

Quite simply, this is establishing, nurturing and supporting a culture of compliance.

By considering these five areas, it is possible to provide some structure and ask good, probing questions that lead to conversations that ultimately inform the decisions and actions of others. Change the way people think when developing and making system changes and 85% of your challenges will gradually melt away.

This is simple to test:

1 – Have a manager ask an SE to grant him admin rights, completed with a bit of a story. If the result is a change in access on the fly, there is an immediate opportunity to educate. In my experience, the education might be better as a discussion with questions, as opposed to scolding and “gotcha.” Connecting the person to the consequences of their actions – in their words – goes much further.

2- Ask the customer if they do post implementation testing. Does it meet the initial scope of the project? Are “lessons-learned” documented and kept on file.

3 – Ask the Data Center manager when the next scheduled fire suppressant equipment inspection is due. Not needed instantly but they should be able to produce a copy of the contract and last maintenance records.

What do you think?

Share your challenges, successes or questions about how to effectively drive your audit and compliance program in the comments below.

The biggest mistake that identity management implementers make is biting off way more than they can chew – we all have grandiose ideas of integrating all of the company’s systems and fully automating them, too! It never sounds that hard when the team is sitting around the conference room table, excitedly brainstorming.

Unfortunately, it doesn’t work that way but as it turns out, fully integrating every last system with identity management is a bad idea anyway – at best it will be costly, at worst impossible.

Reality is that most systems will not integrate out-of-the-box. For those that don’t, full integration means extensive custom coding to ensure a comprehensive two-way interface between the identity manager module and the target system. Legacy systems that are particularly “old” (in technology years, that is) may lack protocols in common with identity manager, making a full integration impossible.

The good news is that fully integrating every system with identity management is not necessary to have a successful implementation. The key to success is effectively deciding which systems warrant a full integration, where an indirect interface will work, and which systems do not require any interface at all.

It is important to carefully consider which systems will require integration at the beginning of the process –ideally before the product is chosen or design work is started – as this decision will drive many of the product requirements. This also focuses the data/process cleanup and other preparatory efforts on the right systems at the right time.

A proper prioritization now ensures maximum efficiency going forward.

But first, a few notes…

B2E and B2C

Much of the focus in this series is on B2E (business-to-enterprise) implementations – that is, identity management within the organization for employees and non-employees using company systems.

When appropriate, I will touch on B2C (business-to-consumer) implementations, but in general, from a process and data cleanup perspective, B2C implementations are much simpler. The typical B2C implementation may seem much larger because it has so many users (possibly millions) and there are some additional technology challenges (e.g., ensuring that the user interface works with any browser), but there is usually only one target system (or maybe a couple), and all users get the same permission set. In a B2C environment, it is important to get a few key decisions correct, and then apply them successfully – a lot.

B2E implementations on the other hand have comparatively fewer users but many target systems, and the complexity of permutations of access can be tremendous. Successfully solve the process and data problems in a B2E identity management implementation and there will be few new challenges with a B2C implementation.

Source of record

“Source of record” – sometimes also called “authoritative source” – is the system that is always “right” with respect to a particular data element. For example, the HR system is typically the source of record for employee numbers. If there is ever a discrepancy in someone’s employee number between HR and another system, whatever HR says is the right answer. Similarly, the email system is the source of record for email addresses. For userIDs, identity management is the source of record.

Although this may seem pretty obvious, it can get fairly complex – especially in organizations with multiple HR or email systems that do not interface with each other. Consider creating a map to identify different data elements that will be important in the identity management implementation, and specifying the source of record for each.

Source of record key point #1: Although one system can be the source of record for multiple data elements (e.g., HR is the source of record for title and employee number), there should NEVER be multiple sources of record for one data element (e.g., LDAP and Active Directory are both the source of record for John’s location).

So what is the source of record for userIDs if there is no current identity management system in the enterprise?

Since userIDs are central to identity management, the answer to this question matters tremendously. Maybe initially the “source” is a database or even a spreadsheet – it’s probably dirty data, but it may be all that’s available. Once the data is cleaned and identity management is implemented, identity management becomes the source of record for userIDs.

This brings me to the most important point about identity management…

Source of record key point #2: Just because it’s the source of record (or authoritative source, which makes it sound even more important) doesn’t mean it’s accurate! Identity management is only as good as the data it receives. A key failure of many identity management implementations is not the technology or even the efficiency of the underlying processes – it’s the lack of accuracy in the source data.

I cannot emphasize the importance of clean data enough, and that’s why the next couple of articles will be focused solely on data cleanup. Unfortunately, some data cleanup goes way beyond an identity management implementation. Many organizations find that HR or other source data is at best missing or outdated, at worst outright wrong. That’s a whole ‘nother can of worms that we’ll discuss later.

For now, let’s get back to this article – prioritizing systems for integration/interface with identity management.

Prioritizing systems effectively

Priority 1: Sources of record and other primary systems

There are several key sources of record that must fully integrate with identity management. Chief among these are:

• Human resources (may be multiple systems)
• Directories (LDAP, Active Directory, etc.)
• Email system(s)

Beyond these “universal” systems, each organization will have other essential systems to be integrated. A guiding principle for success is that any system that is a source of record for a particular data element required by identity management should be fully integrated, meaning that there is two-way communication between the target system and identity management, allowing for automation of data exchange, provisioning/deprovisioning, etc.

Any system that is a source of record for key identity management data is considered Priority 1. The list may stop here, or there may be other primary systems that warrant a priority 1 classification. Here are some criteria for categorizing other systems as Priority 1:

• easy to integrate out-of-the-box
• business critical
• large numbers of users with high user turnover

Selecting the right Priority 1 systems makes the project team more likely to experience an immediate benefit in terms of user experience, achieved ROI, and/or increased security/reduced risk.

Priority 2: Secondary, complex, legacy, or small – but still important

Priority 2 systems are on this list for one of several reasons:

• they meet Priority 1 criteria but the integration would be extremely complex
• they’re important systems but there aren’t *that* many users
• they’re important systems but too “old” to integrate

When faced with a Priority 2 system, consider these options:

• create a generic process that tracks what access is granted via identity manager
• identify the information that is needed and how frequently, and design a data export to a simple flat-file that can later be batch uploaded to role manager on a schedule
• spend the extra time and money on a custom integration

The first option – the generic process – combined with manual workflow and a one-time “dump” of users that already have the specified access allows for the tracking and automation of workflow tasks, which is a step in the right direction. But it is very important to know that this solution does not facilitate user recertification, because there is no interaction with the target system.

The second option – flat-file data transfer – is totally unglamorous, but viable. Careful analysis is needed in this case. In some situations, this option is fairly simple to implement, and provides a lot of benefit. In other cases, this option is not much less work than a full custom integration – if that’s the case, might as well go for the whole solution.

Both options preclude auto provisioning/deprovisioning. Only a full custom integration will allow for that, but from a user management perspective, the challenge is doing the right thing at the right time – especially as far as the auditors are concerned. Most often the problem isn’t administrators failing to do their job – the problem is administrators not knowing there is a job to be done. If identity management can initiate the right tasks at the right time, 90% of the problem is solved. Sure, having it happen “automagically” is better, but the most important thing is that it just gets done.

Leaving some out – at least for now

One of the main tricks in the successful implementation of identity management is to know when to say when.

Whether because they’re too old or too small, there will be some systems that just shouldn’t be on the integration list – certainly not now, maybe not ever. The interesting thing is that one or two of those may be “important” systems from an audit perspective.

For example, we have a financial application at my company that is largely automated so it only has three users – we’ve had one user change in the past two years on that system. But it’s on the SOX list and the auditors are always very interested in this application. Even though it’s a critical application, we have no plans to integrate it with identity management. This is an extreme example, but we have another application that is also on the SOX list with maybe 1-2 dozen users. This application is managed by a single administrator who knows every user personally. Any benefits we would gain from automation (user recertification, transfers, terminations, etc.) are negated by the administrator who often knows what needs to happen for each user before HR even finds out. It’s simply not worth spending the time and money to integrate with such an application because it is already so well controlled.

Populating the requirements list

Although we won’t be discussing requirements in detail until later this year, we’ll actually start building requirements along the way based on working discoveries.

After this month’s exercise, you should have a good idea about what needs to integrate, and to what degree. Ask your engineers to spend a little time examining the protocols that are used by your Priority 1 and 2 systems, as well as the APIs or other integration technologies that may be available on each system. These items will feed your requirements list – especially those pertaining to Priority 1 systems. If an identity management product cannot adequately “talk” to your Priority 1 systems, that may be grounds for instant elimination from the candidate pool.

Action Recap

This month, we covered the following key actions:

1. Identify data elements important to identity management and their source of record – create a map to determine which data elements come from which system, and make sure that none of the data elements have multiple sources of record
2. Prioritize systems to integrate with identity management – sources of record and high-volume systems come first; smaller and harder to integrate systems come second. Some systems should not be integrated at all
3. Start a requirements list – how could/would an identity management product integrate with the systems on your priority list?

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

Identity Management (IDM), or Identity and Access Management (IAM), is a suite of products that work together (more or less cohesively) to manage users and their access/passwords across the enterprise. Most identity management product suites consist of three or sometimes four parts:

-        Role manager

-        Identity manager

-        Access manager

-        Audit manager (sometimes)

Although most product vendors have adopted similar terminology for their components, there is no true standard naming convention nor is there a requirement that vendors use the same name for their corresponding products. My experience is largely with Sun Microsystems’ identity management suite, but this product is not necessarily the right choice for everyone. I will try to remain as neutral as I can, but I ask your understanding if my terminology and examples tend towards what Sun uses.

The Bumpy Road to Consolidation

Have you ever wondered why there are so many components? Why not just make one product that does it all?

The answer lies in the history of identity management.

In the beginning…

… each of the components were stand-alone products created by niche start-ups.

Over time, the larger companies (the usual big players such as Sun, Oracle, IBM, etc.) took an interest in providing their own identity management solutions, and thus began buying out the start-ups and their products to build integrated suites. For example, Sun purchased Waveset as their identity manager and Vaau as their role manager. Oracle purchased Thor (identity manager), Oblix (access manager), and Bridgestream (role manager).

Does consolidation matter?

Consolidation of the marketplace has advantages and disadvantages.

On the plus side is one-stop-shop convenience, and one throat to choke when things go wrong. On the down side, you are stuck with what your vendor of choice offers – maybe their identity manager component is brilliant, but their role manager module just doesn’t meet your requirements.

Given the choice between a hot-and-cold suite or a lukewarm suite (i.e., one whose components are all just average), which do you select? You may also face pressure from management to stick with the vendor partner of choice – if you happen to be an IBM shop, management may be reticent to allow the introduction of HP’s identity management suite, even if it better meets your requirements.

We’ll address these and other product selection issues next December in the last article of this series, which focuses on requirements and product selection (if you need to know sooner, drop me a note and we can discuss). I bring it up now, however, because it’s important to think about what’s really important to your specific implementation as you go, so that when you get to requirements, you know how to prioritize and choose. Please keep an open mind – what you think is very important today may turn out to be less important as you dig deeper – and document your thoughts as you go!

Another big consideration of consolidation is internal interoperability. Just because all of the components are now sold by one vendor doesn’t mean that they are really integrated. It takes time for a company to truly fold in one of these modules. For example, Sun purchased Vaau as their role manager product about a year ago, yet there are still some interesting gaps in the ability of role manager and identity manager to interact.

The biggest consolidation is still pending: Oracle and Sun Microsystems are in process of merging (or trying to, anyway). Both companies currently offer a full-fledged identity management suite. If the merger does go through, what will happen to those products, and how will existing customers be impacted? I would be surprised if they kept both suites, but who knows?

The good news is that while the current round of consolidation is sorting itself out, there is plenty of foundational work to be done to prepare for the selection and implementation – especially with the process and data cleanups.

However, before we even embark on the detailed cleanups and process improvements necessary for success in Identity Management, it is important to take a moment to review the components of an identity management suite and ensure a common understanding and vocabulary. This matters not only for our time together, but also for each project considering identity management.

And Now… The Components!

So what are these things anyway – identity manager, role manager…? Let’s take a brief look at each.

Role Manager: the brains of the operation

The role manager module is where roles, rules, and hierarchies are stored. Except for the most basic actions, it is the role manager module that gathers information on existing users and decides what action should be taken for a particular user – what access they should receive, to which groups they should belong, what segregation of duties rules apply, and how to handle an approval vacancy. This information is particularly important for handling terminated and transferred users to maintain audit compliance.

Fully populating all of the information required to make role manager effective is one of the biggest challenges of identity management, but this is also where some of the greatest benefits are achieved.

It is important to note that role manager can store information even if it cannot be auto-provisioned/-deprovisioned. For example, you may choose to role-base your electronic devices (e.g., desktop vs laptop; cell phone vs smartphone) for manual provisioning/deprovisioning.

Identity Manager: the braun of the suite

The identity manager component typically interfaces with the target systems to initiate auto-provisioning and -deprovisioning workflows, synchronize passwords, execute bulk updates, etc. The identity manager module will trigger some actions on its own based on pre-determined workflows, or it will confer with role manager to execute more complex provisioning actions. Identity manager can be configured to execute workflow tasks automatically, or it can assign tasks to specific administrative personnel for manual action.

Access Manager: simplifying sign-on

In this case, access mostly refers to authentication – the access manager component is what facilitates “single sign-on,” although some modules also mediate authorization, thus the term “access” manager. Of course, as we all know, there really isn’t such a thing as true single sign-on (yet – maybe someday we’ll get there). Although we call it single sign-on, it would be more accurately termed “reduced sign-on.” In any case, when access manager is implemented with a target system, it allows centralized authentication (and possibly authorization) with a source of record such as LDAP or AD, to eliminate the need for individual local accounts and password files on each system.

Audit Manager: reams of eye candy for the auditors

The audit manager component is basically the reporting capability, and is somewhat optional. Some products offer this as a separate module. Other products might include this within identity manager or even role manager. Still others leave it up to the individual organization to integrate their identity management suite with their enterprise reporting tool and generate reports as desired. The reason this component is called audit manager is that when offered, it comes with a variety of out-of-the-box reports that are of particular interest to SOX, PCI, and other auditors.

Action speaks louder than words…

Each month, I suggest a few practices I have learned that will bring quick benefit. For this month, the actions are (theoretically) minimal, since this was an introductory article aimed at simply setting the stage. Still, there is work to be done!

1. Start an identity management journal. In this journal, document:
   1. Expectations of an identity management implementation: what needs to be accomplished? How long do you think it will take? (Hint: once you determine a timeframe, triple it, and you’ll be close =)
   2. What are the expected roadblocks? For example, any management or other influential people that are already leaning toward a specific product, or refuse to even consider a particular vendor? Knowing this information up-front will give you more time to build a strategy to influence, counteract, or otherwise prepare
2. Start considering the team:
   1. Is there anyone in the organization who has implemented an identity management solution before? If yes, ensure their availability to help guide the process
   2. Are there team members interested in learning? This is a great career growth opportunity for smart, hard-working team members that need a new challenge
   3. Does the existing access management team have the bandwidth to embark on process and data cleanups? Most of the up-coming work will naturally fall on them, but if they’re already overworked, it may present a problem. Remember, much of the cleanup work is highly labor-intensive, especially for large organizations. If significant resource constraints are expected, start fighting that battle now
3. Was any of the information in this article new or surprising? If so, spend a little extra time absorbing it or doing some online research.

I am here to help

Leave a comment or drop me a note to let me know how your effort is going. Does your journal reveal any interesting insights? Leave a comment to share with others or ask for guidance.