Words matter

September 23, 2014

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


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 Governance Strategy

August 18, 2014

Identity and Access Management (IAM) projects are 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 ends up being launched to fix a specific problem in the business. Projects are expected to be delivered on time and on budget, and then to wrap up after addressing a specific, tactical 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 technical 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 has to 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 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 strategy.
  • 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 management will realize the benefits of having a strategy guide this crucial program.

Mike

(Yes, we can help you to develop your strategy. Please contact us for more information.)


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


IAM for the smaller enterprise

May 3, 2012

My clients find identity solutions to be complex and costly to implement.  For mature and/or large enterprises, these issues are simply a cost of doing business — and compliance or online strategic drivers are usually sufficient to fund and launch an IAM initiative.

For the smaller enterprise there appear to be two paths followed: do nothing or do it poorly.  When done poorly, shoddy IAM implementations  can result in poor credential management, lousy availability and inappropriate access controls.

So how does a smaller company or organization deal with identity properly? How can users be efficiently identified online without building expensive, custom solutions? What service levels and supports are possible for a login service when staff go home at 5pm? How can niche needs like strong authentication be met without excessive server license costs and complex implementations?

Enter the cloud.  Cloud-based IAM service providers are maturing and there are a number of solutions that offer the smaller organization solutions.  For example:

  • Symplified offers a full IAM service that promises plug-and-play integration with surprising depth, including support for mobile devices and apps.
  • PhoneFactor has a slick and secure solution for two-factor authentication that can be licensed on a per-use basis.
  • TransUnion have a robust identity proofing service for the critical process of confirming the identity of an online visitor.

Using one or more of these solutions allows for rapid deployment of IAM for smaller organizations.  The cost savings are considerable and services levels are beyond what most companies could hope to provide on their own.  There still remains integration work — applications need to be ‘plumbed’ to inter-operate with the cloud solutions — but all the heavy-lifting of designing and configuring a solution is eliminated.

The maturation of cloud IAM solutions means an increased number of companies can implement secure and compliant solutions without the long lead-times and high cost of traditional product-based offerings.  In this age of rampant data breaches and increased focus on compliance, this is a welcomed development.

Mike


Assessing IAM

June 8, 2011

My experience with formal technology planning spans over 20 years.  As an external consultant, I have the advantage of being objective, and can offer fresh insights as inputs to planning and strategy development. However, as an outsider, coming into an organization to perform planning can be difficult because I often lack an understanding of the infrastructure, software and procedures in place.

As a result, the planning methodologies 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 has worked well when doing large project planning, IT strategy work and program development.

Assessments are also 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 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.  Analysis of the environment is then performed using  the seven Pan-Canadian IdM&A components:

  • Legal –Under what legal agreements and legislation does the organization operate?
  • Privacy – How well does the environment match to privacy obligations?
  • Security – Does the current environment meet or exceed information security standards?
  • 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 plan and design improvements and new solutions.
Mike
Code Technology is now offering its standardized IAM assessment service across Canada.  Please contact us at info [at] codetechnology.ca for more information.

The case for less ocean boiling

May 8, 2010

I don’t know who invented the term ‘boiling the ocean’ but it is a great description for projects that are too large, too ambitious and, ultimately, headed for failure.  Identity management projects run the risk of being setup to fail because their sponsors are trying to boil the ocean.

The problem lies in the scope of a typical IAM project.  These projects can often try to do far too much — the sponsor and project manager confuse the bigger, long-term goal with the project objective.

In a IAM strategy report I completed last year, my recommendation to the client was to use a phased delivery approach:

Smaller projects are easier to manage because they have a single focus and set of outputs to produce.  Adjustments to follow-on projects can be made based on lessons learned.  And with shorter projects, management can more frequently see the real results as each project completes – reports/briefings can be written and financial benefits documented.

Since 2007, I’ve been working as the IAM Program Manager for another client and putting these ideas into practice.  This program has been established with eight releases.  Each release is a project that runs between six and eight months, depending on the current needs of the business and our sponsor.

The key for keeping these projects short is scope management. The scope is determined a month or so before the project starts.  Inevitably, we get a change in scope sometime in the first few months — a new application needs to be integrated, the auditor wants a critical feature added, etc.

As any project manager knows, the triple constraint means that if you increase your scope, you can either extend the project schedule or add resources (and cost) to get the work completed on time.  This triple constraint is often addressed by clients by pushing out the schedule.  This also increases cost of course, even if the team size stays the same.

My philosophy is a bit different.  I look to trade off scope for… scope.  If six weeks of extra work are added, I will look to see if six weeks’ worth of scope can be removed.  Lower priority work can often be removed from scope and planned for the next project.

In other words, I want to keep the project schedule and costs fairly static so that the team can focus on an end date — and, by extension, new work and a new project after that date.  In a longer term program I place a lot of value in delivery.  The sponsor needs to see solutions delivered and projects closed.  We must be able to report to senior management actual business value and a list of real accomplishments, not just the percent complete on a project.

The end results are higher team movtivation over the long haul — in three years, I have had zero team turnover — and better, more measurable business results.

Mike