A common use case using Netskope One SSE and Okta is to extend your zero trust perimeter using Okta Network zones and the Netskope NewEdge network. This will create an additional obstacle for an attacker to use compromised credentials and is recommended by Okta as a defense against credential stuffing attacks. The Netskope One client checks the device posture or compliance in real time via Device Classification to ensure that only Corporate managed devices are allowed to connect to Okta. The following Okta authentication policy rule scenarios are presented below: (these would also apply when using tunnels)

Prerequisites for all policy scenarios

1. Prevent users from disabling the Netskope Client in the Netskope Admin console: Settings→ Security Cloud Platform→ Client Configuration → Tamperproof 
   1. For more information: https://docs.netskope.com/en/netskope-help/netskope-client/netskope-client-hardening/ 
2. Create a Network Zone in Okta: Security → Networks → Add zone → IP Zone
   1. The current list of Netskope IP ranges: https://support.netskope.com/s/article/NewEdge-Consolidated-List-of-IP-Range-for-Allowlisting 
   2. By default, Netskope NewEdge inserts a X-Forwarded-For header into all traffic destined to Okta domains.
3. Add the Netskope NewEdge networks or Dedicated Egress IP Addresses (DEIP) to both the Gateway IPs and Trusted proxy IPs (this enables support for the X-Forwarded-For header inserted by Netskope and preserves IP velocity and reputation for Okta Behavior Detection and Threatsight) sections. Creating this prerequisite Network Zone is also required for Dynamic Zones.

Since both sections are populated, this zone is now X-Forwarded-For aware and will utilize the real client IP address for Okta policy and risk assessment 

4. Create a Okta custom error message: Customizations → Other → Access denied error message 
   • Add links for additional help and/or to open a support ticket

5. Create a new Okta authentication policy or update an existing policy rule with the Okta Network Zone created above. See below for an example of Okta policy rules. 

An exception group can be used for testing or exception approvals

Allow mobile device access until the Netskope One mobile client is deployed. Require device registration(Okta Verify is installed) to prevent User-Agent string spoofing or tampering.

Scenario: Restrict access to application(s) for users that originate from Netskope NewEdge

Business Outcomes: Improve user experience for hybrid or remote users. Reduce application identity attack surface and time spent resolving security policy violations by untrusted sources. Reduce breach remediation costs by restricting adversary initial access and persistence techniques.

• Create a rule that requires access from Netskope NewEdge and a password every 12 hours.

End User Experience results

• Okta Dashboard from Netskope NewEdge (Netskope client enabled)

Okta Dashboard not coming from Netskope NewEdge (Netskope client disabled)

• Authentication policy denies access and places a lock symbol on the application chiclet

SP initiated Okta custom error message not coming from Netskope NewEdge (Netskope client disabled) {The Corporate Logo will be your own}

Scenario: Restrict access from Netskope NewEdge in the United States 

Business Outcomes: Reduce sovereignty compliance requirements and time spent resolving security policy violations by untrusted sources. Reduce breach remediation costs by restricting adversary initial access and persistence techniques.

This scenario requires using Netskope Dedicated Egress IP addresses. 

To obtain a list of the Dedicated Egress IP addresses for the Data Planes in the United States in the Netskope Admin console: Settings → REVERSE PROXY→SAML→ NETSKOPE SOURCE IP

Please follow the steps in the scenario above to create an Okta Network Zone using these IP addresses for the Data Planes in the United States.

Using a Dynamic Zone for ASN is not recommended since it only uses the ISP ASN instead of Netskope’s ASN. Proxy type also does not apply, per Okta this type is an anonymizer. Even though the Geolocation data in the logs are correct, testing has shown that neither apply to the Netskope NewEdge IP addresses. 

Scenario: Restrict access to originate from Netskope NewEdge and the user’s client IP originates in the United States

Accuracy of the Geo Location for IPs

Business Outcomes: Reduce sovereignty compliance requirements for user location and time spent resolving security policy violations by untrusted sources. Reduce breach remediation costs by restricting adversary initial access and persistence techniques.

Warning: If you check this box, the Dynamic Zone becomes active immediately without applying to an Authentication Policy {It is recommended to test using your Okta Sandbox or Preview Tenant}

1. Using the Netskope NewEdge zone created above, create a rule to block if Not in this zone:(Netskope client is disabled)

2. Create a Dynamic Zone to Allow IP addresses from the United States

Because you created a Network Zone above called Netskope NewEdge, Okta will now evaluate the Dynamic Zone based on the X-Forwarded-For Header.(User’s real client IP address)

3. Create a rule to allow from the United States 

Scenario: Restrict access for Administrators to originate from Netskope NewEdge or secure on-premise

(If the secure on-premise IP addresses are not behind a Proxy{No X-Forwarded-For}, use only the Gateway IPs section in the Network Zone) 

Business Outcomes: Reduce privileged account access exposure and time spent resolving security policy violations by untrusted sources. Reduce breach remediation costs by restricting adversary initial access and persistence techniques.

1. Create a rule for an exception group (duplicated from prerequisites to emphasize importance)

2. Create a rule to allow from Netskope NewEdge or On-premise zones

Scenario: Restrict access to Okta API Tokens to originate from Netskope NewEdge

Business Outcomes: Reduce privileged account access exposure and time spent resolving security policy violations by untrusted sources. Reduce breach remediation costs by restricting adversary initial access and persistence techniques.

1. Enable the Network Restrictions for SSWS Tokens: Settings→Features {licensed feature, not available in free Okta Developer tenants}

2. You can apply the Network restriction when creating a new API Token as below

Or by editing an existing API Token and selecting the Netskope NewEdge Zone

Troubleshooting

For troubleshooting, you can view the IP Chain in the Okta system log, refer to this Okta support article. If you only see a single IP address in the Okta system log, please verify the X-Forwarded-For header using these websites: https://notskope.com or https://ifconfig.me . If you do not see the X-Forwarded-For header or two IP Chains, please check your SSL Decryption policy in your Netskope tenant.(Adding the X-Forward-For header requires decryption) If you configured a policy to bypass for Okta FastPass or Okta Verify for Windows or MacOS, change this to a process level bypass. The process names can be found in the nsdebuglog.log file as seen below:

**** Add this new Certificate Pinned Application your steering configurations ****

Use tunnel mode if you have Netskope Cloud Firewall and add the required outbound Okta Google Firebase ports