Okta Security Roadmap: Safeguarding Users from Account Compromise

Speaker 1:  With that, I'll quickly introduce our speakers today, two awesome gentlemen from Okta, Alex Bovee, our director of product management for security, and Sami Laine, our director of technical marketing for our security as well. With that, all yours.

Alex Bovee:  Thank you. All right, perfect. Thanks, everyone. I really appreciate everyone coming out to the session today. Sami and I will both be available after the session if anyone asked a question so please feel free to come on up and give it with your best shot. My name is Alex Bovee. I lead product management for security at Okta, so as the world's transitioned to the cloud, moving increasingly off-prem, it really does open up an entirely new security landscape in terms of how do you think about these security problems and how you want to solve them. I spend a lot of time thinking about what does that new threat landscape look like, what are the controls and the features and capabilities that our customers need to keep users secure in a cloud forward world, and really make sure that we can kind of cloud safely, if you will.

Without further ado, I'm going to jump in and tell you about some of the great features that we've been working on and are thinking about really over the next year. Before we jump in, legal makes me give you this wall of text and you are … Feel happy to bring this presentation up later and read through all this if you want but basically, it says this is all hopeful roadmap items for the most part.

I want to start by really setting a context in terms of what we mean when we talk about identity led security. I think the traditional way of thinking about security at the abstract is still relevant in sort of an identity forward world around protect-detect respond. It's just that those terms and those capabilities mean different things in the cloud context in particular and especially as you sort of wrap that layer around the user identity, which is really what the new perimeter is. I know it's a little bit of a cliche but truly, as the world moves out to the cloud, identity is a new perimeter and so these concepts mean different things and we have to think about them differently in terms of the capabilities that we're bringing to bear to solve the security threats that we're seeing.

Let's start at the outside. We’ll start with the protection. Obviously, as a identity and access management company, Okta, we’re sort of bread and butter is that the protection layer, if you will, and so that really starts at identity proofing and strong authentication and capabilities along those lines. As I lead security at Okta, I look after our adaptive multi-factor authentication product and so we have a lot of functionality particular on authentication and strong authentication that really plays a huge part in protecting your most business critical assets and resources.

Let's jump into what we mean by protect. The first way I like to set the table on this is to talk about just the range of different credential types that are necessary to support the modern enterprise. I think what I realized from talking with customers and being in security for eight years now is that there is no one-size-fits-all with security. It really is use case specific, user specific, resource specific, and so what we've done at Okta is really focus on building out a bench of different authentication capabilities and credential types to really support your particular scenario that you're looking to enable.

Maybe you've got contractors and maybe something like Email 2FA is not great for protecting credit card data that's on a remote workstation but maybe that's totally fine for a lightweight second factor challenge experience for an external party. Again, really, the reality here, supporting this deep bench of authentication experiences and so we support on the lowest assurance side and sort of security questions for maybe a lightweight to a fade check, I wouldn't recommend anyone deploying security questions for high-value resources but not bad in particular scenarios. Then, on the higher assurance side, support for things like U2F tokens, which are basically crypto-based authentication capabilities bound to the origin so you can't phish it, you can’t man-in-the-middle it. It's great security from that perspective. Same with Okta, push verify and then certificates are a relatively recent investment that we've been making. I'll talk about here in a minute.

I think for me, fundamentally, this is a picture I showed at last Oktane for the roadmap. Frankly, you'll probably see it every roadmap that I give in the future as well because I really do fundamentally think that at the end of the day, everything in security boils down to the trade-off between these three axes, if you will, usability, security, and deployability. Really fundamentally, the trade-offs we have to make are thinking about what is the right trade-off that I'm willing to make from a usability perspective and deployability perspective to achieve my security goals and vice versa, right?

It's really hard to find the perfect credential, which is super secure and can't be phished but also is incredibly usable, that maybe doesn't cost much money or is super deployable or doesn't depend on an external device or something like that. These are these are all just trade-offs. To that previous slide, the reason that we've made these investments is to really give you that range of different authentication capabilities and credential types to support the right trade-offs for your right scenario in the use case that you're looking to open up.

Just to be illustrative here, for example, last year, we launched support for U2F. Out of curiosity, how many people are using U2F tokens today? A good number. That's awesome. That's great to hear. For me, it's just a great validation of an open standard that customers can really adopt and use that I think solves major security issues. Last year, we launched support for U2F. We also launched support for the web authentication standard, which Windows Hello is built on so you can use things like facial recognition to unlock the private key to authenticate to Okta.

This year, we launched email as the second factor support, so basically a very basic second factor challenge that is supporting the widget so when you authenticate username password, you basically get an OTP delivered to your email and then you can play that into our authentication experience and then authenticate the user. Again, if you're looking to protect, again, customer data in a data center or a remote workstation or something like that, I wouldn't recommend email second factor authentication for that but for, again, a lightweight security check and certain scenarios, it can be a great option.

The other big investment we're making beyond just additional authenticator capabilities is actually investing in supporting a wider range in diversity of use cases across our customers and so we're really doing what we've called internally sort of cloud to ground. That is we really started in the cloud, we were born in the cloud and obviously our support for a second factor authentication for scenarios like SAML-based applications or modern web applications is great but increasingly, we've been adding deeper and deeper capabilities to support on-prem use cases and infrastructure scenarios.

Last year, for example, we launched a new capability around radius-based authentication using our Okta application network, which is a pretty cool feature. It's been well adopted by our customers. This year and over the next few months, we're going to be launching support for remote desktop protocol support, ADFS support so if you're using ADFS for single sign-on, you can plug Okta in there seamlessly and just, again, increasingly adding support for more and more and more of those use cases because the feedback from customers is, “Hey, your strong authentication capabilities are great. Adaptive authentication capabilities, awesome. We want to apply that to more scenarios. We want to make Okta more prolific in our enterprise and roll this out more broadly and consolidate our MFA behind you.”

Along those lines as well, we've also been really trying to broaden that integration of our strong authentication capabilities across, not just our applications but also our partnership network and then investing in making a capability that allows you to really add 2FA wherever you want to. One of the big investments we’re also making this year is in basically kind of supporting a widgetized, if you will, ability to add 2FA to any application, so maybe you've got a homegrown web application, you want to drop 2FA into it, you'll easily be able to do that in the future using a combination of Okta’s APIs and our web SDK experience in our app model. It's a great ability again to really take that strong authentication. I think it’s a world-class experience from Okta, and kind of put that everywhere throughout your enterprise and protect all your resources and applications.

Then, a further extension of the protection is then how do we think about that authenticator experience in those diversity of credentials and move that to modes where maybe we're supporting password-less type scenarios? In other words, how do we achieve the goal of really killing the password or at least supporting companies that may not have passwords to begin with or want to support moving that direction for different groups of users?

Broadly, I bucketed password-less authentication to three categories, modern password-less, which I'll talk through in a minute here, which involves using Okta’s policy framework and our set of credential experiences to remove passwords from flows, certificate-based password-less. Obviously, I wouldn't exactly call certs sort of modern authentication but actually, interesting poll, how many folks are using certificates for primary authentication in some way, shape, or form in their organization today? Yep, so not super, super, super prolific but we do see those use cases and so I'll actually talk through this a little bit later but we have a capability for this in beta today to support certificate-based verification for primary authentication in Okta today. Then legacy password-less, which I won't talk about it's just not as sexy but this is supporting things like radius in the password less mode, which we actually do today.

What do we what do we mean when we say modern password-less? Really, what it's doing is it's taking Okta’s authenticator experiences and then unifying that in our policy framework to allow you to select different credential types for the primary authentication experience for different groups of users, so effectively saying for this group of users, maybe they can use a password for primary authentication, maybe they can also use Okta Push Verify if they want to do that as well. It's about picking those different options and then really modifying that user experience to and identify our first type experience so instead of hard-coding username password, submit, and then step up authentication, it's really a username and then from the username, you can either get your password or you can just directly get an Okta Push Verify experience, for example, and use that for your primary authentication mechanism.

Additionally we hear a lot of asks around particularly for consumer identity access management, maybe removing the password all up and just allowing the user to use, for example, email to authenticate to the product so that's kind of folded into that effort as well and something I'm personally really excited about. We hear, I think all of us are probably guilty of this in the audience of when you register for that random consumer web service out there, you just type in some junk password, you will log in and nine months later, all you're doing is you're using password recovery for primary authentication, which just basically means you're using email for authentication at that point, so recovery, set a temp password, which you're going to forget in two weeks, authenticate to the platform. The reality is we can cut that out and we can make that a lot easier for customers to use just directly from a policy standpoint.

Modern password-less authentication is really about, I think, changing the strength of that authentication experience to kind of kill knowledge-based factors and so roughly, that architecture is Okta, on Okta’s side, we've got a public key. Let's say for example it’s a U2F experience or Okta Push Verify experience. You've got a public key. There's some verification experience from a device or a web browser where that private key verifies an auth that can be used up against Okta to verify that authentication and that's unlocked by some sort of an experience from the user whether that's a presence test or a biometric or something along those lines.

Net-net, the result of that is that you've taken a credential type, which is a password, which can be phished, which could be man-in-the-middled, then replayed. There's a whole bunch of ways you can compromise that credential. You can guess it and you've made that pretty secure from the perspective of removing those attack vectors from the flow.

Similarly, on the certificate side, very similar. Architecture albeit that private key is really just stored then on a card or on your device or something along those lines and so similarly, Okta has the ability to validate that private key up against our service. In the particular case of certificate-based authentications, we've really added that as an identity provider within the admin console itself and so if you think about it abstractly, it really makes sense because that that private key, that certificate has the user associated with it in the subject and so the verification that we're doing is really just making sure that that key chains up to the certificate authority and that we can validate the user and that they haven't been revoked and that they match a user in Okta. Again, this feature is in beta today but you can add support for a certificate-based authentication in Okta.

In the IDP, configuring your certificate authority, configuring how you want to actually match the users, how we do revocation checking and then from a user experience standpoint, supporting … We call it pivot card here but again, it's really just certificate-based authentication, clicking that link, presenting the certificate and then through a mutual TLS check, Okta can actually validate that that user's credential is good, change to the certificate authority. The user is not revoked and they can match them to an identity in Okta.

How many people know what this is? Tardigrade, yeah, exactly. These things are crazy creepy if … I’d encourage you to search for it on Wikipedia. They’re just like the nastiest, ugliest looking things I've ever seen in my life but what's fascinating about these creatures is that they are impossible to kill. They can literally be like dehydrated and then rehydrated 100 years later and they'll come back to life and like keep beating and like making spawn. I don't know how long they've been around the earth for but probably since the beginning.

In some ways, I think tardigrades are a good metaphor for passwords, which is as hard as we try to kill them, they're probably always going to be there and so we should, I think conceptually, really embrace that reality from a security perspective. There's a reason that passwords are passwords, which is that they are super usable and they're super deployable and they suck at security but sometimes, the first two really trump the third. That's why passwords have been so successful. Instead of trying to outright kill them, maybe we just make passwords suck a little bit less.

I'm actually excited to announce a feature that we're launching an Oktane and beta around common password detection. Basically, we did a lot of research, looked at a bunch of lists of breached credentials and so forth and said, “Man, there's just a list of passwords that are just bad and even if you have a password policy like one capital one, lowercase, a number, which is actually the average password policy that customers have, we did the research and looked at this, something like capital password with a zero meets that requirement or password one two three meets that requirement. That's just a bad password. If I was a bad guy and I was trying to attack a system or trying to guess passwords, I would probably start with that list and just go to town. We want to make it a lot easier to just increase the overall hygiene of passwords and again, just make them suck a little bit less, make it not the weakest link potentially in the security chain and just up-level the security posture of your organization by increasing the strength there.

Then, the next aspect of protection is really around contextual access and so we've talked a lot about this. Our adaptive story is really built around this. At a high-level, contextual access kind of is three pieces in my mind. It's the context itself. What do we know about this authentication? What do we know about this user and the history? What's the protocol they're using to authenticate from what network? Which location? What credential type? What's their device and access engine that really has the intelligence to consume that context and then make policy decisions to provide access to those resources on the right hand side?

Excuse me. Another really big investment we've been making is around behavioral-based authentication, so looking at the context of a user's past history to help you make smarter decisions about risk in that current authentication request. If you think about behaviors, you can kind of lump them into some different buckets, I'm a big bucket person as you can tell, around organizing, thinking on products but for example, you could look at location-based behavior, so is this a location that this user has authenticated from previously either at a city or state level or even at a country level? Maybe you want to look at it a radius around a particular lat/long and say like, it looks like they haven't ever authenticated from this general vicinity.

You can look at IP-based behaviors. Maybe you want to relax 2FA requirements for radius-based authentications when users are logging in from their VPNs at home, for example, because you want to improve the usability. You can look at the previous IPs that they've successfully authenticated from and say, “You know what, that is a great indicator from a security perspective. That would allow us to improve usability without compromising on security because we know this user always authenticates from the same IP address at home and so we can relax the 2FA requirements around VPN access.”

Looking at velocity-based behaviors. Is this user, compared to maybe the past five or 10 authentications, does this authentication represent some sort of an impossible travel scenario? You can look at past authentications around brute force behavior, so is this the fifth failed authentication in a series of failed authentications either from that same IP address or that same username or whatever it might be? Then, truly looking at anomalous type behaviors where really Okta is providing a black box there and we're assessing whether or not we believe that that's anomalous based on various inputs.

Our goal here is to expose this through a set of configuration UI. If folks are familiar with our zones capability, it's a very similar functionality where you can actually go in and for your organization, this is a big learning that we had, is that we found that this was very organization specific. What's right for company X for their internal knowledge worker and employees may not be the right size and description of this feature for a large financial institution that is managing consumer identities. We’re really going to give you the granularity to manage those individual behaviors and really define the guardrails for when we're going to assess something as an anomalous location, for example, so I could say look at the past 20 authentications at the city level and if that user is never authenticated from that city in the past 20 authentications, then that's an anomalous location, for example, and so really giving you a lot of flexibility around defining those criteria for what our anomalous behaviors and what are not.

Then, lastly on the contextual access side, we've also made a lot of investments this year around just supporting a better level of fidelity around trusting devices and what you can consider to be trusted devices. On the very low insight, we have super lightweight features around this capability. I think probably one of my favorite … I might get in trouble with the engineering team if they know this but one of my favorite features from this year that we launched is a new device notification feature, which basically looks at the fingerprint of that device. It's completely transparent to the end user, looks at the fingerprint of that device and if that user is never authenticated from that device before, we'll actually send a notification to the user saying, “Hey, looks like you just authenticated from this new device and this was the location and this was the time and day.” It's just great ability to add security again at the device level, low touch and low impact from the user experience standpoint.

On the opposite side of that spectrum, we're now increasingly adding support for things like validating certificates on the device. If you do have a Mobility Management solution, whether that's OMM or something like AirWatch or MobileIron, deploying certificates to those devices is an indicator that they're managed and obviously is a security indicator as well saying that through the process of being managed, we know that it has endpoint protection, it's got these controls to lock device and so forth. We're starting to support those range of scenarios around device trust as well.

The point of all of this, the TLDR, is that we want to create a system where we can use context authentication capabilities, combine with different password-less modes in different ability to assess context around devices, authenticator types, behaviors and so forth, to really give you the tools to improve security and to improve usability. I fundamentally think there's ninja moves here where we don't have to make hard trade-offs in those three legs of the stool that I showed earlier. I think that there are opportunities for us to improve usability and security at the same time by just thinking a little bit more creatively around how we assess risks and how we understand risk in the context of the authentication experience for the user.

Then, switching gears a little bit, earlier, we talked about the three pieces, protect, detect, respond and so we just spent a lot of time thinking about what does protection mean and how do I want to think about protecting my organization from compromise and how do I protect my resources. I'm going to get a little bit more into the other side of the equation. I think protection is great. That's the 95% problem, which is it's your internet scale breach problem. How do you solve the phishing problem? How do you solve the compliance problem in these types of internet scale security issues? Then, the question is, okay, for everything else for that 5% of the problem, how do I get the detection capabilities and the visibility I need to enable my security team, to enable my SOC to make smarter decisions and to have the context that they need to do their jobs more efficiently in conjunction with Okta.

How many folks from the keynote earlier, just out of curiosity? Great. I think a great example here, which I'll kind of talk a little bit more about is that service now integration where we're integrating the service now as instant response capability to really provide that automated back-and-forth touch point between your downstream security investments whether that's your SIEM or your instant response capability, whatever it might be, and actually taking action on that from an access management standpoint with Okta.

One of the other things that gets me really excited about just what we're able to do is thinking about not just the fact that we're at the authentication layer and the access layer because there's so much power and control that we can give people to make better decisions there but I think thinking about how we do that in the context of all the data we generate is also an incredibly interesting problem statement, thought exercise because Okta sees a lot. We see access requests. We see provisioning. We see credential, reset flows and recovery flows. We see all of this information and so we want to try to make that information more consumable and frankly, enrich it even more to make it more useful for you.

Broadly speaking, you can think about detection and responses. On the detect side, how do we add more rules and behavioral-based detection capabilities? I kind of mentioned some of those behaviors earlier around things like anomalies. That's information that we'll be generating in our system log and then you can consume that downstream either in your SIEM or you could actually do your investigation directly in Okta in the system log to try to dig into that. Then we've added some features around things like inline response, which I think we’ll actually demo later as well.

The point here is that we're trying to make that data richer and we're trying to add more. We're trying to apply more learning and more rules and more intelligence to that data to add more value to it for you so that you don't have to necessarily go into your SIEM and generate lots of rules to try to figure out was something a brute force or not. That's information that we can see. We know if something's anomalous because we see those past authentications. We can tell something looks like a brute force. We can tell some of the reputational data around the IP address that users are accessing Okta from and so we can just enrich that and make that data easily accessible to you in whatever context you want to use it right, so whether you're trying to ingest that into a UDA product and really augment your incident response capability or you want to use it to prioritize alerts. Whatever it might be, the point is let's make that data readily available and easily ingestible.

Today, we offer really three ways to get that data, native SIEM integrations. We have a lot of those floating around out there. You can download it from our UI or you can do a custom API-based integration to pull that data. We're also really focused on our partnerships here in our integrations to make that even easier and more out of the box, so we have native integrations with companies like Rapid7, Exabeam, Splunk just to be illustrative but we're constantly focused on that ecosystem and our partnership, so if you have a company that you're working with downstream and Okta doesn't support something natively, feel free to send that over to Okta in some way, shape, or form and I'll kick it to our BD team.

The point is here, we want to make it easier for customers to get value out of Okta and the data that we're generating and most importantly, to leverage those existing investments that you've made from a security perspective because those aren't going to go away. Just because you're moving out of the cloud doesn't mean you don't need a SIEM anymore, you don't need some central location where you need to be able to investigate and drive some sort of an incident response capability. We're super focused on this.

That being said, we're also all about adding better native response capabilities within Okta ourselves. A feature I was really excited for us to build a few months ago is a blacklist capability. We hear from customers, “Look. I'm under attack. I'm getting brute force from these particular IP addresses and or my security team maintains a list of malicious IP addresses that they rotate out slowly over time and I really want to leverage that in Okta as well but I want to do in the pre-authentication capability. That means I want to just deny access from that IP address outright. I don't even want to give the user the opportunity to try to authenticate even though we’ll deny them at the sign-on policy and. This is a feature that we just gave to everybody. We give this to every customer. You should have a blacklist zone capability in your Okta tenant, which basically when you've enabled that as a blacklist just denies access outright from those IP addresses.

Also, I think in about two weeks, we're going to be launching geo of our network zones API capability and so if you then want to sync those existing indicators from your security team into Okta in automated fashion, you can do that via an API integration so really just completely closing the loop, making it super simple to leverage again your existing security infrastructure and investments, closing the loop with Okta, and making it super easy for Okta to be a control point and enforcement point to really up-level your overall security posture.

Then, we're extending this as well. If you have adaptive policies or adaptive authentication, we're also going to make it available for you to be able to use dynamic blacklisting based on the reputation of the IP address coming in, so maybe you want to just deny access outright from/to our exit nodes. Maybe from your perspective, there's no reason why anyone would have a valid reason to be authenticating to Okta from a Tor exit or maybe you're seeing particular malicious country, malicious access attempts coming from a particular country, which we see frequently or maybe you're seeing malicious access attempts coming from a particularly low reputation ISP. You'll be able to blacklist all of those within the Okta policy again just from a security perspective up level your security.

Then lastly, just kind of calling out this feature around new device notifications one of my favorites but this is really just an example of what that looks like. Again, I'm authenticating to Okta. Maybe I'm logging in from my spouse's device or something like that. If Okta has never seen that device from a fingerprinting standpoint, again, totally transparent, we're actually fingerprinting the browser and the device to evaluate that, if we've never seen that, that authentication request from that device before, we can send a lightweight touch notification to an end user.

I think this is a perfect example of putting control and visibility in the hands of your users because I think at the end of the day, the 95% problem is the protection problem was put strong authentication to our most business critical resources and assets but then, the last mile is how do I give visibility to my end users in particular? How do I enable my end users to make smarter security decisions? This is something that you could throw probably 20 incident response people out but the signal that you might get from this when a user forwards this email to their IT team saying, “Hey, I didn't just log in from this country so someone should investigate this,” I think the signal that you get from that really cuts through the noise pretty quickly from a security perspective and really allows you to respond quickly and accurately to potential emerging threats. I have a great story here if anyone's interested about my hijacked Netflix account two weeks ago.

Then, tying it all together, so we talked a lot about roadmap. We've talked a lot about the features we've been working on and what we've been doing. What does it all mean? The sort of step one, tie your shoes, strong authentication everywhere. I can't highlight this enough. If you're not using a strong authentication product or capability today, you really should think about doing that, I hate to say it but even if it's not Okta, you should think about doing that. If it is Okta, it’s even better but I really do truly believe that this is the 95% problem. If you just put strong authentication and protect your most valuable business resources using strong auth, you will solve 95% of your problems right there.

Secondly, begin thinking about how you move to more risk-based access controls. Think about some of the new capabilities we're shipping there and how do you want to change the way maybe you view risk and indicators of risk and how you can potentially relax some security … Well, I don't want to say relax but potentially change the way that you think about defining your security requirements and what you consider to be indicators of risk-based on some of those contextual capabilities.

Then, lastly, visibility and response. If you're not engaged with your security team today to figure out how you can leverage Okta’s data and integrations to really enable that team to make your deployment more secure, I would encourage you to do that. Again, we have a lot of out-of-the-box integration capabilities and sometimes, it's as simple as just talking to the security team and saying, “Hey, look. We're getting a lot of data. We've got Okta out there for identity access management SSO on strong auth,” but we want to look at folding this in and we think that there's value to be had there from a visibility perspective in terms of ingesting that. Without further ado, Sami's going to take over to give us a demo.

Sami Laine:  All right.

Alex Bovee:  Then, we’ll take questions after the demo.

Sami Laine:  Yeah, we’ll take questions. This is just a couple of minutes. We wanted to highlight a couple of the things that Alex brought up earlier. You saw a lot of things that are in the short-term roadmap as in already shipping, coming soon, some of the things on the longer-term roadmap. I wanted to highlight a couple of things that we’re already close on. First of all, if you're logged in into the administrative interface here, one of the things that we're coming out with that is going to be interesting for everybody is that in the actual policies that you set, we now make it available soon to have multi-factor for administrators.

It means if you are not the administrator, anytime you go into the admin button and click on that, you'll be prompted for multi-factor, really easy way to up the security because as you know, if somebody gets access to the actual admin interface, they can change the policy and rules, open up doors that may be a few days before anybody discovers so that's an important baseline security feature. Make the administrative access behind multi-factor every time.

On the multi-factor, I wanted to just highlight one thing. We've been talking about this and adding things here. Right now, we support a really broad portfolio of different authenticators and they include our own Okta Verify with Push and things from third parties. We're not saying that you have to use only [inaudible 00:35:23] made by us. You can use anything that you want and there's a lot of flexibility behind there especially for your on-prem MFA, you can actually tie in all kinds of authenticators. If you're thinking, “Hey, I already have made an investment on a platform that I know I'm going to deprecate over time,” that doesn't stop you from starting now. You can most likely tie that into our platform right into Okta and then when you out of your service that when you run out of licensing, for example, then you can just smoothly move the people over into other more modern authenticators. I just wanted to highlight that.

Like Alex mentioned, if you look at the strength here, there's a wide variety of strength here. Who here would allow, for example, their administrators to log in with just single-factor or SMS? Anyone? I was going to ask that person to leave the room right now but you all pass, so you get security certification credits for this for your certification. Let's take a look at something that I wanted to highlight. If we go into the actual authentication policy then and look at that, in the sign-on policy, we now can then say, for example, for my sales team.

As the sales team is mobile and they go everywhere, their actual factors policy for the actual enrollment and the difficulty to that for one second, I said my sales employees are allowed to use weaker authenticators because they are, in my case, contractors. I can't force them on a company-owned device or anything. I'm allowing them to use Okta Verify with Push but I'm also allowing SMS and voice call authentication but for my administrators, no way. I'm only allowing them things that are very resistant to phishing. I'm not allowing even OTP. I'm only allowing Okta Verify with Push and U2F security keys in this scenario.

Let's go back into that administrator and look at that actual authentication policy. Alex mentioned in the sign-on policy, what we can now allow you to do is to say, “Hey, if your salespeople are logging in, I can set it up and say if they are in the specific zone of where my offices are, I’m allowing them but I can also create policies that are more granular than that. I can go and say, for example in this particular policy, go back and …”

It's the scaling that's killing me here. I'm trying to make it more visible to you all but in my new sign-on policy, if I created this policy here, for example, and assign it to a group, in that policy, I can now create other elements too. I can say, for example, that in this rule, I want to allow users anywhere to authenticate but I want to challenge them with a multi-factor if they see anomalous location. In our first implementation, it means they are not logged in within 50 miles of this location in the last 20 logins, or anomalous client, which means that they're using a browser device that we haven't seen before. In those cases, I want to prompt them for a factor for that device. These are the kinds of policies that you'll be able to create and it makes it much more flexible for you to create meaningful policies, increase the security while maintaining the usability for those users. Don't challenge them unless you need to but challenge them when it makes sense.

I want to leave you with final plug and that's on the system log side. If you haven't looked at system log two, you should. This [inaudible 00:38:47] allows you to filter in into your actual event data, see where your users are coming from, look at the actual activity on where they came in. I can see here, for example, that I have access from Beth. I can take a look at Beth here. I can see her details. She's a traveling sales rep, looks to be in Virginia right now and that looks fine. I can also go in here and start filtering, so I can create a filter here and simply say, “Let's look at outcomes of events and look at those ones that were failures.”

If you don't have us already plugged in to your SIEM tools and into your security operations center even as an administrator, you can do some quick filtering here and let's see … Let's look at the last failures and we see here some failures. Let's look at it on a map and see what we can see. Singapore. That's interesting. Why is Beth Davis in Singapore where we just saw her log in from Virginia? This allows me to drill into these details and see this kind of activity and then, if I want to, I can even say here, for example, I see here a failure.

I can, like Alex mentioned, quickly go in here if I determined that this was a malicious attempt and I see for example a brute force attack in in play, I can look at the data here and I can even go into the actual IP information here and quickly add that one into my temporary blacklist. That way, that IP address is now blocked. I can go back and then evaluate that later but this gives me some flexibility on how I can quickly stop the bleeding, if you will, and then go investigate a little bit further.

We only have a couple of minutes left, so I think it would be a good time to pause here and go to questions. If you have questions, please come up to the microphone so that we can record your questions and answers both. Thank you. Go ahead.

Audience:  Any change in the servicing admin driven changes like policy changes or auth changes in the sys log so we can do like compliance around it?

Alex Bovee:  Yeah, so the question is, will we capture policy changes in the system log?

Audience:  Yeah.

Alex Bovee:  We should be capturing most of those today. If not, maybe I'll follow up with you afterwards and see which ones you're not seeing in there because I know that we do capture system log events for a lot of policy changes if you update the policy or change rules, so I'll double-check with you on that one.

Sami Laine:  Hi.

Audience:  Hi. A couple questions. MFA for administrators …

Sami Laine:  Can you come close to the mic?

Audience:  MFA for administrators, would that be the super admin or any admin role?

Alex Bovee:  Yeah. It's any admin role for any non- user, anyone who clicks the admin tab, yep, at least for initial implementation.

Audience:  All right. We use Okta Verify heavily but there’s limitation. Not everyone has a phone. Would there be any PC version to compensate-

Alex Bovee:  Yeah. This is an interesting scenario. I think it's a great question. One of the … I'm not sure if you saw but GitHub Engineering recently launched the soft U2F factor for max at least. I think that's a super interesting alternative if you're looking for a high assurance credential. It's tied to the device so it really is an attestation of ownership, so you still got an endpoint compromise problem specific to that but in terms of solving like a phishing issue or …

Sami Laine:  Or go to talk to our friends at Yubico.

Alex Bovee:  Yeah. There's always the U2F hard tokens as well but I think those are great options to think about exploring. I think the world of soft U2F tokens is actually a very interesting evolution of what's happening right now with the U2F standard in particular.

Sami Laine:  Stronger than OTPs.

Alex Bovee:  Yeah, much stronger than OTPs, so, yep. Yeah, sure.

Audience:  One of securities you guys have, blacklisting policies.

Sami Laine:  Can you come on in closer?

Audience:  Yeah, sorry. You guys have a blacklisting policy system, which is really manual currently.

Sami Laine:  Yes.

Audience:  What do you guys have in the future against like company-wide DDoS against users? Biggest concern is executive protection. You know their email address, somebody unlocks their email address but they're constantly being attacked. They're intentionally being DDoS-ed out of their system. Do you guys have plans for dynamic blacklisting based on multiple attack vectors against a user?

Alex Bovee:  Yeah. It’s an interesting challenge because the … There's kind of multiple levels of blacklisting, if you will. There's what we build is a pre-auth blacklist, which is you'll get like a 403 error, I think, or something like that if you try to access from that IP. It's really challenging to do anything like that dynamically because the cost of failure, as you can imagine, is really bad. If we said, “Hey, it looks like this is a failed authentication attempt,” and it's just because your CEO literally fat-fingered their password five times and all of a sudden, we blacklisted their IP address, that's a bad day.

Sami Laine:  We have a couple of things that are coming in a short term, which is we see a lot of these attacks come from botnets but they often come from specific countries where you don't have the legitimate activity, so doing a country level IP blacklisting is going to alleviate that. It's not the panacea doing any kind of modeling-based things. That's tricky because very quickly, you're denying good access too but there's other things that we can do around that.

Audience:  Yes, and I guess really what I was getting at is like a perfect example of Dyn that, D-Y-N-S, on how they really were just being hammered from multiple vector points and anytime any attempts of loads were happening, they were just being overrun, so if you unlock an account, the guy goes, “Oh, okay. Yeah, you know. Hey, let me back in,” but your whole company is being swamped. There are targeted company attacks. We’re a security organization so that's the main question is on that.

Alex Bovee:  The other capability, maybe we could talk about it offline, but the other capability we've looked at is a temporarily whitelist for an organization as well so that if you actually are under a temporal, it's not a long term solution but if you're under a temporal sort of DDoS attack where someone's letting loose like a botnet against all your usernames and your work, you could flip something like that on to at least restrict access temporarily. You sort of whitelist them.

Audience:  A simple tie-in question, Cloudflare integration potential for a preemptive?

Alex Bovee:  That’s a great question. I have not thought about that one. I would have to think about that one and get back to you.

Audience:  Thanks very much.

Alex Bovee:  Yeah, sure.

Sami Laine:  I believe we're out of time here with the session so come and see us here on the side and that way, we can let the other guys take the next victims. Thank you.