How to establish a trust anchor (AKA: Digital onboarding of remote employees)

Image by Romain Dancre <> via <>

The following scenario should sound familiar for most of the readers who had to work from home during the recent pandemic.

Your day starts and you sit down in front of your workstation. You turn it on and you are prompted for your credentials. Some form of more-or-less sophisticated multi-factor authentication (MFA) helps ensure that you indeed are who you're claiming to be. That way, your organization makes sure that only the right people can access its resources.

Putting aside the many challenges that this scenario presents under the hood, the truth is that we know quite well how to solve them. We know what methods, technologies and practices can be employed, and which can't or shouldn't.

However, the recent pandemic has uncovered a fundamental weakness, common to most organizations. Before 2020, the typical process would go as follows.

  1. I want to work from home, so I'll need to have access to the company network or systems from my home office.
  2. But wait! In order to do this, I'll need to provide some additional assurance on top of my password (otherwise, anyone who stole my password would be able to access). We know this as MFA. It could be a code sent to my phone, for example.
  3. But wait! In order to do this, I'll need to reliably configure my phone to be this additional factor (otherwise, whoever stole my password could configure their own phone, and would be able to access). We typically do this by only allowing your phone to be configured if you are already connected to the company network.
  4. But wait! In order to do this, before I can connect from home I must have already configured my phone by being at the office in person, which only employees can do (otherwise, whoever stole my password would have a way to configure their own phone, and would be able to access). We typically do this by restricting access to the company network both physically and technically.

(There are variations to this process, of course. Some organizations send one-time codes to the employee's email address... which is even worse, since stealing the password often means stealing access to the email. For educational purposes, the above scenario is generic enough)

And then, the COVID-19 pandemic struck. Now, being at the office was not an option, so that physical presence could not be used to verify one's identity. It should never have been, anyway.

For more than a year already, IAM, Security and IT professionals have been talking about authenticating the remote workers that we already know about. Our current workforce. But what about the ones we didn't know about yet? In such a prolonged working-from-home situation as we have had, most organizations have hired new workers, who have not put a foot into the office for a long time. Therefore, step #4 above is out of the question. The same is true when my phone dies and I need to buy a new one... am I locked out, since I can't go to the office to set up my new phone as an authentication factor?

Yes, this is a weakness in our process. But it's not the weakness that I mentioned at the beginning of this article. Let's press forward and find it.

What do we do when we have just hired a John Smith on the other side of the world, or when I need to configure a new phone for MFA? Typically, we open a ticket with the (heroes of the) IT support team. But... what are they going to do? How can they really help? This is not a technical issue, it's a trust issue. The problem is that we have no way of knowing that John Smith is indeed who he claims to be. He might be an attacker who has stolen John's credentials and is trying to set up remote access in order to access our environment. The same is true for whoever stole my password and tries to set up their phone in order to access our network/systems.

Let's focus on the most complex case (John's, a new employee), which encompasses the other (re-setting MFA). How can we make sure that John (who we've never really met) will be the one receiving the means to access remotely?

We can send a one-time configuration code to John's work email address. With it, they can configure their phone for MFA.

Nope. As we saw before, this does not work, since whoever stole their password can also access their work email.

Ok, then. We can send a one-time configuration code to their personal email address. With it, they can configure their phone for MFA.

Nope. That does not work either. How can we be sure that this email address is actually John's, and not the attacker's? What channel did this alleged John use to disclose this address to us?

Fine. John can simply provide his personal email address when signing his contract, then.

Ok... And how do we know it was indeed John signing his contract? This was not done in person anymore, but remotely, like anything else. How do we know the attacker did not start the attack at the point of establishing that primary trust anchor? It would be the only individual we had ever known, impersonated since the very beginning, and we would give him the same privileges as any other employee (and remember, some employees need A LOT of privileges). It simply was never really John Smith. He might have faked a recruitment process just to steal some customer or financial data, for example.

For the love of...! But he did provide a copy of a government-issued document!!

Aha! And here's that fundamental weakness that we were talking about before... Is the organization validating the authenticity of those documents? Are we even capable of doing so? Do we have people in our HR department who are experts at identifying a fake Brazilian Passport from 1981? Or are we simply blindly receiving personal documentation and storing it without never even opening it? (Which makes sense, since we don't even know what to look for). We have lived with the delusion that our HR recruitment process was solid enough to guarantee the identity of our employees.

This procedural weakness might have been a minor concern in the pre-COVID world, when we had additional (though also weak) compensating measures of making new hires show themselves, in person, at the office, before being able to access remotely. It was too unlikely for them to take the trouble of physically impersonating a new recruit. But in a world in which we might never see some of our colleagues at an office (which means that they require remote access), this flaw will be much more exploitable by avid attackers who won't ever need to actually leave the shadows. They just need to embark on a recruitment processes with a very shiny and fake resume, an equally shiny and fake Passport, and wait for one of them to go well enough to give them an opportunity. In fact, they can do hundreds of those processes in parallel, for tens of companies. Sooner or later, it'll happen.

So... what do we do about it?

Don't despair. The future looks quite bright in the opportunities that it brings. At the moment, there are forward-thinking companies which leverage a mix of Machine Learning and human investigation in order to detect whether a government-issued document is legitimate or not. Once that is settled, and to make sure it was not simply stolen by a devious look-alike, they will also offer video face-recognition, making the candidate move their face in a particular way and pronounce certain words to make sure it is the same person as in the provided document. At that point in time, we have a very strong Trust Anchor that the candidate is who they claim to be, and we can use that point in time to establish the mechanism to configure MFA (personal email address, phone number, biometrics, etc.)

The most interesting thing is that this kind of process can be consumed as a service, removing the need for our organization to handle verifications that we are not equipped to do. We therefore segregate the identity verification process, which the vendor will do independently from the employer, and the consuming and onboarding of the resulting reliable digital identity.

The key thing to remember is that the whole flow, from hiring a user to giving them access to approve payments, is a chain of trust; each link bound to the previous one, until the whole thing is hooked to that Trust Anchor; that fundamental piece of information that we consider certain above all. We know perfectly well that any weak link will compromise the chain. But a weak anchor will make the whole thing collapse, even when all of the links remaining intact.


Post a Comment

Popular posts from this blog

Understanding IAM Governance (AKA: How we monitor, control and decide)

Of Entities, Identities and User Accounts (AKA: I need to know who IAM)