The final step in this month’s activity is to implement the roles and clean up any extraneous access that’s left behind. As in the previous segment, the distinction between enterprise and IT roles doesn’t matter, so I will generalize. The reason for this is that what you implement depends on your strategy – as defined in Part 3. You may be implementing full enterprise roles with all of the underlying IT roles defined, or you may be implementing IT roles only.

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.

Once all of the roles are defined, it’s time to document them and obtain approval for their use. We’re now past the point where the distinction between enterprise and IT roles matters, so in this segment I go back to the generic term, “role.”

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.

Now that enterprise roles have been identified and prioritized, it’s time to tackle IT roles, and figuring out IT roles is where the rubber meets the road. Chances are, neither the department heads nor the HR team can help on this one. It’s up to the identity management team and business “power users” to determine this based on brute-force analysis and tribal systems knowledge.

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.

The first step in role- and rule-basing is identifying and prioritizing the enterprise roles. This sets the direction for the entire effort, which – make no mistake – will be time consuming. Doing some thoughtful planning up-front is therefore imperative to ensuring that you don’t start out off-track.

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.

At this point in the identity management process it is time to consider what access the company’s job functions should have to begin creating roles and rules. This is the first step in automating provisioning and de-provisioning. Even without automation, creating and managing the roles and rules will make manual provisioning (and auditing!) quite a bit faster and definitely more accurate.

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.

We’ve now gone through the employee’s full lifecycle and discussed how to interpret and manipulate HR data to facilitate automation in identity management for new hires, transfers, and terminations. We wrap up this this month with a focus on the accessibility and reliability of HR data.

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.

In the last article, we discussed how to identify access transfers from HR data. Now we’re in the home stretch: terminations.

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.

In the last article, we discussed the HR considerations for enabling auto-provisioning/auto-assignment of tasks for new hires. Now we’ll address transfers.

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.

In my last article, I introduced the importance of understanding the HR system and putting that into the context of using HR data to manage identities. This is a big challenge because while the HR system is a technology, it is rarely managed by IT – more typically it is managed by an HR-owned administration team. And, since there are so many legal restrictions on HR data (from privacy laws to payroll laws to labor laws), identity management teams may find their HR contacts to be reticent to share information, offer integration capabilities, or change anything in their system to accommodate identity management.

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.

We’ve talked a lot about the importance of the HR system to identity management. Without the right integration between identity management and HR, there is no hope for any sort of automation or data reliability. Unfortunately, it’s not as easy as simply building a connector between the two systems. The HR system itself is an ugly monster that must be “trained” to work with identity management. Given the nature of the beast, getting the HR system to work with identity management could be one of the most difficult parts of the journey.

What the HR system is… and isn’t

The HR system is the source of record for payroll. The HR system is not the source of record for access.

Let me say that again: HR decides who gets paid, not who should have access.

This distinction is critical – here’s why…

Identity management relies on HR for information about new, transferred, and terminated users. However:

• New hire issues: some HR departments do not enter employees into the HR system until after they have started working, to make sure they show up for work. Otherwise, they run the risk of paying someone who never worked. If this is the case, auto-provisioning new access will not be possible if access is needed on the first day of work – unless some workarounds are applied.
• Transfer issues: HR systems can track and report on employee transfers, but:
  • The HR system can’t tell you if the employee needs to keep their previous access for a while to train someone else, or if they’re doing two jobs.
  • What might be considered a transfer from an access perspective (e.g., someone going from Accounts Payable to Accounts Receivable) might not be considered a transfer from an HR perspective (both positions are in the Accounting department).

Both of the above make handling transfers pretty complicated – not impossible, just really tricky.

• Termination issues: an employee is terminated in HR when they stop getting paid, but employees don’t always stop getting paid on the day they stop needing access:
  • Most employees will get some sort of severance if they are laid off or even fired, so they may still show as active in the HR system for days, weeks, or even months after they were escorted out of the building.
  • Employees who resign or retire might take a paid leave of absence or vacation on their way out, again making them active in the HR system for days, weeks, or months after walking out the door.

Relying solely on the HR termination date for access removal opens the organization up to potential security threats from unhappy employees for quite a while.

As if all of the above weren’t enough, the HR system may not be update-to-date or “clean”. Sometimes, line management and even job information data is missing or outdated. It’s also possible that new information is slow to be entered into the system. These limitations will eventually limit the capabilities of the identity management enterprise.

Approach

This month, the goal is to develop relationships with the right people in HR (likely the expert system administrators, not necessarily the reps and recruiters themselves, although it might be both) to identify the following:

• How/when new hires are entered into the system (and how job candidates are handled)
• How/when transfers are handled in the system
• Termination process and reasons
• Reliability of data in general, and accessibility of the data for use by other systems.

In the next article, we’ll begin by tackling the new hire process.

So far this month, we’ve updated the <password policy>, created appropriate <challenge questions>, and come up with a strategy for setting initial passwords. Now we are ready to start training the users and wrap up the month’s activity

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.

In the last article, we discussed how to establish appropriate challenge questions to facilitate password self-service. But that’s just half of the password self-service equation. The other half has to do with initial passwords, which is the topic of this article.

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.

So far we have established the value of properly implementing password self-service and successfully tackled building effective password governance. The next step is to develop “challenge questions.”

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.

In my last article, we explored how a properly implemented password self-service mechanism can yield a quick and early return on the identity management journey. Password self-service is a cornerstone in the foundation for reduced sign-on (which is essentially what SSO promised to be).

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.

Note from Michael: this month we’re going to try something different with this series by breaking the articles up into smaller chunks and serve them on a weekly basis. Same series, same great content, delivered in smaller chunks. Cool?

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.

By: Ioana Bazavan Justus

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.

Welcome to the February issue of Identity Management in 13 Easy Steps. In most parts of the country the weather is cold and dreary, and what better weather for an ID cleanup?

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.

Avoiding the biggest mistake

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.

What is Identity Management?

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.

by Ioana Justus

If you were asked to throw a few million dollars out the window, would you do it?

If yes, let me know where and when – I’ll happily wait outside with my catcher’s mitt. More likely, the quick answer to this question is a resounding “NO”. Few circumstances would lead someone to literally throw millions of dollars out the window, down the drain, etc. Not a million dollars, not in a million years.

What about companies that, effectively, waste millions of dollars trying to implement identity management?

The sad reality is that many organizations trying to implement identity management do just that – waste big money – on the wrong technology, or even on the right technology that sits idle because it can’t be used as designed. Worse, some organizations look to even more technology to “fix the shortcomings” of their selected product. The end result is the identity management version of Frankenstein’s monster.

If you peruse the latest identity management articles from your favorite research company, you’ll find the same discussions over and over:  How do we justify the cost?  Why do so many companies stop at “single sign-on”?  Why do implementations take so long?  Why do implementations get halted mid-effort?  What’s the true benefit of identity management?  What’s the ROI?  You’ll also find the same tired answers – whether in printed form, or at one of the many IAM conferences across the country: IAM saves costs at the help desk. IAM can help with audit. IAM can reduce headcount in your access services department. Companies bite off more than they can chew, ROI takes too long, so they give up.

But what does it all mean?

Are we really doomed to these behemoth infrastructures that sit largely un-used, while we pay off consulting and software bills that often run into the millions (if not tens of millions)?

No, we’re not.

IAM is not a lost cause. It can lead to lower costs, easier audit processes, and a demonstrated postive return on investment (ROI). But it takes time – and discipline. As with many aspects of security, identity management is not about technology – it’s about people and process. The technologies are out there, and getting ever-more mature. But, IAM is NOT a Mac or an iPhone – you don’t just turn it on and it magically works. There is a lot of configuration and even custom development that needs to be done after you install your product suite of choice. Even before that, there is a TON of data cleanup, data modeling, and process design that needs to take place, and that is at the heart of this series:

Identity Management in 13 Easy Steps

Of course, the series title is a bit tongue-in-cheek. There’s nothing particularly easy about identity management. Then again, it’s not rocket science, either. It just takes a little thought and a lot of tedious effort – and did I mention discipline? The focus of this series is all on process and data. In fact, product selection is saved until the very last article. That’s right – if you can keep your instant-gratification urges at bay, I recommend that you don’t even bother buying anything until you’re ready to use it. Why spend all that money on a fancy technology if it’s going to sit there, idle, while you beat your head against the wall trying to clean up the data and processes that it needs to function?

An identity management implementation will only be as good as the data and processes feeding it, and that’s the problem many companies face today – most organizations buy a product and figure out after the fact that they have a ton of work to do to make it function. As a result, there is such a lag between the time of purchase and the time of ROI, most management teams lose patience and halt the effort. If you pave the way to implementation by first cleaning house, when you implement the technology its benefit will be seen quickly, which will encourage management to keep it going and try more.

There’s another critical aspect to this approach: gaining the needed experience to properly document requirements. Identity management is extremely complex. No one can just walk in and “get it” in one sitting. Even if the high-level concepts seem obvious, you have to live with the dirty details for a while to really understand the needs of your particular situation. The better that understanding, the better the requirements. The better the requirements, the better the product selection. Choose the right product, and you avoid tossing millions out the window.

Are you ready for this journey?  If so, let’s get started. Here is the series I have planned – one article per month. This may not seem like much, but unless your implementation will have a very small user base, it will take longer than a month to execute most of these steps anyway. Of course, the series may change along the way – I’m already concerned about the volume of information I’m trying to fit into some of the articles. I may find as we go that a few of these topics will require multi-part articles. We’ll deal with that when it arises.

For now, here’s the intended schedule:

December 2009: Identity Management 101 – an overview of the different components of an IAM suite, to make sure we’re all on the same page and speaking the same language.

January 2010: Identifying Systems Integrations – not all systems will integrate (directly or indirectly) with IAM. Determine which ones will feed the priority list for the data cleanups and process work.

February 2010: Data Cleanup Part 1 – before your identity management system can work, it needs to be populated with all userIDs, and those IDs have to be clean. The first cleanup is focused on the primary IDs such as AD/LDAP and other key systems.

March 2010: Data Cleanup Part 2 – a key benefit of identity management is the ability to link userIDs in multiple formats from a variety of systems to the user’s primary record. The second cleanup focuses on identifying which IDs belong to which users in preparation for proper linking.

April 2010: Preparing for Password Self-Service – password self-service is a key cost savings of IAM, but it’s harder than you might think. This article will help you prepare your policies and your users for the technology to come.

May 2010: HR as a Source of Record – the HR system is a primary source of record for employees. It can also be one of the primary sources of errors and limitations for identity management. This article will explain the issues that most companies experience when interfacing with HR technologies (and departments).

June 2010: Role- and Rule-Basing – in order for auto-provisioning and -deprovisioning to work, the roles and rules need to be defined. This article will teach you how to avoid turning this effort into a rat’s nest.

July 2010: Role Hierarchies – workflows cannot be enabled without proper approval processes. But approvers aren’t always line managers. This article describes the various role hierarchies that should be established, and the synergies that can be achieved between identity management and other sources of record (e.g., financial systems).

August 2010: Workflows – workflows are the key to automating many processes. This article discusses the considerations in setting up workflows to ensure that they function effectively.

September 2010: Termination and Transfer Gotchas – terminations and transfers are key control activities that are of great interest to auditors. Getting this right in identity management will save everyone a lot of work. Getting it wrong can be disastrous. Learn the pitfalls in this article.

October 2010: Password Self-Service – whereas the April article deals with the foundational aspects of password self-service, this article deals more with the implementation aspects: how to select challenge questions that make sense, exposing PSS outside of the corporate network, etc.

November 2010: Effective Business Cases – now that your house is in order and you have almost a year’s experience with your organization’s circumstances, it’s time to build a business case to buy a product. This article explores a number of value-added functions of identity management that will intrigue your management and encourage them to allocate budget.

December 2010: Requirements and Product Selection – you’ve cleaned your data, defined your processes, and secured a budget. It’s finally time to pick a product. This article will help you document and prioritize detailed requirements based on a year’s experience in the trenches, so that you can make the best product decision possible.

by Ioana Justus

My career has now spanned almost 12 years, and it still amazes me how so many managers and executives consistently make bad decisions and then are surprised by the results.  As the economy has gone bad, you’d think that people would be a little more judicious about how they spend the small budget they have remaining, but that’s turning out not to be the case.  Surprisingly, I think the vehemence with which we’re shooting ourselves in the foot has increased as the budgets have shrunk.  Now that the economy has bottomed out and is (supposedly) on the rebound, is there any chance of changing some of the behaviors before the upswing takes hold?

Let me ask you a different question: If you lived in Chicago and your house needed a new roof, would you just go out and buy the one recommended by your buddy out in San Francisco, because he’s thrilled with his new roof?  Hopefully, the answer to this is no.  You may take a look at it, but I’d hope that you would confirm that the structural integrity is insufficient for the added wind, cold, and snow weight that Chicago roofs experience.  Once selected, would you allow the contractor to cut corners on your roof installation just to make a specific deadline?  Is a permanently leaky roof worth a couple of weeks?

If you wouldn’t blindly purchase something for your own home based solely on the recommendation of a friend, why would you purchase a product for your company based on the recommendation from a vendor, a colleague in another industry, or a conversation on the golf course?  How can you justify the potential risk?  What happens to your reputation when the product in question doesn’t perform as expected?  Where does the budget come from if you end up having to replace the entire thing?

When budgets are tight, there are better things to purchase with what little you have than bullets for your foot, and there are three very simple rules that can keep your munitions purchases at bay:

1. Don’t ‘ decide’ on a due date, calculate it.  Implementations take time and resources.  As much as you might want something in production by the end of the quarter, it might not be possible to do in a reasonable way.  Before committing to a date that’s just not feasible, spend a little time to determine the effort involved and lead-times for any purchases/installations that may need to be made, and to assess the availability of the resources required.  Then calculate a plausible due date based on the reality of the work effort and be sure to document the consequences of cutting corners, should that still be desired.  Sure, there will be instances when time is of the essence, but those are not as frequent as most people think.  When you consider long-term support costs and the massive adjustments that are usually needed to make a quickly installed product work, the calculated ROI is rarely met, and the costs to reputation and morale are higher than many would like to admit.
2. Don’t ‘make up’ budget numbers, calculate them.  We all instinctively have assumptions about how much something should cost.  Some of us are better than others at guesstimating accurately.  Most of us underestimate – significantly!  So before publishing a number that just doesn’t make sense, do the math.  There’s truly nothing to be gained by setting the expectation that the desired work can be done for half the actual cost.  If the true cost is prohibitive, then the negotiations need to start, and the consequences should be documented and accepted for each item cut.  But if you’ve dug yourself a hole before the negotiations have even started, you’re in for a world of hurt.
3. Don’t fit your problems to a pre-determined solution, pick a solution that fits your problem.  No matter how nice the vendor is or how much you value your golf buddy’s opinion, the product they’re pushing may not be the right one for your company.  The only way to know for sure is to gather requirements first, based on the actual needs, desires, and roadblocks currently being faced by your company.  Then you can assess whether the desired product fits the bill.  If it doesn’t, don’t buy it!  If nothing fits the bill, pick the best option, or consider waiting for future developments.  In any case, be sure to document the trade-offs, and get agreement that they’re acceptable.

Simple, right?   But if we were all doing this, I wouldn’t be writing about it.  The problem is that it has become acceptable to ignore the rules, and anyone who doesn’t follow suit is viewed negatively.  The real challenge is for each of us to take the personal responsibility to follow the rules, regardless of our position in the company.  Only then will we change the expectation and make it unacceptable to ignore the rules.

by Ioana Justus

I had a very insightful meeting with my CIO last week about quality.  One of the questions I asked him is his advice on how to prioritize among many possible tasks when they are all of similar difficulty and impact.  This is the challenge we’ve been facing with improving quality – there are many things that could/should be done, but each one has fairly localized impact, and none of them solve the bigger problem.  His response was that that’s what happens when you take a bottom-up view, and he suggested looking from the top-down instead.  He recommended looking at instilling accountability at the right levels, and all of those many smaller things would take care of themselves.  He’s right, of course, and we’re looking into ways to build that accountability.  In parallel, I’d like to start down this path in an organic fashion, too, by challenging everyone in IT to identify areas of quality that impact them (or where they impact others), and working to improve them.

“Yeah right, Ioana, I don’t have time to do that,” you say.  And that’s really the crux of the quality problem, isn’t it – time.  The biggest reason for not doing an adequate level of quality seems to always be time.  But is it really true that we don’t have time?

I’ve been playing with time lately in my personal life, because I was finding that I’ve been killing my Saturdays with house chores.  I’d let everything build up during the week (even opening mail) because I didn’t think I had time, and then I’d have to deal with it all on Saturday.  No single task takes very long, but ten minutes to water plants, fifteen to sort the mail, thirty to deal with the kitchen, and it adds up.  All told, my husband and I were each spending about 2 ½ hours each Saturday getting all the chores done.  Once finished, we’re too tired to do anything else that day.  So we ended up wasting an entire day – half a weekend! – for a lousy 2 ½ hours’ worth of chores.

Since maid and yard service are not currently in the budget, I thought I’d try something a little different: rather than letting it all pile up, how would it be if I spread it out?  What if I spent just 30 minutes every weekday?  But that still seemed like a lot – I’m too lazy and undisciplined to do 30 minutes of chores every evening, so I tried breaking it up even more.  I’ll spend 5 minutes each morning emptying or filling the dishwasher or wiping down the kitchen counters.  I deal with the mail as soon as I take it out of the box every day.  While my dinner is heating I’ll fold a load of laundry or brush the dogs.  By the end of the day, I find that I got through my list, and I didn’t even notice the time spent.  Sure, sometimes I really don’t feel like doing even the 5 or 10 minutes, but my incentive is a free Saturday, and it sure feels good when I get there.

Ultimately, quality is just one of the many chores of our collective work life.  It’s those extra little things that can make a big difference at the end of the day, but as long as we look at them as big chunks of work, we’ll always think we don’t have time.  But you do have 15 minutes, don’t you?  It’s just a quarter of an hour – 3% of your work day.  That’s all you need to start.  The first step is to brainstorm some things you can do to improve quality in ways that will result in saving yourself or others some time.  I’m sure you can come up with several good ideas in 15 minutes.  Here are some suggestions:

-        Support/Operations:

• List one or more procedures that you should know better to avoid escalation or repeating problems
• List one or more “band-aid fixes” that regularly take your time to apply, that have a fairly straightforward permanent fix
• Identify procedures that are not clear or that need to be updated

-        Engineers/Architects:

• Identify where you or your peers are “re-creating the wheel” because one or more standards or processes isn’t documented
• Identify old standards or processes that need to be updated, or placed in a more accessible location

-        Project personnel:

• Identify documentation templates/artifacts that don’t make sense to fill out, and explain why they do not meet your needs and how to modify them to make them better
• Identify and escalate risks to quality on your project, such as missed requirements or skipped reviews, making sure to articulate the risk in terms of potential cost or consequences

Once you’ve come up with your list, pick an item from the list that you could fix within a month if you spent just a quarter of an hour a day on it.  Discuss this with your manager, and commit to getting it done.

There are about 1500 of us in my IT department – how many are in yours?  And if each person gave a quarter for quality every day for a month, what could be accomplished?  Will you commit to blocking off 15 minutes in your calendar every day in the month of September to make a difference?  Send me an email to let me know that you will, and tell me about your plan.

by Ioana Justus

In April of this year, I was assigned to lead a Quality program for all of IT at my company.  Meaning, I and my team are supposed to significantly improve the quality of IT’s deliverables in the next couple of years.  This improvement in quality is supposed to reduce support costs, reduce incidents and downtime, speed delivery through the creation of reusable materials, ensure we have proper testing environments, etc.  Of course a lot of this implies the need for training and behavior changes, which opens up the people change management can of worms.  It still makes my head spin when I think about our scope.

I also still ask myself, why me?  Why is an InfoSec Manager with expertise in identity and access management being asked to make changes that impact the worlds of (just to name a few) project managers, testing, delivery, operations, and support?  What do I know about these things?

When I asked the leadership this initially, the responses I got were things like, I have a good perspective on customer service, I’m familiar with the support and infrastructure teams, and I have a reputation for getting things done.  OK, I buy that.  I think they also wanted an impartial outsider – since I’m not part of any of the organizations impacted by the work, I’m more likely to be impartial.  I buy that, too.

What I really wonder is if they realized just how much my InfoSec background really plays into this new role – am I slow in discovering what they’ve known all these months, or is it just an interesting coincidence?  The reality is, it’s SCARY how similar quality and security are.  I was reading a Gartner presentation on aligning InfoSec with the business a few days ago, and realized somewhere in the middle that I could replace the word “security” for the word “quality” in the entire presentation and the statements would be just as true.

Think about it:  what is security?  Security is the set of practices, processes, and technologies that for the most part no one wants to deal with.  They’re often viewed as extra work.  Most people buy into security only because it’s required and because if they don’t, bad things happen.  But what happens when you do good security?  Nothing.  No denial of service attacks, no lost data, no hacks, no unexpected downtime, no firedrills, no audit findings, no… you get the picture.

And what is quality?  Quality is the set of practices, processes and technologies that for the most part no one wants to deal with.  They’re often viewed as extra work.  Most people don’t buy into quality because it’s not required but when they don’t do it, bad things happen.  And what happens when you do good quality?  Nothing.  No unexpected downtime, no rework on designs, no missed requirements, no customer complaints, no 3am support calls…  See what I mean?

In one way, security is easier than quality because there are legal requirements for it.  But quality is easier than security in that the consequences of bad quality are much more visible and easy to understand than the consequences of bad security.

So now what?  In my last blog post, I pointed out that the unintended consequence of rewarding too much speed is getting not enough quality.  Interestingly, when it comes to something like project delivery, customers continue to reward speed at the expense of quality even after having numerous bad experiences.  Why?  Well, for one thing, speed equals money and it’s hard to argue with that.  We’re also very much an instant gratification culture – “wait” is a four-letter word.  But the key issue is that the customer experience is negative.  Remember – it’s the positive experiences that drive the behavior, not the negative ones (this is very true in InfoSec, too).  This brings us back to Nothing.  Once we can demonstrate to the customer base that good quality leads to Nothing, they will reward Nothing, which will in turn encourage quality.

It would seem that my job is once again to sell everyone on the virtues and benefits of Nothing – in a bad economy no less.  *sigh*

Then again, Seinfeld made a lot of money on Nothing, so maybe I’m sitting on a gold mine and just don’t know it yet.

I’ve been developing and conducting training classes for years – never entire curricula, but individual classes like security awareness.  In general I’ve been pretty successful, and I haven’t found it that difficult: explain the topic in an organized way, explain why certain things are they way they are, give some concrete examples, and most people get it.

Then I got the first dogs of my adult life, and learned to train them.  In many ways, training dogs is much more difficult than training people because there is no common language and dogs and people perceive the world in very different ways.  Now, before anyone gets offended, I’m not trying to compare people to dogs.  I am, however, trying to compare training methods – there are some interesting differences and similarities that are very educational, and training either species can have unintended consequences.

One of the most popular methods of training any species of animal is called clicker training.  A clicker is just a small plastic thing that makes a clicking noise.  You associate that noise with a treat, and the animal (in this case a dog) learns that the noise means something good is about to happen.  When the dog performs a desired behavior (like sit), you click at the moment that it performs, and follow up with a treat.  Because of the precision of clicking just when the behavior happens, the dog is clear on what you want, and learns a lot faster.  In fact, most dogs figure it out pretty quickly and will start to “offer” the behavior in the hopes of more treats.  This method is also used successfully with human athletes that have to do complex aerial moves like gymnasts and divers, to help them understand when to start or end a tuck or a twist.  The key message here is that immediate positive recognition for doing the right thing is the fastest way to ingrain a behavior – in any species.

The more interesting side of dog training is the unintended consequences.  Unlike with humans, you can’t just explain to a dog what you’re after.  You have to figure out how to guide (“lure”) the dog into doing what you want, but even then it might not understand.  If it doesn’t, you have to wait around and let it do the behavior by itself, and “capture” the behavior by clicking and treating when it happens.  The problem with luring and capturing is that sometimes you reward things that you didn’t mean to reward – thus the unintended consequences.  Here’s an example with my husband’s dog, Kozmo. We rented a house last year that was down the street from a school.  Kozmo decided it was a good idea to get up at 7am, run into the yard, and start barking at the kids walking by.  So every morning for about a week I got up when I heard him, went out with him, called him in when he started barking, and then went to the kitchen for a treat.  By the end of the week, he stopped barking outside.  But then he started doing something new.  Every once in a while, he’d get my attention, and walk toward the dog door, ensuring that I was still watching.  Then he’d rush outside, bark a couple times, rush back in, and go sit in the kitchen and stare at the treat cabinet.  In short, I was trying to teach him “don’t go outside and bark” but he learned “If I go outside and bark when mom’s around and immediately come back in, I get food and attention.”  To this day if he wants attention when we’re around, he’ll go outside and bark a few times, then come back into the house, expecting praise.

So what’s my point in all of this?  When we collect metrics in the customer services space and use them for performance assessments, we are effectively training our employees – if you score well on the metrics, you get a raise.  If you score poorly, you could get fired.  But measuring the wrong things can have unintended consequences – we think we’re rewarding delivering good service, but we’re actually rewarding behaviors that deteriorate service.  A very common example is when we measure speed of service instead of quality of service.  Speed is much easier to measure than quality, and it’s something that can be system generated: how many tickets closed per week, how many minutes spent on each call, etc.  On the surface, it also makes sense: if we’re closing calls and tickets faster, we’re completing more calls and tickets sooner, so the customers aren’t waiting around for service, and that’s good!  But what actually happens?  If an employee gets a gold star for being the fastest, that individual will do his best to continue doing so – at the expense of the customer.  The ticket will get closed with the work not being completed, or the call will end and the customer still hasn’t received the help they needed, or they’ve been passed along to someone else – wasting both the customer’s time and the time of the person they were passed to.  Meanwhile, the employee is getting rewarded for having been the fastest.  Measuring speed without measuring the underlying quality, has the unintended consequence of deteriorating service, when the intent is to improve service.

How do you measure quality in ways that reward good service?  More on that later…

by Ioana Justus

I received a response to my blog titled “End Users: IT’s biggest barrier to good customer service” that I found particularly interesting. The responder wrote, “Some users tend to think that IT is here to serve them. To a point we are, to keep computers/servers/printers/etc running and functional. However, some think that if anything has to do with the computer, then we should be the ones taking care of it. As an extreme example, that IT should be responsible for ordering paper, since paper goes into a printer, and a printer can be hooked to a computer, so it is up to IT to order it.”

Although this is indeed an extreme case, it’s an interesting example and it does bring up a valid point: is it sometimes not our job to provide service to the customer? And do we tell them this?

The answer is, as usual, it depends. The reality is that IT professionals are generally better paid than their business counterparts, and although having IT personnel performing non-IT tasks may occasionally benefit an individual or even a small group, it ultimately hurts the bottom line of the company. So sometimes, it really is in the company’s best interest for IT to not provide the requested service. That said, when faced with such a situation, telling the customer no or not providing the service is not beneficial, either.

So now what? Handling a situation like this really depends on who the customer is. I think there are three categories of customer here:

- A “general” customer – i.e., someone with whom you do not have a current relationship, and whose motivations are unfamiliar to you

- A “VIP” customer – i.e., someone with whom you already have a relationship that you want to build further, or a senior executive of the company

- A “repeat offender” – i.e., someone who is a known pain in the rear or who consistently circumvents the process

Let’s take a look at each case, continuing with the “IT being asked to order paper” theme…

For a general customer, it’s worth it to do some root cause analysis: why are they asking you to order the paper for them? I’d be willing to bet it’s because either they don’t know the official process, or because the process doesn’t work. If they don’t know the process, you can provide excellent service and build a new relationship by helping them learn. Don’t just do it for them – take a little extra time to teach them how to fish. If there’s a form to fill out, show them where to find the form, and help them fill it out. If there’s a person to call, provide the name and phone number of the person, and then call them for the customer. For the single instance, the added time does cost more than just doing it for them, but it will be more than made up if the customer doesn’t have to ask you again.

If, on the other hand, the customer is circumventing the process because it’s cumbersome or doesn’t work, then a little process re-engineering is in order. Depending on who you are in the organization, you may or may not be in a position to facilitate this yourself. In this case, help the customer through the red tape, and at a minimum escalate the situation to your manager and suggest some potential solutions. If you can effect change, be sure to follow up with the customer to let them know.

For a VIP customer, the initial action is just to order the paper for them. To improve the level of service for this group and be cost-conscious for the company, the best thing you can do is coordinate proactive ordering with the right person or department. If the paper replenishes itself, the VIP customers will be happy because they no longer need to worry about it, and they won’t have to ask you to place the order anymore.

In the case of a repeat offender, it may be worth it to do a root cause analysis. If the process is tedious, you could repair a not-so-good relationship by helping to improve the process – or at a minimum, you can get this person out of your hair. If there’s nothing wrong with the process and the person just can’t be bothered with following it, well, that’s why management gets paid the big bucks – to deal with people like that.

by Ioana Justus

In my last blog, I talked about how to build trust with a customer, and the advantages of doing so. By building a relationship of trust, communication becomes more open, allowing the customer to feel comfortable sharing their needs, and allowing the IT service provider to better customize service and anticipate needs. This concept also extends to intra-IT interactions – or regular life interactions, for that matter.

Sociologists will tell you that humans are social creatures – even the most introverted of our species require interaction with others. There is also the concept of the “inner circle” – each person has an “in” crowd that they trust and want to interact with. Evolutionarily, having such a group ensured survival: the group would mutually protect each other and they worked together to find food and raise children. The flip side of this evolutionary model is the rest of the world: If you’re not part of the inner circle, you’re not trusted and are thus treated with suspicion, prejudice, or even disdain. Individuals in your inner circle get the benefit of the doubt when they do something wrong, and you are compelled to help them through it. Individuals not in your inner circle are assumed to be malicious when they do something wrong, and you are compelled to be defensive and accusatory toward them for it.

It frequently surprises me how people assume that things in the IT or business world work so differently than they do in daily life, when there is actually little or no difference. We are the same humans with the same genetic make-up whether we’re home in our sweats or at work in our suits. Everyone knows that the best way to get a new job is to network with people at the target company, and many a manager has been accused of favoritism – Mary got a perk that I didn’t get because the boss “likes her better” (i.e., trusts her more) than me. Even security networks are built on trust (e.g., PGP): if I trust you and you trust John, then I can trust John.

So it stands to reason that if we can increase trust in the workplace, everything gets better: issues get resolved faster, there are fewer nasty surprises, there is greatly increased communication, and a strong desire to be inclusive. This then results in better collaboration between IT teams, which increases sense of ownership that in turn decreases errors and improves the overall quality of deliverables. All of this makes the customer – and thus the boss – happier.

But how do you go about this? Theoretically, it’s simple: communicate and include. Practically, it’s quite a bit more challenging. Make it a point to build trust with your coworkers, especially where you know it doesn’t exist today. At work, your inner circle is most likely your immediate team. But you probably work regularly with other teams. Are you accusatory of them? Do you have a less than impressed opinion? Do you think they screw up or are sub-par? Do they point their fingers at you? Those are the individuals you most want to target. Be sure to have face-to-face meetings with them – it’s a lot harder to think someone’s a jerk when they’re sitting right there. When you invite them to the table, ask everyone (including you and your team) to leave their prejudice at the door. Talk about what’s going wrong openly and honestly, with the intent to fix the problem, not lay blame. This may take some time, but have the good will to keep trying, and consider engaging a practiced facilitator if needed (many people are naturally good facilitators, but if you need someone who has been specially trained, try looking in HR or the training department). Extend gestures of goodwill by inviting the other team to an outing (e.g., lunch or drinks after work) or to meetings that they should’ve been invited to but weren’t. Above all, really listen to their perspective and make an effort to see their point of view. It might take a while, but what you’ll notice over time is increased respect and much smoother workings between you.

It may be a bit pie-in-the-sky, but imagine if you had trust with every team you worked with. I guarantee you’d be a happier employee and you’d enjoy your job a lot more. You’d also get work done faster with higher-quality results, making your customers and supervisors happier, too. And in this tenuous economic climate of cost-cutting and down-sizing, that’s maybe as close to job security as any of us can get.

by Ioana Justus

Ask any security professional what the biggest danger is to their organization’s security, and they’ll all say the same thing: end users. Some may be shocked at that answer, others will laugh ruefully, but it’s true. All it takes is one well-intended but computer illiterate person to bring any number of security controls to their knees. And of course, getting the word out – getting users to do the right things (and not do the wrong things) – is one of the biggest challenges that organizations face today.

Well, it turns out that the biggest problem that IT has in delivering good customer service is also, yes, the end user. I can’t tell you how many times I’ve gotten phone calls from desperate customers, which began with, “I’m not IT.” Yes, I know you’re not IT. It’s OK.

For me this situation has generally been nothing more than amusing, sometimes mildly annoying. But then I started talking to others in IT, and I discovered shock, disgust, and rage. “I can’t BELIEVE they don’t get it!!!” “How can they NOT get it?!?!?!” “Why won’t they learn????”

My responses to this may be surprising:

“I can’t believe they don’t get it” – get over it. They don’t get it. Being shocked and spending cycles on it won’t change this.

“How can they NOT get it?”/”Why won’t they learn?” – it depends. Some have never been taught. Others may have tried to learn, but had a bad teacher. Unfortunately, some genuinely don’t care. Either way, it doesn’t matter – at least not initially.

Here’s the deal: when a customer comes and asks for IT help, they’re coming into your house. You shouldn’t expect them to know any more about IT than you know about corporate law or advertising. Remind yourself that they’re not inherently stupid or difficult – they just have a different area of expertise. If an end-user makes a point of telling you “I’m not IT” what they’re really saying is one of the following;

I don’t think I’m smart enough to understand this.

I’m scared of this because in the past someone in IT talked down to me and made me feel stupid.

I don’t have time to understand this.

It’s not my job to understand this.

I don’t want to understand this.

Unfortunately, their fear or previous bad experiences will often manifest themselves as impatience and rudeness. But getting upset by their lack of understanding or bad attitude sets you up for failure. It ensures that you will be condescending or impatient, which will result in a bad experience for both of you and have repercussions beyond that one encounter: you will be more grumpy with the next customer, the customer may complain to your boss, and the customer will become even more entrenched in, “I’m not IT.” Ultimately, it’s your own heart attack in the making, and it doesn’t do anyone any good.

So start by patiently assisting the customer with the issue at hand. Use terms they will understand, lead them through it, and help them gain the confidence that it’s not that hard. Make it a positive experience for them. Not only will it make both of your days better, but you will have built a relationship of trust, making it more likely that this individual will seek out your assistance in the future and listen to what you have to say. They will also feel more comfortable sharing their needs and fears with you, which sets you up for addressing the bigger problem: why they don’t learn.

At the end of the day, operating a computer is a lot like driving a car – you need to know which pedals to push, and what the warning lights on the dashboard mean. You also need to know the rules of the road. But you don’t need to know how to change your own oil or fix the engine.

If end users could learn some basic computer literacy skills – like drivers need to learn the basic operation of a car – it would make serving their needs a lot easier. Unfortunately, no one requires a license to operate a computer. This is where that positive relationship comes in: it gives you the opportunity to start probing into why the customer doesn’t have the basic skills. If they’re scared or don’t think they can do it, help them learn – even if it takes a little extra time. If they think they don’t have time, help them understand how learning will save them time in the future. If they think it’s not their job, help them understand how basic computer literacy will make their job easier.

If they simply don’t care, then don’t worry about it. As they say, you can take a horse to water-and make sure the water is clean, and even shove its nose into the trough-but you can’t make it drink. If you provide the best service you can, and win over many other customers by making their job and yours easier, no one is going to fault you for those few that just don’t want to participate.

by Ioana Justus

I had two interesting conversations last fall that really made me start to think.  The first discussion was with Michael.  My thinking lately is that Michael’s practices (as described in Into the Breach) would apply not just to teaching end-users about data protection and information security, but to IT personnel needing to learn about customer service.  I’ve been chatting with Michael on ways to apply his ideas within my own organization with the new work I’ve been doing in the services space.

This call was followed by a lunchtime ring from my friend Trish, who just had a very unpleasant experience with a sales clerk at the mall.  She was buying sheets at JCPenney, which had a regular sale, a special Columbus Day sale, and Trish had a coupon.  So the clerk had to enter 3 discounts at the register, and that was a bit much for her.

This all made me think internally to my company’s Service Desk, and to the road that my Access Services team has taken.  The reality is that there is an enormous dichotomy in the customer services space.  Those people that ring you up at the register or who answer the phone at the call center are often the lowest paid, least trained, highest turnover employees at the company in question.  And yet they’re expected to be the most knowledgeable and serviceable of anyone.

I pointed out to Trish (a college professor) that walking in the door she’s more educated, articulate, and confident than most sales clerks she’ll meet.  That immediately puts the clerk at a disadvantage, and anything that goes wrong will make the clerk appear defensive and even less competent.  I further pointed out that it’s very likely that the clerk had little or no training or communication from her management about how to handle the multiple sales going on, so she was relying on her past knowledge to figure it out.  Of  course this creates a bad experience for the customer, who then gets grumpy with the clerk, which makes it even less likely that the clerk will be able to provide a good shopping experience for the next customer.

I’ve seen the Service Desk and my own team in the same predicament – when they are expected to support something without adequate training.  Invariably they get it wrong, the customer gets frustrated, and it gets escalated.  The end result is that the person trying to help becomes more timid and less likely to provide good service the next time around.

I feel that it’s our responsibility as managers to ensure that our teams are empowered to provide good customer service by ensuring that they have the training and support they need.  Although we all instinctively know what good customer service feels like when we’re on the receiving end, not many people instinctively know how to provide good customer service just because they were told, “you must.”

I would challenge all of my fellow managers in IT to spend some time with their team to understand:

- what are the challenges the team faces with respect to providing good service?

- does everyone on the team know what is and isn’t acceptable when dealing with the customer?

- does everyone know all of the processes of the team backward, forward and inside out?

- are your processes even usable, or are they known to be broken?

- are standard expectations set with the customer so that your team can deliver consistently?

- does your team have clear, easily-accessible and updated documentation to help them do their jobs?

We can’t expect our teams to provide good customer service if they’ve been set up to fail, and if they’re going to be afraid of their capability or the consequences of falling short.  Only when we set the groundwork of support to ensure the success of our teams can we expect them to be able to risk providing excellent service.