I was having a discussion this week with a colleague, regarding identity management transformation projects and how organisations get from the often deep quagmire of complexity, low re-usability and low project success, to something resembling an effective identity and access management (IAM) environment. Most projects start off with a detailed analytics phase, outlining the current 'as-is' state, before identifying the 'to-be' (or not to be) framework. The difference is wrapped up in a gap analysis package, with work streams that help to implement fixes to the identified gaps. Simples right?
IAM is renowned for being complex, costly and effort consuming from a project implementation perspective. Why? The biggest difference to for example, large IT transformation projects (thinking enterprise desktop refresh, operating system roll-outs, network changes and so on), is that IAM tends to have stake holders from many different aspects of the business. A new desktop refresh will be ultimately decided by technicians. Business approvers will help govern things like roll out plans and high level use cases, but not the low level implementation decisions. IAM is somewhat different. It impacts not only technical administration of managed resources, but also business processes for things like access requests, new joiners, team changes and so on.
IAM Becomes A Security Issue When It Doesn't Work
IAM is often seen as part of the security architecture framework. This makes total sense. The management of subjects and their access to data objects is all well understood, with loads of different access control mechanisms to choose from (MAC, ABAC, RBAC etc). However, IAM should really be seen more as a business enabler. I always like to pitch IAM as the interface between non-technical business users and the underlying IT systems they need in order to do their jobs. 10-15 years ago, when IAM started to become a major agenda, it was all about directories, (meta, virtual, physical, partial, synced, any more terms..?) and technical integration. "Developing a new app? Whack some groups in an LDAP for your authentication and authorization and you're done". The next step was to develop another layer that could connect multiple directories and databases together and perform multiple account creations (and hopefully removals) simultaneously. Today IAM is more than just technical integration and provisioning speed. It's more about aligning with business processes, organisational team requirements, roles based access control, reporting, compliance and attestation. All of these functional areas have use cases that touch business users more than technical users. However, if those IAM services fail (access misuse, insider threat, hacked privilege account) a security incident occurs.
Think of IAM As Building Data Routes
During the continued discussion with my colleague, he brought up the notion that IAM is really just about data management. The movement of data between silos, in order to get it to it's destination in the most effective and efficient path. IAM data could originate from an authoritative source such as an HR database, before ultimately being transformed into a system account within an LDAP or database. The transformation process will require business understanding (what will the account look like, which roles, permissions, what approvals are required etc) but none-the-less a new piece of data will be created, which requires classification, auditing and reporting. Just the same as a file on a share. By breaking down the entire IAM elephant into bite sized chunks of data creation, transformation and output, you can start to make the implementation process a lot more effective, with re-usable chunks of process and project machinery.
Like with any large scale project, it's often the smallest footprints that make the biggest impact. In the case of IAM, taking small, but smart data management style steps, could be the most effective.