The Review and Approval Process

Review, as a process, typically refers to the checking of the request. So we need to understand for what accounts we want to define a review stage, if any – we may not need this. Think about though our privileged access management and some of those elevated privilege accounts, those we may want to take special care over and actually have that manual review process built in. We can have manual checks or automated checks. And we see some automated checks taking place really helpfully as part of a pre-submission process. We will have all seen web forms where client-side JavaScript code checks to make sure that the data we have inputted into the web form meets the requirements of that form.

If you have a date field, that the information in the date field is actually a date and not alphanumeric characters. So this pre-submission check is a very simple client-side check, doesn’t use any of the server side resources. However, that is usually complemented by, post submission from the client, a similar set of checks to make sure that the information meets minimum requirements, otherwise it is rejected. This means that the data we have ultimately posted to our service for the creation of a new user or for any other system meets those minimum requirements that we’ve defined. It has the correct information that we need to process the request further. This is a really helpful set of client-side and server-side automated checks.

We also have the ability to perform automated checks to ensure that an email account exists. We may again want our manual human review at this point, identity checks of supporting information. You’ll remember the level one level, two level, three and level four identity verification types. And again, we mentioned enhanced screening that may involve even interviews, interviewing the individual or interviewing people referred to offered as references. Any additional processes related to screening or verification need to be defined, we need to understand them, and they need to be captured within the workflow. If we have a good electronic workflow, automated workflow, this will cater for the different types of account.

If a particular privilege type is added then the workflow adapts and builds in those additional checks and passes the incident, the creation request, to the correct part of the organization. So again, this is differentiated by the type of account, and we may need branching logic in our review process. We may need multiple processes for different systems.

We then look to have an approval process. And the context here is that the service desk may not be the best arbiter of what access should be conferred. At the very least, they need to have delegated authority from the relevant system owner or from the data owner. So the service desk, when creating users for a particular system or particular service, need to make sure, if they are approving, that they have some delegated authority to do that.

Often pressure to get accounts created and enabled drives the registration process. So this tends to be fairly well managed, the registration process tends to be fairly well managed in as far as somebody is easily recognized as being unable to do their job or undertake their role completely without the account being created. Checks around the copying of accounts are sensible during the registration process as well. Copying from other user accounts is unwise; creating template accounts for different roles is acceptable. Where people copy other accounts – an active directory has this capability built in, you can say, we have a particular role, let’s copy the user in this role and replicate it. This is not a good way to operate.

I’ve seen this many times. The user that’s selected, if they have a slightly non-standard privilege set then that non-standard privilege set becomes replicated out to any users that are copied from that user. So we propagate our mistakes. We need our service standards again to be defined for the approval phase. So, again, this goes to the relative complexity of the approval process and the type of account that we’re approving and the level of checks that we have involved. Automated approval is possible, and it is very fast, of course. But we need to define the criteria that would need to be in place to grant that approval.

If a manager requests a user account is created, is that sufficient, that if all the correct parameters are in place, we’re happy to automatically generate the account? Well that’s possible. So, we may want to check that conditional steps from parts of the data that’s required or the checks have been completed prior to that automated approval. Manual approval is more typical, and this is certainly the case where any meaningful access to resources is granted, for example, in the enterprise. We do see bulk approval, typically used for creating multiple identities that conform to a single role. Role-based access still requires review and approval, and this process is often seen as a scripted process.

Scripting – very, very common in organizations that have large numbers of leavers and joiners that occur within a short period of time. So, again, the example we gave a few slides ago was in education.