The Human Factor in Phishing Resistance

In the wake of recent security events at Uber and Twilio, organizations are understandably interested in pivoting to authenticators that offer the most resistance to phishing attacks. In this second part of our series on phishing resistance, we consider the human element.

All organizations should aspire to a state in which technical and operational controls reduce the burden on end users to identify and respond appropriately to social engineering.

Large numbers of Okta customers are pivoting toward phishing resistant authenticators, as we discussed in part one of this series. Many Okta customers have chosen to limit all user authentication to phishing resistant factors. Typically these are leading edge organizations, “born in the cloud”, that are not locked into legacy technologies.

Okta’s mission is to enable anyone to use any technology. So we recognize that, by necessity, organizations encumbered by legacy apps will need to support a mix of authenticators for some time into the future. Our policy engine is designed such that these organizations can enforce phishing resistance where it matters most, and only allow weaker (less phishing resistant) authenticators by exception.

So for most organizations, there remains a need to empower users in the fight against phishing. User empowerment can take many forms, including:

• Providing users with sufficient context whenever they sign-in

• Ensuring users are aware of common social engineering techniques

• Providing users with the tools to report suspicious requests

The power of context

The Scatter Swine attacks of July and August 2022 demonstrated one of the critical limitations in authentication flows that use passwords and OTP (one time password) authenticators. An authentication flow that requires an OTP doesn’t provide opportunities for the user to assess context about the origin of a request.

A push request can provide this context. Depending on your configuration, an Okta Verify Push request displays a range of information including:

• The recorded location of the browser making the request

• The recorded device making the request

Okta Identity Engine admins can also add further context to each request using a feature now available in Early Access. This adds to each Push request:

• the name of the application requested, and

• the sign-in URL.

Crucially, if the organization enables Number Challenge (which can be applied to all Push notifications, or only for risky sign-ins), the user also has to verify a random number presented on the sign-in widget.

Okta Verify Push with Number Challenge

All of this context can help users identify when an attacker attempts to use stolen credentials to access their account.

The power of training

To be effective, users need to be aware of what this context means. That’s where security awareness training comes in. As I’ve previously opined, learners are more likely to retain and apply advice if it is provided in the context of their daily work, and where opportunities are provided for strong, positive habits to form.

Historically, security awareness training has appropriately focused on the areas of the most heightened risk: password hygiene. Given the increasing prevalence and effectiveness of multi-factor authentication, there is also value in training users about the methods an attacker armed with stolen credentials might employ when attempting to bypass MFA challenges.

The most common social engineering techniques we have observed, and some corresponding learning outcomes to target for your security awareness training, are included in the table below:

Sample Learning Outcomes

Introducing "Push Bomb"

Push Bomb is an example of a learning experience that can be used to raise user awareness about Push Fatigue attacks and teaches them how to assess the context of a Push notification.

Push Bomb is a proof of concept Okta Workflow developed by Solution Engineer Marc Miller that schedules unsolicited push notifications to a defined group of users to test whether they accept, reject or ignore the request. It provides users a first-hand experience of an MFA Fatigue attack, just as phishing simulations do for credential phishing campaigns.

Marc's Workflow (which is not an Okta supported product) does all of the following at the push of a button:

• Selects a random percentage of users from a defined Okta Group(s) to test according to an admin-defined schedule;

• Leverages the Okta Factors API to check whether each user is enrolled in Push MFA

• Sends a Verify push notification to users and polls for the results at admin-defined intervals, logging whether the user accepts, rejects or ignores the request.

• Sends the user a message on Slack, Teams or email (customer configurable) to confirm they were subject to the test, and offers further guidance based on user actions.

• Prepares a detailed summary report of results for the admin.

An End User Notification delivered by the Push Bomb Workflow

The power of positive reporting

The most important learning outcome, irrespective of the attacker’s methods, is that users are well practiced in alerting the security team about suspicious behavior via channels that are well monitored.

One way for users to develop this muscle memory is via phishing simulations. While the focus of these drills can often lean too heavily into identifying “at-risk” users, the most crucial learning outcome is for users to learn how to quickly report suspicious activity to the right place in both simulated and real-world attacks.

Creating easy methods of reporting suspicious activity is critical. Suspicious Activity Reporting allows Okta admins to configure their org to email a user whenever their account is accessed from a new device, when a new authenticator (factor) is enrolled or when an existing one is reset. Admins can optionally provide the user a one-click path to reporting a suspicious event from the body of the same email.

Just as training and awareness programs need to anticipate the potential bypass of technical controls, your detection and response capability needs to anticipate that users will fail to recognize or act on social engineering attacks.

The next post in this series on phishing resistance will focus on how to use Okta System Log to detect phishing-related events.