IAM: an undervalued skill and a full-time job
09:00 Thursday, 17 June 2021
UK Cyber Security Council
Wikipedia defines Identity and Access Management (IAM) as “a framework of policies and technologies for ensuring that the right users (in an enterprise) have the appropriate access to technology resources”. Frankly, this understates the importance of IAM in the organisation.
IAM can be very straightforward in companies that are relatively new and/or have an authentication regime that has been built with IAM in mind. Unfortunately, the average organisation has a wide variety of technologies, of various ages and various levels of 'bespoke-ness' – which means that one generally has a hybrid setup where some applications and systems authenticate against a central user database – generally Microsoft’s Active Directory (AD) – but others are stand-alone and have to be treated as special cases. Organisations that have been around for more than 20 or 30 years will generally be saddled not just with technology that doesn’t authenticate against AD, but with technology that can’t do so.
The average IAM regime will have three types of authentication: single sign-on based on a central directory service; applications with their own internal user databases; and applications that aren’t managed within the organisation, where one has to contact a third party to request user provisioning and de-provisioning. It should come as no surprise that the third example is the hardest to deal with.
Let us hold that thought for a moment while we look at the most critical elements of IAM. We said earlier that our aim is to “[ensure] that the right users … have the appropriate access”, but this is a multi-faceted concept with some easy elements and some difficult ones. Ensuring that users have enough access to systems is very straightforward in its basic form: if you provision a user’s access to a system and you miss something (or, more commonly, whoever requested the access forgot to ask for something) the user will be in touch asking you to sort it out. Leaving aside the obvious annoyance to the user and loss of productivity, the IAM problem of provisioning users’ access largely fixes itself with no need for the IAM team to be proactive. The challenges in IAM are not, therefore, in ensuring people have sufficient access: they are in ensuring they do not have excessive access, and that when they leave the organisation, their access is de-provisioned.
With this in mind, let us return to the concept we declared “hardest” a moment ago: an externally hosted application into whose access control mechanisms we have no visibility. Now consider a situation in which we engage a service provider to do some work that requires them to access such a system; they have a team of people for whom we ask the system provider to provision access. Perhaps surprisingly, this is one of the most problematic scenarios in IAM. Why? Because unless we take deliberate steps, we have a complete lack of visibility over who has access to what.
If we engage a contractor to do a piece of work for us (a project manager on a six-month term, say) we as an organisation are highly likely to know when he or she joins, and later leaves, the company. If we engage a third party to get their team to do some work for us – mass data entry, for example – the people doing the work are faceless to us, and are just a list of names on a form or email. We will probably not be notified when someone leaves the service provider’s employment: even if the contract stipulates that we should be told, the notification will often be late or even forgotten completely. The “a framework of policies and technologies” mentioned in the definition of IAM becomes more essential than ever.
The definition misses an important point, though: policies and technologies don’t cover the whole spectrum of IAM. In the above scenario, people can fail to follow policies and no amount of technology will allow us to monitor IAM for an application whose access provisioning involves us filling in a PDF or Microsoft Word form and emailing it to the supplier. In such cases the people dealing with IAM need to be proactive – requesting regular lists from the supplier of who has access to what, for example. They also need to be involved in regular service reviews, to ensure that sub-standard performance is stamped on quickly. And if there is a need to take on a new service that cannot be integrated with the corporate AD database, they need to be involved from the very start in order to ensure that the IAM process – particularly monitoring of access and de-provisioning of leavers – is as good as it can be made to be.
Why, then, do so many organisations use their most junior people to do IAM? Access provisioning is done by the front-line, level 1 Service Desk staff who follow a step-by-step guide of what to click on and what to type in order to provision a user. They don’t apply any in-depth IAM knowledge, or any consideration of the risk of what they’re provisioning, because they’re just out of school and they don’t yet have (and can’t be expected to have) those skills. Many organisations lack the skills – and often the people – to do the more complex tasks of verifying access controls and making sure deprovisioning is done effectively and promptly.
So, by all means have your junior teams do the mechanical, hands-on provisioning and de-provisioning. But if you are to avoid descending into a spiral of overprovisioned users and un-de-provisioned ex-staff, ensure you have the people with the skills, knowledge and experience to do it.