code – Code Technology

Access Governance Strategy

Identity and Access Management (IAM) projects are often initiated due to an audit finding or security review. These projects have limited management focus — really, if we’re honest about it, a compliance driven project is launched to fix a specific problem in the business. The project is expected to be delivered on time and on budget, and is wrapped after addressing a specific business need.

An Access Governance program doesn’t lend itself to this type of tactical approach. Access Governance needs a strategy, one that will help drive initiatives over the mid- to long-term. This is true even when (or perhaps especially when) an initial project is launched due to a compliance problem.

Access Governance has a longer life cycle than audit or security reviews, which are typically annual events. This is because access is something that crosses business boundaries, requires complex systems integration, and is dynamically changing as the business changes.

Business or IT strategies can help programs like Access Governance get established and funded. A strategy for access can critically assess business needs, develop roadmaps for addressing those needs, and help management to set performance measures.

When setting out to develop an Access Governance strategy, there are some key activities to be considered:

Know the audience — Is the CIO the primary reader of the strategy, or will it be used by multiple executives and managers? A clear understanding of the business audience is crucial before embarking on the development of a strategy.
Identify relevant business goals — What is the organization trying to accomplish? What are the business goals for the next three to five years? Read the business plan and look for ways that access management can support those goals.
Link Access Governance to business strategy — This is the key to the process and it must be done well. Explaining how a program of Access Governance helps move the business forward is critical. But linking Access Governance to business goals needs to be realistic and defendable if the strategy is going to be adopted.
Identify champions — The strategy needs to be built with full support of those business leaders that will receive the benefits of Access Governance. Make them part of the strategy development process and listen to their input. You’ll be rewarded with loyal supporters of the program.
Develop a readable strategy — There is nothing worse than a dense, technical document passing itself off as a strategy. Strategies need to be filled with business language. They must use terms that the audience understands, and they need to be structured in a way that encourages reading. Costs need to be identified and provided in both summary and detailed forms. Illustrations and models are key, and a realistic project roadmap diagram is mandatory.

Once the strategy is approved, a program for Access Governance can be developed. Soon, priority projects will begin to deliver strategic results, and your supporters will realize the measurable benefits of having a strategy guide this crucial program.

Mike

Assessing IAM

My experience with formal technology planning spans over 20 years. As an external consultant, I can offer fresh insights as inputs to planning and strategy development.

The planning approach I have used have always included an assessment phase — a set of tasks in the project that is primarily concerned with collecting information about the environment. This works well when done prior to project planning, strategy work and program development.

Assessments are a vital part of Code Technology’s work in identity management. An IAM Assessment can be delivered on its own, or as part of an identity management strategy project. The approach we have formulated for IAM Assessments is a little different than the generic IT information gathering. Identity management assessments need to be structured to address key components that impact IAM design and delivery.

If you’ve followed this blog for any length of time, you’ll know that I regularly reference the Pan-Canadian Identity Management and Authentication (IdM&A) Framework. This framework has provided an excellent structure for assessment and strategy development work.

My approach, then, is to leverage the framework in the development of an IAM assessment. Without the structure and completeness of this framework it would be difficult to ensure everything was covered.

The heart of the assessment is information gathering: infrastructure, applications, identity stores, policies, processes, etc. Once these details are collected, analysis of the environment is performed using the seven Pan-Canadian IdM&A components.

Key questions are used to drive the assessment analysis:

Legal –Under what legal agreements and legislation does the organization operate? How do these drive compliance for IAM?
Privacy – How well does the environment match to privacy obligations?
Security – Does the current environment meet or exceed information security standards? What key identity and access risks need to be considered?
Trust – What trust arrangements (if any) exist between federated organizations?
Assurance – What processes and technology exist to ensure information assets are protected to the appropriate level of assurance?
Identity – How are identities organized and managed? What identity attributes are stored and utilized?
Service Management – How robust and flexible is the current environment? How will it need to be supported?

An assessment is more than just information gathering — the analysis can help to immediately highlight strengths and weaknesses in the environment. Follow on work can use this documented ‘snap shot’ of the identity management environment to address security gaps, make improvements and plan for new solutions.

Mike

Pan-Canadian Identity Assurance Model

In October 2008, I wrote a five part review of identity assurance, based on the framework contained in the Pan-Canadian Strategy for Identity Management and Authentication. At the time these blog posts were the only Canadian resource available for analyzing and planning identity assurance.

Since then a number of changes have occurred that have prompted me to update these posts. For example, an Assurance, Identity and Trust Working Group was established by the national Identity Management Steering Committee. This team prepared a report, the Pan-Canadian Assurance Model, that provides more guidance and detail than the original framework.

Having said this, the goal of the model remains unchanged; it strives to standardize identity assurance to allow for provincial and federal systems to interoperate. It is foundational to the broader Pan-Canadian framework, and is key to implementing citizen services across the country.

The identity assurance model is primarily concerned with establishing agreed-to levels of assurance and defining the concepts and terms each party need to understand. It has an emphasis on federation and looks to support risk management activities within partnering organizations.

The Pan-Canadian identity assurance model is represented as follows (click/tap to enlarge):

While this model is an important input into this blog post series, it needs to be supplemented by real-world experience. For each topic in the series, I will inject examples from my experience implementing IAM solutions over the past ten years, and provide insight into the opportunities and challenges offered by the model.

First in the series, click here for the post on Information Classification.

Mike

Mike, Michael. Okay, eh?

Identity matching is tricky. I have been working on health-sector project recently where it really matters that the identity in one system matches the identity in another. When access to patient information is being managed, identity matters. A lot.

So when I boarded my flight today my ears perked up when the boarding agent asked his coworker “Mike, Michael. Okay, eh?” The coworker said she thought so and after checking a list of allowed first name synonyms I was free to board.
Of course, the issue here is that my flight was reserved under Mike and my government ID has my legal name Michael. The airline – fairly recently as far as I can tell – has created this list and added a double check before boarding.

Identity matching matters and I’m guessing we will see a lot more of this type of process implemented for transactions where a high level of assurance is needed.

Mike

Reblog: ISACA Now

Thanks to the ISACA Now blog for posting my article, Eliminating Passwords in the Enterprise!

Managing IAM middleware

middle

There are a lot of different jobs in IT.

My first few positions were in software development. Then networking and infrastructure, and a bit later on, along-side security teams. When I was introduced to IAM in 2003 (then called ‘authentication and authorization’) it was so new there wasn’t a nice, tidy category for it. A few years later, I noticed Oracle had put IAM in a ‘middleware’ bucket so I guess that’s how we’ll refer to it — even if Wikipedia describes middleware a bit differently.

Implementing IAM middleware isn’t an overly natural thing to do. It isn’t the same as the standard application development, server rack upgrade or firewall install. So it can be useful to consider IAM projects and operations in comparison to these three common IT activities:

Software Development — Like application development, IAM has to consider user requirements including usability, attributes and business rules for data. BUT developing a single system is far easier than implementing IAM. There are more system integration points — it is middleware — making it technically more difficult. For a project manager, IAM also has more project teams to coordinate. For example, I’m currently working on a provisioning initiative that has five technical delivery teams and spans two large organizations.
Infrastructure — IAM typically (if not always) involves a directory, and directories, notably Microsoft AD implementations, are paired with operating systems. Infrastructure changes to these operating systems impact IAM and vice-versa. The big difference between IAM and infrastructure projects is that IAM middleware requires tailored configurations and/or custom software components. In a large organization, standard infrastructure (or infrastructure services) can meet their needs. IAM is not so standardized as the management of identity is more closely tied to business needs and strategy. Assuming
Information Security — Protecting privacy and access to information is part of both the IAM and security worlds, and IAM is often described as a sub-set of information security. But IAM is about letting people in and the remainder of info sec is about stopping access… Implementing IAM requires an understanding of these two different views in order to create solutions that meet compliance requirements while still meeting user needs for access.

Managing IAM middleware well is the goal and understanding the differences between IAM and traditional IT practice areas is key to successful projects.

Mike

The mailroom

In the 80s the mailroom was a very happening place. In those days, mail ruled. For a business, the mail was a lifeblood of breaking news and information. Sort of the Internet in slow-mo. With paper.

My sister’s boyfriend, through his good Irish luck and a winning smile, managed to get a contract handling the mail for IBM in downtown Edmonton. This was 1983 and with oil at $28/barrel, local jobs were scarce and decent indoor jobs almost impossible to land.

The summer of ’83 was looking grim for me. I had a couple of gas jockey jobs and those were barely paying the rent. With tech school tuition due in August ($484! Cash money!) I needed to get going. Luckily, my sister convinced this future brother-in-law to take a two month holiday to Europe — and I became the mail room servant for IBM.

The IBM mail room was located in a nice, new downtown office tower and I even had a window. My ‘office’ was a counter stacked with mail, small parts boxes and even the odd heavy crate with the latest IBM tech. I got paid $5.00 an hour.

Each morning the mail would arrive. I’d collect, sort and pile it all into a rickety cart for delivery to individual offices. Rolling along the corridors I must have been quite the sight: bad fitting dress shirt, grey dress pants — topped with a mop of unruly hair and propelled by dirty-white Stan Smiths. The IBM-ers were kind to me though, dropping by my counter to talk shop over bad 80s coffee and even letting me read their discarded Think magazines when they were done…

Every few days I’d help to assemble a mail-out, and what I remember most is stuffing envelopes with brochures, info sheets and specs of all the latest IBM offerings. Displaywriter, System 34, System 36 and the new IBM PC/XT ruled. But Selectric typewriters were still hot items too…

The first computer I ever coded on, a few years earlier, was an IBM 5150 Personal Computer so these shiny booklets were tech porn to my college eyes. By the end of the summer, I’d read everything there was to read on IBM’s 1983 lineup and could have written the Wikipedia entries for this gear from memory (if only the commercial Internet existed…).

I left with a few treasures: copies of Think, an IBM employee handbook and some discarded parts.

But what I left with the most was a love of tech and, true to the IBM motto, an improved ability to think. It may have just been a mail room job but it was my first chance to interact daily with business professionals, talk tech and get immersed in a career IT setting.

Good times.

Mike

A week in the life…

What goes on in the typical week of an identity management consultant? Here’s a sample of my workweek:

Most days start right after breakfast at my home office, and consist of coffee and Twitter. I have a solid list of IAM sources that are streaming new information every minute, and I use the caffeine-loading time to get caught up on news and events.
I usually have one primary client, and for the last few months I’ve been working with a large health organization to implement an identity provisioning solution. This project is highly tailored to the client’s clinical and administrative needs, and must meet the needs of multiple stakeholders. My job, as a project manager and integrator, goes beyond PM — I need to develop business architectures, review/develop requirements and communicate to three different project teams.
I tend to have one or two other projects on the go that I need to personally be involved in. Whether it is overseeing another Code consultant’s delivery or kicking off a new strategy project, I like the variety and interaction that comes from these smaller assignments.
Lunch usually equals surfing: news, politics, Oilers hockey.
I’d try to post monthly to this blog and manage my Canadiam LinkedIn Group at least once each week. Social media is important but easy to get too involved with for little return (IMO).
Business development is important to a boutique firm like Code Technology. Saturday mornings are a good time to check online RFPs and write proposals.
I keep a reading folder going in Dropbox. With the Dropbox client installed on all my devices (Mac, Android phone and iPad) I can easily read an analysis or whitepaper whenever I have an extra few minutes. Currently I have several Gartner and Kuppinger Cole IAM papers downloaded and ready to review.

So that is about it. Even though my work is specialized, variety is the key to serving clients, continued learning and growing my business.

Mike

By any other name

I’ve recently been looking at the implementation of name change processes for enterprise IAM environments. People change usernames, first names and last names for a variety of reasons: marriage, divorce, religion and so on.

According to a reliable internet friend of mine, each year approximately 50 in every 10,000 users request username changes in one typical IAM system. That corresponds to 0.5% each year.

Now that doesn’t seem like a lot does it? But for an enterprise it may be big deal due to the manual work effort involved to make these types of changes. When looking for IAM benefits, the reduction of workloads — for employees, service desk staff and the access team — are always worth looking at.

Let’s look at an example of 10,000 employees, all politely organized in an AD or LDAP that is nicely integrated with an IAM solution. Enterprise applications like email are fully integrated, with provisioning updates pushed out every night. Applications are integrated in different ways. Perhaps a few apps are fully integrated, and use the IAM service for identity (username, first name and last name) and are protected by the IAM login service.

But many other apps have limited provisioning, and cloud-based apps may not be provisioned at all. When a name change comes along, what happens? Well, without an automated provisioning processes offered by an IAM service three things will happen:

the user will have to go in and change their profile in each application.
the user will have to request someone else (e.g. the Help Desk) to modify their profile in each app, or
nothing – the name information gets stale.

So, in this scenario, 50 employees every year need to update their information in one or many applications. The manual work (number of tasks) becomes a simple calculation of the number of name changes multiplied by the number of applications the user needs to access. If there are 50 name changes, and an average of 7 different applications, then that’s 350 manual changes per year, and maybe that is manageable. But if either of these multipliers increase — say you have a dozen apps per user, or you are a much larger organization — then the workload on your users and help desk can become expensive.

Or worse, these applications will continue to have incorrect name data in their profiles. This can lead to follow-on attestation (confirmation of entitlements) problems, audit confusion and other issues.

Understanding your applications and the reality of name change volumes can help to better plan and upgrade provisioning solutions.

Mike

Words matter

I should know better.

I walked into a meeting of business types recently and started talking about their IAM service, how provisioning would be implemented and how SSO was part of the next release. SSO was going to be a good thing. Their users would very much enjoy SSO!

Except that they had no idea what SSO was…

The thing is that the audience — all very capable professionals in their own right — were having a hard enough time with the acronym soup already presented. They were still struggling with the picture of permissions for users being moved from one system to another. They were all still mapping their view of what the application did with what IAM would bring to the table. Their gaze grew distant, shoulders sagged, connection closed.

Why didn’t I just say Login Service? These people login to their computers every day. They login to their online banking, and their Facebook accounts. They login to their phones. They get login.

Words do matter in IAM. Figure out who you are talking to and use the right ones.

Mike