CISOs today are scrambling to cope with a multiplying universe of systems and access management scenarios. The typical enterprise hosts workstations, internal resources, SaaS applications, legacy systems, command line environments, privileged workflows, and more, each of them needing to be secured.
What they're finding is that securing all of these with two-factor authentication (2FA) or multi-factor authentication (MFA) within a single identity universe is a difficult if not insurmountable task. That's why many haven't even arrived at the next set of problems—the fact that once a login or workflow is protected by 2FA or MFA, each still works in basically the same way:
-
The user requests access
-
The user is asked to provide their identity
-
The user is challenged to prove this identity with a password
-
The user is challenged to prove this identity with a 2FA or MFA step
-
Access is granted
But what happens after access is granted?
In many cases, from the identity perspective, nothing. Once access has been granted, the user's identity is presumed. Because after all, you can't go on challenging the user to prove their identity all day long. With most common authentication tools, this would mean an effective work stoppage.
Even asking users to reconfirm their identity every hour would be considered onerous, detrimental to workforce retention, and terrible for employee and IT workforce morale. Yet from the security perspective, confirming identity only until access is granted is a significant problem. It does little to address problems like:
-
Session walk-aways that are vulnerable to step-ins
-
Work-from-home hardware that may be shared by spouses and other family members
-
Man-in-the-middle attacks and hijacked sessions
-
Illicit credential sharing
-
Sorting out actual identity in cases of authorized credential sharing
-
Theft or malicious seizure and use of devices with open sessions
-
Provably attributing taken actions to specific individuals after login is complete
These are serious risks, too—yet dealing substantively with them can feel entirely out of reach when just achieving a broad 2FA or MFA rollout across disparate systems and workflows feels insurmountable.
Moving Beyond "Pull" Identity
What if we could kill two birds with one stone? That is to say, what if one approach to security could enable the deployment of MFA not just to SaaS applications, but to things like legacy systems and command-line tools as well—while enabling users' identities to be confirmed and differentiated long after the start of a new session or privileged workflow, without interrupting work?
A new identity paradigm—identity-as-a-signal—may be how we get there. Recall the old model:
-
The user requests access
-
The user is asked to provide their identity
-
The user proves their identity
-
Access is granted
This is a "pull" approach to identity. To gain access to resources needed for work, the user is asked to provide a claim about their identity and then is asked to supply proof of their claim. They have to take concrete steps to deliver these in response to the request.
If they succeed, they get access. Afterward, they aren't asked again for some time, because this "pull" is laborious and interrupts work. Worse, it's difficult to configure many systems, particularly legacy systems, to "pull" the kinds of credentials generally called for by security best practices today.
Identity—Available As a Signal
Imagine for a moment an environment in which identity can be consumed as an ambient signal. Rather having the equivalent of gate agents demanding ID before visitors are allowed to use resources, company systems would instead simply "tune in" to already-present identity signals in real time, without any need for a "pull."
In other words, what if identity wasn't an ID card, but a "broadcast" signal that any company system could consume? Shifting from "pulling" identity from users by request to confirming users' identities with a real-time signal, if such a thing were to exist, could enable something more like:
-
The user requests access
-
Systems check the user's ongoing identity "broadcast"
-
If this signal is live (i.e. identity is confirmed), initial access is granted
-
So long as the signal is live (i.e. identity is confirmed), access remains open
-
The signal can be checked at any time, or even all the time, to continue to confirm identity
Imagine further that this signal could be generated without requiring users to do anything special— they're simply "recognized and confirmed as themselves" by observation, as they work. A system like this would accomplish a variety of holy-grail-like things:
-
Users could focus on work, rather than on answering "pull" requests for identity confirmation
-
A new path would be opened to strong identity in legacy systems and applications
-
One signal like this, if abstracted through an API, could be used to provide environment-wide 2FA or MFA
-
True continuous authentication becomes possible—identity at all times without interruptions
When taken as a vision for the future of authentication, this sounds awfully effective.
It's In the Wild
As it turns out, several attempts to turn identity into a signal just like this are already in the wild. Most right now rely on personal hardware:
-
Mobile phones and their device IDs
-
Mobile phone sensor biometrics, especially fingerprint readers
-
New generations of mobile or wearable authenticator devices
This is fine as far as it goes. It gets us to identity as a signal—but with certain key concessions.
-
Often it's not actually the user's identity being made available, but a device's identity
-
In many cases, there is still a security "pull" in play—it's just been shifted to phones
-
It still requires an affirmative user step that isn't part of work per se—namely, carrying a particular device
What if we could eliminate these problems, too?
At Plurilock™, we're beginning to roll out solutions based on the identity-as-a-signal paradigm, but without the concessions above. Instead of requiring the use of a particular personal device, we're taking things a step further, recognizing users by:
-
The way they interact with whatever workstation they're using, and in particular
-
The highly individual, fingerprint-unique cadence of their everyday typing
-
The similarly individual, idiosyncratic properties of their pointer interaction
By using properties of users’ bodies and movements that are observable as they work, we're able to generate an identity signal without requiring the involvement of personal devices of any kind—and without requiring them to take any affirmative steps whatsoever.
Ongoing, real-time identity signals from every user in an organization can be achieved without any intervention by the user—and these can then be consumed and used by any system for authentication, audit logging, taking action when necessary, or any other needed IAM purpose.
It's true continuous identity without needing "pulled" proof from the user—and without added friction.
Getting to the Future of IAM
As we continue to refine identity-as-a-signal technology and put it into the hands of clients, we envision a world in which many of the current problems in IAM and authentication are eliminated by the fact that identity is just there inside the enterprise, at all times, for every user.
Our goal is to empower security personnel to do all kinds of things that have never been possible before—from layering additional authentication factors on top of hard-coded legacy login prompts to enabling real-time administrative IAM actions.
As a security professional, what would you do with a signal that could tell you at any time who's really using a device or resource—and that could flag you within seconds if the user at the console changed?
We think the answers to this question over the next few years will change cybersecurity completely. ■
