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.
