Oktane19: Roadmap: Okta Security, the Path to Zero Trust

Alex Bovee: My name is Alex Bovee, I lead product management for Okta for Zero Trust and Security.

Tanh-Ha Nguyen: And I'm Tanh-Ha Nguyen, and I'm also on Alex's team, product management.

Alex Bovee: Great. And we're here to talk to you about the security roadmap in the road to Zero Trust. Before we get started, lawyer statement. Basically we're gonna talk a lot about roadmap today, future vision, all this is subject to change. We'll go on when everyone's read it all. Or not.

Alex Bovee: So before we actually get started and talking about Zero Trust, I'd really like to spend a little time to kind of level set around what we mean when we say Zero Trust and conceptually how we need to think about that from a security perspective. If you were at RSA this year, you probably caught everyone's doing Zero Trust these days. You know that's great because I think it's getting, on some level, a little bit of hype around some adoption and people are starting to think about this from a security perspective, but it's also a little bit bad because when you talk to three different people about it you get three different answers and perceptions about what that actually means.

Alex Bovee: So first thing first, I'm gonna give you the Okta opinion on what we mean when we say Zero Trust. It's really rooted I think first and foremost around this concept of identity perimeter as a perimeter in that fundamental shift. So in that old world security model, the network was the M&M if you will, this hard candy shell outside and this soft chewy, gooey inside. When you're on the network, everything was trusted, you didn't have to MFA, you had access to critical business infrastructure and then everything outside was bad. It was very sort of castle and moat.

Alex Bovee: The reality is, I don't have to tell people in this room this because you're at an Okta conference and so you're doing some cloud at some level, but the proliferation of SASS, the proliferation of IAZ, you're exposing public APIs, you're managing identities across your workforce, your consumers, your business partners, a myriad of different devices. BY owned, corporate owned. It means that all of these things and people and identities need to connect to all these different resources and that's not happening within your network. That's happening all over the place. That's happening on the Starbucks WiFi, that's happening on your cell phone network, that's happening on your corporate network. It's all over the place.

Alex Bovee: And, so fundamentally we have to shift that way that we're thinking about securing that, because you can't draw a castle and moat around the entire Internet. That just fundamentally doesn't work. The way that we think about it is that, that's what we mean when we say identity is the new perimeter is you've gotta start to define that identity is the perimeter and start to put your security controls around that.

Alex Bovee: It also, I think, helps to think about Zero Trust in terms of shifts in philosophies and I'm gonna go through a few of these just to really streamline. I think the reason this is important is you can start at the 10000 foot view, great, perimeter is being dissolved, fantastic, what does that actually mean? It means you have to start thinking about how you solve security problems a little bit differently. One example of this is privileged users. At Okta we don't think about privileged users, we think about users. I think the reality is identities are identities, users are users. It's not that a user is necessarily privileged, it's that the transaction that the user is trying to perform, the resource that the user is trying to access is a privileged resource or needs a privileged level of authorization to perform that action.

Alex Bovee: So we have to start thinking about shifting that. We need canonical identities for people and we need to layer on the contextual access controls and the security controls based on the level of security and assurance needed to perform that action and authorize that action.

Alex Bovee: Static, long lived credentials are the bane of secure systems. If you had a dollar for every time someone's password was compromised or the developer accidentally checks in privileged Amazon keys on GitHub on accident and there's crawlers running around looking for these things ... like, these static long-lived keys are ... they're just fundamentally not secure and we have to move to a world where we're getting away from static credentials. One of those are SSH keys, which we'll talk a little bit about later, or passwords that are just kinda floating around the internet. Those are shareable, they're compromise-able, they can be phished. They have all these security properties which are absolutely horrendous, and so we have to move to more short lived protocols and ways of injecting credentials that have really short TTLs.

Alex Bovee: Another shift, trust is rooted in the network. You have to assume your network is compromised, so assume that your users are accessing the resources from the Starbucks wifi. Assume that they're accessing it from home, assume that they're on the southwest wifi. Don't root trust in network anymore, start to move your policies away from taking security signals with a rooted trust in the network and adopting your security posture based on that signal, it's not a good signal anymore.

Alex Bovee: And lastly, one of the challenges from an access management standpoint in particular was that historically we had all these point integrations and configurations so if you were managing access to these resources, that would be done through this policy control, or you know an integration specific to that resource. We have to start moving to central policy and access control, and that does a couple things. It allows you to, at least in the case of Okta, leverage the benefits of things like contextual access capabilities across your broad set of resources, but it also allows you from a governance standpoint and consolidation standpoint, have the ability to quickly understand who has access to what and control that access and drive all sorts of secure experiences around that like user provisioning, de-provisioning.

Alex Bovee: So without further ado, the way that we think about Zero Trust is really around architectural components or building blocks. And the idea is that across each of these, these are fundamental technology platforms, if you will, that we are building products upon. Each of these has a critical kind of component or value add to a Zero Trust architecture. The first is the IDP. The IDP is fundamentally the backbone, it's the orchestration engine that allows you to move through an experience of identifying a user to authorizing them to access a resource. Strong authentication, can't have users without actually authenticating them digitally. Endpoint and device, being able to identify that device, being able to understand the security posture of that device is critical. Centralized access policies, centralized authorization that can perform at the scale of the internet so you can quickly authorize the transaction level. And access gateway component, being able to authorize traffic flows potentially to support legacy applications.

Alex Bovee: And then the last is thread detection, so understanding at the identify level what's happening around your users and then helping to add intelligence to those systems to be able to understand whether or not a user's been compromised or whether they're performing untrusted activities.

Alex Bovee: And all this is overlaid with two components from an Okta perspective. One is an ecosystem's integration, so in typical Okta fashion, we believe that every company, every user should be able to their, you know, best in class, best in breed technologies and bring that bear within the Okta ecosystem. So one of our strategic and technical goals across each of these areas is that we wanna play well with everyone. If you wanna use a different MFA provider, God forbid, because I own the MFA product, but if you wanna do that, you can do that. If you wanna use a different end point solution, you know, different authorization in general, we wanna make all of these components pluggable and orchestratable, such that you can actually bring in your best of breed technologies and leverage the Okta ecosystem around that.

Alex Bovee: And then fundamentally, all of that stack sort of leads up to producing and providing products and experiences on top of that. So what we're delivering to our customers is a opinionated architecture around Zero Trust that delivers you secure experiences to access resources, whether that's SASS or APIs or with the launch of our server access product infrastructure.

Alex Bovee: I'd love to go into each of those architectural components, we only have 45 minutes, and I think the only thing between the final session and the party is this session, so we'll limit it to five buckets here. And the first is identity provider. So let's talk about that for a second. If you didn't catch John Gronberg and Will's session yesterday about consumer identity being hard, definitely watch that on YouTube. They talk a lot more about this, but we'll dig in for a second. From an IDP perspective, it's important to kinda understand the role the IDP plays in authorizing and providing access. It's really ... it's the backbone, it's the orchestration engine that's performing these critical activities around identifying the user, authenticating them, enrolling them in devices or credentials and then authorizing them to perform some action.

Alex Bovee: And one of the big investments that we made this year for Okta and what we're excited to announce at Oktane is the identity engine. And so the identity engine, when we took a step back and thought about our opinionated flows of how we were providing access management with our current pipeline, we realized that we had baked in a lot of assumption. We had baked in an assumption that all users have a password. We had baked in assumptions about how you wanted to do recovery, about where you wanted to insert hooks to do call outs to third party systems. So part of what we're doing with the identity engine is unbreaking those assumptions and providing lots of hooks and components and orchestratable technologies such that you can do those call outs to your ecosystem. You can integrate your third party risk score engine, you can use, you know, some custom flow if you want to, to be able to drive some customized experience. You can do progressive profiling. You can progressively enroll users into credentials, and you can put that all on top of a customized experience where the user can drive ...

Alex Bovee: Excuse me, where you can have custom branded experiences on top of that. And so we're really excited about this capability. This is really gonna take Okta to the next level, but our customers are gonna have pretty unparalleled level of flexibility to drive the experiences for their end users and their consumers that they want to using this capability.

Alex Bovee: Shift real quick and talk about authentication. This is one of my favorite things to talk about. So, what I find really interesting about authentication is just fundamentally how it's changed over the last five years. It's been a pretty big shift in just the landscape around authentication. And one of the key, I think, trends that we're seeing and when you just look out ten years from now is that FIDO2 is just fundamentally commoditizing the authenticator experience. Whether you're a mobile crypto device experience, a foreign factor, or an external security key, like a Yubikey or a platform authenticator like Windows Hello or Touch ID. All of those experiences have very similar security characteristics.

Alex Bovee: They're backed by cryptographic operations, they're non-phishable or phishing resilient and they're interoperable across service providers. So what that's doing is that's giving us a platform now to solve at scale the phishing and broad based credential attack problems that we've seen just completely plague the ... you know, the adoption of the internet over the last 20 years. But, that doesn't come with out problems. You know, old world problems, if you will, around things like hardware based OTP experiences or passwords or security questions is maybe if it was a hardware based token, it was particularly challenging from a deployability perspective, or if you were using knowledge based authenticators like security questions or passwords, they were phishable. Those were challenges.

Alex Bovee: The reality is that WebAuthn is not gonna solve all the problems. It's not a silver bullet, it's not gonna ... with some set of challenges being resolved, we're just gonna face some new ones. And I think with the new ones in particular, when we start to hit it, the authentication layer and solve it from a tack perspective, it's just gonna shift the place that the attackers begin to hit it. The authentication flows for a user, particularly on enrollment and recovery. So, how do you securely bootstrap a user into a WebAuthn token? How do you allow them to recover their account?

Alex Bovee: And then finally, interoperability. So hardware life cycles. These are real problems. People are on old Windows machines. We get it. You know, maybe unsupported or Mac machines that don't have touch ID. Not everyone's using the latest and greatest. We've got interoperability issues across browsers, and so this is just gonna ... there's gonna be a runway with which it's gonna take us to mature and sort of lifecycle out of some of these interoperability issues from an OS and hardware perspective in particular.

Alex Bovee: And this is just illustratively, they kind of called this out as we were building some of our web authentication flows in Okta, we found that there's just a diversity of experiences and compatibility across different browser experiences. So, you know, maybe on Firefox it supports the ability to silently, you know, detect whether or not a platform authenticator is available. I don't even actually know if that's true, but I think that's true. And maybe that's supported on the other browsers, but the reality is there are different experiences. The browser now controls the user experience, which is great from a user perspective in some ways, but not necessarily if they're moving across browsers on different devices. But ultimately what that's gonna do is really push on the service providers, and this is where Okta can help, to drive an excellent user experience across those different interoperability issues. So driving to things like adoption across different browsers, particularly enrolling web authentication, platform authenticators, making sure that we're solving those UX friction issues where things are unsupported across the browser level.

Alex Bovee: Just to talk a little bit more about this, I think, from a security perspective. One of, I think, the interesting trends that we'll see is that historically, you know, attackers always go to the weakest link, and they go to the place where it's the lowest effort for the biggest return. They're ROI driven, just like everyone else. And, on the internet, up until now, it's been all about credentials. It's been about passwords in particular and knowledge based authenticators. It costs an attacker very little to send out a mass internet scale phishing campaign across your organization and get the, you know, 10% of people opening it, one percent of people clicking it, and one percent of those people actually entering those credentials.

Alex Bovee: That worked well. When you start to adopt and get broad scale adoption of web authentication and FIDO2, that's not effective anymore. So where does the attacker go? They have to start hitting the other parts of the experience. They have to attack the enrollment experience and the account recovery experience. So we'll start to see things like attackers hitting the self-service reset flows, hitting your help desk, trying to socially engineer that IT person to reset your users credentials so they can do a bootstrap enrollment. So Okta's committed to adding additional technology layers and experiences into the product that are gonna help you proactively solve this problem.

Alex Bovee: From a road map perspective, we're really focused on a few big areas. One is enrollment. So just being able to support those multiple credential enrollments, particularly web authentication. If you're using your mobile phone, maybe Android's got a built in platform authenticator or IOS does. You've got your corporate machine that you're using Windows Hello on, you've got your BYO machine. Those are all gonna be separate enrollments and we wanna drive our users to securely enroll in those separately.

Alex Bovee: And that really leads into the next piece which is adaptive enrollment. So, as you're moving across machines and experiences, making sure that we're bootstrapping users securely into those additional enrollments so they're always having the best user experience with the lowest friction possible across that authentication experience. New verification UX. Enrollment and recovery. From an enrollment and recovery perspective we're, you know, very interested in building out ecosystems and experiences that allow our customers to securely identity proof users, whether that's using a third party identity proofing system or something home grown, so you're gonna start to see a lot of investments coming out of Okta allowing our customers to crack open the recovery experience, feel it out customer recovery experiences and drive strong identity proofing experiences from an enrollment perspective.

Alex Bovee: Shifting to devices. Let's do a deep dive in that. Device is interesting because device identity is super hard. And part of the reason it's so hard is that there's this ... a huge array of different device types across Mac, Windows, IOS, Android, all accessing resources across different browsers with compatibility, thick client applications. And what that means is that it's very challenging to present a unified and consistent user experience across a highly sand boxed IOS device and a Windows 7 laptop machine. So part of the challenge that Okta's been focused on is how do we actually build best in class user experiences across these in the most extensible way possible?

Alex Bovee: So how we're thinking about that is really about building device identity as a platform and experience. That is to say, driving the primitives at the product and the API level that allow you do to token exchange experiences to drive device enrollment and extensible experiences that allow you to do device attestation and device identity binding to authentication and other flows. Now it's gonna allow Okta to produce a series of first class, sorry, first party experiences that actually do that binding experience, all of which are gonna be supported from your best in breed MDM experiences in terms of rolling out those different experiences that allow you to do device identity binding and provide that device identity through a sign in flow, for example.

Alex Bovee: Part of what you then need when you're thinking about device identity is actually visibility. One of Okta's road map investments this year and what we're really excited about is really about making device identity and devices in particular first class citizen or universal directory product. That is, give customers the ability to understand which devices have been enrolled, registered to their accounts, give end users that visibility as well, and start to give you a lot more information about the security posture of those devices.

Alex Bovee: And then we wanna tie all of that together through a more seamless, log in experience from the desktop and OS login experience down to actually signing in to Okta. And so we're starting to look at the OS login experiences and understanding how we can actually propagate how the user authenticated from that OS login experience to ... and attesting to that to an Okta single sign on experience, with consideration for things like continuation. That is, if the user logged into the machine ten hours ago with a password, you might want to do a step up authentication to reconfirm that user's identity or a presence test to verify that it's still that user.

Alex Bovee: Ultimately, all of this is gonna drive these secure and seamless password-less experiences, which we're super excited about. So we've been working hard on features like factor sequencing that allow you to mix and match the different authenticator experiences to sign in to Okta. Combining that with things like web authentication. You get frictionless user experiences that are highly secure. Wrist based access controls and machine learning to drive contextual understanding of the risk of the user in the authentication has been a big area for us. Our future is currently in data. And then finally, thinking a little bit smarter about how we actually drive the flow of evaluation from a policy perspective has been a pretty big investment area for us as well, and so we're starting to roll out things like pre-authentication policy evaluation that allows you to drive a deny experience before actually evaluating the credential to do things like prevent user lock outs.

Alex Bovee: And so with that, we are gonna switch to a demo.

Tanh-Ha Nguyen: All right. Thanks, Alex. So, in this demo, I wanna walk you through a couple of the features that Alex just talked about and that we're really excited to show you. So first of all, let's start with authentication experience. If you look on the screen right now, you'll see that my Okta sign in widget might be a little bit different than what you're used to seeing. There's no password bar. And that's for a very good reason. This Okta org has integrated a couple of features that affect the authentication experience.

Tanh-Ha Nguyen: First of all, I've integrated risk based authentication. So after I enter in my user name, what I enter in next is completely dependent on the risk context of my login. Secondly, I've integrated factor sequencing, which is where passwords don't have to be my primary mode of authentication. It could be something else first. So we're flipping around the authentication scheme. Finally, I have integrated WebAuthn. So you'll notice here that I'm using a Chrome browser, it's a Macbook Pro, and I have touch ID. So, weaving it together, let's see how it looks.

Tanh-Ha Nguyen: So you'll see here that Chrome is actually prompting me to login with touch id. I use my thumb, swipe it here, and voila, I'm in. Super easy. We're really excited about that, because you guys have been using this probably on your phones for your banking apps for a couple of years now but it wasn't really possible on the desktop. So, with the advent of WebAuthn, FIDO2, and support by a lot of the major browsers, we're able to bring this to Okta. Now, like I said, I'm using a Macbook Pro with touch id, that's a pretty new device, but we've tested on several different ones. So we've used Macbooks, we've used Surface Pros, we've used Android devices. And this last one, Chrome browser on Android devices should reach over a billion users in the world. So you can bring this to your applications and to a lot of users.

Tanh-Ha Nguyen: So switching over a little bit. How is this all configured? Let's go to the admin panel. I'm gonna start with Risk Policies. Risk based authentication. So here you see that all my sign in policies ... I only have one risk score policy. And the risk score policy has three rules. One for high risk, low risk, and medium risk logins. What are these? Let's start with low risk. This is the one that was just evaluated when I logged in. And you'll see that the policy is all centered around risk. If Okta evaluates the login context as low risk, usually this is Okta recognizes a combination of the device, the network, the location, we will give it a low risk score. And then, the admin has set two possible authentication chains.

Tanh-Ha Nguyen: Here, I can either login with WebAuthn, which is what I did, or alternatively choose Okta Verify Push. One strong factor and you're in, because we've already done risk based authentication. Now say I'm traveling. I'm in Mexico City, I'm in a hotel, and for some reason, I have to log into to Splunk to check ... I don't know. I'm on vacation. So that most likely will be a high risk login, because I'm on a hotel computer, I'm in a different location on a network I've never logged in before. None of these are associated with me in Okta. In that case, again, two different authentication chains. And again, the first factor is a strong factor. Either WebAuthn or Okta Verify. Now, since we don't recognize a lot of the context of this login, we'll step you up with a knowledge based factor, a password. So this is to protect against the case that someone compromised my device and was able to get into my machine.

Tanh-Ha Nguyen: And you'll see that this ... these two factors combined is nothing new, but what's new is we've flipped it completely around. We're not exposing your org to credential based attacks because the strong factor, the more unphishable factor comes first. So finally you'll see that to make this work, I've had a lot of factors enrolled. I had Okta Verify Push, I have WebAuthn, I had a password, and I might even have a back up factor. And we know that factor enrollment is a big pain point for our customers. Imagine you're in your first day of work, you have to bring all your forms, you have to get a new computer, you have to get a Yubikey or a token, your badge, all that stuff. It's hard.

Tanh-Ha Nguyen: So, we have worked on a new feature called Factor Grace Periods, which gives users more time to enroll the required factors. So here, I have an MFA enrollment policy with two required factors. And this applicable to everyone in my org. I require Okta Verify and WebAuthn. Now the new thing here is that I've set an enrollment period for three months, starting from yesterday. So that means that my users have three months to enroll the required factors, and if they don't do it on the first time, they'll be prompted at most once a day to enroll until they've had everything they need. And this way, you can move your entire org, however many people there are, to have the required factors, and then swap them over to a different factor sequence.

Tanh-Ha Nguyen: And with that, back to Alex.

Alex Bovee: Hey, thanks, Tanh-Ha. So one thing that we didn't mention is that web authentication is actually EA Today in previ environments. That'll be in production next week, so hopefully everyone takes advantage of that feature, that's a great feature. Next up, we're gonna talk about threats. Threats I think is a pretty interesting area in particular because the landscape around threats is very different from IDAS perspective. So one thing that we've gotten universal feedback from our customers about is that fundamentally customers need more control at the edge, around who's able to access and make requests to the Okta service, around unauthenticated protocol end points in particular, and so we're looking at adding a lot of policy controls and capabilities around allowing, denying access, driving smarter work flows or a mediation work flows at the edge in particular, based on the intelligence or ... that Okta can provide or based on the business rules that you wanna add to your organization.

Alex Bovee: And that really leads me to ThreatInsight. So Okta ThreatInsight is a feature that we talked about Oktane last year. We're gonna launch this into EA in a couple months. This is available to all of our customers because we believe security at some level should be free. Okta ThreatInsight is a super exciting feature. So when we took a look and took a step back at what the problem statements were that our customers were having, it was clear that these broad based credential attack problems, password stuffing, password spraying, brute forcing, you know, botnet driven attacks were just a massive problem for our customers. And this was clear across ... you know, whether it was WS trust protocol end points because we're using O3-65, a Legacy access or modern authentication protocol end points.

Alex Bovee: And so Okta ThreatInsight gave us the ability to look at the edge, the requests that were coming in, introspect things like credentials across multiple different requests, across multiple different orgs and fundamentally make an assessment about whether or not we thought that that request was malicious. And so we are looking across our thousands of customers and billions of authentications a day, across work force users, consumer users, and making assessments in real time about whether or not that we think that requests are threats. And so we've seen some really interesting take aways from this, based on early results. The great thing is from a SAP perspective, this is taking the onis off of your SAP to go through and understand this data from spelunking through splunk, exercise in trying to understand whether or not an IP is malicious. Maybe it takes that exercise down from days to literally minutes from a ThreatInsight detection perspective, gives you a core screen control to be able to block access from that immediately at the Okta edge.

Alex Bovee: And just on early assessment of some of the data, we notice that we've got about a 90% detection rate, even looking at our own internal data around malicious requests. So this is a super promising capability. It's not gonna solve the problem 100% day one. We view threat detection and threat prevention as a journey, but I think this is a great leap forward in terms of proactively being able to drive detection of threats at the edge and then prevent those from targeting your users and impacting user experience.

Alex Bovee: I think this also kind of highlights a really important point, which is that threat detection and cyber attacks in general is an asymmetric warfare game. So, the attackers are using fundamentally different tools than your defenders are. It is very easy for attackers to change their signature and adopt and change to your prevention mechanisms, to change, to impact your ability to actually detect them. And part of the problem with that is that if it takes an attacker ten calories to change the way that they're attacking your infrastructure or organization, but it takes you 1000 calories to actually detect them and then respond to that and recover from that, that's a big problem because it means fundamentally that you can't scale that. It's a lot easier for those attackers to come after you than it is for you to address those attacks.

Alex Bovee: And we're seeing that across the board from a security perspective with the CSOs that I talk with. It's fundamentally ... the SAP just isn't scaling for our customers. That is, you've got alert fatigue, you've got lots of false positives thrown across tons of different consoles, chair swivel across those consoles, and everyone's taking an incremental technology approach, layering more and more security technologies on top of these problem statements, trying to address the issue. But I think when you take a step back, we have to reorient towards outcomes, and Zero Trust is a big step in that direction.

Alex Bovee: I think also applying technologies at the edge like ThreatInsight which is an analytics based approach to trying to proactively identify attacks is also a big step in that direction. Our strategy fundamentally is about addressing at scale internet attack problems, like credential based attack problems through technology such as web authentication and adoption, solve the 80% attack problem, get those alerts out of the way, get rid of that alert fatigue and then it gives your incident response team and your security team the ability to focus on the targeted attacks and the novel attacks that are attacking your organization. This is gonna help you scale your incident response team.

Alex Bovee: How you also have to think about that is giving users more visibility and control over their security. So when you're talking about that targeted attack problem or the relatively sophisticated attack, you will never be perfect at coming up with a set of rules that are gonna identify those things. Fundamentally, that's the idea behind the targeted attack is that they're gonna be very specific about trying to evade those detection mechanisms you have in place. And so how can you help solve that problem? Give users more visibility and tools to be able to take control of their security.

Alex Bovee: We've launched a lot of features over the last year in this direction. We've shipped things like new device notifications that'll alert a user if an unknown device is logged in from their account. Credential reset and enrollment notifications, so if someone has reset their MFA credential or enrolled in a new credential, we'll alert the user to that. But you're gonna see even more from us. You're gonna start to see us investing in things like a self service security center from an end user perspective, so I can quickly go on and understand the devices that are attached to my account, applications that I've authorized from an OAuth perspective, lot more visibility and notification controls across different channels, whether that's web, email, Okta Verify is a push notification system or SMS. We wanna give users a lot more signals so that they can be more proactive in their security.

Alex Bovee: Part of that as well is tying together that security detection, notification experience from an end user and actually allowing the user to take a little bit of control around self-remediation. Sometimes a user might think that something is suspicious with their account, but they feel powerless to do that. Maybe they shoot an email off to the IT team. So we're starting to think about how we connect things like workflow to some of those communication experiences and those self service experiences so that you can drive a secure, end user driven experience that allows you to recover your account or alert your security team or yeah, drive some sort of account recovery experience.

Alex Bovee: And with that, we're gonna switch back to another demo.

Tanh-Ha Nguyen: All right. Thanks, Alex. So, we're gonna go through what it takes for an end user to report suspicious activities. But first, let me put on my end user hat, yeah. So you know who I am. And here is my end user email account. And you see that there's two suspicious emails from Okta. Well, not suspicious, but things that I don't recognize. My MFA factor has been reset and then it's been re-enrolled. And it happened somewhat recently, probably while I was setting up for this demo. It wasn't me. So, I'm gonna go look in more. I don't know what this is. I see a green button to report suspicious activity.

Tanh-Ha Nguyen: Again, I can see a little more details, and then I'll see that if I go and report this suspicious activity, my org admin will automatically be notified, I will be signed out of all my devices and be put in password reset mode. So, I'm comforted by the fact that if an attacker had gotten in sometime earlier, they'd be kicked out and couldn't get back in again. Press the blue button, and I'm done. And that's all I need to do as an end user, and it's all we want the end user to need to worry about.

Tanh-Ha Nguyen: Fast and simple. So, switching roles again, taking off this hat. Let's go to the admin experience and the admin email inbox. You'll see here that I, as an admin, have received this notification that an end user has reported activity, and I can go here and review the security event. Clicking on here takes me to a filtered view of the sys log, where I can see the events that were associated with the event that the user reported. I can see that the information about the client, the event, and even see a map view of where this happened. Now, you have to note here that the user reported suspicious activity is a distinct event in Okta's sys log. So that means that you can export that event to your SIM, to downstream systems, and you can subscribe to it as an event hook. So you can trigger actions in other services if you wanted to.

Tanh-Ha Nguyen: Now, going back to Okta, you'll recall that when I, as an end user, reported suspicious activity, my sessions were reset and my password reset. So the way we orchestrated that is actually through the Okta automations feature. So going here to work flow automations, you see that I've created an automation upon user reported suspicious activity. So when this happens, Okta will perform the following actions: send an email to the admins, clear the user's sessions, and reset the user's passwords. Now, if this isn't the right set of actions for your org, this is all configurable.

Tanh-Ha Nguyen: You can go and edit, say I don't want to reset the user password, and I don't want to clear the user's sessions. Activate. And I'm good to go. So this is just one thing that we can do in Okta to help secure your end users and actually this is only one aspect of the automations feature. So if you didn't already see the automations hub, I would highly recommend that one on YouTube as well, just to see what else that you can do. With that, back to Alex.

Alex Bovee: Great. Thanks, Tanh-Ha. So last step, we're gonna talk about resources and in particular a new set of nouns, if you will, that Okta's really excited about providing access management to. So historically, Okta's been known for providing access to SASS and APIs through our APIs access management products, but most recently with the announcements at Oktane, we're moving into two new categories: Legacy applications and infrastructure. Particular on infrastructure, we're really excited to announce the launch of our Okta Advance Server Access Product.

Alex Bovee: Okta Advance Server Access is gonna step up your ability to do secure access to remote servers in infrastructure, using a Zero Trust philosophy. So we've killed SSH and long lived credential keys from that access capability. You don't have to worry about a developer accidentally sharing them, you don't have to worry about revoking them, and you also don't have to worry about checking them out of a system. And fundamentally that starts to solve those problems that I mentioned earlier in terms of philosophies around giving you short lived tokens and experiences to seamlessly log you in to that infrastructure, but also using Okta's contextual access capabilities. So, using device aware access, strong authentication, tying that all together to seamlessly log you into servers.

Alex Bovee: And we're excited about where we're gonna go with this product as well. So, today you can use the Advance Server Access product to do SSH and RDP based login across your favorite cloud and infrastructure as a service environments, whether that's GCP, Azure, or AWS or even your private infrastructure for that matter. But we wanna increase the ability to leverage this product across your infrastructure, in particular by supporting native's experiences such as Amazon CLI or other CLI environments, developer friendly experiences, such as Terraform, so that you can seamlessly spin up these environments, using ephemeral tokens and furthermore, investing in how we help customers meet them where they're at in terms of their current infrastructure capabilities.

Alex Bovee: So if you have more fine grain permissions or authorizations on the server, things like doing sudoers drop in file management from an entitlement perspective, using our server access product, you're gonna see all of those capabilities this year, coming out from our server access. And then just to recap, again tying this back to a Zero Trust mentality, we're killing static keys, we're killing shared accounts, we're killing check out processes. There's no such thing as privilege escalation, because it's always ... it's just about fundamentally the user who's accessing it, giving them just in time provisioning and de-provisioning capabilities, setting your contextual access policy on the server, or a set of resources you wanna provide access to, using that to do device aware access or strong authentication. So it's really leveraging that Zero Trust mentality to be able to provide access management.

Alex Bovee: So final thoughts. Let's bring this home. So one of the interesting things that we've talked to the customers ... one of our ... when I was meeting with a customer, they said ... and it really resonated with me, which is that, "Google has a company full of propellor heads, and we just have the people in this room." And that really hit home for me because I think we've seen all of our customers sort of struggle with the idea of like ... we wanna get to these better security outcomes. We wanna get to a better security architecture, but we fundamentally can't rebuild our entire technology stack and infrastructure. We can't build a server access product. We don't have the ability to do that.

Alex Bovee: And so what we want to do is we want to give you the reference architecture, we wanna give you the tools, the capabilities, the platform components and the products on top of it that allow you to achieve that better outcome and that secure experience using the Okta product stack. We want to be your partner to modernize your access management experience across all of your different resources, whether that's SASS or Legacy Applications or infrastructure and securely move to the cloud and move to that better security world and get better outcomes for your organization.

Alex Bovee: And with that, we'll take questions. Thanks.

Tanh-Ha Nguyen: Thanks.

Speaker 3: Hi, so with regards to reporting suspicious notifications, are there any plans to integrate that not just in email but also in the Okta mobile app?

Alex Bovee: Yeah, definitely. So the way that we view the end user notification experiences in particular is really about supporting those across different communication channels. Email is just one communication channel. SMS is another. Okta Verify Push channel is obviously another good experience where you can drive that. So you'll start to see some of those experiences coming out.

Speaker 4: Hi, there. One quick question. Do you guys have any plans to make any products or any functionality for the privacy requirements like, you know, CCPA coming up in the future? How are you planning to support that? A road map perspective?

Alex Bovee: That's a good question. I don't have a great answer for you on that one, but I'd be happy to take it off line afterwards and explore it with you.

Speaker 4: All right, thank you. Regarding the devices part that you mentioned in those five points, what are, you know, the plans when dealing with enrollment and maybe security check ups that you may have? Is there something that you're planning to use, part of the road map or could you elaborate a little bit more on that?

Alex Bovee: Yeah. So, we view device identity from obviously an identity perspective. This device is managed, it's trusted. And then also from a security prosper perspective, so I know that we have integrations with folks like vmware today where we can federate some of those experiences across to Okta. We're also looking at building out a set, an ecosystem around your favorite EDR vendors to be able to provide that context in Okta and use that to make an access management decision.

Speaker 4: The demonstration about the password resolve indication using WebAuthn is pretty impressive. Good job on that.

Alex Bovee: Thanks.

Speaker 4: But, when it comes to WebAuthn, you cannot make the assumption that all the devices are going to be incorporated with the platform trusted sources. So, for example, you have the first screen with just the username and you click next. If you don't have a way to use a fingerprint scanner on the device will WebAuthn be device context sensitive to be able to prompt a password on the next screen?

Alex Bovee: Yeah. That's a great question. Basically, the problem statement is from a WebAuthn perspective it's really driving a credential verification using a nonsynocryptographic signing operation. What WebAuthn does support is the ability to pass additional attestation information about how that signing operation took place. Not every key experience or authenticator does that, but that is additional context that you can crack open and take a look at. So, our, kind of, step one in this was just supporting WebAuthn, driving the more secure enrollment and broad base adoption. But, another investment that we have on the roadmap this year is really additional layers in the product that allow you to more precisely slice how you want to treat the verification of the credential itself so that a presence test from a WebAuthn perspective might be treated different from a security perspective in factor sequencing than a biometric verification.

Speaker 5: So how those things are going to work with behavior detection? Are they going to work side by side or behavior detection going to be part of the other insight?

Alex Bovee: Behavior detection today is a different layer within the policy capability. We've actually incorporated all the behavior detection into our risk scoring capability. From at least that perspective, if you want to use more fine grain controls you can continue using the behavior detection feature. If you want to use a more coarse grained risk score, you can use the risk score that we'll provide to you.

Alex Bovee: And, I think we're out of time, but I'm happy to take one more question or... should we do one more? Sure.

Speaker 6: Hi. Hello.

Speaker 6: So, for self-service password resets is there any plans to include using additional factors other than the SMS, email-

Alex Bovee: Yes, yes there is. That's on the roadmap. Our team is working on it. You'll be able to use all your favorite factor experiences, WebAuthn, you too have Okta Verify to recover your password in the future.

Speaker 6: Any idea on the timeline on it?

Alex Bovee: We are. We can take it offline.

Speaker 6: Okay.

Alex Bovee: We're working on it.

Speaker 6: Yeah.

Alex Bovee: I don't want to promise it in front of everybody.

Speaker 6: No worries.

Alex Bovee: I'm pulling a PM move here. Thank you all, appreciate it.

Tanh-Ha Nguyen: Thanks.