5 Keys to Hardening Your Defenses With Okta MFA

Okta SSO (Single Sign-On) enables your team to use a single login experience to access all applications, which streamlines and simplifies the end-user experience. However, as the gateway to all applications within the organization, it also makes an attractive target for attackers. If compromised, any SSO system can provide cybercriminals with access to many systems at once.

Fortunately, Okta SSO enables stronger authentication policies than would otherwise have been tenable because the authentication process can be conducted once as part of a user’s familiar sign-on routine. This allows Okta to strengthen security by integrating robust Multi-Factor Authentication (MFA) capabilities with its SSO offering. But deciding how to deploy this rich MFA functionality can be complex and sometimes overwhelming.

In this blog post, we’ll try to demystify some of the important issues and provide five keys to effectively deploying MFA to meet your organization’s security goals.

What is MFA?

Because we’ll be talking about MFA a lot, it may be helpful to ensure we have a common understanding of what it is. We like the following definition provided by Center for Internet Security (CIS):

“Multi-factor authentication (MFA) is a digital authentication method that requires two or more distinct authentication factors for successful authentication. There are three authentication factors:

1. something you know (e.g., password or PIN),
2. something you have (e.g., proved by a passcode sent to or generated by a device or account), or
3. something you are (e.g., a biometric, such as a fingerprint to unlock a phone).

Multi-factor authentication requires that authenticators come from two or more of the factors. Using two different passwords would not qualify.

Two-factor authentication (2FA), also known as two-step verification, is a common application of multi-factor authentication where two of the factors described above are included. For instance, a user account requiring both a password (something you know) and a one-time passcode sent to the user’s phone (something you have) employs two-factor authentication.”

Balancing Accessibility and Risk

Any MFA strategy needs to balance user accessibility and enterprise risk. If authentication becomes too cumbersome, users will seek ways to avoid it and may compromise enterprise security to do so. If authentication is too lax, attackers may be able to compromise accounts and data within the organization.

There is no single approach to MFA that works for every organization. The culture, appetite for risk, and user technical proficiency are some of the most important factors to consider when developing a strategy. This post is intended to provide guidance around selecting the most appropriate policy for your organization. Tevora’s engineers frequently are called on to use their experience and judgment to provide guidance around MFA policies during our engagements and we use all these factors to help us make recommendations.

Organization- vs. Application-Level MFA

Okta allows MFA to be applied in two ways: at the organization (org) level and the application (app) level. The org-level login process is the primary authentication that users undergo when they log in to Okta. Think of this as the primary gate to Okta. The app level is applied to each app within Okta and allows you to have different experiences depending on the app used. Okta also enables users to have MFA policies at the app level that apply only if the user hasn’t provided MFA recently.

The Payment Card Industry Security Standards Council (PCI SSC) has made MFA a requirement for years and also provides some guidance around protecting MFA deployments:[BD1] 

The authentication mechanisms used for MFA should be independent of one another such that access to one factor does not grant access to any other factor, and the compromise of any one factor does not affect the integrity or confidentiality of any other factor. For example, if the same set of credentials (e.g., username/password) is used as an authentication factor and also for gaining access to an e-mail account where a secondary factor (e.g., one-time password) is sent, these factors are not independent. Similarly, a software certificate stored on a laptop (something you have) that is protected by the same set of credentials used to log in to the laptop (something you know) may not provide independence.

One of the best ways to avoid factor-bypass vulnerabilities is to have a strong org-level policy within Okta and ensure all apps require Okta authentication to access them.

5 Keys To Okta MFA Deployment

In this section, we’ll cover five keys to developing an MFA strategy that hardens your defenses against cyber threats and addresses your unique organizational security needs.

1. What Should We Do About Remote Access?

One of the most common practices for authentication is to require MFA for remote access. This approach assumes that users who log in locally (e.g., in the office) are more likely to be who they purport to be and that users logging in remotely represent a greater risk. It’s common for organizations to require MFA for all remote login scenarios. This has become even more common during the pandemic with Work From Home initiatives.

MFA can help to identify and prevent unauthorized access attempts. For instance, MFA can serve as a detection mechanism by generating SOC alerts when a user successfully provides a password but fails to authenticate with the second factor.

MFA can also be a prevention mechanism when accounts are identified as targets for password spray attacks. Factor Sequencing from Okta allows users to be prompted for their one-time password from Okta Verify or Google Authenticator before they are prompted for a password. In this way, an attacker must guess successfully from a million possible options before attempting to guess a user password.

One important consideration in using MFA for remote users only is that this approach does not strictly follow the tenants of Zero Trust Architecture. One of the key Zero Trust tenants is that no user is implicitly trusted, even if they are accessing resources from within a company’s internal network. All users, devices, or systems requesting access to organizational resources must be authenticated and authorized. If your organization has committed to a Zero Trust Architecture, you’ll probably want to apply MFA requirements for all users, regardless of location.

2. How Should We Handle Administrative Users?

Administrative users have access to control how a system functions for other users or systems. These users are valuable targets for attackers because they frequently have access to either revoke or circumvent controls that would block attacks (e.g., reset other users’ passwords or disable firewall rules or MFA requirements).

For system administrators, IT help desk, and other pure IT support roles, your MFA approach can be relatively straightforward. We suggest applying policies for these accounts at the org level so that MFA is required whenever users sign on to Okta. This can be augmented with app-level policies. For example, you can require MFA if a user has not been authenticated within the last two hours when accessing a high-risk application like AWS. This ensures that if a user session is compromised, the length of time it will be useful for an attacker is limited.

3. How Should We Control Access to Sensitive Data?

Users with access to sensitive data can also pose significant risks to an enterprise during account compromises. These users can be difficult to identify because sensitive data can take many forms and organizations often do not have a good understanding of where their sensitive data resides. But here are a few common scenarios to begin reviewing within your organization:

• HR personnel and managers with access to Human Resource Information Systems (HRIS). These users usually have access to a significant amount of PII.
• Engineers with access to proprietary design documentation, including proprietary data and trade secrets.
• Senior management email access. During many compromises, executive emails are the most valuable type of data targeted by attackers.

For these types of scenarios, typically, an app-level policy to require MFA for access is appropriate. This can also serve as an opportunity to provide a subtle notification to users of the sensitive and secure nature of the information they are about to access.

4. How Should We Incorporate Device Trust in Our MFA Strategy?

Okta allows user devices to be identified as trusted or untrusted. This process uses a certificate enrollment process to ensure only managed devices are included and varies from platform to platform. JAMF is used for enrollment of Mac laptops. Mobile devices use an enterprise MDM. Windows systems can work using Active Directory and IWA integration functions. Notably, device trust functions cannot be used to influence org-level policies, only app-level policies.

Most organizations are not using device trust designations to remove MFA because a PC or other trusted device can become compromised and serve as a launch point for an attacker. But device trust functions can help to augment other MFA policies. For instance, you may want to consider using device trust in the following situations:

• When a user is connecting to a high-value app and coming from an untrusted device, they must undergo additional authentication. This may include reentering the account password or performing authentication with two additional factors.
• When a user uses an untrusted device, Okta has detected high-risk behavior, and the app is high-value, access to sensitive apps is restricted.
• When a user uses an untrusted device and Okta has detected high-risk behavior, MFA is required (when it normally is not).

Okta’s Device Trust functionality provides new metrics to monitor the overall risk of authentication events within Okta and should be treated as an additional layer of decisioning.

5. How Should High-Risk Behaviors Influence MFA?

Okta Advanced MFA allows behavior-based functions to be rolled into decisioning logic. This can be based on criteria such as impossible travel, users logging in from a new device/browser that wasn’t used previously, or a new country or location. While these criteria are not always an obvious or definitive litmus test for authentication, they can be effective as indicators that additional verification should occur using MFA.

Additional Resources

Here are some additional resources that expand on the topics we’ve covered in this blog post:

• Okta MFA
• Okta SSO
• NIST Zero Trust Architecture Paper
• CIS MFA
• Tevora Okta Security Solutions Datasheet

We Can Help

If you have questions about Okta MFA or would like help implementing it in your organization, just give us a call at (833) 292-1609 or email us at sales@tevora.com.

---