swipe to navigate

Process optimization and automation

Most organizations have less-than-optimal processes for onboarding new hires, adjusting access rights in response to changes in user location or relationships or deactivating access when people leave. These processes, collectively, are referred to as joiner/mover/leaver or J/M/L processes. These processes are usually the end product of evolution made over many years, often addressing no-longer-relevant requirements.

IAM systems are designed to automate J/M/L processes. Before implementing automation, organizations must decide whether to:

  1. Automate existing processes, as-is; or
  2. optimize processes before optimizing; or
  3. replace old processes with best practices.

The easiest choice is to automate existing processes. This is because any process change can quickly become contentious -- different stake-holders have different preferences and may defend their choices forcefully. Moreover, real-world J/M/L processes are complex, so changing them is daunting.

This is also usually the wrong thing to do, except in those rare organizations where existing processes are optimal. Why automate a broken process, rather than fixing it first?

Optimizing existing processes is therefore preferable to automating current-state, but this begs the question: if there will be significant process changes, why not start from scratch? Are organizational requirements so unique that custom J/M/L processes are needed? Is there some reason that best practices developed for other organizations cannot simply be adopted, wholesale?

In most organizations, it is simpler to discard old processes and adopt new, best-practices ones, as compared to examining every existing process in detail and fine-tuning it to improve SLA, efficiency and controls.

The question then is where to find IAM process best practices? Fortunately, a set of such processes is freely available, published on the Hitachi ID Systems web site. There are process definitions for managing the identities and entitlements of employees and contractors in a corporation and for managing the access of partner users to a portal:

Hitachi ID is developing additional process sets, for higher education and healthcare contexts in particular.

Data cleanup versus process automation

Roles are not a pre-requisite to automation

IAM systems automate business processes to grant access to new users, revoke access when people leave an organization, manage access requests and approvals, automate access changes to reflect changing business needs, enforce policies regarding user access and more.

Some people assume that, before an IAM system can be deployed:

  1. Inappropriate entitlements must be cleaned up.
  2. Roles must be defined, to automatically assign appropriate access rights to users.

These pre-conditions to IAM deployment are a myth. Every organization, no matter how bad their access rights data, has at least manual processes to grant and revoke access and those processes work at some level. While cleaning up entitlement data is a worthwhile goal, it is in no way a pre-requisite to automating IAM processes.

On the other hand, once an IAM system is deployed, a variety of processes, including analytics, org-chart construction, data cleansing and more can be brought to bear to support the definition of roles and the automatic assignment of roles to users.

In other words, IAM does not depend on role-based access control (RBAC) and RBAC does not strictly require IAM, but RBAC is much easier to deploy once an IAM system is in place.

Automation is made easier through standardized processes

If process automation requires robust connectors and complex process definitions, then perhaps it really is hard to implement?

In the past, this was true, but today we have reference implementations. A reference implementation incorporates best practices processes for a given type of IAM system -- for example, to manage identities, entitlements and credentials in a corporation or similar organization. By adopting best practices wholesale, an organization can:

  1. Discard legacy, inefficient and possibly insecure processes.
  2. Implement robust processes quickly, at low risk and with minimal cost.

Using a reference implementation such as Hitachi ID Identity Express replaces multi-year, million-dollar, high risk IAM implementations with a deployment that takes just a few months, tens (not hundreds) of days of consulting, and results in feature rich automation without significant risk.

This makes it possible, and actually preferable, to automate IAM processes first and tackle entitlement analytics later. Moreover, with connectors and automated processes in place, analytics can link back to automatic remediation, rather than tickets for system administrators to manually revoke inappropriate access.


Comment via LinkedIn