How To Implement Just-In-Time Access: Best Practices and Lessons Learned

With the just-In-time (JIT) access control method, privileges are granted temporarily on an as-needed basis. This reduces static entitlements, lowering the risk of compromised accounts and preventing privilege creep. In this blog, we’ll share how we implemented JIT access internally at Tenable using Tenable Cloud Security, and offer recommendations we hope you’ll find useful.

Just-in-time access (JIT) is a valuable security practice that allows organizations to limit the time and the scope of users’ access to resources, such as applications and systems. However, implementing JIT access successfully is challenging, as it requires careful planning and ample communication between the security team and all other departments. At Tenable, we went through this process. Here, we share the lessons we learned and the best practices we adopted, as well as explain how you can leverage Tenable Cloud Security when implementing JIT access.

Benefits of JIT access

The most notable benefit of just-in-time (JIT) provisioning is its ability to restrict access duration. By granting permissions only upon request, JIT can reduce identity and entitlement risks by 75% or more in most scenarios. For example, a user who requests permissions for a 40-hour work week will not have access during the remaining 128 hours, thereby significantly minimizing the user’s identity-breach risks.

Another significant risk reduction made possible by JIT is the prevention of privilege creep. Over time, users tend to accumulate permissions for edge cases. These are usually one-time privileges granted for setup or troubleshooting tasks that are never removed. An example would be granting a user admin privileges over a tool for a rollout and then forgetting to remove those access rights once the project is over. JIT prevents the accumulation of permissions by making the access temporary and automating the cancellation of privileges. 

JIT access can also simplify permission assignments. For example, multiple least-privileged administrator assignments can be combined into one eligibility. While it might seem like a step backward, users must request this access, which they’ll only receive for a limited amount of time. This can streamline the organization’s access requests and reduce the security team’s overhead. 

However, implementing JIT access is a challenging task requiring significant communication between infosec and all other departments and teams in the organization. Read on to learn how we approached our JIT rollout using Tenable Cloud Security.

Preparing for JIT access

To configure Tenable Cloud Security’s JIT feature for your environment, you should first connect it to your identity and access management (IAM) provider, such as Okta’s, and manage JIT eligibilities in the IAM system’s interface. 

That way, Tenable Cloud Security’s JIT feature can be used with any application connected to the identity provider. Tenable Cloud Security supports the following identity providers: Microsoft Entra ID, Google Workspace, Okta, OneLogin, and Ping Identity. Tenable Cloud Security offers onboarding guides to connect it with these IAM systems. You will also have to configure a “JIT Administrators” group so that the security team can create and manage JIT eligibilities. 

The team members responsible for the implementation of JIT access should all be well versed in the usage of Tenable Cloud Security’s JIT, both as administrators and as an end users. Familiarity with the tool will allow JIT team members to answer questions from other teams and show them demos throughout the rollout process.

In addition, if your organization’s corporate infosec policies do not address JIT access, they should be revised accordingly. JIT access policies should cover the following: 

• the ephemeral nature of JIT access requests
• approvers’ responsibilities
• criteria for risk-acceptance when JIT cannot be used 
• duration limits on access requests
• when approvals are required

By updating the infosec policy prior to the rollout, common issues can be avoided and the policy can be used to push adoption. 

Work small, win big

Changing access methodologies is a major undertaking because each team and system within an organization has unique circumstances and edge cases. Any disruption in access to the organization's systems can affect productivity and may disrupt rollout plans. Because of this, JIT should be rolled out gradually on a team, system, or even an entitlement basis to ensure a smooth transition and limit the scope of any potential issues. The following process can be used to engage with teams and to roll out JIT: 

Working with the process

Identify

Tenable Cloud Security can be used to identify excessive permissions in connected cloud environments. Look under “IAM -> Excessive permissions” to find great candidates for conversion to JIT access. There may be opportunities to simplify assignments and permissions by combining several similar roles into a single one backed by JIT for security. While this does violate the principle of role-based access control, the reduction in the number of roles and limited duration access offered by JIT make up for this.
 

^{Overprivileged identities detected by Tenable Cloud Security}

Moving beyond the capabilities of Tenable Cloud Security, a hands-on assessment should also be performed. The reason for this additional evaluation is to address the unique requirements and constraints that each system, application or tool may have. The assessment should begin with the most business-critical systems and work downward based on sensitivity. Of note should be administrator users; users with the ability to escalate their permissions; and users whose permissions are broadly scoped. For each system, the highest privileged entitlements should be considered first by addressing the following questions:

• Can Tenable Cloud Security’s JIT access feature work technically with this application, system or tool?

Ensure that the application can handle automatic provisioning and deletion of user accounts by a single sign-on (SSO) provider such as Okta. If a system has API tokens, check if they are bound to user account(s) and follow the lifecycle of the account(s). API tokens that do not get deleted or disabled with the user account should be actively monitored. If the permissions granted to users allow them to create static user accounts, those actions should also be monitored to ensure that JIT is not being circumvented with static credentials.

• How will the eligibility be used?

Frequently used access such as those needed to perform daily job duties are poor candidates for JIT. The login steps added by JIT can be inconvenient and obstructive if users have to perform them every day. In addition, low-risk access like the ability to submit support requests are poor candidates for JIT because the risk reduction may not justify the complexity.

• What options do we have for recovery or emergencies if JIT fails?

JIT access introduces a point of failure over traditional static access control if, for example, the JIT functionality has an outage or if approvers are unavailable. In the case of a JIT outage, recovery-service accounts should be made to retain access to business-critical systems. Generally these are static identities within the application with admin privileges to recover from an incident. When an access request is made outside of normal business hours, there can be significant delays in getting approval. If this occurs during an incident, the time-to-resolution will be impacted. The escalation process should be established to handle incidents prior to rolling out JIT access to prevent disruption of recovery efforts by JIT. 

Communicate

Transitioning from a traditional access model to a JIT access model can add significant friction for users. While Tenable Cloud Security’s JIT has integrations like Slack and email notifications to enhance and streamline the user experience, these features need to be communicated to the team being onboarded. To ensure adoption, it is important to communicate and work with teams and stakeholders during the process to address their concerns and earn their trust. Generally, this should begin by demonstrating the JIT functionality to system owners from an end-users’ perspective. Be ready to make changes requested by teams, as it may be necessary to grant them more access than their current entitlement allows, in exchange for their adoption of JIT access. Engage the team to see if there are areas outside of what the infosec team has identified where JIT can be implemented. This could be another team’s access to the same application; a different application they may want to onboard; or a complex authentication process that can be simplified. 

After you have buy-in from the system owners, you should scope access eligibilities. In Tenable Cloud Security, eligibilities are defined by their requestors, approvers, access duration and cloud providers’ scope of access. Requestors and approvers should be organized into groups in the SSO system for automatic and easy onboarding and removal. Generally, these are groups that are already in use with static permission assignments. Determining requestors with the system owners is straightforward; anyone who already used the entitlement should be granted eligibility. There may also be additional requestors that could be added to the eligibility from the security comfort afforded by JIT access such as: occasional and infrequent users; help desk users to assist with troubleshooting; and additional administrators.
 

^{Examples of eligibilites in Tenable Cloud Security’s JIT console}

Determining approvers is a more difficult task, as approvers are context-sensitive based on the access risk. Approvers should always be more than one person for the purposes of redundancy and coverage. Approvers should also be educated on the system's usage to meaningfully approve or deny access requests. Overlapping the requestors and approvers is a good approach – provided all of the requestors are good security stewards. Tenable Cloud Security’s JIT allows for three layers of approvals; that way, multiple layers of approvals can be used for high-risk access. Multi-layered approvals usually follow the organizational diagram, beginning with a peer on the same team and escalating up to managers/directors or system owners, depending on the context. If the access risk is low, approvers can be forgone entirely.

Many teams will have questions about availability regarding JIT: What happens if no one is around to approve my request? What happens if JIT is inaccessible? What if I need access longer than JIT will allow? The infosec team must be ready to address these concerns. Generally, a backup service account should be configured to handle edge cases. Usually, this is the default admin account in systems for recovery and setup purposes. Logins by the service account should be reported to the infosec team for review. Processes for accessing the service account should be documented internally and shared with the system owners. If feasible, multi-factor authentication (MFA) should be added to the service account, ideally with hardware tokens, although this may not be an option for remote system owners. 

Implement

JIT access should be deployed alongside the traditional static access, and a concrete date should be set for turning off static access. It is important to maintain both during a transition period so teams can grow accustomed to the JIT process and identify any issues. During this period, users should be encouraged to proactively report any usage issues. Approvers and requestors may need to be revised or entitlement permissions changed. The attention should be on the enablement of the users. Sometimes this can mean granting additional permissions or allowing a large group of users to be requestors or approvers. 

It is strongly recommended to maintain as much of the JIT setup in infrastructure-as-code (IaC) because that will allow for quick expansion, easy documentation and drift prevention. JIT access generally requires three distinct configurations when in use: the JIT tool, the identity provider, and the system being accessed. These configurations can quickly become cumbersome and drift easily if not maintained as IaC. Additionally, changing access models is a prime opportunity to adopt IaC across systems being onboarded if they are not already configured as such. 
 

^{Example of Terraform IaC groups used by JIT}

Once teams are completely transitioned to using JIT access, the static entitlements should be removed. A precise date of termination of the static assignment should be agreed upon by the infosec team and the system's stakeholders. Any recovery or break-the-glass access should be tested end-to-end before the entitlement is deleted to ensure recovery accounts are working and configured properly. You should maintain a notation of the permissions of the entitlement and significant stakeholders in case the permissions need to be reverted and you need to demonstrate the reduction of entitlements.

Next steps

As the team finishes implementing JIT for the identified entitlement, the incremental process of identifying other high-risk entitlements should begin again, ideally working with the same team. Periodic access reviews should be scheduled to ensure that eligibilities are scoped correctly and to determine if permissions should be changed based on utilization. Keep up to date on the capabilities of the JIT tool and the needs of the teams in the organization. New capabilities may enable large portions of the organization that were previously blocked.

Final thoughts

Here’s quick recap of the key lessons we at Tenable learned during our JIT rollout:

• Successful deployment of JIT access requires continuous communication with teams to ensure a smooth transition. 
• Helping teams feel confident and comfortable with the JIT process before and during the migration is critical to success.
• Ensuring that teams are educated on the capabilities of JIT allows them to proactively suggest new areas of adoption that help improve their own workflows.
• A JIT adoption project gives organizations a unique opportunity to build out strong, resilient processes to improve the security and scalability of IAM in the organization. 

To learn more, visit Tenable Cloud Security's JIT access webpage and check out the solution overview "Cloud Just-in-Time Access: Enforce Temporary Elevated Access to Cloud Resources."