Why is Identity Management so difficult and expensive?

It’s not uncommon to see organisations get sold on the idea of Identity and Access Management, but as soon as they’ve defined their requirements and gotten quotes from vendors they usually end up with some serious sticker shock.

Deploying Identity and Access Management (IdAM) solutions aren’t like your standard IT projects. Replacing an aging backup solution, upgrading all your Windows boxes to the latest and greatest version, upgrading Exchange, or moving unwieldy shared folders to SharePoint all pale in comparison in complexity to an IdAM deployment. Plus those types of projects have definitive conclusions that are then passed (or thrown over the fence) onto Ops for management, but IdAM doesn’t work in that model.

Hopefully this post sheds some light on the reasons why it’s so difficult and costly to implement an IdAM solution, but also to show you areas where you might be making savings.

The software is only a fraction of the cost

IdAM software can be is expensive. Generally they’re licenced per user, and then additional costs are added for how the solution is deployed (number of instances, connectivity with other systems, back-end infrastructure, deployment infrastructure, and so on). Even if you go down the FOSS path (yes, there are FOSS options), you’re just transferring the cost to somewhere else, like increased development and support time.

Another factor in the cost is the types of users that are being managed. Generally they’re piled into two buckets, “internal” and “external”. “Internal” users are your actual employees, and “external” users are everyone else (for instance, your customers or anonymous users utilising your services).

Once you have the licencing sorted, the rest of the cost materialises in the form of professional services, support, training and ongoing integration. A large IdAM solution can, no should, take more than 12 months, because of the rest of the reasons below.

It’s not just a software installation, it’s a change in business processes

You can’t just install an IdAM solution and expect that to be the end of the project. Most of the products out there don’t actually do anything out of the box. The bulk of the work is the integration with all the other products within your organisation. Connecting Active Directory, HR systems, Payroll systems, corporate wikis, intranet websites, VPN services, and so on. So, naturally, the IdAM solution is going to affect more than just the IT department.

Once these services are now centrally managed within the IdAM solution, you’ll have to change how the business operates to fit these products. Users requesting access, password resets, account modifications, access provisioning, managing system administrators, etc. all have existing defined processes around how they’re done. These processes may just be “go ask Bob for access and he’ll make it up as he goes along” or it may be formal documentation stored in the document management system, or KB articles that the helpdesk manage.

All of these processes will need to be documented, replaced, and then everyone needs to be aware of the change. Too often I’ll see business process change, but only a few people are aware of it and the old process still gets followed by those out of the loop.

It’s worth it though. Having all users, groups and roles managed with access requests and approval processes all through a single interface gives you that absolute control in your organisation, and you can quickly eliminate all of the old redundant processes that are kicking around.

Staff will be automated out of their jobs

Once your IdAM solution is fully automating account management across every service in your organisation, you’re most likely going to find particular staff members are going to have a lot less work to do.

This can be a positive outcome, as 1st-level help-desk staff will ideally have to deal with trivial matters less (and are freed up to fight real fires), back-end IT staff will be called in less to provision accounts in systems, security staff will complete their audits much faster, and users will get access to systems they need faster to do their jobs.

So while you may see the IdAM solution eating up more of the IT budget, you may free up multiple positions (and buckets of money) elsewhere in the organisation. But of course you’re going to get push back from those that are threatened by the change and the impending loss of their jobs, and the larger the organisation the more likely this will be an issue and drag out the implementation phase.

Sysadmins are going to fight you

Sysadmins love control. As they should, it’s their job to maintain control so that they can fix problems as quickly as possible. They want to keep access to root and admin accounts. They want to be able to quickly unlock their accounts when they realise that they had accidentally used their own credentials to set up a scheduled task and it keeps locking them out after they changed their password.

But, they need to lose these privileges. They’re too much of a risk to the organisation. Sure, you need to keep some “break-glass” accounts on hand to cover you in the event of an emergency, but those need to be kept physically locked away somewhere, like in a safe. They should only be using shared privileged accounts if the job their doing at the time dictates that requirement, and the rest of the time they should have no idea what the credentials are for it.

Some of the IdAM products out there offer “PAM” (Privileged Account Management) services as an extra feature. These are great for managing all the shared accounts on servers, but you need to make sure your admins don’t just find a way around the tool so they can work faster (see the bit on SIEM below).

IdAM becomes the single point of failure for your IT services

What happens when you connect every product to an IdAM service and it goes down? Well, nobody in the organisation can log into anything. The business grinds to a halt, and everyone is looking at the person who built it.

Like any critical IT service, IdAM needs to be deployed in a highly-available architecture. You need multiple instances across multiple sites (if you have that kind of infrastructure). You need a fast disaster recovery solution to restore it in a failure, and you need a proper test environment to weed out any problematic changes.

This is going to drive your cost up if you need more virtual hosts to service the design. The good news is most of the products out there can handle quite high workloads, and they usually all support working in some clustered arrangement.

Security solutions are invisible

It’s always hard to sell the concept of security to people, as it’s like buying insurance or maintaining personal fitness. The only way you can measure success is looking back after 5, 10, 20 or more years and asking “did we keep our data, employees and customers safe?”. It gets hard to sell that to the C-level (especially when they have to show success this FY), so most of the InfoSec industry rely on FUD to sell the products.

IdAM solutions aren’t exempt from this perception problem. Just like a good sysadmin, once they’re up and running properly they will give the appearance of doing absolutely nothing for the business. And it’ll definitely be under the magnifying glass when budget cuts come around, so the value to the organisation of time saved needs to be flaunted (and it’s usually quite easy to measure that value if you capture the right data prior to the IdAM deployment). A flashy front-end usually helps too.

You can also help sell the concept by looking at the cost of data breaches. Vendors love to publish this kind of information as sales tools, but it does highlight the fact that if you don’t have a breach, you haven’t had to spend (on average) USD$4 million from dealing with it.

The project tries to tackle the entire business at once

The biggest contributor to the sticker shock for IdAM solutions is organisations wanting it to be a total overhaul deployment within some arbitrarily short time-frame. This is a guaranteed recipe for failure as it (like the majority of IT projects) will blow out in time and/or money, and whoever is giving you the invoice is going to add more money to it to account for the deployment risks. The best approach for implementing IdAM is to roll it out in small phases. Your users will feel a lot better about it too as they can get used to the slow transition.

Here’s one good approach:

1. Install the IdAM solution.
2. Connect it to Active Directory (assuming you’re using AD of course…) to be able to centrally manage AD accounts and groups.
3. Set up password management capabilities for users.
4. Change the password reset business processes to now use the IdAM solution.
5. Connect another application to the IdAM. HR systems are usually good to hook up first.
6. Set up provisioning capabilities to the HR system.
7. Set up processes so that helpdesk/admin staff can assign users to be able to access the HR system. Make sure users don’t have to authenticate with separate credentials.
8. Repeat steps 5, 6 and 7 with every other service that is inside the organisation until you’ve captured them all.

This works quite well as you get to encapsulate all of the negative impacts of business process change within individual groups in your organisation. You only have to deal with the HR people at once, then the payroll people, then the sysadmins, and so on.

You can’t avoid software development with IdAM solutions

Some organisations try to avoid doing development work internally as they don’t like bespoke solutions. It would be nice if there were a COTS solution in the IdAM space, but there isn’t. The sheer fact that it’s required to be connected to so many dysfunctional systems means that a developer is needed to jump in a establish that connectivity between services.

Not every piece of software can handle being integrated with an IdAM. Your sysadmins might be using some FOSS wiki solution for their internal documentation that only supports LDAP authentication. Your project management tools might be a bespoke solution because nothing on the market could meet your needs. Your HR system might be a cloud solution that isn’t a commonly used one, but you got a great deal on it and the other options are too expensive to migrate to. You might be managing a ton of legacy applications that keep floating around for critical services (I’m looking at you government agencies).

These products require a developer to write up provisioning and management scripts/software to work with the identity solution so you can still get that holistic management. There’s no way to avoid this. The vendors will say “oh yeah, we provide connectors for everything!”. This translates to “we give you the tools, but you’ve still got to put the pieces together to make it work”.

SIEM goes hand-in-hand with IdAM

It’s all well and good to have an IdAM managing all your business process for Identities, but it’s of absolutely no value if you’re not monitoring anything happening outside of it with a SIEM solution.

If somebody creates a local administrator account on some server, your security team needs to know about it immediately. Not when the bi-annual audit occurs and valuable information has already been stolen. They need email/sms/pager/smoke signal alerts being sent out straight away. Wherever the IdAM solution has gaps (which they all do, no matter how awesome the sales guy tell you their IdAM is), the SIEM and alerting processes need to fill those gaps.

So, if you’re not really collecting and analysing logs properly, it’s probably time to get that sorted too.

It never ends

You can’t “complete” an Identity Management project. It just becomes a part of operations. New processes, groups, products and people are entering and leaving your organisation all the time. Your IdAM solution will become useless if you don’t nurture it. I’ve seen organisations capturing requirements for what needs to be connected to the Identity Manager in an all-encompassing architecture/design document suite, only to have the current architecture change underneath them before the new one is even approved.

You will always need an Ops team to keep the IdAM running and ready to integrate with your changing business. This is an ongoing cost that needs to be considered, but if you can get the new solutions integrating with the IdAM first, then you’ve made a huge saving already. You may even spec new services that are more IdAM-friendly, like supporting direct provisioning through a RESTful API and direct federation with Identity Providers (instead of using archaic authentication protocols).