How long should privileged password and privileged session checkout durations last? This is a common question that consistently arises when I speak with security professionals, most recently when I participated in an executive forum and roundtable. As every security professional can imagine, there are several approaches and considerations to evaluate when trying to determine what is the “Best Practice” for password and session checkout duration. Obviously, you need to assess the security risks involved with making that decision for the checkout duration, as well as what risks you’re mitigating, or even introducing, based on your decision.
To make the best decision, IT and security teams need to evaluate, categorize, and then prioritize the types of privileged accounts and their usage.
1. Evaluating Accounts
When it comes to account evaluation, you should consider the types of accounts and their access rights. These accounts could be Domain Controller admin accounts, Application Server Accounts, Database Accounts, Line of Business Servers, Network Devices, etc. These accounts can also have multiple access rights, meaning they can be used to log onto multiple servers or assets, applications, databases, and network devices. Understanding the account access rights will help guide the evaluation process.
2. Privileged Account Categorization
There are several ways you can categorize accounts—the important thing to remember is you are trying to categorize “sets” of privileged account access so you can then prioritize them in the next step. When it comes to categorization, you should consider the following:
- Are the privileged accounts in a production domain or a development domain?
- Do the accounts have access to the crown jewels of your production environment, such as domain controllers?
- Do the accounts have access to critical cloud environments?
- What about high-risk financial application(s) or critical database(s)?
There are several ways you can categorize, but the goal here is consistency. The framework for privileged account categorization will vary from organization to organization, depending on such factors as size, amount of accounts, access, etc.
3. Prioritizing the Categories
Once you have successfully categorized the accounts in a format that makes sense to your organization, the next step is prioritizing each of these categories. The priority should align with highest risk to lowest risk. This means that if your domain controller admins are the most important accounts, or pose the biggest risk to the organization, they should be made a high priority. At the opposite side of the spectrum would be development sandbox accounts used for testing, which would be considered much lower priority.
In some cases, organizations have not separated privileged access or access rights to dedicated accounts. Instead, users leverage their “Namesake” account for all access, email, applications, etc. This should be considered “Bad Practice!” If you are using or leveraging this access model, you should seriously reconsider separating the privileged access to a dedicated administrative account to reduce your risk exposure.
Once you have completed the prioritization across each category, you can then start to develop your baseline for password and session checkout duration.
4. Considerations for Developing Password/Session Checkout Durations
The hardest part is done, now comes the easy part. The best way I’ve found to approach this is by starting with a baseline for your low-priority accounts. The baseline should be the minimum amount of control over the duration an organization is willing to accept. In some cases, organization might choose to align these with security controls, standards, or policies. More often than not, the controls, standards, or polices haven’t been written, which is why this question about checkout duration always seems to arise.
When considering a baseline, remember, its easiest to start with the low-priority accounts for the most relaxed checkout duration. Typically, these types of checkout durations will range be 48 hours to 7 days. Remember, these are low-priority accounts with minimal risk. The beauty of creating this baseline is that now you have a starting point. You can optimize checkout duration timelines across each category and priority.
When you consider the highest priority accounts that pose the biggest risk to an organization, you may want to consider checkout durations be as restrictive as 1 hour. This means that, if a user needs to check out this type of account, they will only be able to check it out for 1 hour before it expires, and they have to re-request the privileged password at the end of the hour if they need to continue using it. In some cases, organizations have chosen to add an additional layer—requiring approval prior to releasing a password.
Achieving Best Practices for Password/Session Durations
While there are several options and exceptions to consider, you should keep in mind that for any type of production access that leverages a PAM password safe where privileged credentials are controlled, managed, and released to users, checkout durations should never last longer than the particular user’s typical work day. Some exceptions might be Backup Engineers, Critical Engineering Operations, or Debugging Engineers who might need to perform tasks that extend beyond a typical 8-12 hour workday. These types of users should be evaluated, categorized, and prioritized based on this type of use case.
At the end of the day you are ultimately trying to mitigate risks associated with privileged access. Some types of privileged access might not carry as much risk as others, but having a solid framework and baseline provides a standardized approach for organizations to use when trying to answer the question of “How long should we let users check out passwords and sessions.”
Privileged Password Management Explained
8 Best Practices for Privileged Password Management
Christopher Hills, Deputy Chief Technology Officer, BeyondTrust
Deputy CTO focused in Privileged Access Management (PAM) and Identity and Access Management (IAM). Architecture, Engineering, and Implementation of BeyondTrust's Privileged Access Management Solutions enforcing Privileged Password Managment and Privileged Session Management, Privileged Endpoint Management, and Secure Remote Access which utilizes a single pane of glass for all management aspects including Audit, Reporting, and Vulnerability.