The Provisioning Process

So for provisioning, any provisioning process, ideally, should be linked into our incident or case management system, into our service desk. The reason for this is that we need the process to be auditable – the whole process, including the outcome, whether the outcome is successful, or whether the outcome is that the provisioning request failed or was declined. We need to understand the scale again. This is essential if we’re considering manual processes because this would link straight to our service standards. We need our processes to be effective and, again, to support the business. Scripting and automation can manage fairly fine permissions or coarse permissions.

But where we’re using scripting and automation, one of the dangers is that the default approach tends to be fairly simple, fairly coarse permission allocations. So if we’re looking for something more refined, we need to make sure that those scripts work and have some sort of approval process for them in their own right. If we’re creating 4,000 users based on a script, we need to make sure that that script is creating exactly the right type of user. Scripting also requires us to understand the implications of that script. Double-clicking scripts is very easy. But what is the outcome? I’ve seen huge problems here where people have clicked files, assuming that the outcome is positive.

And actually, it’s created duplicate accounts, it’s overwritten accounts, it’s deleted accounts. So we need to be very, very careful. These become very powerful tools. There are tools available to help manage this process for a non-technical or semi-technical users. And these can help enforce the process. We can have restricted views on services like Active Directory through MMC consoles. There are third party applications that plug into directory services, like Active Directory. And they help us manage the provisioning process through the use of a wizard. You enter details, you click next, and it guides people through the process step-by-step. And this is helpful in that it ensures that congruence with our process, with our procedures.

And this can be very useful for temporary staff or areas where we have a high level of turnover. So if you’ve got a staff that aren’t going to be, perhaps, as skilled as they might be, these electronic solutions guide the user. When we’re provisioning, we may want to consider limiting the access. This is very much the case again for contractors, for third parties, for vendors. And we see very often now contractors as a shadow workforce. And many organizations have exemptions from the standard processes for contractors. Are they allowed to bring their own equipment, their own IT equipment, into the organization and add it to the network? I see that.

For third parties and vendors, typically now for remote supportive systems and services, they will want to remote into your network, whether it’s through Thin Client or whether it’s through a VPN. This we need to manage carefully. These accounts sometimes are not named accounts. The account name is in the name of the vendor. This creates a big potential vulnerability for us. Who has access to that account? Who is using the account? How do we enforce that accountability again? Do we have a review point for some of these unusual accounts for temporary staff? If they’re temporary, we should expire the account periodically and seek renewals, seek confirmation that the account is still required.

For the third parties, good practice is that we disable the accounts when the maintenance window is not active, and we raise a change, we go through some kind of change activity, to allow the account to be enabled. If we can have those accounts as named entities, tying them to an individual, that’s great. And we can also shadow sessions. For things like Thin Client, if somebody is remoting into your network, you can actually make sure that that session is managed. All of this helps us manage the risk around some of the users that become treated in a slightly less standard way, that may be treated in a non-standard way.

We see contractors as a growing area, certainly over the last 20 years. And the issues, as we referenced with Ed Snowden, he was a contractor working across a number of roles. Contractors can very easily work in an organization longer than some of the permanent members of staff. If we’re not enforcing the same level of pre-employment checks, the same controls around their accounts, the same conditions, then we may be open to maybe making ourselves vulnerable. Active Directory and other access management tools, as we’ve said, do allow for account cloning. If we are going to clone an account, we should have a master template account that we clone from, not an account that is in use, just for the reasons we described.

If that account that’s in use that we’re cloning from has problems, we propagate those problems forward. So the process and enforcement here aren’t just about your directory service. Also think about all of those line of business systems, your wireless network, your database accounts, your service accounts. We may not treat them all the same, but they should all be subject to processes. And the processes must be actively enforced.