The other day I was talking to an acquaintance who has been, not particularly enthusiastically, dragged into an identity project from her usual role of security architect. She said they were starting the project the way everyone does: by examining the onboarding process. “Such a bad place to start,” I heard myself blurting out, “… though everyone does”, I lamely followed up, and the conversation moved on.
I’ve thought about it a bit more since, and I’ve decided that “speaks-without-thinking Carol” was onto something. A better place to start mapping processes and planning the groundwork for identity automation is the other end of the lifecycle. That is, start by looking at the processes for account termination, permission deactivation, group deletion or resource archiving, and figure out what you’d need to have in place to be able to automate that.
I can already imagine myself trying to explain this to anyone who isn’t a veteran of identity automation – the blank looks, the irritation, the immediate assumption that I’m trying to “over complicate” what is surely a “quick win”.
I’d argue that a focus on deprovisioning forces us to look at the whole data set. Creating a new account, however convoluted your business processes, is the easy part. The real work is in identifying all the existing digital identities of interest, linking them to their managed source record, and tidying up processes so we can easily know when they’re no longer needed. If you were to start your identity automation project with deprovisioning, you’d have a lot more ground work to do, but you would end with a much cleaner data set, better incorporated processes, and a more “fit for purpose” solution that can be extended to other use cases. If, instead, your classic Phase One plan is to “create new accounts for new people, and figure out the rest later”, all you’ve got is the orchestration of that one task.
My main concern is that a tight focus on provisioning can, and does, lead to bad decisions. Sure, your tool or script or bright idea to orchestrate using the service ticketing system can create a user account. As I’ve already said, that’s the easy part. The hard work is in properly managing these digital objects – when to update them, when and how to change what they have access to, and when to switch them off. In IT, we’ve probably all seen the results of automation that was set up to create but never delete. The worst systems are the ones that generate crazy numbers of groups, shared resources and service accounts, or bulk-create accounts for external users that will never use them. All of these digital objects, so easily created, come with a maintenance cost that gets particularly onerous at times of migration, merger and large-scale systems change. They also increase the cyber attack surface, so we all know they should be purged, but the level of forensics needed to determine which ones are still needed is as tedious as it is onerous, so always ends up on the “do later” pile. How different would things be if, every time we created something, we also had to plan for it’s eventual deletion?
I know that no one would really do an identity management project that starts at the end and ignores the beginning of the digital identity lifecycle, but we can at least argue for doing both. Automation that adds to the pile without also clearing away is only creating more headaches for the future.
