NEW: Microsoft Vulnerabilities Report 2022 - Read the Findings of Our Annual Report Read Now

  • Partners
  • Support
  • Careers
  • English
    • Deutsch
    • français
    • español
    • 한국어
    • português
BeyondTrust
  • Products

    Privileged Password Management

    Discover, manage, audit, and monitor privileged accounts and credentials.

    • Password Safe
    • DevOps Secrets Safe
    • Privileged Access Discovery Application

    Endpoint Privilege Management

    Enforce least privilege across Windows, Mac, Linux, and Unix endpoints.

    • Windows and Mac
    • Unix and Linux
    • Active Directory Bridge

    Secure Remote Access

    Centrally manage remote access for service desks, vendors, and operators.

    • Remote Support
    • Privileged Remote Access
    • Privileged Access Discovery Application

    Cloud Security Management

    Automate the management of identities and assets across your multicloud footprint.

    • Cloud Privilege Broker

    BeyondInsight

    Experience the industry’s most innovative, comprehensive platform for privileged access management.

  • Solutions

    Use Cases

    • Cloud Security
    • Compliance
    • Cyber Insurance
    • Digital Transformation
    • Endpoint Security
    • Operational Technology
    • Ransomware
    • Service Desk Efficiency
    • Zero Trust

    Industry Applications

    • Financial Services
    • Government Agencies
    • Healthcare
    • Law Enforcement
    • Manufacturing
    • Schools & Universities

    Solutions

    The BeyondTrust Privileged Access Management portfolio is an integrated solution that provides visibility and control over all privileged accounts and users.

  • Resources

    Learn

    • Blog
    • Customer Stories
    • Competitor Comparisons
    • Datasheets
    • Demos
    • Glossary
    • Podcast
    • Whitepapers

    Attend

    • Events
    • Go Beyond
    • Training
    • Webinars

    Support

    • Changelog
    • Professional Services
    • Technical Documentation

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

  • Company
    • About
    • Leadership
    • Core Values
    • Partners
    • Careers
  • Watch Demo
  • Contact Sales

My Privileged Password & the Implications for Human Interface Devices

September 23, 2019

  • Blog
  • Archive

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.

Privileged access in relationship to a company's organizational structure

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)

Photograph of Morey J. Haber

Morey J. Haber, Chief Security Officer, BeyondTrust

Morey J. Haber is the Chief Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored three books: Privileged Attack Vectors, Asset Attack Vectors, and Identity Attack Vectors. He is a founding member of the industry group Transparency in Cyber, and in 2020 was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board. Morey currently oversees BeyondTrust security and governance for corporate and cloud based solutions and regularly consults for global periodicals and media. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition where he served as a Product Owner and Solutions Engineer since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. 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.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Whitepapers

Microsoft Vulnerabilities Report 2022

Whitepapers

Cybersecurity Insurance Checklist

Whitepapers

Privileged Access Management: PAM Checklist

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support
  • Cloud Privilege Broker

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Podcast
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press
BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2022 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.