by any other name

October 31, 2014

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


Where you from?

September 14, 2014

Periodically I have a disconnect with a client or a consulting partner. You know, one of those moments when you realize you are on different pages than you thought you were when the conversation started.

I’ve realized that there are typically two types of people working in Identity and Access Management. The first group comes from a security background, while the second has access administration or maybe more general IT on their resume. I’m a graduate from the second school.

This really dawned on me about five years ago. I was talking to a consultant, who was relatively new to IT, about identity management and how my job was to give the right people access to the right resource, yadda, yadda, my normal spiel. He was listening but had a furrowed brow and I realized he was struggling with the ‘allow access’ part of the conversation.

I quickly learned that he was an ex-military police officer with experience in electronic security systems. He was much, much more interested in blocking access and ensuring maximum security. The idea that we could (and should) make access easier was hard for him to understand.

I have learned that there are some in this business that come from a position of wanting to over-secure everything. If that’s who you are working with, it is best to consider that viewpoint because they won’t be able to move forward with an IAM solution until their primary security needs are met.

But there are also those of us that want a really good user experience even if it means managing some additional security risk. We’ll always look for a design that allows access — while still being compliant with security and privacy —  but is more aligned with client business needs.

Where you from?


Access Anarchy

August 18, 2014

It is no secret that enterprises run on information: records tucked away in databases, procedures retrieved from content management systems and transactions posted by business applications.  These information systems are as varied as the people who access them, ranging from highly-structured data stores to loose collections of images, files and assorted bits.  And cloud computing is flinging corporate information in ever-more places, onto remote servers, accessed by employees and customers whenever and from wherever they like.

access governance entitlements identity managementInformation Security professionals have to deal with questions that probe into information access.  On the surface, management — and their earnest auditors — have a simple question: who has access to what?   After all, access controls have been around for half a century and it is common practice to apply those controls to all types of information.  So what is the problem with these Who Has Access To What (WHAW) questions?

Put simply, security managers fear these questions because they are very difficult to answer.  And these, inevitably, then lead to ‘who gave access to whom’  (WGAW), ‘when was access granted’ (WWAG) and ‘why wasn’t access revoked when Bob left five months ago’ (WWARWBL5MA… okay, enough with the acronyms…)

Auditors know of these challenges but they are obligated to ask the questions.  It is their thing. And they don’t forget they asked — predictably they will return a year later to ask again.

Traditionally security managers would simply work with existing tools and cobble together reports based on information contained within business applications.  Once notice of an audit arrived, the security manager would direct access cleanup, export data from various systems, clean up the data, import data into a reporting tool, create reports, correct reports, format reports and submit them to management.  With anything less than 30 days lead time, this manual, inefficient process puts strain on the team and leads to errors in the reporting.

The main issues here are related to identity and entitlement management.  Let’s look at identity management first.

  • The true ‘source of truth’ for enterprise identity is the company’s human resources system.  No employee gets hired, paid or retired without HR knowing about it.   But what about temporary staff? Or contractors? Or those new employees from the company we just acquired that are in a separate HR system? The source of truth for these individuals — all of whom will have access to information — likely isn’t a single HR system.
  • Digital identities in enterprises are represented as accounts in a directory (typically Microsoft Active Directory or another type of LDAP store).  These accounts are created when employees are hired and removed when they leave.  An account is used to access network resources such as shared folders, content management systems and email. Provisioning of a user’s information directly from HR into Active Directory should be a straight-forward and high-value integration — and, sure enough, many enterprises have solved this problem already. But those relatively high-churn temps and contractors are often left outside this loop, requiring manual processes to create, modify and revoke those accounts.
  • Enterprise applications also require accounts, and these are often unique to each application or application suite.  Increasingly these accounts can be linked to the directory account, but that capability isn’t a given.  Legacy systems may have no support for this type of account linkage let alone any kind of dynamic provisioning.  And even if they are linked once, there’s no guarantee that they’ll be updated as the user progresses through the organization, experiences key life events (e.g. a name change), goes on extended leave, or, ultimately, retires or quits. As a result, gaps result that can be exploited by others who have access to the enterprise network.

Access issues are similarly challenging, and even more complex:

  • Before we get to describing the problem (even amongst ourselves), can we even agree on terms? Quick: what is the difference between an ‘access right’ and a ‘permission’? How about ‘entitlement’, what exactly does that mean?  Do you group users into ‘roles’, or perhaps you prefer ‘groups’?  Each system has its own, often arcane, language for describing what a user can access.  I have no real bias towards any one term but I’ll use ‘entitlement’ for the remainder of this article.  Entitlement is simply any form of application access right granted to a user.
  • ‘What’ is being accessed is similarly a challenge to define.  Some applications give access to all information.  Others have entitlements based on application functions or menu groups.  It is common to only have entitlements created for access to a group of records, or even a single record. Other systems have field level access controls.  And of course we have files and folders… as you can see, ‘what’ is being accessed is difficult to describe.  For now, let’s call all of these ‘information objects’.
  • These objects exist and need to be protected if we are going to keep the auditor happy (or less unhappy). Going back to our access terms, we might control access to one object using group membership entitlement – a common technique with Active Directory and network folders.
  • A business application might also use group-like entitlements that are related to job functions, but instead calls them ‘roles’.  And the roles don’t map to the same AD groups because, well, this application’s information objects aren’t used in the same way as network information objects are used.
  • Another system works from job title entitlements — only users with payroll titles can access the payroll system.  Of course, job titles may have little to do with the application’s groups or roles…and job titles change…

The result is that linking a user’s digital identity to an entitlement, then making sure the entitlement is controlling the right information object is a difficult problem to solve.  In practice, security managers delegate this responsibility to the owners of each business application.  They are given processes to follow for requesting access.  Sometimes the processes for access changes involve an email or two. Or a call to the help desk.  Or a full-fledged Access Governance tool. But in many cases it starts with a hallway conversation…

See where all this is going? That’s right – access anarchy. It seems hopelessly complicated to manage WHAW and we accept the next invite to the audit review with dread.

Over the next while, I’ll outline solutions to Access Anarchy: creating an Access Governance Strategy, having a better understanding of risk, developing standards, implementing software tools, and enhancing training. The key is to embracing the importance of Access Governance to quell Access Anarchy in your organization.

Mike


Old job, new job

August 5, 2014

It has been a while since I’ve had a new ‘primary’ contract so I thought a post on the old and new is in order.

Since 2007, I’ve been the IAM Program Manager for the Alberta Government department of Innovation and Advanced Education. We assembled a development team to build a new IAM solution for the department’s growing online services. Web applications for post-secondary students were the main priority but business partner access to online services and SharePoint sites was also required.

The solution was built on top of Active Directory Federation Services (AD FS) and was developed in .Net. The services developed include self-service registration, authentication, authorization, identity proofing, access administration and reporting. We call it the Secure Identity and Access Management System, or SIAMS for short.

Today, that IAM solution has 650,000 identities, processes over 100,000 logins per month and supports 35 business applications. It supports a host of self-service features like password reset via SMS, and can deliver up to LoA 2 identity proofing.

I’m proud of the team that put the system together and very appreciative of the support I received from Innovation and Advanced Education’s management over the years. Code Technology will remain on the job with Dallas Gawryluk taking over the reins in an expanded project management role.

My new position is as a Systems Integration Project Manager with Alberta Health Services. The IAM solution on this project is quite different, and the job I’m being asked to do is already both interesting and challenging.  Working with multiple teams, I am hired to plan and deliver an implementation of an enterprise IAM solution for clinical users and access administrators.

New faces, new issues — and after seven years, a slightly different commute to work. I’m looking forward to the next year!

Mike


Pan-Canadian Identity Assurance Model

September 17, 2013

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):

identity_assurance_standard

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


Managing Access — an Enterprise Issue

June 4, 2013

I got my start with identity management 20 years ago.  For much of the 90’s I installed and supported networks, and provided system administration services.  In this role I helped enterprises with creating user accounts and granting access to network resources (mostly files, folders and printers).

I’ve recently completed a couple of projects that remind me of those simpler days.  Last year I worked on an enterprise Access Governance project.  This project, for a financial institution, was a challenging to me and important to the client.  The primary driver for the project was to answer the auditor’s question ‘who has access to what’.  This organization, like so many large enterprises, needed to have an efficient method of determining which users were accessing which applications, databases and files.

Reporting on this is harder than it seems. The wide range of financial, human resource, marketing and client self-service systems means that access is granted in many different ways.  User accounts are common for enterprise systems (like network login and email) but often unique for ERP, custom or business area-specific applications.  Even if the same network account is used across enterprise applications, reporting on access (security groups, permissions, rights, etc.) is very difficult to automate. As a result, reporting on who has access to what is pretty much a manual exercise that is impossible to carry out without a significant effort.

There are a growing number of tools that are effective in supporting the type and style of access reporting required by enterprises.  But before the tools can be considered, a philosophy of strong access governance needs to be established.  According to Aveksa, a leader in access governance solutions:

… with business-driven identity and access management solutions, companies can empower the business owners to take ownership of identity and access control, provide consistent, full business context across Identity and Access Management systems, connect to the full set of data and application resources, and significantly lower the total cost of ownership

What makes Access Governance difficult is that it is a new concept that is (I think) widely misunderstood.  Executive management are uninvolved unless a breach has occurred that forces them to take interest.  Senior IT management (CIO, Directors) are feeling the heat from auditors, but have no experience with the new Access Governance tools and methods.  Managers are swamped with ‘real work’, and analysts generally consider the whole exercise to be either ridiculously time consuming or impossible.

The trick, I believe, is to get support for Access Governance as high up in the organization as is possible.  That might be the CIO level, or possibly higher if poor compliance reports or breach incidents are a priority for executives.  Only with senior support can a program be established that will deliver on Access Governance and, ultimately, start to lay the groundwork for an appropriate program.

Mike


Recent IAM reading…

January 3, 2013

I didn’t blog or even tweet much over the holidays, but I did manage to catch up on a few good posts and articles while lazing around…

  • The Quest to Replace Passwords — Extensive report on challenges with replacing password (HT@aniltj).  The table on page 11 is worth a good study for anyone interested how various password-less authentication options stack up.
  • Identity Management on a Shoestring — An excellent report on how to implement IAM in an enterprise without spending years/millions.  Uncanny resemblance to work I’ve been involved with in the past several years, i.e. customized implementations that are not constricted by the cost and complexity of COTS solutions.
  • Economic Tussles in Federated Identity Management — Another excellent paper, this time on the economic issues related to Fed ID.  Points out how successful implementations occur when IdPs, SPs and users all receive benefits.
  • OASIS Identity in the Cloud Use Cases — A list of 29 use cases that are a solid reference for future IAM projects that involve cloud services.  (HT to @RBsTweets.)
  • Gov’t of Canada SecureKey page — A summary of SecureKey and the Canadian federal organization and legislation that supports its implementation.  Would be nice to see a link to the PIA…

These should get your new year off to a good start – happy 2013 everyone!

Mike