Data Cleanup Part 1: Primary UserIDs
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:
- Identify the primary ID, and determine who owns each ID
- Identify and retire obsolete IDs
- Connect primary IDs to the appropriate records in the target systems identified in last month’s exercise
- Develop (and use!) a process for keeping the IDs clean until identity management can take over
- 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.
Prioritizing Systems Integrations
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:
- 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
- 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
- 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.
The First Brick: Understanding Identity Management
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!
- Start an identity management journal. In this journal, document:
- 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 =)
- 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
- Start considering the team:
- Is there anyone in the organization who has implemented an identity management solution before? If yes, ensure their availability to help guide the process
- 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
- 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
- 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.
Identity Management in 13 Easy Steps
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.
Shooting ourselves in the foot: Can the bad economy keep us from buying more bullets?
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:
- 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.
- 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.
- 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.
Call to Action: Give a Quarter for Quality
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.
Quality and Security – Same Song, Different Verse
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.
Unintended Consequences: Training, Metrics, Speed, and Quality
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…
Customer Service and the Greater Good
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.
Trust, Sociology, and IT
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.
Engage with Michael
-
Journey Into the Breach
