What Processes Are Important?

So we have a manual or automated processes. Both are entirely valid. And this isn’t a binary option. We have degrees of automation. By way of example, we can have a manually reviewed pre-approval area for accounts that have been automatically provisioned, where somebody individually agrees those accounts. We can have some form of electronic data capture, whereby the key components of the provisioning request are placed into an electronic form for somebody to– it’s a supplement– to add additional information to. Whatever we choose, we need to be clear on the processes that we have, those that we’ve approved, and how they operate. We also need congruence between what we say we do in our policies and procedures and what we do in practice.

Also, logically, we need some way to check that this is happening. And this is our auditability. We need some kind of enforcement. And this typically falls into two realms. We can have administrative enforcement, where we direct people, we tell people what they must do, how they must behave. Or we can technically enforce behaviors. The only way to complete the task is by following a technical workflow. Of those two approaches, the second is far stronger. Forcing people to follow a technical workflow means that there’s no option, no alternative. We also need to consider scale. And this may influence our choice of processes.

I mentioned scale because we’ll look at a case study towards the end of this course, where there was a huge scale of registering citizens over a very short period of time. But also day-to-day, in some organizations, the scale may necessitate or dictate the type of processes that we have. If we look at higher education, universities, they can have 4,000 users, maybe more, leaving or starting on the same day. In this case, we want to consider either automated provisioning or scripted provisioning, where we start to take input files, things like CSV files, and we use that alongside a provisioning script to generate the credentials, and potentially even to issue them as well.

Latency relates to the type of process that we have and also to the level of sensitivity. We need to understand what the latency is, the delay, the time period for the process to complete. And we need to define this in the process and also in any related service standards. Two good examples. The first is military credentials. They may have some extensive background checks that could take weeks or even months on occasion. I’ve seen months not be unusual for a time period for clearances for military access. If the expectation of the management team or the individuals is that it will be faster than that, then we have a mismatch of expectations. So we need this to be very clear.

We also see semi-automated or automated provisioning sometimes occurring in batches overnight. And the same is true of deprovisioning. So if we link our HR system to the creation of user objects within our organization within our directory, then at that point, if the provisioning is overnight, that may be fine. It may be fit for purpose. But it may not. If you deprovision somebody overnight, there’s a period of access beyond that employee departing a building. So access by that individual may still be possible. So we need to think carefully about our requirements, about the process, and about how we communicate the outcome of that process, that approved process.

So with automated provisioning, we mentioned HR data– typical source of information for creating user accounts. We also can use automated provisioning through the use of ERP-type systems or CRM systems. Microsoft Azure and other directory services now have very good connectors. Most third party developers will develop for the standard user repositories and allow you to federate your users from one of these systems to others.

Incident management integration refers to the fact that we can start to integrate the service desk systems into our user repositories as well. At a minimum, our identity and access management system, we would want to ideally integrate with some kind of information on an automated or semi-automated basis from a HR system. This allows us to trigger the set up, the creation, any modification related to the change of roles – remember, our role-based access – and also, any deactivation or deprovisioning processes. We may want to include checks for any changes.

For example, with regard to deprovisioning, if somebody is leaving for a period of time and is perhaps deprovisioned from the payroll system, but is still an employee, perhaps we want to double check that. What we do see is the manual processes tend to be far weaker than the automated processes. Over the many, many organizations that I’ve worked with in an audit capacity operationally, the manual processes where managers are asked to complete forms at a point in time when a certain circumstance occurs, you’re relying on the memory and the awareness of the individual manager to follow those processes. By linking something to HR data, that semi-automated or fully automated process can be stronger.

Active Directory can be used to provision other accounts as well. It doesn’t just connect to other third party services to receive information– for example, Exchange for email services. And we can start to provision automatically things like file services, home directories. I mentioned Windows. There are different directory services out there. The alternative products, such as Lotus Notes, offer similar features and capabilities. An identity and access management system can allow for, or an effective identity and access management system should allow for exigent circumstances to be managed. So although the automated process is the default, if we have something that needs to be done differently, somebody with the relevant permission can override this.

Not every automated process will capture all requirements or all needs. And having some kind of manual check makes sense in terms of reviewing what’s happening and having an oversight, but also the ability to, again, offer that override. As we mentioned with automated processing, we want to consider the latency of the process. So the initial registration, we have the request generation, the request checking.

The request medium: how is the request raised? Is it on paper? Is it through a web-based form? How is the request then subsequently processed? For our registration process, we need to think through all of these different areas. And it may be that we have multiple approaches. If as an enterprise, we have customers who register online for our services. If you are an e-tailer, you have an online store, this is typically what you would want as part of your registration process. Your registration process for internal users will almost certainly be different. So we need to understand how the request is initiated. Do we require sponsorship from a trusted source?

So for our internal users, typically a new user request should be raised by a manager or should be approved by a manager. Whether that’s through the manager creating the relevant HR data that then is provisioned into our other systems, or whether that’s the manager creating the request directly, the manager becomes the person accountable for that activity, for creating that user. We need somebody with authority to sponsor it. For our customer accounts, again, we may require far less information. Different ways we could consider registering people are typically telephones, online, emails. Ideally, though, we want some kind of workflow management tool.

Something that is going to capture the data, not require the data to be re-entered, because we have a potential for the data to be changed or re-entered incorrectly. And that workflow management tool then makes sure that any permissions, any privileges that are afforded, are appropriately managed, that the workflow follows the correct steps that we have defined.