Monitoring for Abuse of Administrative Privileges

Chris Niggel and Brett Winterford

All applications require a highly-privileged administrator role to deploy and maintain that application. The monitoring and oversight (audit) of actions performed by users with these roles is a cornerstone of any well-designed security program.

A number of research projects have highlighted ways in which the most privileged administrators in Okta could, if unchecked, abuse their privilege in some way. These research efforts serve to reinforce some long-held security principles: most notably the principle of “least privilege,” that a user or application should only have the permissions required to perform a specific role or function, and the principle of governance, where those responsible for holding privileged access are held to account for their actions.

Below we’ve presented some best practice advice on limiting, securing and monitoring administrative access to Okta.  

Constrain Privileged Roles

Okta HealthInsight is a tool that prompts administrators to address misconfigurations or conditions identified in their Okta tenant (“org”). One HealthInsight reminder recommends limiting the number of highly privileged roles (“SuperAdmins”) in any given org.

The SuperAdmin role grants its user full privileges to all the powerful administrative capabilities Okta makes available to its customers. A SuperAdmin can manage users, policies, applications and administrative permissions and set org-level security configurations. Every new Okta org is provisioned an account with the ‘SuperAdmin’ role, and the SuperAdmin has the ability to create other admin roles using this account.

As our colleague Gurinder Bhatti recently blogged, with great power comes great responsibility. The majority of tasks an Okta administrator needs to perform do not require SuperAdmin access. For this reason, there are eight other standard admin roles in every Okta org that can be used to constrain administrator access. Your help desk admin doesn’t need the same rights as the admin that manages API access, for example.

As customer implementations of Okta grow larger and more complex, it creates a requirement to further align administrative capabilities with an individual’s role. To support this need, Okta developed Custom Admin Roles to allow organizations to set even more granular permissions within a role. So your helpdesk admin might, for example, only be granted permissions relevant to users within a specific functional unit (organization or group), a specific set of duties or specific applications and resources. 

Delegated flows, meanwhile, provides administrators the ability to run (but not modify) specified Okta Workflows, without requiring SuperAdmin access. 

Secure Admin Access

Given what an attacker with unauthorized access to highly privileged roles in Okta can do, admin access should be locked down according to the level of risk associated with how that role might be abused.

SuperAdmin roles should ideally make use of Privileged Access Management solutions that securely store and rotate ephemeral credentials.

Global Session Policies should enforce shorter session durations and idle timeouts for admins versus regular users. 

While the permissions and resources available to any given admin role might vary, access to the Okta Admin Console would nearly always meet the NIST criteria for an AAL2+ and AAL3 application. At minimum, the total session for an admin would expire at 12 hours, with an idle timeout of no greater than 15-30 minutes. 

 

 

Authentication Policies for access to the Admin Console should at a minimum require:

  • Phishing Resistant authenticators (select “Phishing Resistant” as a possession factor constraint) in a policy that requires any two factor types;
  • Access from a trusted network zone (using an allowlist of trusted IPs/ASNs);
  • Access from a registered or managed device (ideally a device exhibiting a strong security posture); and
  • Re-authentication “at every sign-in”.

 

We also recommend enabling the following features in Okta to prevent abuse of stolen administrative sessions:

Auditing and Monitoring Admin Access

As employees change roles throughout their employment, it is common that they also amass and retain privileged access to systems and data. 

Organizations should perform periodic access reviews of admin role assignments and ensure that privileged access is appropriate for each individual. Okta offers an out-of-the-box report that provides a snapshot of all admin roles in use.


Outside of these pre-built reports, privileged access to Okta’s administrative functions can be monitored by security teams using Okta System Log. </p> System Log events can be <a data-cke-saved-href=" />browsed, searched or filtered in the admin console, queried and filtered programmatically via the System Log API, and can be exported or streamed to third-party security monitoring tools.

Given there are over 700+ events emitted by System Log, it might seem exhausting to know where to begin monitoring or auditing this access.

There are a few ways to narrow it down. Keep in mind that most events in System Log follow a similar pattern:

<domain>, <resource>, <action>

 

So the following query returns events related to users:

eventType eq user.*

 

The next iteration on this query returns events related to user accounts:

eventType eq user.account*

 

And the following event returns user password resets:

eventType eq user.account.reset_password

 

With this structure in mind, below we’ve listed some search terms that could be useful when auditing administrative access.

Access to the Admin Console

All sign-ins to the Okta Admin Console create a unique system log event:

eventType eq "user.session.access_admin_app"

 

Sign-in events of interest might include events in which access to the Okta Admin Console is denied, especially where there are multiple failure events. 

Similarly, you might be interested in access to the Okta Admin Console from a new device or IP or access that triggers a velocity condition (aka “impossible travel”). 

(NB: both of the detections below assume that the displayName for the Okta Admin Console has not been modified by administrators.)

EventQuery in Okta Identity Engine
Access to Admin Console denied

eventType eq "user.session.access_admin_app" AND outcome.result eq "FAILURE"

User Denied Access due to ASN/IP Session BindingeventType eq "security.session.detect_client_roaming"
Request to access Admin Console from new device or IP 

eventType eq "policy.evaluate_sign_on" and target.displayName eq "Okta Admin Console" and ((debugContext.debugData.behaviors co "New Device=POSITIVE" and debugContext.debugData.behaviors co "New IP=POSITIVE") OR (debugContext.debugData.logOnlySecurityData co "\"New Device\":\"POSITIVE\"" or debugContext.debugData.logOnlySecurityData co "\"New IP\":\"POSITIVE\""))

Request to access Admin Console that triggers a Velocity conditioneventType eq "policy.evaluate_sign_on" and target.displayName eq "Okta Admin Console" and ((debugContext.debugData.behaviors co "Velocity=POSITIVE") OR (debugContext.debugData.logOnlySecurityData co "\"Velocity\":\"POSITIVE\""))

 

Privilege Assignment

An audit of administrator privileges should consider what privileges have been assigned to different admins or groups of admins. Any eventType that ends with “privilege.grant” will cover privileges granted to both individual admins and groups of admins.

EventSystem Log Query
Assignment of admin privileges or resources to a new user or group.eventType ew "privilege.grant" 

 

User Lifecycle Events 

Querying an event that contains the string “lifecycle” provides a fairly comprehensive view of user lifecycle events triggered by administrative actions.

EventSystem Log Query
User lifecycle events initiated by admineventType co "lifecycle"

 

At the org-wide level, this query includes lifecycle events for external IdPs and authenticators, down to devices and authenticators configured at the level of the individual user. Some more granular queries for specific categories of lifecycle events are presented below:

EventSystem Log Query
Creating, activating, updating or deleting an Identity Provider.eventType sw "system.idp" 
Creating, activating, updating or deleting an Authenticator/Factor (org-wide).eventType sw "security.authenticator" OR eventType sw "device.push.provider"
A reset, update or suspension of a user’s authenticator.eventType sw "user.mfa.factor"
Admin initiated activation, deactivation, deletion or suspension of a user’s registered device. eventType sw "device.lifecycle"

 

Policy Change Events

A search for events that contain the word  “lifecycle” list include most changes made to an Okta signin policy. Changes to rules within policies aren’t necessarily captured by that query. The query below captures a range of events related to changing access policies.

EventSystem Log Query
An Okta Sign-In Policy, or a rule within it, is created, updated or deleted by an AdmineventType sw "policy.lifecycle" OR eventType sw "policy.rule" OR eventType sw "app.policy"

 

Other Configuration Changes

There are a number of org-wide configuration events in Okta’s Event Catalog that are just as critical for monitoring and auditing purposes. Changes to network zones or device management platforms, for example, can result in a loss of access for large numbers of users.

EventSystem Log Query
Creating, updating or revoking an API Access TokeneventType sw "system.api"
Creating, updating or deleting a network zone, or adding/removing it from a denylist. eventType co "zone"
Adding, updating or deleting a device management platformeventType co "device.platform"
Updating, disabling or changing the network zones evaluated by ThreatInsighteventType eq "security.threat.configuration.update"
A user’s Okta attributes or password pushed/synchronized to an external application via SCIMeventType sw "application.provision.user*"
Creating a new SWA AppeventType eq "application.lifecycle.create" AND debugContext.debugData.requestUri eq "/api/internal/orgadmin/apps/swa"
Creating a new AD/LDAP sync agenteventType eq "system.agent.ad.create"
Creating, activating, deactivating or deleting a Log StreameventType sw "system.log_stream"

 

You’ll find a larger set of admin-relevant event types in the Event Type Catalog.

Trusting privileged users is a necessary risk for any application, and the security best practices of least privilege, strong authentication, and activity monitoring provide you with the tools you need to verify actions and mitigate this risk. Okta provides robust solutions to address these requirements. It’s worth noting that all of the events listed above can trigger a custom Okta Workflow (either through a connector event card or an event hook), such that admins can automate responses to events of interest. 

By adding the controls detailed here into your security program, you can ensure your administrators have appropriate access, and are using that access to protect your organization.

Change Log

1.1 - Mar 8, 2024

  • Updated recommendations to include new features released as part of Okta Secure Identity Commitment: Protected Actions, ASN/IP Session Binding.
  • Updated detections section to include System Log event for for an authentication failure arising from session binding.

1.0 - Oct 25, 2022

  • Original Published
Chris Niggel
Regional CSO, Americas, Okta

Chris is the Regional CSO, Americas at Okta, where he is responsible for corporate security compliance, third-party risk, and responding to customer security inquiries. Prior to Okta, Chris spent 6 years leading the adoption of Cloud Technologies at LinkedIn, helping them grow from 350 to over 6,800 employees. He started his career designing, developing, and delivering content management, system administration, and messaging solutions for customers such as Nestle, Cisco, AMD, Telus, and the US Department of Defense. He is also an active member of the Northern California ski community, where he volunteers with the Tahoe Backcountry Ski Patrol performing search & rescue, and teaching ski mountaineering & outdoor survival.

Brett Winterford
Regional CSO, Okta APJ

Brett Winterford is the regional Chief Security Officer for Okta in the Asia Pacific and Japan. 
He advises business and technology leaders on evolving threats and helps them harness advances in identity technology to drive business outcomes and mitigate risk.
Prior to Okta, Brett held a senior security leadership role at Symantec, and helmed security research, awareness and education at Commonwealth Bank.
Brett is also an award-winning journalist, having long ago been the editor-in-chief of iTnews Australia and a contributor to ZDNet, the Australian Financial Review and the Sydney Morning Herald. Most recently, he was the founding editor of the Srsly Risky Biz newsletter, a companion to the Risky Business podcast, providing the cybersecurity, policy, defense and intelligence communities with a weekly brief of the news that shapes cyber policy.