We break down 10 key security configurations and features to ensure robust authentication and identity management within your Okta instance to help prevent future attacks.
Okta is a leading identity and access management solution used by enterprises and organizations worldwide. It offers a range of security controls and configurations to ensure secure identity federation. Still, like every advanced identity provider, the platform must be configured properly to achieve its full potential, which isn’t always as straightforward as it sounds.
Threat actors targeted Okta in several security breaches throughout 2023, sending waves of panic across their customer base and cybersecurity teams worldwide, including:
-
- 1Password – Attackers compromised a member of 1Password’s IT team and gained access to their Okta tenant with admin privileges.
-
- MGM – The casino giant, an Okta customer, suffered hundreds of millions of dollars in damages after ransomware attackers broke into its system via a social engineering campaign.
-
- Okta – Attackers targeted Okta itself, leaking sensitive customer information extracted from HAR files, which were stolen from the Okta ticketing system.
In the face of breaches like these, identity providers like Okta are developing more security configurations and controls. Properly configured, these can drastically reduce the chances of successful attacks.
However, identity providers can only do so much. Whether through a lack of awareness or understanding, many Okta customers aren’t using available security features in the Okta platform effectively or at all. In this article, we share 10 features to help you strengthen your Okta security posture and avoid misconfiguration.
Top 10 Okta Security Features
#1: Okta ThreatInsight
Okta ThreatInsight is a security feature designed to enhance the protection of Otka’s identity management services. Its main purpose is to identify and mitigate potential threats such as brute-force authentication attacks and password spraying.
How ThreatInsight works
Okta searches customer logs for known patterns of identity attacks. For example, if it detects an IP address trying to authenticate to more non-existent users in your tenant than the threshold allows, ThreatInsight will classify these attempts as suspicious and block the address. Okta tracks suspicious IP addresses of all tenants, which means ThreatInsight can block a suspicious login attempt based on detection from another tenant.
How to configure ThreatInsight
Even though it should be enabled and configured by default, many tenants have it disabled. To check whether ThreatInsight is configured, log in via the Okta admin console. Navigate to Security, then General, and scroll down to the Okta ThreatInsight settings. The action configuration should be set to Log and enforce security based on threat level.
Note: You can use Okta’s Network Zones to exclude IP address ranges from ThreatInsight.
To identify detections by ThreatInsight, search the Okta system log for the event type security.threat.detected. Use the Result Reason field to find out why Okta audited and blocked the source IP address.
#2: Session Lifetime Configuration
The Okta session lifetime configuration helps organizations limit the lifetime of an authenticated user session. After an Okta user signs in to the system, the session lifetime limit is enforced. When the configured lifetime has expired, the user must re-authenticate to maintain access.
The session lifetime configuration minimizes the risk of session hijacking attacks. If a session cookie of an active Okta session is compromised, it’ll be valid for as long as the Okta administrator permits. However, if an attacker gets hold of a time-limited session token, it might not be valid when they try to reuse it.
How to configure session lifetime
Okta enforces session lifetime configuration using Global Session Policies. These are not app-specific – they enforce a set of global settings that control every Okta session.
Okta has introduced two ways to limit the lifecycle of an active session:
-
- Configure the Maximum Okta global session lifetime – this is the maximum lifetime of an active Okta session.
- Configure the Maximum Okta global session idle time – this is the maximum timespan of inactivity allowed during an active session. Even if the global session lifetime limit has not been reached, users will be prompted to re-authenticate should they exceed the maximum idle time.
An organization can have multiple global session policies with multiple rules in each one to enforce different configurations based on the target application or user group.
Configuring both of these is simple. Navigate to Security and then Global Session Policy. Find the relevant rule, and click Edit. Scroll down to the section on Okta global session management:
The screenshot above shows our suggested configuration:
-
- Maximum Okta global session lifetime (12 hours) – we recommend that employees authenticate at least once in a workday.
- Maximum idle time (6 hours) – we recommend that the maximum idle time is lower than the global session lifetime. In this example, it’s set to 6 hours, so if an employee is idle during the workday, they must re-authenticate.
- Persistent cookies (Disabled) – this provides an extra layer of session security. It’s not time-related.
When the user exceeds the session limits, they’ll be logged out of the system, and the following message will be displayed:
#3: Admin Console Session Management
The Okta admin console is a sensitive application with a large potential blast radius, so should only be assigned to authorized users. Okta lets you specifically limit the session lifetime of the admin console. This differs from the global session policy, as it’s an app-based limitation and doesn’t affect the Okta session.
The Admin Console Session Management feature lets you limit the lifetime of administrative sessions. It’s very easy to configure and doesn’t require any re-evaluation of the sign-in strategy. In this way, organizations that don’t limit their users can still do so for admin access with the click of a button.
How to configure Okta Admin Console Session Timeout
On the Okta admin page, navigate to Settings > Features. Toggle Admin Console Session Management:
Once the feature is turned on, administrators will be limited to a maximum session lifetime of 12 hours and a maximum idle time of 15 minutes.
These settings can be edited by navigating to Applications > Okta Admin Console, selecting the Sign On tab, and then Edit on the Okta Admin Console session.
#4: Password Policy, Lockout, and SSPR
Password policies in Okta serve multiple purposes and can be used to define the following properties:
1. Password complexity and age
2. Lockout and user unlock policies
3. Who can take advantage of the Okta Self-Service Password Reset (SSPR)
Threat actors often target users who don’t have multi-factor authentication (MFA) in place with password-guessing attacks to get their foot in the door of an organization’s system. But the harder it is to steal or crack a password, the harder it is for attackers to succeed.
This is why Okta’s password policies not only define the strength of passwords but also what happens if a user is under a suspected attack, such as how many failed authentication attempts are needed to lock out a user (if any) and how long it takes to unlock the user again automatically (if at all).
Okta allows you to assign multiple password policies for different groups. You could assign policies based on sensitivity, for example, such as one for administrators of the tenant and another for general users.
The admin policy would be more restrictive and produce different results during an attack, such as ensuring that locked-out administrators are not unlocked automatically or can use SSPR.
How to configure Okta password policies, lockout, and SSPR
In the Okta admin console, navigate to Security > Authenticators > Password > Actions > Edit. Below, you can see our suggested restrictive password policy, designed to protect administrative users:
You’ll also need to edit the policy rule. Scroll down to the rules segment and edit your policy rule to deny administrators the option to use SSPR. If an admin can’t use SSPR, an attacker with access to the admin’s email account won’t be able to reset their password and gain access to the Okta account.
Use the following configuration to deny SSPR:
The suggested rule allows authenticated users to change their password and prevents unauthenticated users from unlocking and resetting their password by themselves.
#5: Okta Behavior Profiling
Okta behaviors are a list of attributes that Okta uses to create a profile of users in the tenant.
The list of available behaviors is as follows:
* Location (country, city, geolocation)
* Device
* IP address
* Velocity
Behaviors can be configured to allow specific access rights. A behavioral profile creates a baseline for each identity, which helps to verify that a user is who they say they are. A deviation from the baseline, such as a user that typically signs in from Germany suddenly doing so from Argentina, might suggest that the identity has been compromised.
How to configure behavior rules
You can create behavioral conditions in Okta’s global policy to grant or deny access. This example shows how you can configure your Okta tenant to deny an authentication attempt if it comes from a new country.
In the Okta admin console, navigate to Security > Behavior Detection. By default, the New Country behavior should be configured as follows:
This identifies users who log in from a country different from that of their last ten successful authentication attempts.
To enable this, navigate to Security > Global Session Policy. Choose a policy and add a new rule as the highest priority. In the Behavior is section, type “New Country”. Okta will auto-complete your input based on the configured behavior detections.
In the Access section, select “Denied.”
This rule will strictly deny access to Okta from new countries according to the behavior detection settings.
We suggest applying behaviors like those above to an administrative group to minimize their attack surface.
Identify Okta behavior rules in logs
When a rule with a behavior condition is applied, new content is added to Okta’s sign-in logs. The behaviors are displayed as a boolean set of values:
More information about behaviors is available on Okta’s documentation page.
#6: Okta Automations
Okta Automations is a feature that helps you automate a user’s lifecycle based on their activity level. There are two types of Okta Automations:
* User Inactivity in Okta – changes the user state after a period of inactivity in Okta.
* User Password Expiration in Okta – changes the state of the user if they fail to change their password after a certain time.
An identity provider might have hundreds or even thousands of entities. The bigger the directory, the harder it is to maintain access for users who need it. Dormant users offer attackers a way into the organization. Using Okta Automations is a straightforward way to automatically disable dormant users.
How to configure Okta Automations
The available automations can be triggered by one of two conditions:
* The user is inactive for too long – if a user exceeds the threshold number of days for inactivity, the automation is executed.
* The user’s password expires – if the user fails to change their password by the threshold number of days, the automation is executed.
The automation can change the Okta user state to Suspended, Deactivated, or Deleted.
This example shows how you can configure an Okta automation to suspend users who were not active in the last 90 days:
1. In the Okta admin console, navigate to Workflow > Automations.
2. Select Add Automation and call it “Suspend a user after 90 days of inactivity”.
3. On the new page, click on Add Condition.
4. Select User Inactivity in Okta.
5. Set the duration to 90 days.
6. In the group membership setting, click Edit and type “Everyone.”
7. In the schedule setting, choose Daily and hit Save.
8. In the action pane, select Add Action.
9.The action type should be set to Change the user lifecycle state in Okta to Suspended.
10. In the top right corner, click on the Inactive button and change it to Active.
With these settings configured, inactive users will be suspended. This automation ensures only the necessary level of access is available.
How to identify Okta Automations
You can monitor automations by searching Okta logs for the event type “policy.execute.user.start”:
#7: Bind Admin Sessions to an Autonomous System Number (ASN)
An ASN is a number used to identify the owner of an IP address range. Okta’s Early Access feature ensures that the ASN an admin uses for authentication remains the same for the rest of the session. If the ASN changes, the admin must re-authenticate.
Session hijacking is a common technique threat actors use to gain unauthorized access to user accounts and abuse their session, often from a different geographical location.
The attack works like this: When an Okta user signs in, a new session with a unique identifier is generated, which Okta tracks using the ASN from the initial login. If a session is stolen and replayed from a different geographic location, the ASN will change as well. When Okta receives the HTTP request with the same unique session identifier but from a different ASN, it requires the user to re-authenticate. This way, a valid session cookie is not enough to stop the attacker from replaying the session from a different geolocation.
How to configure admin session binding to ASN
In the Okta admin console, navigate to Settings > Features. Search for a feature called “Bind Admin Sessions to ASN” and toggle the button to enable it:
How to detect admin session migration in logs
When Okta suspects that a session has been stolen and asks for re-authentication, it logs the request. You can use this log to search for suspicious session activity in the organization:
#8: Enforce phishing-resistant authenticators to enroll additional authenticators
Okta supports phishing-resistant authenticator types that are more secure than others. Phishing-resistant authenticators protect Okta users from phishing attacks.
If a user wants to add another MFA method to their account, they’ll need to present an MFA response from a device that has already been configured.
The Early Access feature requires the factor in the response to be phishing-resistant. This is because attackers often enroll a new factor to achieve persistence over a compromised user account. If the compromised user has an email MFA and the attacker has access to the user’s mailbox, they can add a new factor device. When the phishing-resistant authenticator feature is turned on, the attacker can’t enroll a new factor unless they present an MFA response from a device belonging to the original user.
If this feature is turned off and a user tries to enroll an additional authenticator, they’ll have to present an MFA response from any of the factors already configured for their account:
In this example, you can see that the user can use the security question MFA to enroll a new device.
Once the feature is turned on, only phishing-resistant options will be displayed for the already configured devices.
Now, the user has to provide a phishing-resistant factor to enroll a new device.
How to configure the right Okta policy
In the Okta admin console, navigate to Settings > Features. Search for a feature called “Require phishing-resistant authenticator to enroll additional authenticators” and toggle it.
#9: Okta Network Zones
A network zone is a customizable object that can be used to control access to an Okta tenant based on the origin of an authentication request. There are two types of network zones:
1. IP zone – an aggregated list of IP addresses and ranges.
2. Dynamic zone – one or more conditions based on IP address metadata such as geolocation, ASN number, and other incriminating characteristics, including TOR exit nodes and a proxy address detected by Okta.
Once at least one network zone is configured, it can be used as a condition by Global session policies and Application authentication policies.
How to configure a network zone
In the Okta admin console, navigate to Security > Networks. In this case, you’ll create a network zone that’s designed to block malicious IP addresses. Click on Add a zone and choose your preferred configuration:
1. IP Zone
1. 1 Zone name: Disallowed List
1.1.1 Gateway IPs: IP addresses or IP CIDRs to include in the network zone
Click Save
The screenshot above shows an IP zone comprised of two IP addresses and one CIDR.
Dynamic Zone
1. Zone name: Disallowed List – Condition Based
1.1. IP Types: If you want to block proxy addresses, you can use one of Okta’s proxy detection tools:
* Any Proxy
* Tor Anonymizer
* Not Tor Anonymizer
2. Locations: a geographic location (or more) of your choosing
2.1 ISP ASNs: a list of ASN numbers to include in the list
The screenshot above shows a dynamic zone that contains any proxy from Israel or the USA and is part of the ASN number 111.
Both zones let you block access from IPs matching the listed conditions. If this option is turned on, Okta automatically blocks requests from addresses in the zone. If not, a global session policy or an application authentication policy should be configured to support the new network zone.
How to configure a relevant Okta policy
In the admin console, navigate to Security > Global session policy > Policy > Policy rule. Then look under Policy Settings and enter the following options:
1. In the User’s IP section, select “In zone”
2. Type the zone name into the textbox and click on the auto-completed name
3. In the Access section, select “Denied” for disallow lists, allowed otherwise
The rule blocks Okta from accessing addresses specified in the zone called Disallowed List. The same logic can be applied to application authentication policies to control access to a specific application based on network zones.
#10: Detect Lockouts Caused by Unknown Devices
This feature lets Okta distinguish between recognized and unrecognized devices that are attempting to sign in. If an employee has successfully signed in to Okta with a device before, it’s recognized. If they haven’t, it’s unrecognized.
When a user logs in from an unrecognized device – including computers, browsers, and IPs – Okta permits the sign-in attempt within the limits specified by the password policy. If the user exceeds the maximum allowed login attempts on the new device, access will be restricted. However, if Okta identifies unsuccessful sign-in attempts from an unrecognized device, it will block new sign-in attempts from such devices while still allowing access from recognized ones.
How to configure Detect lockouts caused by unknown devices
In the Okta admin console, navigate to Security > General. Search for a feature called “Detect lockouts caused by unknown devices” and click Edit. Set the configuration to “Enabled” and hit Save.
Where Are You At Risk?
Okta offers a variety of features to boost your organization’s security posture. Okta customers do not commonly use the 10 features and security configurations we’ve covered in this article, though they should be. After all, some of these features could have prevented the recent Okta security breaches or at least reduced their magnitude.
It’s important to remember that configuration or automation alone is not always enough and that intelligent monitoring is a crucial aspect in detecting and preventing cyberattacks.
If you’d like to see where your Okta misconfigurations exist today, Rezonate can conduct a free Okta risk assessment and identify any existing risks or misconfigurations in your environment. Request your FREE risk assessment report today!
