LoFP LoFP / okta

okta rule

TitleTags
a user experiencing legitimate login issues (forgotten password, typos) may trigger credential attack alerts before successfully authenticating.
a user experiencing login issues may generate multiple device tokens through repeated legitimate attempts.
a user may have multiple sessions open at the same time, such as on a mobile device and a laptop.
a user may report suspicious activity on their okta account in error.
a windows administrator may have triggered a low-fidelity credential access alert during a legitimate administrative action. following this, the administrator may have reset the mfa credentials for themselves and then logged into the okta console for ad directory services integration management.
administrator roles could be assigned to users or group by other admin users.
administrator roles may be assigned to okta users by a super admin user. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
administrator roles may be assigned to okta users or groups by authorized super admin users during normal it operations such as onboarding, role changes, or organizational restructuring. verify that the behavior was expected and authorized. exceptions can be added to this rule to filter known administrators, service accounts, or automated provisioning systems.
an okta admnistrator may be logged into multiple accounts from the same host for legitimate reasons.
applications will tag the operating system as null when the device is not recognized as a managed device. in environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
automated integrations or scripts using service accounts with session cookies may trigger user-agent based detection. consider excluding known automation accounts by okta.actor.alternate_id.
automated monitoring or penetration testing tools scanning from multiple ips.
automated password reset flows where a user fails multiple times then succeeds after resetting their password.
automated processes or misconfigured applications retrying authentication may trigger this rule.
automated testing or monitoring tools that do not persist cookies may trigger this rule.
consider adding exceptions to this rule to filter false positives if okta mfa rules are regularly modified in your organization.
consider adding exceptions to this rule to filter false positives if okta policies are regularly modified in your organization.
consider adding exceptions to this rule to filter false positives if oyour organization's okta network zones are regularly deleted.
consider adding exceptions to this rule to filter false positives if sign on policies for okta applications are regularly modified or deleted in your organization.
consider adding exceptions to this rule to filter false positives if the mfa factors for okta user accounts are regularly reset in your organization.
consider adding exceptions to this rule to filter false positives if your organization's okta applications are regularly deactivated and the behavior is expected.
corporate proxy or vpn exit nodes may aggregate traffic from multiple legitimate users with login issues.
false positives are expected if administrators access these function through proxy legitimatly. apply additional filters if necessary
if a mfa reset or deactivated was performed by a system administrator.
if a user requires an anonymising proxy due to valid justifications.
if an end-user incorrectly identifies normal activity as suspicious.
if the behavior of creating okta api tokens is expected, consider adding exceptions to this rule to filter false positives.
if the behavior of deactivating mfa for okta user accounts is expected, consider adding exceptions to this rule to filter false positives.
if the behavior of deactivating okta policies is expected, consider adding exceptions to this rule to filter false positives.
if the behavior of revoking okta api tokens is expected, consider adding exceptions to this rule to filter false positives.
large enterprises with many users experiencing simultaneous password issues during credential rotation events.
legitimate and authorized user creation
legitimate creation of a new admin role assignment
legitimate creation of an api token by authorized users
legitimate users who routinely use vpn or proxy services for privacy may trigger this if they also trigger unrelated security alerts.
mobile users switching between wifi and cellular may show ip address changes. correlate with device type and typical user behavior patterns.
okta policies being modified or deleted may be performed by a system administrator.
okta policies modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
security testing or red team exercises using proxy infrastructure.
shared service accounts accessed from multiple legitimate infrastructure ips.
shared systems such as kiosks and conference room computers may be used by multiple users.
shared systems such as kiosks or conference room computers may have multiple users authenticating.
the number of okta user password reset or account unlock attempts will likely vary between organizations. to fit this rule to their organization, users can duplicate this rule and edit the schedule and threshold values in the new rule.
unknown
unlikely
user might of believe that they had access.
users legitimately switching networks (e.g., vpn connect/disconnect, office to home) may trigger ip-based detection. review the geographic distance and time between ip changes to assess legitimacy.
users may share an endpoint related to work or personal use in which separate okta accounts are used.
users with legitimate multi-location access (mobile + home + office) experiencing concurrent login issues.
when an admin begins using the admin console and one of okta's heuristics incorrectly identifies the behavior as being unusual.
when an admin creates a new, authorised identity provider.