Demo: How Okta Can Help Stop Account Takeover Attacks

Welcome to this video on how Okta can help you solve account takeover attacks. The increasing prevalence of credential breaches as well as identity attacks, credential stuffing and phishing. We know that consumer applications face an increased risk of account takeover attacks. To understand and solve this problem, organizations traditionally have relied on a number of different solutions outside of the identity layer. But with Okta's identity centric approach, you now have an option to solve this problem at the core point of attack.

Today, we'll see a number of features that organizations can leverage as they try to tackle this problem. To understand how Okta can be part of this equation to stop account takeover attacks, we'll jump into Okta's features to show you some of the key features that can be part of this conversation. Now to see how Okta can be part of the authentication journey and protect against account takeover, let's look at what Okta offers from a password policy standpoint.

Traditionally, a large number of attacks had been due to weak or compromised passwords. And having the right complexity and password policy for your organization is the critical first step and basic hygiene that organizations can take to stop the risk of account takeover. Okta offers a range of easily configurable options that allow admins to pick the level of complexity that is appropriate for their organization.

Everything from the length of the password to the complexity of the password can be specified by a simple set of clicks in the admin dashboard. Additionally, Okta allows you to block commonly used passwords so that you can prevent brute force attacks from impacting your authentication. Now to look at what Okta has to offer from a product standpoint, we start this journey at the authentication policy or the password policy page. This is easily navigable under security and authentication. Now to understand what Okta offers to protect against account takeover, we start off by looking at the password policy that admins can easily configure in Okta.

We know that a majority of attacks happen due to weak or compromised credentials. And to make this a little more secure, Okta offers admins the ability to configure the password length, as well as the complexity associated with the password. Additionally, knowing that your account login and password reset are common sources of account takeover attacks, Okta makes it easy to enforce and control when and where users can reset and recover their passwords. Admins can easily enforce policies that restrict from where a user can change a password.

Now going beyond just a login and password, let us look at some of the more advanced features that is available to admins to protect the organizations. The next layer that Okta offers is what we call as Okta's behavioral detection, or a behavioral detection or adaptive authentication policies. Here, admins can configure a number of different contexts around each user's login, such as device, IP, location, as well as travel patterns to identify anomalous behavior.

So let's take a look and see what's one of this looks like. Here, in this case, the admin is configured that an impossible travel pattern is when the user travels at the rate of more than 805 kilometers per hour. This is the average speed of an airplane. Now this is useful when you see abnormal or quick succession of logins happening from two distinct geographical regions. For example, when someone logs in at 8:00 AM from New York City, but at 9:00 AM logs in from London, we know that this is an abnormal travel pattern where either someone has sharing credentials or more likely a victim of account takeover.

So by leveraging each of these policies, admins have a clear policy layer that can flag abnormal logins. But also going beyond that, Okta also gives you the ability as part of the authentication layer, to configure a sign on policy that factors in all of this risk into the login. Next we look at some of Okta's network policies that could be useful to stopping account takeovers. Okta's network zones allows you to specify approved white list and black list locations from which you allow authentication traffic.

Now this could be useful to either stop malicious traffic originating from TOR exit points or similarly could be used to block traffic from countries that do not do business in. A common example is in this case, the user has decided to block traffic originating from a list of high risk countries. Next we look at Okta's adaptive multifactor authentication policies that is configured under Okta's security behavioral detection tab. In simple words, Okta's AMFA is a number of user login contexts that is used to analyze the risk associated with each login.

Now this context could range from device, IP, geolocation, as well as travel patterns. This feature allows you to analyze all the login context around each user's login before you give an access decision. Now in this case, a simple policy could be that you do not allow anyone or two successive logins happening from a distance that is greater than 805 kilometers.

Next, we look at Okta's network policies. In simple words, and network policy is a list of approved white listed or blacklisted zones from which a user can authenticate. Here for example, in this case, the admin has configured a list of banned countries from which an authentication attempt can be stopped from. Other common users are an admin can use this feature to block traffic from IP locations that have been associated with TOR exit points. Next we look at Okta's adaptive authentication capability that looks at all the login context around each login request.

These contexts include velocity, device, IP, geolocation, city, among other contexts. Now, these could be very useful and powerful to stop account takeovers because they are able to detect and flag abnormal login requests. Now, for example, in this case, an admin is able to build a policy around a new IP associated with that particular user.

Now if this user has not been associated with that IP address, it could be used to prompt for multifactor authentication, or it could even be used to block the user from logging it. Now the question is what do you do with all of these things? Next, we look at Okta as multifactor authentication. That is the foundation for strong customer authentication. As the MFA platform, Okta offers a number of different strong authentication options that can be an effective final barrier against account takeover. Okta's MFA platform gives you everything from knowledge-based checks to OTPs and biometric authentication to stop attackers.

Administrators can not only deploy these different options to customers based on their business and security needs. They can also control how the user logs in or registers for a particular factor. Now in this case, for example, the administrators configured a number of different MFA options that end user can use based on the group that the user belongs to.

Additionally, the administrators can specify from which region the user can register for a different factor. Now this is very useful because we know that a lot of account takeover incidents originate from international locations. And if you're a business that does not have customers that do access your application internationally, now you could restrict enrollment to only regions from which you have your customer base from.

Now in this case, the administrator specified that the enrollment can happen only from the United States because possibly their business only works and operates inside of the United States, as well as this happens from the first time when the user logs in for MFA.

Another key feature of this option is some of the strong authentication options that are defined by standards such as WebAuthn. Now WebAuthn is a standard-based passwordless authentication option that can be used both as a primary authenticator as well as a secondary authenticator. The cool part about this factor is that there is no credentials being shared over the wire, so it also protects you against man in the middle as well as phishing attacks.

Now let us bring all of this together under our authentication sign on policy. Now here the administrator can configure a cascading list of policies to which end user can authenticate. Here for example, if a user is logging into, let's say for example a loyalty account, the administrators has specified a number of different rules that can be leveraged to assess the login flow.

Here, it's a pretty straight forward policy. It says that if the user is authenticating without passwords, which is another option that we allow instead of Okta, the user can authenticate from anywhere, but it has to go to a stronger authentication option. So in this case, we say that something as strong as WebAuthn, that I just spoke about, can be used. Or something like Okta verify can be used without demanding a second factor.

We do this because these are very strong assurance factors. But when the user authentic using a low assurance fact like SMS, we now forced the user to go to a second factor such as Okta verify before they can get access to the service. So this way as you think about the strength of the authenticators, you can set up different credential chains to stop against low assurance authenticators being a source of account takeover attacks.

Now another policy the user configured, which is largely driven by passwords, is that you can now force the user when they just use passwords as the primary authenticator that they can use a second factor of their choice as the secondary authentication option. Now, these are all the options that can be used to prevent account takeovers from happening. The question is, what do you do when an account takeover actually happens? How can you learn from that? This is where Okta's security dashboard can be a pretty useful tool for SOC operations. Here in this case, we provide all the details associated with the user's login so that administrators can understand and build an identify security gaps in their login flow.

This information can also be exported into a SIM tool, for example, so that your SOC team can construct a complete narrative around what happened before authentication, during authentication, and post authentication inside of the application. Now this is how you can see Okta protects organizations against account takeovers. We offer a strong password policy that can be the foundation. So next, we offer an adaptive policy feature set that can be used to decide when to drop MFA or not. And third, you can use MFA as the final barrier against unauthorized access into the application. With that, hopefully you can now construct and protect your users from the risk of account takeover. Thank you.