Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

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

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Why You should Evolve from User-Based to Asset-Based Privileged Password Management

November 5, 2020

  • Blog
  • Archive

One of the most sacred and effective password management security best practices states that “Thou shall not share passwords”. More specifically, this means you should not:

  • share passwords with other users
  • have shared accounts
  • share passwords among multiple resources (applications, automation, and accounts)
  • recycle/reuse passwords, even after a period of time, whether on the same resource or any other resource

While this security best practice goes back a long way, it is frequently ignored or only loosely enforced.

From the early days of Windows Server to Azure Administration today, sharing an administrative or domain account has often been the only way to make things work. For example, sharing administrative accounts for MS SQL is required to set up a remote database, and using a domain for authentication is required in lieu of MS SQL security using the infamous “sa” account.

Once threat actors realized that shared passwords were an easy target, cybersecurity professionals began to develop countermeasures to mitigate the threat. Unfortunately, many legacy applications make it incredibly difficult to change an administrative password. Ill-considered password changes can cause outages if the underlying systems and account mapping is not fully understood.

Today’s privileged access management (PAM) solutions can meet the password change challenge. The password security component of PAM is typically referred to as privileged password management, or privileged credential management. These solutions provide secure password storage/vaulting, automatic credential discovery, and automated rotation of passwords, including the rolling back of passwords if key services fail to start. This concept of complete password management is incredibly important if you are focused on only managing a password versus the asset because the variable is the password itself that targets a fixed asset.

Evolving from Purely User-based Password Management to Asset-based Password Management

The early versions of PAM were based on the secure storage of a text secret or file. They essentially followed a paradigm of securing a user-based secret in the form of an account. The list of assigned users to that secret did not consider where the credentials were actually being used, nor if the account was unique, shared, or adhering to password security principles, such as password complexity.

This legacy concept of user-based password management is key because secrets could be stored without any linked relevance to the business. It resulted in PAM solutions that had sprawling lists of user-based credentials and, unfortunately evolved to many of the solutions still on the market today. Yet, user-based secret storage was designed with the proper plumbing to manage the constants in the problem; the assets themselves.

For legacy PAM solutions, if you want to manage an account, you create the credential and then assign it to an asset or resource(s). In a shared credential model (which is not ideal), this creates a simple one-to-many relationship. One account is used on any number of resources and available to any number of end users. This violates the security best practices we mentioned earlier. On the other hand, if you try to enforce password uniqueness, you end up with a sprawling list of accounts with a one-to-one relationship with every asset or resource. That inherently creates a management issue because you must link everything to the managed account before you can report on assets, users, or correlate access for certification. It becomes a very lengthy list in an enterprise because the account becomes the primary index. And, if you consider that resources should have an account for each potential user to avoid shared account access, the reporting and backend logic in the database is not optimized to manage assets, since it was originally optimized for users. It does not promote keeping accounts unique per asset per user and adhere to security best practices.

Realistically, in every environment, there will always be a need for some shared accounts; they will never completely vanish, but there should be a better way to implement a PAM solution versus restricting the solution based on the legacy user design. To solve this problem, consider what we are actually managing. We are trying to manage a resource and the secrets within it and the risk it represents. Assets and resources are more than just an account with a password associated to a user. They can actually have any type of secret for a carbon-based life form (human user) or for any type of automation and application-to-application access. Any asset or resource can have multiple secrets in various forms. This makes managing assets in a PAM solution as the ideal paradigm, and the required index in the storage of managed systems. After all, without a resource assigned a secret, then the storage of a user and password alone has no meaning. There always has to be a relationship of what the credential is to an asset.

In addition, if you perform a simple asset discovery, you can identify where all your assets and resources are and then discover all privileged accounts. The account cannot exist without the asset.

Finally, if you manage resources starting with assets, the one-to-one or the one-to-many relationship is simpler. This is because enforcing the requirements of “shared passwords” makes it easier to prove the one-to-one relationship based on the asset as opposed to the user.

While some may consider this nuance in the design of a modern privileged access management solution trivial, it has some distinct benefits that should not ignored:

  • Orphan accounts, those with no assigned assets or resources, cannot occur because all accounts must be linked to an asset
  • Automation to onboard user accounts can occur during discovery since the account and asset are identified at the same time, regardless of whether on premise or in the cloud
  • It is easier to automatically discover an asset than to discover all accounts within it. If you start with the asset you have a baseline to work with. If you have discovered users only, linking them to where they are used and where they could be used is much more difficult.
  • Identifying all the users who have access or have accessed a resource is simpler and faster because the asset is the primary index key for linking accounts together. This is a straightforward matter of scalability.
  • When measuring risk, the score is assigned to the asset or resource. While you can assign risk to an account, it does not align with other solutions that mitigate risk like vulnerability, configuration, and patch management. Only an asset can have risk, (i.e. based on a misconfigured account). There are no industry standards like CVE or CVSS for measuring an account risk because the account must be used on an asset to create some form of meaningful measurement. Just because the account exists alone with privileges does not mean it has a risk without the resource component.
  • The asset-based password management paradigm strengthens security best practices by eliminating, wherever possible, the usage of shared passwords. This is performed by understanding a secret as datum that serves no purpose unless it is assigned to an asset or resource.
  • Asset-based PAM aligns with other business initiatives like Change Control and Asset Inventory Management.

While the goal of privileged password management is to protect privileged user accounts, it is actually more effective to manage those accounts at a higher level, the asset itself. This provides the flexibility to address privileged access to any type of resource and, most importantly, implement security best practices like the elimination of shared accounts, without additional cost and overhead.

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.

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.

Up next

From November 4, 2020:
BeyondTrust Remote Support & ServiceNow CSM Integration Boosts Service Desk Productivity through Automation & Streamlined Workflows
From November 9, 2020:
Service Accounts – Don’t Overlook this Hidden Privileged Access Risk

You May Also Be Interested In:

Webcasts | February 24, 2021

Your PAM 2021 Blueprint: Securing Privileged Accounts for On-Premises and Cloud Assets

Whitepapers

Evolving Privileged Identity Management (PIM) In The 'Next Normal'

Webcasts | January 21, 2021

Welcome to 2021: A BeyondTrust Global Partner Update

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

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

Resources

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

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 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.