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 the output improved from fan folder paper to monitors, touchscreens, and other forms of motion-based interactive devices, the need to secure privileged access for HID became plainly evident. Privileged access security was not only needed to protect the data and operations of the device, but also its configuration, other resources that could be leveraged from the interface, and even simple tasks, such as powering off the asset or inserting a DVD.
Physical Security Versus Software Security to Privileged Resources
The question of privileged access to resources then becomes a question of physical security versus 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 interacting with the applications hosted by the device. It is important to note that this was not always the case. Prior to Windows XP (August 2001), a simple Control-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 the resemblance. As a simple matter of fact, even on a modern iPhone, I have family members that can unlock each others’ 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.
It is the privileged access to human interface devices that begins the journey for a threat actor when physical access is permitted, and a privileged attack becomes a combination of the device, a password or biometrics, and a potential HID vulnerability. This all occurs before any lateral movement or advanced persistent threats can form a beachhead.
For the sake of this blog, I would like to coin a term called “my privileged password” that creates the concept of a user entering a secret (password) into a human interface device to authorize interaction with the asset and applications, and who should have them. This is critically important when the attack vector is based on local, physical access to the resource.
To that end, since physical security is not the answer (with the exception of only the most highly sensitive of environments) because it would limit usage altogether, the discussion evolves to “who should have a privileged password to even engage in any interaction?” The answer is not obvious since devices like cellular phones are generally only used by individuals, and workstations are typically assigned to a single user (albeit outside of shared resources). So, who should have a privileged password, and which HID devices should that user be able to interact with?
First, let us 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, or a sole contributor and a part of the rank and file contributing to the success of your organization? What is role? An auditor, information technology administrator, help desk engineer, sales person, chief information security officer, etc.? Your title and job role should implicitly determine whether or not you should have a personal privileged password for a resource and HID interaction.
If you think this a bold statement or something your organization struggles with today, consider the following… The higher your professional title, the lower the number of personal privileged passwords you should have—and for the privileged passwords 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 not have privileged access, access to privileged passwords, nor potentially normal access to any HID resources that would accept privileged passwords—even if they were available.
As you move down the organizational structure, privileges and privileged passwords should be assigned by role and follow the model of least-privilege access. The least privilege model entails assigning only those rights and privileges absolutely necessary for a role to perform its functions. This means eliminating the practice of provisioning blanket excessive rights that could be misused or introduce additional liability.
This should also hold true for mid-level management. Barring the ego of a direct report owner, privileged passwords should only exist and be viable against a resource by the team members that actually use them, and not anyone else unless an emergency or break glass scenario warrants it.
Moreover, these privileged user accounts should not not be “always on”, meaning they have persistent privileged access. An always-on privileged access model, while remains the default practice for most organizations, greatly swells the risk surface, since the accounts always have privileges enabled, 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 that secures the accounts, only activating them for use for the duration they are needed to perform an authorized activity. This is an ephemeral approach to privileged accounts and inherently limits privileged access using a HID.
This brings us back to “my privileged password.” Only the roles needing privileges should get them. The privileges should not be exposed, or potentially available, unless the workflow warrants the privileges be activated at that time. The figure below illustrates this application of privileges by title.
While there are always exceptions to this model, “my privileged passwords” should also consider the second aspect of appropriate access: “Where can they be used? This is a context and confidence problem, and requires a human interface device for actual persona interaction. 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 privileged 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, etc.
Finally, with regard to HIDs, privileged credentials should also always be monitored based on method of input. That is, did they originate from another application or from a HID? The method used for privilege elevation is just as important as the credentials themselves since inappropriate usage rarely occurs via a threat actor typing on a keyboard, but rather leveraging automation for malware, scripts, or another compromised application. My privileged passwords are the privileges you potentially have access too, where you can use them, and whom they should be assigned too using a standardized model.
While this concept may be new to some readers, it is definitely possible within many organizations struggling with privileged access management (PAM) initiatives. The PAM solutions chosen to help you on your journey need to manage by role, job, HID, and context in order to secure privileged passwords for anyone, and at any time.
If you would like more information on how BeyondTrust can help solve these problems, please contact us today. Our just-in-time privileged access management technology is designed to tackle the sprawl of privileged passwords and persistent privileged access.
Related Resources
Passwordless Administration Explained (blog)
Modernizing Your Privileged Password Security (blog)
BeyondTrust Enterprise Password Management (solutions page)
4 Ways Privileged Access Security Tools Can Prevent a Third-Party Breach (blog)
Hardcoded and Embedded Credentials are an IT Security Hazard – Here’s What You Need to Know (blog)
Morey J. Haber, Chief Technology Officer and Chief Information Security Officer at BeyondTrust
Morey J. Haber is Chief Technology Officer and Chief Information Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four Apress books: Privileged Attack Vectors (2 Editions), Asset Attack Vectors, and Identity Attack Vectors. In 2018, Bomgar acquired BeyondTrust and retained the BeyondTrust name. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. Morey currently oversees BeyondTrust strategy for privileged access management and remote access solutions. In 2004, he joined eEye as Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.