Credential Issuance and Managing Change

When we’re issuing credentials, this is simple conceptually but is very difficult in practice. We need to consider a secure channel of distribution. Is email a secure channel? What about if the credential we’re distributing is to the email account? I said before, I said in a previous section, I once had a new account password emailed to me, but the password was for the email account. That process was very poorly thought through. So this may not be possible if the credential is a foundation access to services to send it electronically. How do we generate and how do we issue those credentials? It’s important to think through. Email is not considered secure.

When we’re sending an email, it’s sent by default as plain text over the internet. It’s like sending a postcard over the internet. So we need to consider what security is appropriate and is required. Here we consider the different types of channel that we may wish to use. Do we want to present the credentials in-person with identity verification? So an individual has to present themselves in person and present some kind of additional identification in order to have the credentials released to them. For some PKI keys that I receive, I had to travel 200 miles with my passport, with lots of sensitive information to prove who I was in order to receive the private keys. Very, very high-security operation, required in-person approach.

Credentials may require active enrollment, for example, biometrics. So we may need the person to be present because we need the biometric measures to allow the credential to operate correctly in the future. The use of additional channels, though, is typically more secure, as with authentication. So if we’re issuing a username and a password, perhaps we consider sending them via different channels. We could send information relating to the username back to the requesting manager, and the password is handed to the new employee when they present in-person on the first day.

So this use of additional channels is very, very common in a high-security environment. This is typically a balance of speed, cost, and security. Again, we’re trying to make sure that something works, is practicable, but also is secure. Companies want to remain competitive, and additional costs are not very appetizing. Especially for customers. When we’re enrolling customers, typically you see a very low threshold for enrolling a new customer. So speed can be important. What would happen if Amazon took 48 hours to approve a new account? So this can be difficult. We need to gain agreement for this process from all stakeholders, and we need to find the correct balance. And there will often be conflicting interests.

As with most of these processes, we can consider different processes by the level of privilege granted. So more onerous processes are applied when we have credentials that are issued with greater privilege. This is the area we do least well, absolutely. I’ve audited hundreds of companies over 20 years. And consistently, this is the area we struggle with. And this is the area that gets a lot of press as well. So the example we’ve given already is Ed Snowden, where people move within an organization, where we change our positions within an organization. So provisioning an account is a very obvious step. Managing change requires much more diligence.

So if somebody requests additional access, firstly, we need to understand whether or not we need to revoke any existing access as part of that assignment. So the additional privilege allocation may prompt a review of the access, of the existing access. We want defined processes for dealing with any suspensions. We want processes for exigent circumstances around revoking privileges. If somebody is fired, we need to be able to deal with that instantly and in a very fast and secure way, and in a way that secures the broader asset base of the organization. If we suspect that credentials have been compromised, certificates or tokens, we need a way of revoking them.

PKI infrastructures that we’ll look at in the technical section do allow for this revocation. We can revoke the private key, and any future transactions will be unsuccessful– very powerful. So we need a process. We also need our service desk to have a process, the security teams to have a process. What follow-on activities are required here? If we have an exigent circumstance, maybe we can process it, but do we need to follow up on any of the information that’s been passed to us? So we’re typically better at provisioning than we are at managing change. So we need to be very careful around making sure that we continue to provide least privilege. Really easy, again, conceptually, very hard to do in practice.