Oktane19: Defending Against Identity Attacks Today and Tomorrow

Sami Laine: In a world, where identity attacks come from every direction, only one man stands between ... no, let's not do the voiceover, let's do actual presentation.

Sami Laine: So identity attacks today and tomorrow, what is the core topic here? Remember to start talk from definitions. Identity means a lot of things that can be attacked in different ways. We're focusing essentially on the identities that are used to create accounts either for workforce scenarios. So this would be employees, contractors, contingent workers, and so forth. It's in the context of access to applications and resources, whether they're in Cloud or on Prem. It also includes identities of end users, customers, members, citizens, on those customer facing use cases.

Sami Laine: The world of identity attacks pretty broad. So we wanted to focus down a little bit, and talk about the different types of identity attacks and what our focus is going to be. There's identity attacks that happen at account creation. This is typically done to identity theft and synthetic account creation. If you're a bank you know exactly what we're talking about. It's fake account creation based on real identities for things like tax return, fraud or credit fraud of different clients. Then you have account takeover attacks where somebody has credentials and they have an account but they get compromised either through credential theft directly or indirectly through credential stuffing, password spraying or brute force attacks.

Sami Laine: And then there's of course denial service type attacks, that can lead to lockouts and they are usually a byproduct of credential stuffing or brute force. But some of those could be the primary motivation, so those two overlap a little bit. And what we're going to do then is we're going to focus here specifically on this credential takeover part, and let's look at the different components on how it's done. The first thing of course is credential theft. I list here phishing and spear-phishing, but it also includes DNS hijacking, malware, key loggers on the device, realtime men-in-the-middle attacks, etc. But phishing is the most common one and spear-phishing for high value targets.

Sami Laine: The methodology is pretty simple, you craft a site that's designed to fool the user to thinking it's a real one, securing a URL that's similar enough that they don't notice easily and then you send it to the users by way of text messages, direct messages on Instagram, social media, spray them onto a web blog, comments sections, YouTube videos, whatever is the method of distributing that. But you usually use some kind of trust there, you pretend to be somebody else to get them to click on the link. Then you capture those credentials and use them either later, which was the traditional method or right away in real time. In the case of those realtime man-in-the-middle attacks.

Sami Laine: They have a new important part here because they defeat a lot of the MFA as well. And then of course the question is, why is phishing and spear-phishing is still happening in 2019? We thought that we got over this a long time ago, right? Nope. It's still rising and because it works great, it works great because people have deployed no MFA or the MFA is too weak. And of course people reuse passwords, which makes it easy for you to do things like, capture them from one side and then try them on others. So this is a leading indicator also to the next one. And then of course there's lack of security awareness or in some cases security fatigue or risk fatigue or alert fatigue. It's hard to keep employees and folks energized to stay vigilant because you're asking them to do something really hard.

Sami Laine: Notice several differences on repeating, repeating, repeating websites where almost always it's the right one. People are really terrible at that. Okay. What about the next one? Credential stuffing has been in the newest slot. This here is pretty simple. You get a big set of credentials, usernames and passwords. You either buy them, steal them, find them on a drop site like, Pastebin or Mega.nz. And then you automate, you take those credentials may be filter them a little bit, grip out really obvious with garbage once and then start just starting trying them on a lot of sites. You do this by automation, you buy a tool or get create script. This works and of course you can try this on all kinds of sites, usually POPular sites where they have a better chance of succeeding.

Sami Laine: So start on Office 365, Linkedin, Gmail, et Cetera. Why does this work? It's because people reuse those passwords, people are lazy. They pick one good password and then use it almost everywhere. The good password is no longer good if it's breached anywhere, and they can be used on other sites. And of course, these sites don't deploy strong MFA. So that makes it problematic. This type of an attack cost Uber over 600,000 pounds because an engineer that had been breached somewhere else had used the same exact credentials on GitHub, and their repo got POPped and then all kinds of privacy lost with some sued. So that was not fun day.

Sami Laine: This attack can also be stealthy. Because if you do it carefully, then each one of this login attempts from this tool will look like a failed login from the user. So this is not obviously on the radar, and they may look like normal logins, and the real users won't get logged out until... unless they get over ambitious and try multiple combinations.

Sami Laine: Next one that is also common here is password spray. This one is one where you figure out the actual format of the user's passwords on a given site. Identify that username pattern, and it's very easy today, because passwords used to be ... Usernames and passwords were both treated a little bit differently before. Today the username is really not private information or secret information. It's publicly out there because in most sites today it's the email that's the username. So email is easier to discover you just need to drop into Linkedin and figure out what's the email pattern, name pattern for a particular company for example.

Sami Laine: This works the same way because people pick terrible passwords and there's weak MFA, so no surprise there. This can also be stealthy. This type of attack is sometimes known as reverse brute force because here you just pick a bad password and try across multiple usernames. Which brings us then to the actual brute force attacks where you can tool or create a tool or buy a tool that makes automatic log in attempts by trying many passwords across one username. This is automated and very scalable.

Sami Laine: This also works because people pick a terrible passwords. The passwords here are in the top 100 breach passwords. They're also a top 100 most common passwords. They're one of the previous slide, which was password that was cute with a little @sign, and a zero had been pwned last I checked over 55,000 times. So even many people think that they've picked something secure, they do a bad job at it. Now, these attack again works because there's either no MFA or weak MFA behind it. So let's take a look at then the chain. If the authentication comes through, and these are the types of attacks, where do they go?

Sami Laine: If you look at these parts here, we have our applications that are sending authentication requests, mail applications, terminals and browsers. And they come over different access protocols that have different properties. They support those protocols, inherently support different authentication methods, either basic authentication, username and password only or modern auth in order to access a service. And here's the problem. Old male clients, they only support POP and IMAP still white and deployed, whereas more and we have modern male clients also support ActiveSync, Exchange Web Services and MAPI. PowerShell is its own thing and then of course on browsers it's coming over HTTPS.

Sami Laine: Almost all of these can go through that basic authentication flow, where all you need is username and password unless you take steps to block that from the impossible. And then the modern authentication is not supported by those older protocols like POP and IMAP. We will come back to this. This is just setting the stage, so what happens next? This request than comes in, to a service that handles the authentication and authorization like Okta. What does the IDP say?. From our perspective we just expose authentication and points. They could be the modern auth and point here. This is what Okta sign on widget uses, so if you go to sign on to Okta or you have a sign on widget on your own custom site, it goes against this modern auth and what we see here is a lot of things.

Sami Laine: We see that username and password, we can see the IP address, and we see the user agent stream, browser type, device fingerprint behavior analytics are possible. We can do MFA. Life is good here. We also have come to other endpoints. WS-Fed and auth too. Interesting thing here is the WS-Federation, because this is what's used when it's a delegated notification out of Office 365. Here all we get this username password and IP. This makes it harder to actually detect the attacks. So with this backside premise, what do you think is the most targeted service today for identity attacks? Any takers? You get a prize. Yeah, exactly. It's all 365, why? Because that's where your mail is. Email is gold. Once you POP somebody Email, you own them.

Sami Laine: The only thing that I'm worried about is email, and I'm worried about enough that I quit Gmail and went to something more secure. It's a key to the kingdom in the sense that you can impersonate the person that can be a great launching pad, but there's also a more subtle reason than just email is scrolled on why this is the target first, because it's related to those underlying protocols. There's the more subtle reason. So if you look at how that Office 365 is accessed, everybody wants the first thing that we just use a browser, and it's modern auth. We can do MFA, we can do our adaptive MFA, re-scoring behavioral, all those great things.

Sami Laine: But the wild world of email refuses to die. Some of these clients that are out there like Gmail App, IOS Mail App, the Mac mail APP, et Cetera out of 2016 support modern auth. But there's a lot of outliers there that are still widely deployed like Outlook 2010, POP and IMAP and lots of third party male clients, especially in the Android ecosystem where there's just like a plethora of them that don't support the modern auth protocols necessarily. As well as some embedded applications that require authentication, that can only support those old protocols.

Sami Laine: So the legacy auth or legacy apps makes things hard. So if you look at then on the attack frequency, we did some analysis here, how many attacks can we basically add detect on the legacy endpoint versus the modern endpoint. And it turns out that looking at the authentication failure rates 10 times more failures happen on the legacy auth. And it's not just that, there's like accidental miss types of passwords. This is what they're targeting. Why is that? It's because why would you pick the deadbolt ? Here the modern auth is motion detector lights, you got your ring doorbell video camera there, and you've got their biometric deadbolt. But the legacy auth is the open side yard gate, and the sliding glass door from 1960s with a latch that's broken, like my house.

Sami Laine: So that's why. And why would you pick the deadbolt? So let's take a look at the landscape then. What exactly is the landscape looking like? We can look here and look at the types of attacks, the goals, like you want to actually compromise the account or simply disrupt the service. We can look at the means of the attack, we can look at the motivations and the impacts to your organization, either account compromise or account lock. So we have introduced today at the keynote, a lot of new capabilities that help you, especially with modern auth part, but we also have capabilities that are a little more subtle. And for that I'm going to bring up, Neha Anna how is cool pack manager to tell you more about that.

Neha Anand: Thank you, thanks Sami. So how many of you have seen one or more of these attacks in your organization? Yeah, it's an asymmetric problem that we are dealing with here, today more than ever. It's never been easier and cheaper for someone to initiate an attack, whereas the effort and cost that is involved in detecting, preventing, protecting from these attacks are huge. So we at Okta are focused on building products that can help us reverse this imbalance, make it easy for us to detect and respond and at the same time make it difficult for an attacker to succeed.

Neha Anand: Let's take a look at the products that we have today and things that we are working on and will be available within the next six months for you to use for these credentials based attacks. Okay. First we have a global list of black listed IPs. This is a list of IPs that our soft team has identified as malicious, and these are blocked at the router level for all of our customers. Next, you have the option to create your own black list of IPs and locations that you have identified as malicious. By analyzing Okta system log data or data from other third party vendors. This is an org specific blacklist. It's specific to just your org and any request coming from these are blocked at the service level.

Neha Anand: But for those of you who have users who are also signing in from the locations that you're seeing these attacks come from black list is not an option. So you can set up an Okta sign on policy that denies access to those locations, and the sign on policy also gives you the option to exclude your users, that is likely your users. So you can set a policy that says, "Deny access to location x," and exclude your set of users. But a few months back we realized that in spite of a deny policy in place user's accounts we're still getting logged out. And that was because of then Oktavius evaluating these policies.

Neha Anand: What was happening was after the users submitted their users ID and password, Oktavius was validating whether these credentials were correct or not. And only if these credentials were correct, we will not even be evaluating the policy. So for an attacker who is trying out different passwords, who doesn't have that right password is not getting this combination, got It? And we were not even getting to the point of evaluating the policy. So after a certain number of attempts, the accounts were getting logged out. So very recently we made the change, and we switched to this order. We reversed it. So now after user enters the user ID, we already have all the context that we need to evaluate the policy. And if there is a match to the denied policy, the access is denied.

Neha Anand: It gives you two benefits. A, The number of incidents of account lockouts have reduced because now there's deny access doesn't really count towards the password attempts made by the user. What happens is, the access has been denied to no matter what you enter in the password text box whether it's the right password or the wrong password, your access has been denied. And B, The attacker doesn't get to know the access has been denied because we show the same error message that you would see when you entered the wrong password. So they just see that their credentials are wrong. They don't get to know that their access has been denied.

Neha Anand: So this works great with modern authentication. Let's take a look at what will help us with both modern auth, as well as, the Office 365 legacy protocol based attack. Okta ThreatInsight. Okta ThreatInsight is a threat detection and response tool that aggregates data across all of our customers, applies patterns to detect credential based attacks such as, brute force and passwords attacks. We then identify the IPs that are involved in these attacks and block them, and mark them as risky. So when a request comes in, we check if this is a risky IP. If it is, then we can go ahead and block those requests. If it is not, then it goes through the usual sign on policy evaluation. So one thing that I want to highlight here is that the set of risky IPs is available to all of our customers. But the action to block these IPs is org specific.

Neha Anand: So it's an admin control in settings and you can choose to block or not block these IPs. As the identity provider we are in the direct line of attack. And I think that is our biggest advantage over other vendors because we get to see these raw events in real time. And with the right tools in place such as Okta ThreatInsight, we can detect the attacks and because we are also the access managers, we can take the action to respond to these attacks in real time and that's our biggest benefit with Okta ThreatInsight. The next use case that I want to talk about is something that many of you would have seen. This is where you have a targeted set of users that are getting attacked frequently. One example that comes to my mind is where we observed that for one single user there were 400 different IPs with failed log in attempts within a span of two to three hours.

Neha Anand: No points to guess that this was the CEO of the company. So you must have observed similar kinds of attacks for yours as well. So how can we handle these type of attacks? For this, we have our Risk Based authentication. There was a demo during keynote session as well as during the security roadmap session, about how the feature works. In short, what we are doing is we are building the normal behavioral profile of the user by looking at the past successful log in events of that user. So when a new log in event comes in, our risk engine takes into account the contextual data from that login event combines it with the behavioral profile of the user and generates a risk score. Based on the risk score the risk level could be high, medium or low, and you can set policies to respond to those levels accordingly.

Neha Anand: Let's go back to my example of 400 IPs. What happens when a request comes in from one of these IPs? So we will know that this IP, this location, these device is new to the user and the user has not signed in from that before. So the resulting risk score for that IP will be high. And if you have, for that log in event will be high. And if you have a policy in place that prompts the user to authenticate using strong authentication factors such as Okta Verify with Push and WebAuthn, you're bad user will not be able to authenticate themselves, and their access will be denied. If it is the right user, they will have access to the factors, and they will authenticate successfully, and they will be able to access their application.

Neha Anand: In an off chance, if your factors are compromised, and it's actually the bad user who is able to log in, then that's an incident of account takeover. But in this situation you can use our security automation where the end user will be notified and they can report suspicious activity. When they do so, a bunch of actions can be taken and you can even pass that information downstream for your incident management and response. When we get notified, we take these actions in addition to the actions such as killing the user session. We also mark that data as malicious data and make sure that that data is excluded from the normal behavior profile of the user.

Neha Anand: So next time when we see a request come in from those set of IPs, they will go through this whole process and your user will be secure and the access for the bad user will be denied. You can configure factors that you want to use with risk levels or different criteria that you use in your sign on policy using Okta Modern Password list. This gives you the flexibility to pick and choose factors of your choice. Password is no longer the mandatory primary factor, it is one of the factors among the pool of factors and this feature gives you the flexibility to mix and match factors for different criteria that you want to put in your sign on policy.

Neha Anand: It not just allows you to use strong and secure authentication method, it also makes designing experience of your users simple and seamless. So imagine your user signing in with a simple click of a button using Okta Verify with Push or using YubiKey or now that we support WebAuthn and they can authenticate using Windows Hello or Touch ID on their MacBook or the biometric fingerprint from the Android device.

Neha Anand: Last but not least, make sure that you can reduce the surface area of your attack further by taking care of accounts that are dormant and inactive. So you can set policies that would suspend accounts that are inactive for over a certain period of time. There are policies that are available that will scan through these accounts and if they are inactive for over a certain number of days, the accounts with be suspended. So we talked about a lot of features here. Let's see where the come into picture in the authentication path. The new features.

Neha Anand: Okta Trading Site falls under service level along with the org level blacklisted IPs and locations. Any requests that goes past this level, you can apply the sign on policy applies to those. And this is where your network zones, behavior dynamics zones and risk scores comes in. You can set the policy to deny access or prompt your user to authenticate using one or more of the factors using our Okta Passwordless and once the user authenticate themselves successfully is when they get to access the applications. You can security sensitive applications further by creating an APP sign on policy. You can use network zones to control where these applications can be accessed from. You can use the device context to control which devices these applications can be accessed from a managed device or unmanaged device or a certain combination of OSN browser.

Neha Anand: Similarly, you can set policies around your factor enrollment, reset, and recovery and control using network zones where a user can enroll for a factor or where a user can reset from a factor. So that can be done using network zones. Okay. Let's take a closer look at one of the features that I talked about. I'm going to give you a quick demo of Okta ThreatInsight. So first of all, this is my admin console and I need to enable Okta ThreatInsight on my account. For this, we need to go to security, gender, this is where the Okta TreatInsight setting is and you have two options.

Neha Anand: The first option is, the first option when you enable this option, you are only monitoring or auditing the data. So what happens here is, you will see a system log event show up every time that there is a ... Every time that we observed that one of your user's account was accessed or was accessed by an IP that was identified as risky by Okta ThreatInsight. So this just logs, so you'll just get system log event with this option. The other option that we have is that we log as well as block. So this option, which is log and block will automatically block those IPs as well for your organization.

Neha Anand: In case there are IPs that we incorrectly identify, say there are false positives and it's your actual user that is logging in from those IPs, you have the option to white list those IPs as well. And this is the option, the exempt zones option that you can use to white list IPs. This is where you just you create a network zone and you can add that zone here. Any of the IPs in those zones will be white listed so they won't be blocked. So I have one created one. So this is just an example of a white list zone that I've created.

Neha Anand: So now I have enabled block in my account. I'm going to switch to the end user who is going to sign in from an IP that we have identified as risky for ThreatInsight. Just give me a second. Okay. It's a bad IP. So now what happens is, when the user signs in, they get this message which says, "You do not have permission to perform the requested action and that access has been denied." So let me switch back to the admin console and I'm going to just switch to the WiFi, which is not risky. Let's put up the ThreatInsight and here and I go into system log, you will see that there is a new system log event here that says request from suspicious actor. The action that was taken was denied the IP that we saw the access from with the IP information is there. In the details. You can see that this IP was identified for passwords superior attacks and we denied access for it.

Neha Anand: Like I mentioned, that in an off chance that this IP happens to be one of the IPs that is not risky for you and you want to white list these or you need to do is from the system log itself you can click on this, one second. An active zone and here I can select the zone. This is the zone that I had white listed in my settings and you can pick either to proxy IP or the Gateway IP and that's it. So your IP has been added to the white list so you don't have to switch between screens to go and update your network zone it gets updated directly from here and that IP will not be blocked.

Neha Anand: So that's what I have for Okta ThreathInsight for a risk based authentication. If you missed the demo during keynote and the security roadmap session, we have a rerun of security roadmap tomorrow or you can come talk to us at our booth and we will be happy to walk you through the feature. Now we will have Sami back on the stage to talk about the best practices.

Sami Laine: Okay, thank. All right. So with that you have now a bunch of tools. Some of them you may have known already. We introduced new ones today and we reminded you of some of the ones that are available to you. How then do you piece this all together? The first step of course, is deploy strong NFA. Who here has an organization that doesn't deploy NFA for everyone? We have a few. All right. You go to the the hall of shame, it's the next door over there. It's hard. We get it. You have to understand what your user Population is and pick the authenticators that are the right ones.

Sami Laine: Even SMS that is arguably weaker done not having anything at all if you use it for password reset because it allows you to do a path that you can control into your password reset, even that's the right one for some scenarios like for example some end user customer use cases where you really have no control over and the infrequent that you need to do. Email one time password or email magic link might be a better solution for there as well, but we're really pushing people to go towards the right. If you go to a software or hardware one time passwords, those are better. The challenge with those, is that they are also phishable.

Sami Laine: If you have a phishing attack that is real time, they could simply ask what that code because now again you were asking the user to do something that's hard for them. Recognize a site that is incorrect site when they're trying to masquerade as a real one. The attacker doesn't need anything except that credential. So if you have the user hand that credential over including the OTP, the attacker is golden as long as they have real time capabilities, as either somebody sitting there waiting for it or more likely automation. There's a lot of malware that does this automatically now, there's toolkits that allow you to do this.

Sami Laine: So we're pushing towards the right hand side. When you go to something like Okta Verify with Push, and especially when you go to security keys and device authenticators the world gets a lot better. One of the key things that happens here is that it fundamentally changes how MFA works. Now with security key and device authenticator with FIDO2 it is not the user who has to recognize that this is a bad site I shouldn't give up my credentials. The site has to prove themselves to the security key and the device authenticator. This fundamentally changes everything because now the attacker can't succeed, if they create a phishing site, you go to the phishing site, there's 2FA.

Sami Laine: They can't replay this because the device authenticator seemingly doesn't recognize the SSL certificate of the attacker. As the attacker can successfully steal the SSL cert of the organization that they're targeting, they can't get in. So the security keys and device authentication are great. They fundamentally change the dynamic. They do things that computers are great at and humans are bad at. So if you have an option to go towards that direction, we highly recommended it. If you saw our security roadmap where we have a lot of exciting things coming around there and that's going, the WebAuthn for example, it's in preview this week and in production starting next week.

Sami Laine: What else can you do except to deploy strong MFA? Remember that this is only a good option if you actually are in that modern auth path. Why you telling me this? This is one where I'm being attacked. Well, let's talk about where you're being attacked. You're attacked on the passwords. First thing you can do is simple step. But most people don't know about this that I've talked to. In Okta you can block common passwords from being selected by the end user. Today the list is about thousands of the most common passwords, we're just now increasing that about hundreds fold to about a hundred thousand most common passwords including most common breached passwords.

Sami Laine: So with a simple click on that your users can no longer select the password that it is weak enough that it would be susceptible to some of these attacks that I'm talking about. So, that's a great first step. Make it harder to crack. You can go further and especially if your organization is standardized on the Chrome browser and download the Okta Passprotect Chrome Extension. This allows you to seamlessness securely, have the end user's computer check what they're typing in the password field is actually one of the breached passwords that have been reported on all the data breaches that Have I Been Pwned from Troy Hunt has been collecting.

Sami Laine: So it's hundreds of millions, billions of passwords that it's checked against. Say, did you pick something that's already in the breach Corpus and now leaked out into the world. And it's a seamless in that the user can simply say, "No, I'm okay," so it just pops up and goes away. It's completely seamless. You can download it in a Passprotected aisle. Then of course it's time to make sure that your end users are participating in their own rescue and you do that by enabling them to see when something's happening. So new device notification emails, you can enable them and decide that they can know when they're actually logging in from something new. It's not foolproof but it's getting better.\

Sami Laine: Also one of the real big ones here that you saw on the demo is that if somebody is resetting their email or password, sorry, somebody is resetting their multi-factor credential or enrolling into a multi-factor credential, you can send an email about that as well. The beauty of this is that the first thing that an attacker often does is reset the password and roll into an MFA to lock the genuine user out. This can allow you to get that early warning, your per users are telling you when something suspicious happens right away.

Sami Laine: So let's go back to this legacy protocols then, the purpose should be let Sunset this. How do we get rid of this? You start by inventory goal, the applications that are accessing your system and Office 365 in this example. Look at the ones that are only capable of POP and IMAP, put them on the death watch and get rid of them when you can. Have them replaced by more modern alternatives, on almost every platform this is an option. That way the authentication events situations only allow through ActiveSync, EWS and MAPI. This gives you a position then where you can go and start the disabling protocols.

Sami Laine: So you can, in Office 365 you can actually disable those two protocols. Once you've disabled those protocols, you can also go and disable the basic authentication path. Now every authentication in your organization is flowing through the happy path where we can do all of the strongest things, strong multi-factor authentication or the behavioral risk based protections, in addition to everything else. And if you can't get there today, we have ThreatInsights that helps deal with some of those attacks, especially on those legacy protocols.

Sami Laine: We put together a couple of assets for you so that you can actually take these with you. So the first thing is we have a whole ebook on securing Office 365. It covers all these best practices and it's available for download from this link. How the Federate O365 authentication to Okta disabled the legacy of, there's some powershell involved, we apologize, configured O365 client access policy and Okta revoke the refreshed programmatic change, educate to users, cut off clients. It's a whole cookbook on how to and some best practices on how to communicate this, a great asset to download.

Speaker 3: Is this available online?

Sami Laine: Yeah. This is also available from our website, we threw just the shortcut for you folks. Sorry about that. So if you go to Okta website, you can just search for that, you'll find that there as well. It was too long URL for me to put up on the screen. We also have then another ebook that's, the specific topic that we talked about today on how to best practice, implement multifactor authentication, improve your password policies, configure networks source, on APP config and have user awareness campaigns.

Sami Laine: This is also available to you as a free download. So with that, we wanted to open it up and answer any of your questions, so I'm going to bring Neha up here. We have here a two room monitors who are going to be bringing in microphones up so you could just raise your hand, they'll run to you and that way we can all hear it and it gets recorded as well. We have one here.

Speaker 4: Does Okta have a mechanism of recognizing IP addresses that individual organizations mark as non-malicious that may be a mistake and evaluating that, so everybody gets the benefit of seeing that type of information?

Neha Anand: So you mean a global white listing, kind of thing type?

Speaker 4: Right. Okta is not perfect and mat get an IP address wrong. So be it one organization or a number of organizations, start marking an IP address as a valid entry point, does Okta see that and say, "Oh, we need to update this."

Neha Anand: So that's a feature that is on our roadmap and we do acknowledge that that's the requirement that needs to be implemented. Yes.

Sami Laine: As of today, if you use ThreatInsight, it's important to remember that although Okta does global a look at the IP attacks that are happening and fail off indications to decide which ones go to the block list, each blocking and white listing is organization specific. So you then decide whether you want to just monitor that and get system log events or block them and if there's a fourth part of it the white list applies to you.

Sami Laine: So that way if you happen to have a genuine user but there's actual attacks emanating from that same IP, you can white list that for yourself, so that the genuine user comes through, but it won't impede any other organizations ability to defend against actual attacks coming from the team IP, which happens often in situations where all the traffic is coming through mega proxies and there's a very narrow number of IPs that gives sign.

Neha Anand: Okay. Yeah. But in addition to that, we do want to look at if there are more than one organization that is white listing a certain IP, then how do we white list for all of you. Yeah.

Sami Laine: Do you have a question here?

Speaker 5: All right. Hello. Could you share a little bit more about how ThreatInsight analyzes the risk of IPs? Is it something internal to each implementation, something that is managed by Okta or maybe even something that you rely on third party information to do that? So, for example, whenever I first activate ThreatInsight, what would be the first lists of IP study would use to sort of decide that risk?

Neha Anand: So we're already collecting data on our production cells. So even if you say enable it today, we already have data from all the other organization that we have identified those IPs as risky and that will apply to your organization as well. And you choose to block at any point today, tomorrow, whenever, whatever information we have at that point will be available to you as well.

Sami Laine: There's no training period because Okta globally looking at all the incoming traffic and then monitoring and saying which ones to watch that are the riskiest, the worst once we've blocked already are on the service level. But we can't block anything that might have any false positives. So the threshold is really high. This gives you that next layer and you can then choose whether you want to start walking those as well. So if there's no training period you start using in day one, everybody gets to benefit. Any other questions? We have a couple of more minutes. Yeah, go ahead.

Speaker 6: With the risk profiles that you guys showed in setting the different modes of authentication based on the risky Simons and stuff like that. Are there plans to integrate that into like the server access feature that you guys introduced today or the Windows Sign on in general? Say like you could have a scenario where someone's sitting on a trusted network they can just get a text message code sent to their phone or-

Sami Laine: No text messages. Kill SMS.

Speaker 6: Yeah. Could they just tap approve and then it signs them into Windows without typing a password?

Neha Anand: Yeah. So this V1 of what we're introducing for the space or authentication where we are looking at Okta sign on policy only but in future we will extend it to other parts of the product as well, like app sign on or factors or even evaluate if it applies to server access management.

Sami Laine: But on the server. Actually, it's important to note that what we do there already has risk based authentication today. Because on day one it's looking at your Okta session from this laptop that you have active right now. And if your sign on policy requires strong authentication to your laptop before you can go and make a connection to scale life you have to have a live Okta session.

Sami Laine: So all of your Okta sign on policies for that Dev Ops engineer apply, you can require where both and U2F strong auth indicators to even get into Okta. And then when they have their Okta session live, they can then just type in the target machine's name and they're in. So in that sense, since it's not in line between the user and the Ad Server, it's really about the context of that user and their session on that laptop right now. All right.

Neha Anand: There's one in the back.

Sami Laine: Go ahead. Oh, well we have one here and then one in the back. Go ahead.

Speaker 7: So you are keeping track of risky IP addresses. Are you also working with the partners in the OIN for approved IP addresses? So I know that my partners use these IP addresses. These are okay.

Neha Anand: Yeah. So those are some of the IPs that we are looking at and white list it, white listing those IPs, yes.

Speaker 7: We have time for one more question.

Speaker 8: Quick one to piggy back off of his question. Sorry about that. How are you handling consumer based VPN? Because they are used in attacks, right. But at the same time we do encourage our employees to use VPN when our corporate VPN isn't available. So how are you handling those IPa knowing that a good chunk of them are used for attacks?

Neha Anand: So, if these IPs are something that you have already configured as part of your network zones that you trust, we will be treating those as white list. So we won't be treating those IPs as you know, IPs that we are, as any of the other IPs that is not trusted by other, any of the organization. So if these VPN providers that you're talking about, you have a network zone in your organization already and these are white listed IPs, then we will treat those as white listed IPs.

Sami Laine: But I think your question was also about consumer grade VPNs, if you're corporate VPN.

Sami Laine: Yeah, yeah, if people just have that, then we would treat that as any other access control. So the likelihood of us seeing both genuine users to a corporate portal and attackers that are happening to write on that same VPN, it's Kinda rare. And if you look at the overall overarching landscape, attackers tend not to like to come through VPNs because that makes them detectable. If those VPN providers are collaborating with law enforcement, they can see the source IPs. They tried to be more stealthy than that. They usually use botnets that they can rent or something else.

Sami Laine: Then VPNs for the attack, but if there's a lot of attack traffic coming from one VPN exit node, that happens to be some consumer VPN, and that raises through the threshold where we see enough of them to block that IP, we would block it. Then your genuine user who was so unfortunate that they had say same exact VPN provider that particular day gets blocked. They can contact you and you can add it to your temporary white list for example.

Neha Anand: Yes. Yeah. Okay.

Sami Laine: All right. I think that's pretty much timeout for us here, so thank you very much.