Overview

Exec’s Okta actions help you protect your data in cloud services (SaaS) when a threat has been identified on an endpoint. You can automate the following containment actions for the associated Okta user:

  • Clear the Okta user’s sessions
  • Suspend the Okta user
  • Add the Okta user to an Okta Group with different (restricted) access

By securing the Okta user associated with a compromised endpoint, you’re securing access to the cloud services that power your business, including email, file-sharing, and infrastructure services like Gmail, Dropbox, AWS, and others.

Use-cases

Exec’s Okta actions can be manually or automatically run when a threat is identified or after a threat has been remediated.

Actions include

Clear Okta Sessions

  • Revokes identity provider sessions and OpenID+OAuth tokens, ensuring an attacker can’t use sessions or tokens stolen from the endpoint

Suspend Okta User

  • Prevent attackers from accessing the compromised Okta account via web or native applications

Unsuspend Okta User

  • Reinstitute access once the threat has been contained or remediated

Add Okta User to an Okta Group

  • Use an Okta Group to restrict access to sensitive services or resources while an endpoint is compromised or under investigation
  • Example: The “Limited Data Access” Group could restrict access to services that expose confidential or personally identifiable information (PII) by removing access to particular services
  • Use an Okta Group to require stricter authentication or (re-)authorization controls like MFA or Okta Push Verify, requiring the attacker to compromise multiple devices

With bring your own device (BYOD) increasing in popularity and the traditional security perimeter dissolving in favor of zero trust networks, it’s important to incorporate identity-centric controls in your incident response procedures.

Getting Started

Add your desired Okta action(s) to a new or existing Exec playbook.

Okta API Domain & API Token

See Okta’s Getting a Token guide for detailed steps on how to obtain an API token.

Best practice guidance:

  • Create a local Okta user account that is dedicated to this integration; this account will be referred to as the Service Account
  • Assign an Okta admin role to this Service Account that provides just enough privilege to perform the actions that you desire. Role details can be found here. It will either be an Org Admin or Group Admin
  • The Service Account needs to remain active to support this integration
  • The Password can be changed without affecting the API Token you generated

Human Approval

In some instances, like with Okta actions, full end-to-end automation isn’t possible (safely) without some form of human review or approval. 

While the endpoint has an associated user identity, that user identity (AD_DOMAIN\joren) may not exactly match that user’s associated Okta identity (joren.m@example.com).

In this case, we will suggest possible matches and have your team make the final call prior to taking the automated action. We will send a link to you via the specified notification preference.

Support

Need help or want to see support for other providers?
Contact us at support@redcanary.com

Did this answer your question?