Overview

Summary: Trusted Proxy and Network Zones

Audience: Okta enterprise customers, customers with compliance requirements, and customers who may have taken improper guidance from vendors/partners.
 

Applies To

• Network Zones
• Customizations

Security Knowledge

In our pursuit of enabling simple and secure access to any technology, Okta Security periodically reviews customer implementation of Okta SignOn Policies. Our primary goal is a policy engine that steers Okta Admins toward strong security outcomes. During one of these reviews, Okta observed customers using a Network Zone configuration that could result in unintended consequences for their security posture. 

This configuration would appear as follows:

Org Name: [Org Name]

OrgID: [OrgID]

Network Zone name: [Network Zone name]

This Dynamic Network Zone designates the entire internet (0.0.0.0-255.255.255.255) as a trusted proxy. When configured this way, access requests from devices in that policy are not evaluated by ThreatInsight, Okta’s baseline protection against high-volume, credential-based attack. This implementation choice reduces Okta’s ability to protect users from credential-based attacks.

We have observed that this configuration has been recommended by third parties in some cases in order to differentiate between Desktop-based and Browser-based Sign-ins to Okta. 

Irrespective of what MFA policies you use to protect access to resources, we urge you to consider the potential impacts of choosing not to take advantage of ThreatInsight:

• Exposure to credential-based attacks: Exempting all internet addresses from ThreatInsight exposes your users to credential-based attacks such as password spray attacks and credential stuffing.
• Impact on risk scoring: ThreatInsight evaluations is one of several inputs into Okta’s Risk Engine. Many Okta customers create different SignOn Policies based on these assessments of risk. Most often this results in relaxed requirements for requests assessed to be low risk and the imposition of higher assurance controls for those deemed high risk. If ThreatInsight is not evaluating your requests, a higher risk event may be assessed to have a lower risk score.
• Fewer detection opportunities: Irrespective of whether ThreatInsight is configured in block/enforce mode versus audit/log mode, the signals generated by ThreatInsight are surfaced in both System Log and in various dashboards within the Okta Admin console. Choosing not to evaluate requests reduces the opportunity for your team to recognize and respond to events of security interest.

Recommended Actions: Okta recommends considering removing the rule that designates 0.0.0.0-255.255.255.255 as a trusted proxy. 

More about Trusted Proxies: When an admin creates a Network Zone in Okta (an IP zone, specifically), they have the option of designating this zone as a Gateway IP or a Trusted Proxy IP. 

We recommend the following whitepaper for learning about how ThreatInsight responds in either scenario.

If you want to learn more, leverage our multiple resources available at the Okta Support Center.