Protecting Administrative Sessions in Okta

Privileged users have always been and should always expect to be under constant attack from motivated adversaries.

Over the last 90 days, Okta has devoted many of our most skilled resources into a program of work that dramatically hardens the Okta Admin Console, resulting in a number of new features, a subset of which are listed below.

The purpose of this blog post is to zoom out and think holistically about how to use these features to:

• Reduce the attack surface of your Okta org,

• Prevent account takeovers, and

• Limit the blast radius of a stolen session

Reducing the Attack Surface

The first step to preventing unauthorized access to privileged applications is to reduce the number of accounts with privileged roles.

Okta’s standard administrative roles offer the fastest path to value for new workforce deployments. Over time, the most security conscious organizations migrate to Custom Admin Roles in pursuit of least privilege access.

This journey starts with:

• Assigning administrative permissions by Group, and avoiding assigning them individually. This greatly simplifies the administration and governance of policies.

• Identifying tactical ways to minimize the number of accounts with highly privileged roles (Super Administrators, Org Administrators, App Administrators). Delegated Flows, for example, offers opportunities to reduce the number of Workflows users that require administrative access.

• Breaking down common administrative functions (such as assigning users to apps, or factor lifecycle operations) into Custom Admin Roles, and assigning them to specific resources (groups, apps, workflows etc), to further promote least privilege.

The target state is to move as close as possible to “zero standing privileges”.

Zero standing privileges is a model in which an administrator gets access to the resources and permissions they require on a just-in-time basis to complete a specified task, after which time the access is automatically revoked.

Okta Privileged Access Management (OPA) uses this principle to secure access to servers, databases, apps and other targets. When OPA is combined with the Access Requests feature in Okta Identity Governance (OIG), organizations can be confident that all access to privileged resources is authorized, ephemeral (temporary), and recorded for easy auditing.

However, we want zero standing privileges to be a design pattern in reach for even the smallest of Okta’s customers. Okta is committed to ensuring that every workforce customer can achieve zero standing permissions for access to the functions they require to administer Okta.

Okta’s product team has subsequently lifted a subset of premium Okta Privileged Access and Identity Governance features and built them directly into the Okta Admin Console to make this essential protection available to all Okta Workforce customers at no cost.

Using this configuration, the journey to zero standing privileges in Okta is simpler again:

1. Assign all administrators with custom roles designed for the minimum resources and permissions required to complete day-to-day work;

2. Create a Request Approval process for administrators that require temporary (“just-in-time”) elevated permissions for administrative tasks that are performed less often,

3. Require dual authorization (approvals) from two or more fellow administrators for access to roles with elevated permissions.

4. Create an action in the Access Request that adds a user to a group assigned the elevated permissions after authorization and removes them from the group after the specified time period expires.

The only exceptions you might need to make to this process are:

1. A break-glass account with a super administrator role.

   Depending on your deployment, you may require an account for emergency access. This “break glass account” needs to be protected by policies that assume your trusted network or PAM solution is not available. We suggest limiting access by network location (using secondary or tertiary IP ranges for redundancy), and also requiring multi factor authentication. A common approach is to require one of several physical FIDO2 security keys enrolled for the account, plus a machine-generated string as a password. Access to this account should be monitored with absolute vigilance: any use should set off alarm bells in the SOC.

2. Service accounts used in machine-to-machine authentication

   Don’t neglect accounts used for non-human (machine-to-machine) access. Use OAuth 2.0-based API Service Applications, wherever available, with the least required account permissions and scopes applied. If you are using legacy static API tokens for any integrations, make use of Okta’s IP allowlisting feature: this ensures that Okta APIs will only accept requests using these tokens from trusted locations. Vault all static API tokens, maintain an inventory of their purpose, and audit and rotate regularly. Once configured, service accounts should be members of an Okta Group, and a global session policy should be applied to that group that denies interactive access (NB: this won’t restrict API access). Maintenance tasks should require a formal access request process that temporarily subjects the account to a different policy. Service accounts should otherwise be closely monitored for detection of unauthorized interactive and/or shared access.

Preventing Account Takeovers

As discussed, Okta has built best-in-class features to prevent unauthorized access to the Okta Admin Console. Many of these features are enabled by default.

The resilience of your environment largely depends on sound configuration of policies and supporting controls. At minimum, Okta Security recommends protecting administrative users by configuring the following:

• Enable ThreatInsight in log and enforce mode. This will detect and prevent high-volume credential based attacks on any account that still requires a password.

• Apply strong authentication policies to groups with administrative permissions.

• Require administrative users to sign-in using passwordless, phishing resistant authenticators (Okta FastPass, FIDO2 WebAuthn, Smart Cards).

  • Enforce phishing resistance in policy.

  • Require users to verify their identity via a biometric challenge (preferred) or PIN.

  • Deny the use of discoverable FIDO2 credentials (Passkeys) for access to the administrative console and require use of device-bound FIDO2 credentials instead. Passkeys may otherwise be susceptible to theft from unmanaged devices or cloud service accounts.

• Require access via trusted, managed devices for administrative access.

• Require access via managed browsers (i.e. do not allow administrators to sign-in to personal accounts from the browser).

• Use endpoint security integrations to deny access to devices exhibiting poor posture.

• Deny all requests to administrative apps from anonymizing proxies and other untrusted networks using Dynamic Network Zones.

• Evaluate user behavior and risk in policy, and alert on anomalous authentication requests (such as new device + new IP).

• Apply an explicit, catch-all deny rule for any access to the Okta Admin Console that doesn’t meet the above conditions.

Reducing the Blast Radius of a Stolen Session

Irrespective of the strength of your protective controls, your threat model must also account for the theft and replay of an administrator’s session token using malware or other means.

Okta’s revised default session duration for the Admin Console is designed to limit the opportunities for adversaries to exploit a stolen session token.

ASN Session Binding, which is enabled for all Okta workforce orgs by default, limits the ability to replay a stolen session outside of an expected context. Security teams can optionally insist on enforcing IP Session Binding for the Okta Admin Console, which binds all requests during an administrative session to the same IP used during authentication. IP Session Binding is on by default for all new Okta orgs.

We also recommend the following:

• Enable Protected Actions in the Okta Admin Console. This forces step-up authentication before an administrative user can modify critical settings, such as enabling a third-party Identity Provider or resetting all factors of an administrative user, greatly reducing what actions an adversary can perform with a stolen session token.

• Configure a Re-authentication Frequency of “Every Sign-In Attempt” to all administrative applications. This greatly diminishes access to applications using a stolen user session.

• Choose FastPass as your primary authenticator. FastPass provides a fast, consistent user experience on all OS/browser platforms, prevents and detects real-time AiTM phishing campaigns, and offers an ability to constrain credentials to approved devices. It can also play a role in mitigating the theft of session tokens: FastPass can be configured to evaluate device signals on managed and unmanaged devices prior to allowing access. Okta can subsequently use these device signals to assess device context every time a user requests a new application during a session, and require re-authentication if device context is assessed to have changed.

Finally, it’s important to audit the use of administrative roles and to monitor for suspicious administrative activity. As we’ve said in previous posts, the monitoring and oversight of actions performed by users with administrative roles is a cornerstone of any well-designed security program.

We recommend the use of Log Streaming for the fastest access to Okta System Log events in the SIEM of your choice. You can find a sample of common detections we have published in collaboration with Splunk and Google Chronicle.

A new event relevant to organizations that have deployed ASN and IP Session binding is provided below.

Okta’s engineering teams have worked tirelessly over the last 90 days to provide the guardrails and additional features required to protect access to administrative functions in Okta.

Over 9000 Okta orgs adopted ASN Session Binding within three months of its release, giving us the confidence to turn the feature on for all Workforce customers by default. Over 95% of Workforce orgs have maintained the default maximum and idle session duration configuration we switched on for all customers in January.

We remain committed to prioritizing the features that protect privileged users under the Okta Secure Identity Commitment.