Oort Insights
Oort provides more than 40 checks. This page provides a brief summary of each check. For further detail, please view the relevant sub-pages.
A user has used a bypass code to sign in instead of MFA. Bypass codes are issued when a user lost their phone or asks for temp access.
Recommended Actions
Users should not be assigned bypass codes or run in bypass mode. If they do, please make sure to link a ticket opened in security.
Okta allows impersonation, mainly for support.
If an attacker takes over an admin account they can impersonate other legitimate users.
Recommended Actions
Please contact your Okta administrator to ensure the actor is authorized to impersonate a user session.
We recommend Okta admins share a teams/slack channel and attest, preferably with a ticket that the work was sanctioned.
If the user impersonation session is not legitimate, make sure the target user is returned to a good state and create an incident.
A user was assigned an admin role.
Recommended Actions
Please make sure this assignment was done through the right process and confirm in a Slack/Teams message.
If the target should not be an admin or should not be assigned that role please start an investigation and add the ticket number here.
Common browsers like Chrome, IE/Edge, Safari, and Firefox comprise over 80% of browser activity. Rare browser activity can be a security issue due to the latency of applying patches to those browsers. It also may indicate that this is not the user who usually uses the account. This check has a customizable allow or block list.
Recommended Actions
Please review the activity of users tracked with a rare browser. Evaluate the user alongside other security anomalies like new locations or login failures. You can exclude this user from the check or add the browser to your allowed list.
You can toggle between using a blocklist or an allowlist. You can allow only users with email domains in your allowed list (recommended), or you can allow from a list of popular personal email providers. We do not recommend the latter in a work setting.
Recommended Actions
Depending on your security posture, consider deleting users using emails with those domains, and exploring why you have them in the system. You may also update your allow or block list.
User logged into application directly. Preventing logins with a username and password, ensures that users can’t bypass your SSO system.
Recommended Actions
Users should not be logging into application directly, unless this is an admin initiative to respond to an SSO outage or other problem. If they do, please make sure to link a ticket opened in security.
Adversaries may create/modify an account to maintain access to victim systems or modify the configuration settings to evade defenses and/or escalate privileges.
To identify such actions, Oort alerts on new (over the last 90 days) administrative actions performed by the account or on actions performed on multiple targets simultaneously (more than 10 targets in 10 minutes - configurable).
Recommended Actions
Verify with the account the reason for the changes.
Note - most of the alerts will represent accounts/application lifecycle (join/leave/move) so it's important to check the context of the action.
Users with a sudden spike in failed login attempts after a long period of inactivity.
Recommended Actions
Investigate the source of failed login attempts and update geo-blocking rules. Check if the username was in any known data breaches. Follow recommended remediation for Inactive Users. Trigger an access review with the user’s manager to verify that the dormant account still needs access. If the account is unneeded, suspend it. Otherwise, continue monitoring it for activity and suspend it after a grace period of configurable number of days.
An Azure Active Directory (Azure AD) business-to-business (B2B) collaboration user's UserType = Guest. Most systems allow you to easily invite these users into the Directory. This check tracks if these guests have logged in during the last configurable number of days. Most compliance frameworks require you to assess and purge these users promptly.
Recommended Actions
First, assess the users' security posture. We can also determine if users have conditional access and MFA enabled. We recommend deleting these users on a schedule, as they are easy to re-invite.
Inactive users are users who have not shown any activity in the past configurable number of days yet also have accounts with enabled status in one or more systems.
Why is it a problem?
Dormant accounts carry unnecessary financial and information security risks for your organization. These users might consume application licenses without using them. By leaving standing entitlements in place that are not needed or not used on a regular basis, attackers may be able to use a dormant account to gain access to sensitive systems and data. By reducing the number of accounts and adopting a least privilege model, organizations can ultimately reduce the attack surface of the entire organization.
How is it measured?
Users who are enabled (Active status) and who have not successfully authenticated during more than configurable number of days.
Recommended Actions
Trigger an access review with the user’s manager to verify that the dormant account still needs access. If not needed, suspend the account immediately. Otherwise, continue monitoring the account for activity and suspend it after a grace period of configurable number of days.
IP address reputation is like a credit score. Each address has a score based on associations with bad behaviors. It likely poses a risk if it ever hosted malware, phishing sites, or spam. The riskier the address, the worse its reputation. Like a credit score, its reputation takes a while to clear.
Oort uses an up-to-date risk service to notify customers when a user logs in from a marked address.
Recommended Actions
We recommend contacting the end user to purge the machine originating the traffic. In order to reduce false positives, only successful logins are tagged.
These are the users that have logged into the admin console in the last week.
As is, it is mainly a report to see if you can notice someone you don't know or who should have not done this. It is a method to track who is logging in and tracking changes.
Recommended Actions
Please track if you see someone you do not know or who might be odd.
Consider reviewing the list on a weekly basis or connecting to the digest email.
After the attackers gained access to account credentials they may abuse the automatic generation of push notifications to MFA services (such as Duo Push, Microsoft Authenticator, and Okta) to have the user grant access to their account.
To detect such an attack, Oort calculates the number of failed authentications on an account over 1 min timeframe and alerts if the number is higher than 5 (configurable).
Recommended Actions
Check with the account if the failed login attempts were initiated by the account.
Check for suspicious access to applications right after the MFA flood attack.
Check if the username was in any known data breaches and update the account password if needed.
Attackers may obtain and abuse account credentials to gain initial access, persistence, privilege escalation, or defense evasion.
Monitoring accesses from locations with no operation can identify such credentials misuse. To identify compromised accounts, Oort alerts on successful logins from a new (over the last 90 days) country for the tenant.
To reduce false positive alerts, accounts that were created less than 3 days prior to the check run are excluded. In addition, access from a managed device will be excluded for customers with Azure AD with InTune.
The check will be triggered on anomalous activities in the last 24 hours (configurable).
Recommended Actions
We recommend contacting the end user to verify the origin of the actions.
Accounts that were created but never successfully logged in.
Recommended Actions
Trigger an access review with the user’s manager to verify that the unused account is still necessary. If not needed, suspend the account immediately. Otherwise, reset the account and direct the manager to onboard the user correctly.
Multi-Factor Authentication (MFA) requires users to provide something they know, like a password or PIN, or something they have, like an out-of-band device or a one-time password provider. All users should be using MFA to gain access to the system.
Recommended Actions
Some system accounts may not have MFA. We recommend categorizing those for easy detection. Consider using solutions like expired passwords to block access to these accounts.
For newly created user accounts, Oort provides a default of 14 days before alerting that this account has no MFA configured. This value can be modified in the Check Settings.
Adversaries may create/modify an account to maintain access to victim systems or modify the configuration settings to evade defenses and/or escalate privileges.
To identify such actions, Oort alerts on new (over the last 90 days) administrative actions performed by the account or on actions performed on multiple targets simultaneously (more than 10 targets in 10 minutes - configurable).
Recommended Actions
Verify with the account the reason for the changes.
Note - most of the alerts will represent accounts/application lifecycle (join/leave/move) so it's important to check the context of the action.
Extremely long sessions without re-authentication pose a security threat and can increase the chance of session hijacking.
Recommended Actions
Clear the end user sessions to require re-authentication.
We recommend setting "Maximum Okta session lifetime" to 16 hours (one working day) and "Expire session after the user has been idle on Okta for" to 2 hours.
Okta authentication policies should have a maximum session length configured to prevent extremely long sessions without re-authentication. Similarly, the session idle time should be set to an appropriate value for your organizational policies.
Enforcing session timeouts for idle and maximum session lifetime is an important security control for mitigating attacks such as session hijacking. By default, Okta recommends that the session idle timeout is set to 2 hours (120 min) and the Maximum Okta session lifetime is enabled and set to no more than 30 days.
This insight will fail if any of your active Okta authentication policies do not have a maximum session lifetime value OR if the session idle expiration value is higher than the Oort value (configurable, 120 min by default).
Recommended Actions
Validate your Okta authentication policy settings.
We recommend setting "Maximum Okta session lifetime" to 16 hours (one working day) and "Expire session after the user has been idle on Okta for" to 2 hours.
Configure this insight session idle value to match your Okta session policies.
Okta has several rate-limiting functions for API. In this check, we alert system.org.rate_limit.violation and core.concurrency.org.limit.violation and we share which users contributed to the rate violation.
Recommended Actions
Okta has several rate-limiting functions for API. In this check, we alert system.org.rate_limit.violation and core.concurrency.org.limit.violation, and we share which users contributed to the rate violation. In most cases, these are service accounts from services that require tuning, such as Oort, Datadog, or Workday. Please check your organizational rate limits based on Okta API rate limit categories.
Consider the following actions: (1) Contact support of Okta to increase the rate limit if the operation is required, (2) Contact support of the product to see if events can be tuned (3) Consider moving to EventBridge to collect events.
Running parallel sessions is not high risk on its own, but is not common outside of IT.
This check flags users that have different session IDs in a one-minute timeframe, from at least two unique user agents and two unique IPs where and not all IPs are common for the integration
Recommended Actions
Please verify the users with sessions running in parallel are from IT/InfoSec teams.
These are the service accounts that have successfully signed in during the last week.
Service Accounts are usually used for backend-to-backend communication and are not supposed to have sign-ins.
Recommended Actions
Please track if this sign-in is legitimate.
Consider reviewing the list on a weekly basis or connecting to the digest email.
This check detects users that reported suspicious or unrecognized activity to the org admin from an email notification.
This check requires the "Suspicious Activity Reporting" feature to be configured in Okta.
Recommended Actions
Oort recommends you notify the user and admin channel, Oort allows the user to say the user made a mistake to reduce false positives. Please review the highlighted activity in the log to see the highlighted session.
Users who hit a limit on verification phone calls or text codes during sign-in.
Recommended Actions
If the problem repeats periodically, encourage users to move to an app or an external authenticator. If that is not possible due to local or business regulations, consider using an external provider like Duo.
This check detects if a user is accessing from an unmanaged device in the last 7 days (configurable). Oort will give an indication of the event and IP if the device was managed or not to allow you to inspect it closer.
Recommended Actions
We recommend alerting the users to use their managed devices directly or managers if the behavior persists.
Among others, long-lasting active SSO sessions can cause accounts not to reset their passwords. These accounts didn't reset their passwords for a configurable period of time. We suggest enforcing a password reset.
Recommended Actions
We recommend enforcing password changes for users that fail the check.
Your IDP allows you to categorize users by type. We highly recommend using this feature. Guests and API users are most likely to be missing a user type.
Recommended Actions
Log into your IDP's admin console and update the users with missing types. Ensure that your user-creation process includes type assignments.
Email forwarding is mostly harmless and comes from the need to deal with life changes and organizational shifts.
It is also a known bad pattern for people knowing they are about to change jobs and is a cause of data loss.
Recommended Actions
Please check if the forward rule is legitimate, for example, contractors and managers or a potential data loss issue.
Multi-Factor Authentication (MFA) requires users to provide something they know, like a password or PIN, or something they have, like an out-of-band device or a one-time password provider.
The National Institute of Standards and Technology (NIST) recommends using one-time password solutions or cryptographical solutions such as Google Authenticator, Okta Verify, or Microsoft Authenticator as the second factor of authentication.
Recommended Actions
Encourage users to use stronger authentication on a more regular basis. If that is not possible, we recommend tagging users with administrative privileges in critical services like Okta and Workday, and providing them with physical authentication solutions like Yubikey.
Multi-Factor Authentication (MFA) requires users to provide something they know, like a password or PIN, or something they have, like an out-of-band device or a one-time password provider
The National Institute of Standards and Technology (NIST) recommends using one-time password solutions or cryptographical solutions such as Google Authenticator, Okta Verify, or Microsoft Authenticator as the second factor of authentication, as SMS and voice calls are susceptible to attacks.
Recommended Actions
Encourage users to use stronger authentication on a more regular basis. If that is not possible, we recommend tagging users with administrative privileges in critical services like Okta and Workday and providing them with physical authentication solutions like Yubikey.
Last modified 21d ago