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.
