Recently, Okta acknowledged a breach where attackers were able to gain access to customer session tokens, and other sensitive data through HAR captures in their customer support system. Attackers were then able to use the unexpired session token to access the Administrative API in the customer’s Okta tenant. The Administrative API was accessed via the browser which only requires a session token or cookie unlike the typical approach using a bearer token. In this case, the attackers were able to gain the initial access to the customer support system via an employee syncing a service account password to their personal Google password manager.
Netskope customers can address and help prevent such exploits through a multi-phased approach. Let’s take a look at the first phase.
Phase 1: Controlling Personal Google Account Logins
Netskope was initially built as a Cloud Access Security Broker (CASB) with an inline proxy capability. This background provides our Secure Web Gateway with a breadth of granular controls across cloud applications including both personal and enterprise (corporate owned and third party). Controls based on the instance of the cloud app, username being used to login to the app, activity, data and more allow for us to prevent logins to personal accounts even in the case of Google Workspace where a shared URL is in use for all tenants. To see this in action, I’ve written a policy that blocks logins to personal instances of Google Accounts:
When I attempt to enable sync on Google Chrome and login to my personal Google Account I receive a notification that this is prohibited by policy:
This might seem like a heavy handed approach as your users may want to read emails or need access to personal Google Drive for their own personal use. Instance awareness controls allow you to safely enable this access without risking data loss by writing policies that allow read access to personal Google Drive and Mail instances but block write activities:
These policies can be combined with Google’s native control over the Password Manager via GPO. This would allow you safely enable users accessing their personal Google instances while still applying threat protection, data protection and other controls and restricting access to the password manager. The first phase of the breach would have been prevented using the controls above, as the user would never have been allowed to login to Google Password Manager to sync the service account password.
Phase 2: Using IP Restrictions for Administrative Roles
The breach reported to Okta was identified in part via a suspicious IP address found during investigation. In the second phase of mitigating against such a breach, we can use Netskope’s egress IP architecture to implement a positive security model to flag traffic from non-Netskope or corporate owned IP addresses as suspicious or outright block it.
Before we jump into the configuration it’s important to understand how traffic egresses Netskope. Any traffic that is steered to Netskope is inspected at one of Netskope’s NewEdge Data Planes in more than 70 regions and the destination app will see a Netskope IP Address once this processing is complete. By restricting access to your Identity Provider and SaaS applications to Netskope IPs you can significantly reduce potential for unauthorized users or devices accessing your applications. Let’s take a look at the options Netskope has for egress traffic.
Shared Egress IPs
The default behavior for traffic steered to Netskope is that traffic allowed by policy then egresses Netskope owned IP addresses. These IP addresses are shared and Netskope provides the full scope of shared IPs for allow listing. Administrators can require that users accessing specific apps or all apps must come from Netskope IP ranges (examples for common IDPs are provided below). Now the drawback here is that while this does restrict access to just Netskope IPs, it doesn’t guarantee that the traffic is from your tenant or your users.
Dedicated Egress IPs
Netskope provides an optional feature called Dedicated Egress IP Addresses. These are still Netskope owned IP addresses but when enabled they restrict traffic for your tenant(s) to specific IP addresses reserved solely for your organization. This guarantees that traffic from these IPs is coming from your tenant and users. IP addresses can either be made available globally or in specific regions based on your organization’s footprint.
The Mitigation
We just discussed the egress IP options for Netskope but how does this actually mitigate the threat of an attacker using an already valid session token? Using Netskope and Okta’s native controls, we can take a multi-faceted approach.
- Any session token not from a Netskope IP address or corporate owned IP addresses should be considered an Indicator of Compromise (IOC) and start remediation automation to disable the administrative account and any recently created accounts or API tokens from said account along with human notification for investigation. This is especially relevant for administrative access as this traffic should ideally never come from a BYOD or third party device. (Reference)
- Implement IP based rules using Authentication policies in Okta and the respective SaaS applications for administrators (and optionally users).
You should evaluate the below controls within your environment and ensure that you have break glass accounts exempted from the below controls or also allow access from your own network. This will allow access in the event of an emergency. For future consideration, Okta has released a new Early Access feature that when a network change has been detected the session token is revoked, which requires re-authentication. You can enable this under Settings > Features in Okta:
Further, Okta Identity Threat Protection (expected early next year) which is based on the shared signals framework (Reference), will provide additional capabilities that can leverage Netskope’s User Confidence Index Score to automate remediation capabilities.
As for controls available today, you can implement an IP restriction policy in the Global Session Policy. Implementing IP restrictions within the Global Session Policy ensures this applies to general Okta sign-ins and API based access. While the below example focuses on Administrators, you can also consider applying these controls to your regular users as well and consider how you handle BYOD use cases. Individual applications within Okta (and in many cases the SaaS app itself) also support specific policies for IP restrictions.
When creating the Network Zone, copy and paste the Netskope Shared Egress IP or Dedicated Egress IP addresses as shown.
Set a Maximum session lifetime (more restrictive options are suggested below)
If you do decide to implement similar controls for user based access, consider balancing the session lifetime and idle sessions for user experience versus security. In general though, the Administrator based sessions should be much shorter lived and more restrictive.
Final Thoughts
We’ve provided a fairly informal discussion on how Netskope’s Instance Awareness, flexible steering and egress IPs can be used to help secure Administrative access to your Okta tenant. One other risk to consider is that an attacker with a compromised session token to Okta could theoretically enroll into Netskope (or other authenticated proxy solutions) if you’re using an IDP based method. You can mitigate this risk by using Netskope based device posture checks to ensure the enrollment and traffic are coming from legitimate devices.
This article primarily focused on Okta but similar controls are available from other Identity Providers such as Microsoft’s Entra ID via Conditional Access. Although the intricacies of API access and the capabilities differ, administrators can still leverage IP restrictions using Netskope to ensure access is only from authorized users and endpoints. The same instance awareness policies discussed for Google also apply to Microsoft and numerous other applications. Additionally, Netskope also supports tenant restrictions for Microsoft via Cross-Tenant Access Policies.