The utilization of always-on privileged accounts has been the default mode for administrative access for the last 40 years. However, always-on access, or persistent administrative credentials (referred to by most analysts as “standing privileges”) represent a massive risk surface as it means the privileged access, rights, and permissions are always on and ready to be exercised—for both legitimate and illicit purposes. And, this risk surface is rapidly exploding alongside the growing use of virtual, cloud, IoT, and DevOps environments in our ever-expanding privilege universe. Of course, cyber threat actors are well aware of what is essentially the overprovisioning of privileges via the always-on and persistent model.
As we have discussed, traditional perimeter-based security technologies only can protect privileged accounts within their boundaries. Privileged accounts are now truly everywhere across your organization. Each one of them is potentially another privileged attack vector, and some of them are accessible directly on the Internet. This is where just-in-time (JIT) privileged access management (PAM) can help.
Just-in-Time (JIT) Privileged Access Management
Just-in-time (JIT) privileged access management (PAM) is a strategy that aligns real-time requests for usage of privileged accounts directly with entitlements, workflow, and appropriate access policies. Companies can use this strategy to secure privileged accounts from continuous, persistent, and always-on access by enforcing restrictions based on behavioral and contextual parameters. This forces accounts to operate with ephemeral (time-based) properties. As much as possible, organizations should try to reach a state of “zero standing privileges.”
To take a step back for a moment, let us ensure we have a solid definition for a privileged account again. A privileged account is one that is granted privileges and permissions above that of a standard user. This could be a superuser account with elevated privileges (somewhere between standard user and administrator) or the highest level of user privileges, such as administrator (in Windows environments) or root (in Unix/Linux environments).
Just in Time Applied to Sample Accounts and the Windows of Privileged Exposure
During a week, an always-on privileged account is available 168 hours. With an always-on privileged account model, accounts are accessible all the time, even if they are under password management. The risk surface exists even if the threat actor does not know the password. With a JIT PAM model, individual privileged accounts are only used for just the time to complete the task or activity. Assuming separation of privileges and separation of duties have been implemented, each unique privileged account should only be active for a small fraction of the workweek to accomplish these goals. As illustrated above, when this reduction in the privilege account status is managed, the risk reduction potential is huge. As an example, Privileged Account A needs to perform tasks that take a little less than 5 hours in one week. The threat window is only 2.9% compared to the entire week. This example can be applied to accounts B and C too. Therefore, the quantifiable time exposure represented as risk is significantly less when using a JIT PAM approach to managing privileged accounts.
Just-in-Time Privilege Management Strategy
A just-in-time approach to privilege management does require organizations to establish criteria for just-in-time privileged access and accept that the accounts that fall within this policy are not available outside of potentially break glass scenarios.
While similar concepts for JIT existing across other use cases (e.g., manufacturing) are well established, applying the model for a security and operations solution does present some technical considerations during an implementation. An initial consideration is around the just-in-time account(s) delegated for privileged access.
The goal of a JIT privileged account is to assign or create the necessary account “on the fly” based on an approved task or mission, apply the appropriate privileges, and subsequently reverse the process once the task is complete or the window or context for authorized access is expired.
JIT Account Creation and Deletion: The creation and deletion of an appropriate privileged account to meet mission objectives. The account should have traits to link it back to the requesting identity or service performing the operation for logging and forensics.
JIT Group Membership: The automatic addition and removal of an account into a privileged administrative group for the duration of the mission. The account should only be added to an elevated group when the appropriate criteria are met. Group membership should be revoked immediately upon completion of the mission.
JIT Privileges: The account has individual privileges, permissions, or entitlements added to perform a mission once all criteria are met, but only for a limited duration. These rights need to be revoked once the mission is complete and should include certification that no other privileges were inappropriately altered.
JIT Impersonation: The account is linked to a preexisting administrative account(s), and when a specific application or task is performed, the function is elevated using those credentials. This is commonly done using automation or scripting with Windows “RunAs” or ∗nix sudo. Typically, the end user is unaware of the impersonation account for this type of operation, and the process may overlap with always-on privileged account delegation.
JIT-Disabled Administrative Accounts: Disabled administrator accounts are present in a system with all the permissions, privileges, and entitlements to perform a function. They are enabled to perform a specific mission and then subsequently disabled again once operational criteria have been satisfied. This concept is no different than having always-on administrative accounts, with the exception that native enablement functionality is leveraged to control JIT access.
JIT Tokenization: The application or resource has its privileged token modified before injection into the operating system kernel. This form of least privilege is commonly used on endpoints to elevate the privileges and priority of an application, without elevating privileges for the end user.
Entitlements: When privileged access management (PAM) is integrated with identity and access management (IAM) solutions, entitlements between solutions can be synchronized for privileged access. To that end, JIT access can be assigned directly via PAM solutions or, alternatively, programmatically through IAM entitlements. While the IAM entitlement workflow is a longer technology process for synchronization and has a lag time, it does provide a vehicle for account certifications based on privileges that are void when linking with PAM solutions to control access.
Workflow: The concept of workflow approval is commonly associated with call centers, help desks, and other IT service management solutions. A request is made for access and, using a defined workflow of approvers, access is either granted or denied. Once the workflow satisfies an approval, a JIT account can be enabled. This typically corresponds to the user, asset, application, time/date, and associated ticket in a change control or help desk solution. Privileged session monitoring is typically enabled by PAM solutions in this scenario to verify that all corresponding actions were appropriate.
Context-Aware: Context-aware access is based on criteria like source IP address, geolocation, group membership, host operating system, applications installed or operating in memory, documented vulnerabilities, and so on. Based on any logical combination of these traits, JIT account access can be granted or revoked to satisfy business requirements and mitigate risk.
Two-Factor (2FA) or Multi-Factor Authentication (MFA): A common method for authorizing privileged access to always-on or JIT privileged accounts is 2FA or MFA. While this does not distinguish between the two access techniques, it does provide additional risk mitigation by validating that the identity has proper access to a privileged account. It can, however, be used as a JIT trigger for an account using any of the techniques listed earlier.
Simply put, JIT triggers are just that, conditions for an account to be placed or created in a state for privileged access. They can be used stand-alone or logically grouped with other triggers to instantiate privileged account access or revoke it. The two key takeaways for teams to consider are what policies govern a JIT account for proper privileged access, and what conditions should be met for its revocation?
Time and date windows for access and change control
Commands or applications that may indicate a security compromise
Detection of access to sensitive information
Termination of the primary session
Existence of corresponding collateral in a ticketing solution
Inappropriate modification of resources, including installing software or modifying files
Inappropriate attempts at lateral movement
The manipulation, creation, or deletion of user accounts or datasets
Workflow for a Just-in-Time Privileged Access Request and Session
Implementing Just-in-Time Privileged Access Management
While JIT privileged access management (PAM) is a relatively new concept, perhaps it is here just in time to meet the challenges of always-on, persistent, or standing privileged access to a sprawling universe of privileged accounts.
In order to be successful with JIT PAM, consider enabling privileged accounts only when needed for authentication and control when and where they can be used. This involves expanding the security model to deny all privileged activity until the appropriate business criteria are satisfied based on their usage. This entails not only restricting account access like traditional PAM, but the actual privileges, permissions, and entitlements that the account can use in real-time. For many organizations, this is the next, most impactful step they can take toward protecting their valuable IT estate. And, from an auditor’s perspective, this works toward eliminating any findings that state you have too many privileged accounts.
When are privileges needed for runtime, like service accounts, and when are they needed for a specific session or application usage based on a task? Task-based usage is ideal for JIT PAM.
Any batch-driven, trigger-based, or scheduled tasks that are infrequently executed are worthy for JIT PAM consideration.
The design and implementation of any new resource or applications should use the lowest necessary privileges from the start. Requiring, designing, and coding for the exclusive use of administrative privileges should be avoided.
End users should never enter secondary administrative privileged credentials to invoke a JIT PAM workflow. A valid Trigger and Method should always be invoked, and not single-factor authentication.
The discovery of always-on privileged accounts should be identified per asset and resource during normal inventory discovery and assessment processes.
Accounts used for JIT workflows should not be shared in order to properly certify usage and demonstrate compliance to an identity.
Account creation and deletion as a JIT method must fully document the requesting identity and account to properly provide certification for privileged usage.
Any attempt to use an account used in a JIT workflow that is not in an elevated state can be considered a possible indicator of compromise since its attempted usage is outside of established workflows.
If possible, design your JIT PAM workflows to integrate with your IAM (identity and access management) workflows for better visibility into your entire entity governance model.