Protection, without perimeters

Given the premise that “identity is the new perimeter”, we’re often asked about the role network attributes should play in restricting access to applications, servers and data.

Can we, and should we, for example, deny access requests originating in high-risk countries or countries involved in conflict?

The reality is that network context still matters. We can take into account the identity of the network and location our users are authenticating from. If a customer determines that there are no authorized users in a region or country, a least privilege approach might warrant a decision to not allow networks from that region to connect to its applications and data.

The network source of an access request is one of the many attributes that can be dynamically evaluated prior to or during authentication as part of “Zero Trust” approach to security.

In Okta, the building blocks of this assessment are what we call Network Zones.

Okta Identity Engine - for illustrative purposes only

Okta Administrators can configure a network zone by IP (or IP range), which is useful when allowlisting trusted network locations, for example, or denying requests from IPs known to be untrustworthy.

Okta’s Dynamic Zones go one step further. These zones are based on a dynamic evaluation of IP attributes, such as what country, organization, or Autonomous System Number (ASN) / Internet Service Provider (ISP) is associated with an IP, whether the IP is associated with known proxies such as TOR, or whether those proxies attempt to anonymize the true source of the request.

Network zones can be taken into account prior to authentication, during authentication, or at any other time the security context of a session is re-evaluated.

Pre-authentication

Network attributes can first be evaluated during pre-authentication: that is, when a user attempts to load an Okta sign-in page in their browser. Administrators can configure a network zone to limit access to their sign-in page to the trusted locations they expect users to sign-in from.

During authentication

An organization might choose to block access requests from anonymizing proxies, or from ASNs with a poor reputation, or from high-risk countries where they don’t expect to have any legitimate users at pre-authentication. But this approach is less ideal when you need to provision access by exception - such as to a handful of legitimate users in a country or from an ASN where you ordinarily wouldn’t conduct business.

You might, for example, have a small set of known users with a legitimate reason to authenticate from a country that you would otherwise be considered risky. In these circumstances, network zones can be evaluated during authentication.

An administrator might, for example, require that users authenticating from a specific network zone(s) meet an additional set of security requirements than those authenticating from a trusted network.

Okta Identity Engine - for illustrative purposes only

Okta allows for these use-cases to be managed through group membership or user and device attributes. Policies can then require these users to present higher assurance factors (such as those that are device bound, hardware protected, or otherwise phishing resistant). Or they might be limited to only authenticating from a known, registered or managed device, and/or from a device that exhibits specific device posture.

Administrators may also take an “adaptive” approach - applying a differentiated set of access conditions based on an evaluation of risk. How risk scores are calculated varies by organization: Okta’s Risk Events API allows admins to factor in risk scores derived from external signals, such as their third-party security partners. “Out of the box” scores are determined by evaluation of both network reputation and any changes in user or device behavior (new device, new location, new IP, impossible travel, or other factors).

Administrators can use this breadth of policy and authenticator options to develop “zero trust” access policies from a single control plane. A zero trust approach to security requires a “trust, but verify” approach around any single attribute.

What does that mean in practice?

• We should anticipate a small number of users will choose common passwords and re-use them. Okta allows admins to deny common passwords and apply strong password policies.

• We should anticipate that even strong passwords will be reused and occasionally stolen. Use of rate limiting controls on authentication endpoints and allows admins to protect accounts using multifactor authentication.

• We should anticipate attackers will attempt to anonymize or spoof their location. Okta provides admins a broad mix of complementary attributes to assess in access policies: everything from behavior detection to device context, high assurance factors and integrations with third party security providers.

While typically network zones are configured in the Okta administration console, they can also be programmatically managed using Okta’s Zones API. The API provides the ability to poll, create and update network zones. This comes in handy when updating larger sets of IPs across multiple network zones using intelligence gleaned from outside Okta.

Modern internet infrastructure is highly ephemeral, with many IP addresses being rapidly assigned and reassigned to users and devices. Because of this, determining the reputation of any given IP is relatively dynamic and highly contextual. Okta will only block an IP address globally where malicious intent can be inferred with high confidence. We strongly recommend organizations complement it with their own blocklists.

This shapeshifting environment requires a defensive approach that can rapidly assign reputation to an IP as soon as it is observed in attacks. That’s where Okta’s ThreatInsight – and machine learning more generally – can play a role.

ThreatInsight

Okta ThreatInsight is a default security capability available to every Okta customer that is designed to detect and block high-volume credential-based attacks that target Okta endpoints.

ThreatInsight uses heuristics and machine learning to recognise common password spraying, credential stuffing and similar brute-force attacks. Importantly, it harnesses the network effect of the many millions of authentication requests made to thousands of Okta orgs on any given day to provide currency to the reputation of any given IP.

The capability offers a security baseline for all Okta customers, with minimal configuration required. An Okta admin simply selects enforce mode in the Okta Admin Console to automatically deny requests identified as malicious at pre-authentication, or audit mode to tag the malicious request with a higher risk score during authentication or to generate alerts in your SIEM/SOAR.

Security is a Team Sport

The Okta Identity Cloud can assess all of this context from one control plane and intuitive administration console. But we also view zero trust security as a “team sport”. Okta deliberately constrains our assessment of IP reputation to behaviors observed across the Okta Identity Cloud and the intelligence we consume from trusted partners.

Your security and threat teams have a much better understanding of your cloud and data usage patterns, including your use of Okta. The Okta Risk Events API offers an ability for administrators to ingest signals from other sources of risk data: such as network service providers with broader visibility, partners that assess risk across an entire Content Delivery Network, specialist providers of bot management services, or data collected by customers themselves. These can augment native Okta capabilities and give customers a larger set of data from which to evaluate the risk of any given request.

This open and neutral approach and partnerships with other best-of-breed providers offers the best opportunity for you to provide users with frictionless access to applications and data using a least privilege model across both user and network identities.

Chris Niggel contributed to this article