Prevent Social engineering attacks by implementing Okta’s best practices.

Tactics, Techniques and Procedures

Below are some the tactics, Techniques and procedures an attacker may use.

• Threat actors appeared to either have a) passwords to privileged user accounts or b) be able to manipulate the delegated authentication flow via Active Directory (AD) prior to calling the IT service desk at a targeted org, requesting a reset of all MFA factors in the target account. In the case of Okta customers, the threat actor targeted users assigned with Super Administrator permissions.
• The threat actor would access the compromised account using anonymizing proxy services and an IP and device not previously associated with the user account.
• The compromised Super Administrator accounts were used to assign higher privileges to other accounts, and/or reset enrolled authenticators in existing administrator accounts. In some cases, the threat actor removed second factor requirements from authentication policies.
• The threat actor configuring a second Identity Provider to act as an “impersonation app” to access applications within the compromised Org on behalf of other users. This second Identity Provider, also controlled by the attacker, would act as a “source” IdP in an inbound federation relationship (sometimes called “Org2Org”) with the target.
• From this “source” IdP, the threat actor manipulated the username parameter for targeted users in the second “source” Identity Provider to match a real user in the compromised “target” Identity Provider. This provided the ability to Single sign-on (SSO) into applications in the target IdP as the targeted user.

Best practices to implement.

Best practices for Tenant level security in DelAuth mode:

1. If you use delegated authentication, Harden the okta agent server with all latest patches and provide less access to server.
2. Implement Least privileges for AD service accounts based on the functionalities. Refer the section Okta service account permission.
3. Implement Okta MFA Credential Provider for Windows to enable strong authentication using MFA with Remote Desktop Protocol (RDP) clients. Using Okta MFA Credential Provider for Windows, RDP clients (Windows workstations and servers) are prompted for MFA when accessing supported domain joined Windows machines and servers.. Configure Okta MFA to Windows server
4. Turn on automatic updates in Okta to Okta AD agents, So it is always up to date.Schedule automatic updates to agents
5. Go Passwordless, Mainly implement passwordless for all superAdmins account in Okta. Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn.
6. Turn on and test New Device and Suspicious Activity end-user notifications.
7. Lock down tenant level admin access to trusted IP zones. For example to Office network. so admins cannot login to Okta admin console without being in trusted IP zones.
8. Create a block list from specific countries or IP zones.
9. Implement custom admin roles and follow best practices Best practices custom admin role
10. Consider automating super user privilege using a JIT mechanism for a time bound access.
11. Rotate API keys and move towards OAUTH permission model where ever applicable. Implement OAUTH for Okta
12. Upgrade to OIE( Okta identity engine) and implement authentication policies based on assurance level requirement. Implement Authentication policies
13. Implement Fastpass.
    • Okta FastPass provides passwordless authentication from any device or location to any Okta-managed app.
    • You can use Okta FastPass with any device management tool. There’s no dependency on AD or a specific enterprise mobility management (EMM)/mobile device management (MDM) software.
    • You can combine Okta FastPass with device-level biometrics to avoid extra prompts when accessing Okta-managed apps.
    • Okta FastPass works with IdP flows (for example, Agentless DSSO).
    • If desired, you can combine Device Trust with Okta FastPass, so passwordless login is only available on managed, compliant devices.

Workflow automations around security:

Security is first and foremost to any business. Always be proactive than reactive, Below steps provides some best practices around automating security.

1. Implement helpdesk verification tool to verify users enrolled factors before reseting passwords.
   • Use Okta rockstar tool Okta Rockstar
   • Create a bot in slack or Microsoft teams to integrate with Okta workflows. Helpdesk veriftication tool using workflows and slack This can eliminate direct access to Okta admin console and provide automation for verification and resets.
2. Monitor password resets and factors resets for possible account take over using Workflows. Refer the Okta workflow template section for the below flow Monitor account take over

3. Monitor system logs and alert on any suspicious activity via event hooks. Refer the workflow template section for below flow.

4. Deactivate inactive accounts over period of time by Monitoring the Okta last login. Refer the workflow template section for below template

Inbound Federation implementation best practices :

What is Inbound Federation?

Inbound Federation allows access to applications in a target Identity Provider (IdP) if the user has successfully authenticated from a source IdP. The feature can also be used for Just-in-time (JIT) provisioning of users. It’s a feature that is used to save months off mergers, acquisitions and divestitures. It is also popular with large organizations (such as global parent companies) that require central controls or globally provision one set of applications (while also empowering divisions to have some level of autonomy for their own policies and apps).

Given how powerful this is, access to create or modify an Identity Provider is limited to users with the highest permissions in an Okta organization – Super Administrator or Org Administrator. It can also be delegated to a Custom Admin Role to reduce the number of Super Administrator’s required in large, complex environments.

These recent attacks highlight why protecting access to highly privileged accounts is so essential.

Best practices for IDP sso configuration.

The simplest recommended configuration to prevent most security concerns is to configure the SAML IdP with these settings:

• Account Linking disabled 
• Using a Filter (regex) to only allow users with a certain domain in their username (email) to ensure only users from a particular Spoke can authenticate.
• Creating users when a match is not found (JIT).

However that might not be possible in some cases (i.e. domain in emails is the same for users in the spoke as in hub and account linking is needed for some reason such as if all users were imported into Hub via other methods and they need to be matched).

When that happens and account linking must be enabled for an IdP, then the main goal is to reduce the likelihood and impact of potential account takeover/impersonation of privileged accounts in the Hub. 

To achieve that, the following configuration settings are recommended on the Hub Org (where the external IdP provider is created):

Groups Configuration

• Create a specific group per external IdP (Spoke) to be used later for IdP configuration and policies.

Authentication Policies

• Create an Authentication Policy for Spoke/IdP specific groups (created in the previous step) so that it denies access to selected apps: Admin Dashboard app and any other sensitive apps to be determined by Hub Admin.
• Create a Global Session Policy with Deny Access for “Okta Administrators” group if coming from any external IdP (multiples IdPs can be selected)
  • this requires IDP_BASED_SIGN_ON_POLICY FF to be enabled but it is GA
  • Set this policy as the first one to be evaluated
• Created Global Session Policy to Require MFA for “Okta Administrators” group
  • Require phishing resistant factors if possible.
• Note: Even when creating custom admin roles, users who get custom roles assigned will automatically be considered part of the “Okta Administrators” group so the above suggested policies will cover custom cases as well.

IdP Configuration

• Configure Group Assignment to specific groups and set to the group created in step one for the specific idp/spoke

• Rely on IdP JIT (create user when no match is found) to create new users into the Hub org if possible for user provisioning

• Note: Review again and If not strictly needed for a very specific reason, then disable Account Linking
  • If required then enable Account Linking
  • if account linking is enabled, consider putting users in a group as part of IDP auth and setup a policy in Okta admin app to deny login for the people in this group. This can prevent Admin account take over.
  • Consider disabling Account Linking after a period of time which would ensure that all existing users in the Spoke have already SSO into Hub and thus all links created.
  • After disabling it any new user created in Spoke would be handled via JIT
• Set a Filter to only allow usernames that match the defined RegEx pattern.
  • If users coming from a Spoke have a different domain than employees and users from other spokes and hub, then
    • Use a pattern like ^[A-Za-z0-9._%+-]+@spokedomain\.com
• If all users share the same domain, then set a regex that will deny specific users (this list should include all known administrators in the Hub)
  • Use an expression like this to allow any user except the ones explicitly mentioned (users in the expression are the privileged accounts we want to protect)
    • ^((?!(admin\.user\.1@company\.com|admin\.user\.2@othercompany\.com)).)*$
  • Unfortunately the expression is static, so if new administrator users or privileged users are created in the Hub, the expression will have to be manually updated.
  • The expression will not prevent impersonation of end user accounts, but by excluding administrators (or any other privileged account) we greatly reduce the impact

• Detection 
• Use the System Log to review authentication events via IdP.  
• Search eventType eq “user.authentication.auth_via_IDP”and carefully review events where the Actor is “Okta System (SystemPrincipal)” and Target is an end user. 
• Such events indicate that an account linking operation happened. 
• If the target user is a privileged user (or important person in the organization) take manual necessary actions to ensure any potential incident is properly handled.

• Failsafe mechanism
• The idea is to use Workflows automation when a successful SSO via IdP for an administrator user (part of Okta Administrator group or with custom admin role) happens, to automatically perform certain actions such as:
• Deactivating the user
• Removing the user from Okta Administrators group
• Delete existing account link with IdP
• Revok all existing sessions for the account
• etc.
• Consider building such automation as a template available at https://github.com/okta/workflows-templates 
• Note 1: this failsafe mechanism would act “after the fact” when the potential account impersonation/takeover already happened, hopefully quickly enough aiming to reduce the impact.

Best practices for Okta Org to Org provisioning:

What is Okta org to org?

You can use the Okta Org2Org integration to authenticate and optionally provision users from a source Okta org to a target org. The integration is installed and configured in the source org. You can use Okta Org2Org to connect multiple source orgs to a single Okta target org. This integration enables the source orgs to push users to the target org.

If you choose to use the provisioning features of the Org2Org app, you can use OAuth 2.0 or an API token to secure the connection between the orgs.

A common scenario where Org2Org is used is the hub-and-spoke model. In these scenarios, the spoke orgs are the source orgs and the hub org is the target org.

Best practices for Okta org to org.

• Use always OAUTH permissions to setup provisioning between orgs. Refer the documentation OAUTH for Okta org to org
• Use best practices in Spoke to securely keep keys used for client assertion signing
• If using JWKS to publish the public key, only do so via HTTPS channels
• Create admin permissions for the API app with OAUTH permissions in Spoke.
• Do not enable Org to org from spoke to HUB.