Whether in the guise of increasing regulatory pressure, or through a credit-crunch-driven round of redundancies, most organisations of more than a handful of people need to verify the IT access their employees have, comparing this regularly to the rights they should have.
Both in my own experience and through stories of others, it seems most large organisations are woefully bad at doing this – most often conducting adhoc manual reviews, orchestrated by an overworked IT Security team. These are almost always achieved through mailing Excel spreadsheets, or people wandering the office with printouts… “Are you the owner of this system, and if so, what does it do?”
There are far better ways of doing this – both as a one-off, and as a regular exercise.
First step – People
Firstly, you need a good source of people data – ideally your HR system or some kind of directory containing names, job titles, locations and line managers of your employees. It’s important to be able to trust this hierarchy – there’s little point worrying about access rights if you’re not sure whether someone’s still an employee, or who they work for.
Current access rights
Once you know who all your people are, who their managers are and what job they do, you need to determine the access they have.
If you’ve got a provisioning system, great – this will already have a store of the rights in most of your key systems. If not, or for systems beyond the scope of your provisioning tool, you’ll need to capture the user access rights.
For critical applications, you might be forced to report on this sort of thing anyway, but if not, get into the habit of capturing simple files of users and group memberships.
Validation – the challenge
So you’ve now got an employee hierarchy and a series of application rights. To validate, it’s just a matter of checking with a given user and his/her manager that the access is what they need and no more, right? That’s a great theory, but most business managers have no idea what group TRD47 does or why you need to be in it or the hundreds of others that you’re in.
Here’s where that ‘better way of doing things’ comes in – most identity & access vendors now have products for role mining & certification.
Let’s take a big warehouse and into it pour all those lists we collected earlier. Next, we’ll take the following steps:
- Get line managers to confirm their direct reports
- Get system owners to describe each access group for their application
From here, we can run some pattern matching giving output like these:
- All employees get a mail account and Windows login
- All IT staff get admin rights to their workstation
- All traders get access to the trading system
- HR get access to the HR system
Starting with really broad definitions that cover as many people as possible, we gradually narrow down on individual teams, defining the rights they have into business roles. When we’re happy, we can start to validate these roles, having the IT organisation confirm each permission group.
This leaves business managers just to confirm that employees have one of these ‘friendly’ roles.
The second time
Once you’ve captured these role definitions and validated them (and their exception cases), it’s relatively easy to maintain this and conduct regular audits.
Whenever a new system or group is created, this gets captured. If you release a new application, you’re most likely aiming it at a set of users, and this should already have been defined as a role (the London sales team, for example), so you add the new system to that role.
When it comes to your next certification cycle, you need the role owner to confirm that a given role still contains the right systems, and you need line managers to confirm their employees. Much easier than trawling around with Excel.
In between certification cycles, things are much easier too, especially when you tie your role management tool directly to your provisioning solution (this is pretty easy, as all support standards-based communication). If an employee moves within the organisation, you don’t need to worry about what systems they need access to, or cleaning up the access they had – you’ve just got to add the new role to their profile, and take the old one away.
Likewise for a new joiner or a leaver – their access is well defined, so you know exactly what to give, and what to take away.
So next time someone mails you a spreadsheet asking you to describe what a system does, and who should have access to it, tell them there’s an easier way.