The concept of a human interface device (HID) has a deep history in keypads, keyboards, and even punch cards, to interface with computing technology. As output improved from fan folder paper to monitors, touchscreens, and other forms of motion-based interactive devices, the need to secure access when using a HID became clearly evident. In addition, privileged access to these devices was not only needed to protect the data and operations of the device, but also its configuration and other resources that could be leveraged from the interface. This includes even simple tasks, such as powering off the asset or inserting a DVD.
A Physical Discussion Around Passwordless Authentication
The question of privileged access to resources then becomes a question of physical security vs. electronic security. Take, for example, a keyboard. It typically has no physical protection to stop a potential threat actor from interacting with its keys. Rather, the keyboard relies on software to prevent resources from interacting with the applications hosted by the device. However, this was not always the case. Before Windows XP (August 2001), a simple Ctrl-Alt-Delete would reboot, or force the operating system to have terminal-based interaction with the end user, and potentially bypass any security and privileged access to the resource. Software has been playing catch-up over physical privileged access for years.
And this is not an isolated or old-school case. Consider the facial recognition technology on your mobile device. Anyone can look at the device and the software, in conjunction with biometric sensors, to determine if you are authorized to access the device. If the technology is working as designed, access should be denied. However, should you have an identical twin, even Apple recognizes (pun intended) that their facial identification technology can be spoofed by identities that have a similar resemblance. As a simple matter of fact, even on a modern iPhone, I have family members that can unlock each other’s phones with a simple glance. In my opinion, they do not look that similar, but the attribute-based technology in facial recognition computes that they are close enough to unlock the phone based on this HID technology.
Any form of access to human interface devices begins the journey for a threat actor when physical access is permitted, and a privileged attack becomes a combination of physical access to the device (including diagnostic interfaces and physically breaking into the internal electronics of the device), a password, biometrics, or a potential HID vulnerability. This all occurs before any lateral movement or advanced persistent threats (APTs) can form a beachhead. Therefore, any secure passwordless authentication strategy and technology must protect and be secure against physical threats first.
An Electronic Discussion Around Passwordless Authentication
Physical security alone is not the answer to a passwordless authentication strategy because it would limit usage altogether, not just who should have access or privileged access to the resource. The answer is surprisingly not obvious since devices like cellular phones are generally only used by individuals, and workstations are typically assigned to a single user, but hardwired telephones and other office devices have no physical restrictions or security around their usage. So, who should have access (especially privileged access) and how do you accomplish it without traditionally entered credentials using an HID? Answering this question merely with biometrics is inadequate. Biometrics, like fingerprints or facial recognition, is a single-factor authentication solution and, as we have already discussed, does not provide the confidence to allow for privileged access to sensitive resources. A threat actor can circumvent biometrics. What is needed is a form of multi-factor authentication that has exceptionally high confidence in the identity and that is truly passwordless.
To tackle this problem, let’s first begin with your persona. What is your job title and what is your role(s) within an organization? Are you an executive, vice president, director, manager, contractor, or a sole contributor? How do you contribute to the success of your organization? What is your role? An auditor, information technology administrator, help desk engineer, salesperson, chief information security officer, or others? Your title and job role should implicitly determine what level of privileges you should potentially have and, therefore, the level of confidence needed for authentication. This statement is true for passwordless authentication, the use of credentials with or without multi-factor authentication, and applicable to any privileged access strategy you choose to adopt. It is included in this section because it is often overlooked for passwordless authentication models, yet always applicable.
The higher your professional title, the lower the privileges you should have access to within your organization. And, for the privileged access you do have, the privileges should be restricted, and not an administrator or root. In other words, in most organizations, a CEO, and, in fact, anyone in the C-Suite, should have neither privileged access nor unrestricted access to privileged credentials.
As you move down the organizational structure, privileged access should be assigned by role and follow the model of least privileged access. The least privilege model (discussed in detail later on in this book) entails assigning only those rights and privileges absolutely necessary for a role to perform its functions.
This should also hold true for midlevel management. Barring the ego of a direct report owner, privileged access should only exist and be viable against a resource by the team members that actually use it, and not anyone else, unless an emergency or break-glass scenario warrants it.
Moreover, these privileged user accounts should not be “always-on,” meaning they should not have persistent privileged access. An always-on privileged access model, which remains the default practice for most organizations, significantly swells the risk surface, since the accounts always have privileges enabled and, thus, always pose a potential threat via misuse, whether intentional or inadvertent. The best practice is to adhere to a just-in-time privileged access model (also discussed later in this book) that secures the accounts, only activating them for use for the finite duration they are needed to perform an authorized activity. This is an ephemeral approach to privilege management and inherently limits privileged access, especially when confidence is based on a passwordless strategy.
- 1.
The workflow warrants the privileges be activated at that time
- 2.
The confidence of the passwordless authentication model is high
- 3.
The identity requesting access is correct and follows a multi-factor authentication approach to ensure that the user has not been spoofed
Privileged Access in Relationship to a Company’s Organizational Structure
While there are always exceptions to this model, passwordless authentication models should also consider a second aspect of appropriate access: “Where can they be used? This is a problem for HIDs and leads us to consider role-based access and attribute-based access to authenticate a user properly. This is a context and confidence problem. For example, privileged accounts should not work on resources that are misaligned with the employee’s role. Privileged accounts should definitely not work on resources owned by executives in the C-Suite. In addition, if passwordless authentication access attempts are inappropriately made from these resources, they should be flagged as potential indicators of compromise since they should not be used by upper management. This also includes all the relevant context data for access, including geolocation, source IP address, time of day, device requesting access, and so on. Passwordless authentication must go beyond just a Boolean acceptance of credentials in order to approve access.
Requirements for Passwordless Authentication
When using an HID, all passwordless authentication should be monitored based on the method of input. That is, did it originate from another application or from an HID? And, what HID?
The method used for privilege elevation is just as crucial as the passwordless authentication model itself since inappropriate usage rarely occurs via a threat actor typing on a keyboard, but rather from leveraging automation for malware, scripts, or another compromised application. Also, attacks almost always leverage some form of remote access.
The physical security for passwordless authentication is just as important as the characteristics of electronic passwordless authentication.
Any passwordless authentication model is only as good as the security of the underlining operating system, infrastructure, and supporting resources. A threat actor can circumvent any passwordless authentication model if the platform hosting it is itself vulnerable. Consider how it is maintained, updated, and hardened.
Any passwordless authentication solution should integrate with role-based access and attribute-based access models. The technology should support, and work in conjunction with, multi-factor solutions—even if they are passwordless—to provide a high level of confidence for authentication.
Passwordless technology needs to be context-aware to determine if the access is appropriate on authorized devices and by authorized individuals. It essentially needs to be HID-aware, especially for privileged access.
Passwordless authentication technology should be identity- and role-aware. This is best suited when the technology can integrate with directory stores and identity governance solutions.
Passwordless authentication relies on algorithms to provide a confidence rating for authentication. It is not a Boolean match like a username and password combination. For any organization looking into implementing passwordless authentication, they should request an explanation of the algorithms or patents behind a vendor’s technology and any testing or proof for its accuracy. If the vendors say “no” or it is proprietary, select a different solution. You are basing user authentication on some form of mathematical model and you should have at least a basic understanding of how it works. This is especially true if it is needed in a court of law to defend or prosecute inappropriate access.
Finally, the higher the privileges trusted with passwordless authentication, the higher the confidence needed to be in the technology itself. This explains the detail provided for roles, privileges, and job titles in the organization. Therefore, it is safe to assume that passwordless authentication may not be the best fit for everyone in the organization.
While this discussion and analysis may be new to some readers, passwordless authentication is definitely possible within many organizations struggling with privileged access management (PAM) initiatives. Any PAM solutions chosen to help you on your journey need to manage by role, job, HID, and context in order to secure passwordless authentication models for anyone, and anytime.
The Reality Around Passwordless Authentication
Sample Passwordless Authentication Mechanisms
Biometrics : This technology has been deemed by many technologists as the Holy Grail to replace credentials. While it is true that biometrics should be unique per identity, it has been proven that fingerprints can be replicated, facial recognition bypassed (the twin and child factor for FaceID), and the databases storing biometric information stolen for future malicious activity.1 Therefore, biometrics as an authentication mechanism alone is never a good idea for privileged access. It is a single-factor technology when used stand-alone. Biometrics should always be paired with multi-factor authentication technology before allowing privileged access.
Keystroke Timing : An emerging patented technology that provides authentication based on the rate keys are typed on a keyboard. Surprisingly, the results of this method are very good, but it has been shown to have “known” false positive authentication rates when the user is under duress. For example, if the user breaks their hand, or is only typing with one hand due to something they are carrying, these models falter in authenticating a user since the pattern and rates have never been documented for them before. The machine learning portion needs to be retrained for this situation. And using traditional credentials is unfortunately the only viable fallback mechanism (with multi-factor authentication for privileged access, of course).
Federated Services: One of the more promising approaches uses a blended technology approach from single sign-on and multi-factor authentication. The approach requires you to authenticate once to a federated service using a traditional, trusted mechanism. This service may be based on traditional credentials and include other multi-factor technology normally hosted in the cloud. Once authenticated, your presence (geolocation, device, asset risk, time, and date, etc.) is used to authenticate against other services and applications. This can be seamless or rely on a two-factor code sent to a dedicated mobile application, SMS text (not as secure due to SIM swapping attacks), or another vehicle to authorize a new session. Social media accounts like Facebook and Google have been at the forefront of this technology, but outside of Microsoft Active Directory Federation Services, Microsoft Live, and Microsoft Hello, the adoption of these models has been slow and organizations have been hesitant to trust this approach unless a dedicated multi-factor vendor has also been installed.
As a backup when passwordless layers fail, credentials are the only viable backup. This still needs to be managed.
Legacy technology (and every piece of technology created at the time this book was published) still requires credentials under the hood, whether this is an administrator account or service credentials. Passwordless solutions are just a new security layer on top and may not be compatible, especially for custom applications.
A physical injury to the hand, eye, or face can cause biometrics to fail. Microsoft Hello, Samsung Galaxy Note, and Apple iPhones FaceID are the first generation to take these to consumers. However, their reliability, false positives, and potentially false negatives will also drive whether or not these ultimately prove acceptable passwordless solutions.
For a threat actor, passwordless solutions represent a real challenge to gain privileged access as compared to traditional credentials. However, just like recent tribulations in election hacking, sometimes it is better to go after the supplier of the technology than trying to hack the organization that has deployed it. If you can break the passwordless solution by stealing a biometric database, finding faults or vulnerabilities with the tool itself, or installing malware on a mobile device, the end results of a breach are virtually the same.