Okta SecOps on Security: Protecting Your Okta Orgs

Cameron: Hello. So, I'm Cameron Euro and I'm a security engineer on the Okta corporate security team. I'm here today to talk a little bit about how Okta protects our Okta tenant and a little bit about how you can do that as well. I'm joined by-

Jason: I'm Jason Pazoni I'm a solutions architect from Motorola Solutions. I have been responsible for a lot of areas in addition identity and assessment management, so I've been responsible for our deployment of Okta.

Cameron: So let's go ahead and jump right into it. Just to provide some additional context, I'm not a product guy. I don't do features. I don't do roadmaps. Literally, Okta is one of the services and security controls that I have to deal with on a daily basis as a corporate security team member. I look at it the same we I look at a lot of our other services such as like firewalls or anti-virus and chances are when we do have any security incident like a report of a phishing attack or anything like that, I do a lot of the same things you guys do. I go into the system log and I start looking around and see what happened. I think that I have a very similar perspective to a customer because we are an internal customer of Okta, at Okta.

With that out of the way, this is just some things that I've kind of picked up and kind of discovered over the last year and half that I've been with the team. So, obligatory Okta slide. I'm sure you've seen this in pretty much every single presentation at this conference, but it's pretty clear that Okta, we sit in front of all of your most important applications and services.

From a security team perspective, right, you're a security engineer or a security architect, you're constantly looking to place controls in place to protect these things, right? When we do place security controls in front of things, we want them to be as efficient and as effective as possible and we want to put them places where you get a good ROI. In this case, turning each and every single one of your downstream applications into a fortress doesn't scale. It's probably also impossible because they're all unique and different and have special snowflake features and may or may not offer you the security controls that you need. When you have Okta deployed, when you put all your security controls at the Okta layer it basically kind of trickles down and protects all of the downstream applications as well, so it scales much better and I think you get much better return for your investment from a detection standpoint.

So, monitoring Okta, first up is actually to take a look at what's going on within your Okta tenant. You do this primarily using the system log. You go into the admin section of the Okta app, you take a look at what's in the system log. The system log is a very basic event viewer. It doesn't have a lot of advance features, but we're not also trying to compete with Splunk or anything like that. I'm also going to plug right here the fact that I wrote a paper, actually, on how the security team at Okta uses the system log to investigate incidents and that's also a public document so if you search for the Okta Incident Response Guide it's on Okta.com and I'll have a link to it later on in the presentation. If you've ever looked at our marketing around the system log and you're like, how would I actually use it? You're just listing features. I really go in depth in my paper about how to use it, how to understand the data that's in it, basic querying, and filtering, and stuff like that so check that out if you're interested for more.

When you're looking at the system log, the system log is full of all kinds of Okta system events, right? These events are usually associated with some type of event name. Mentally, when I'm looking at these events I group them into two groups. The first group is user activity. These are things that your Okta users are doing. They're logging in, they're changing their passwords, they're using SSO'd access applications and this is really important from a security stand point, right? You want to know what your users doing. You can also spot malicious access or malicious activity. This is also really hard for security teams to kind of leverage. A lot of it is focused on base lining and detecting deviation from that baseline, which can be very difficult to do at scale especially for very large customers or customers that have a lot of business units. It's still something that's very relevant to your security team and when they're responding to an incident the user activity is going to be very important. From a detection standpoint, you get out of it what you put into it. So user activity is one.

The second group is Okta activity. So, Okta activity is like changes to your Okta tenant or admin type stuff, so the creation of a new admin user or the modification of a network zone, or the creation of an API token. These are things that happen within Okta. If I was to build something from scratch, this is where you probably want to start because they're very low volume for the most part. They are probably only going to be initiated by highly privileged users like your super admins, and then in a more mature organization these changes will likely only occur during change windows and they'll usually have associated change request tickets or change advisory board tickets.

In the case of someone creating a new admin user or granting admin to an existing user, in our case we'll immediately go in and see if there was a ticket associated with that action, and did it occur during the approved change window? It's very easy for you as a security team if you have that kind of setup in place, to notice any sort of change to your Okta tenant. I also think that this is a good place to start because once you can ensure the integrity of the Okta tenant, and that people aren't going to come in behind you and change things after you set it up all nice, that's also really important and you probably should figure that out before you do anything else. You want to make sure that it's set up the right way and detect any sort of modification or deviation from that.

On top of that, the third reason is changes to your Okta tenant and the admin section, such as changing policies, can broaden your attack surface. If someone goes in and they change a policy that you had set it could open you up to more types of attacks, or attacks from more different vectors. Those are definitely things that you want to audit.

Here I'm also going to plug another thing that I did, so this is my two, the first being the Okta Incident Response Guide. Okta has not done a super good job documenting what their events mean. If you were to say, ask, what does it look like in the system log when a user gets locked out? I don't know. There's no real public documentation around that. I kind of figured a lot of this out through trial and error. I started up my own Okta tenant and I just did things to it and saw what events were generated and over the last year and a half I've kind of identified and settled on the top 20 - 25ish events that I tend to go to when I'm conducting security incident investigations. What does it look like when someone accesses the admin section of the Okta tenant? Oh, well, in this case it's a user.session.accessadminapp. This is something I made for myself but I was able to get it published for this talk. It's on the Okta Security Lab's GitHub account. So, github.com/Oktasecuritylabs/cheatsheets. If you want to know what are some of the events you might be regularly dealing with when you're conducting an investigation, or you're not sure where to start from building your own alerts, these are probably good ones to start with. Be sure to check that out if that's something you're interested in doing.

Finally, bringing it all together, like I said earlier, the system log viewer is not a SIM. It's not a log analysis tool. It lacks key features to do a lot of the things you're probably going to want to do like send you an email or trigger a pager duty notification if something happens, or do any sort of long term pattern based analysis so if you wanted to, say, determine the failure rate of logins for a particular IP address over a 60 minute period you have to search in the system log, export it to CSV and then do all kinds of stuff like that, or you could already have it pre populated in a system that has those features. We support a number of integrations into existing tools such as like Splunk, LogRhythm, Sumo Logic, and I'll talk a little more about this later, but we have an API that is paginated access it's your Oktatenent.com/API/logs it's that simple. It feeds it back to you in Jason form, so you can just push it directly into elastic search if you wanted. We highly recommend that you do.

What happens once you begin to detect potentially suspicious or malicious stuff? Well, then you have to get into the investigation stage. What does this look like? Well, it looks a lot like dealing any other sort of application or web app. The logs contain all the things that you would expect like user agents, IP addresses, the API or URL endpoint that was hit, Okta specific stuff like the username or user ID. These are all high value indicators you're probably going to want to grab because during a security incident you're not only going to be in Okta, you're likely going to pivot into other data sources once you've identified these IPs. If you know that a particular is a host it is conducting malicious log ins you can then pivot and look at your other apps or say your firewall or your VPN that's not connected to Okta. The other thing that also is really useful that I don't know if you guys know is in the system log, we have a leased GEO IP database. We tag every single request and every single in the event log with the approximate city/country it came from which can be really useful for spotting anomalous traffic if you're a business that only operates in California, for example. Usefulness depending.

The other thing that people may not know is that every single event that goes into the system log has an associated session ID. Now, what is a session? It's an ID that represents your unique Okta session token which you're using to single sign on to apps, so it's buried like really deep in the Jason. You have to go down like four or five drop downs to get to it, it's in event debug something or other, but you'll find it. It's there. I promise. Anytime you spot a suspicious log in or a log in that you don't recognize or someone does something they're not supposed to do, one of the first things that I would probably do is grab the session ID, plug that in to the system log or your SIM or log analysis tool and look at all events associated with that session. It could also be a very powerful tool from a detection standpoint, so you can do things like look at a session that has requests coming from multiple countries, which we'd call like a Superman scenario internally. So someone duel logs in from the Philippines and the United States at the same day, for the same session would be kind of unusual, right? Sessions are a really powerful tool.

Also, there's another thing in there that is not as consistent but we also have something that's called transaction ID and for an event that triggers multiple lines in the system log may also have a transaction ID that links them all together.

So, I'm going to go off on a little bit of a tangent, as well, because here's another thing we don't document super well, and I think we could do a better job. It's also is extremely confusing. As we were building out our alerting and our dashboards and deciding who we were going to investigate, this was something that I struggled with when I first started at Okta and it took me a while to kind of wrap my head around it but it's pretty simple so I'm going to try to explain it right here.

This is what a single sign on event looks like at the top, so, at this date, this user, did this thing, to those targets. In this case, Cameron Euro, the Okta user, did a single sign on event to a particular app instance and a particular app user. Well, what is an app instance, what is an app user? You can have, in this example, multiple box instances. One say that's only for legal, one that's only for finance. They can exist in the same Okta tenant because they have different app instance IDs.

When you're dealing with your system log you make sure to be careful and you differentiate between the display name, which in this case is Microsoft Office 365, versus the actual app instance ID because there could be collisions. You could have multiple app instances that might have the same name, possibly? I don't know. Then, within that particular app instance you have an app user. You notice that one is tagged as user and one is tagged as app user. The user is the Okta user, the app user is that user account within that particular app instance. Hopefully that cleared some of that up, and this is really important because if you're investigating a security incident, you want to make sure you actually know what the IDs actually mean and you're looking at the right ones because that app user will never show up in your logs outside of that particular app instance, or single sign on access to that app instance, or DPROV or provisioning events. It's kind of confusing topic and when you're in the heat of the moment and investigating a security incident, you want to be sure that you know what indicators you're actually collecting, and what you should be looking at.

Then obligatory type of life cycle slide, I just love this one. I'm sure everyone has seen this before if you're in the security space, so this kind of outlines how an attack or an intrusion would be carried out by an attacker. First they're going to do a little recon, they're going to check you out. They are going to do an initial compromise where they break in for the first time, and then they're going to start digging in and worming their way through your network. In a conventional incident response scenario, but it does apply to Okta as well. It looks a little bit different, right? In our case, initial recon would be username, enumeration, and password spraying for example where a more traditional attack

Cameron: Username enumeration and password spraying, for example, where in a more traditional attacker life cycle model, the initial recon would be open-source intelligence gathering, and map scanning, or vulnerability scanning perimeter, but it does apply, and you should keep this in mind if you're an incident responder. When you see things in your Okta tenant looks suspicious to you, you should try to place them somewhere on this life cycle. Personally, when I'm conducting an investigation and I find something suspicious, I place it on this life cycle, because that will drive the things that I look for, right? If I see password spraying, I'm not going to go looking at all the changes to my Okta tenant and new apps that were added, because that's not related. But what I would start looking for is the next thing in the chain, like the user login, and also where you sit on the attacker life cycle should ideally influence the response actions you take. If they're in the complete mission section, it's time to start unplugging cables from the backup servers, right? But if they're in the initial recon stage, you can take a bit more of a measured approach, so keep this in mind.

And then finally, as you're doing your investigation, you should keep in mind what your goal is. Your goal, when doing incident response, well, the investigation part anyway, is to fully scope the incident. Once you detect something, you have to investigate it and figure out everything that occurred that might be malicious, which I refer to as fully scoping, and that should be your goal during this stage, because if you don't fully scope the incident, for example, you're basically going to waste a lot of time, and the attacker is just going to get right back in. So, in Okta, the scope would refer to what users, what sessions, maybe what apps were accessed during what times.

But you also need to keep an eye on the big picture, right? Okta's just a single component, it's one of your security controls, it's not all of them. And also, things outside of Okta can affect the security of Okta, right? So in my previous example you identify an Okta user that you believe is compromised, or they have lost, or given up, or been phished, and they don't have their credentials anymore. The attacker does, and they've taken control of that account. So, you say, "Oh, cool, I know exactly what to do," and you suspend the user in Okta, you kill their session, and you issue a password reset email. You're like, "Cool, done." Except when that user resets his password from his compromised laptop that has a key logger on it, and then you start over. So that's what I mean by identifying the incident scope and knowing where you might need to look outside of Okta as well, cause you want to make sure you're doing an effective response, which is the next slide, of course.

So, when you're responding to things in Okta, the first step is going to be containment. So you want to prevent any sort of further damage from occurring. You want to evict the attacker and make it harder for them to get back in. So, within Okta, really the tools that we make available are suspension, so you can suspend the user so you can no longer log in as that user. You can kill their Okta session, which kills their session token so they can no longer do single sign-on activity. And then you can also, I guess ... There's a couple other things you could do I guess. The knee-jerk reaction might even be to delete the user, get rid of it, recreate it and start over fresh. So that's probably the first initial step that you're going to take when you're trying to contain an intrusion. And then you're going to follow that up by locking down access to Okta temporarily, because once you start evicting the attacker and responding and suspending the users that they're relying on to get in, they will fight you to regain or retain that access to your environment full stop. Once you start fighting back is when it really gets heated.

And I'm also going to highlight something on this slide that is a little bit touchy, and that's the downstream applications part. So, Okta, we integrate with all kinds of apps, and all these various downstream apps have different ideas around security. Some of them think that by default, SAML is optional. Outside of our control, right? But, to give an example of downstream application sessions possibly coming back to bite you while you're doing your response is Office 365 in particular. So most of you don't do a full Okta login and MFA into your Office 365 mailbox every day. You might do it maybe once a month or whenever. You ever thought about why that works, it's because Office 365 issues its own tokens to trusted devices, I think they're called refresh tokens and they can last for up to 90 days. And then those refresh tokens are used to give access tokens, which last about an hour, and they're constantly refreshed by the refresh token. If you kill the Okta session or suspend the user, they're still going to have an access token and be able to log in for the next hour, so you have to kill downstream applications as well. And just standing up here thinking, a good kind of research project would be all the apps in the Okta application network that have that kind of caveat.

So you need to be prepared and know your apps, cause when you're responding to an intrusion is not the time to go on stack overflow and figure out which powershell command to use to kill an Office 365 session. It happens to the best of us.

And here is where I'm also going to go off on a bit of a tangent, so please forgive me. On the topic of Office 365, this is unrelated really to the rest of the presentation, but I want to use this particular kind of moment and podium to say something. Office 365 is one of the most common Okta applications, if not the most common. If you look at our business, our work report, I think it's our most commonly used application. Anyone want to admit to having it deployed in their environment? We do. A lot of hands. Everyone that had their hand up has been the victim of password spraying over the last year. Period. Like if you have an Office 365 tenant, you have been the victim of password spraying. Why is that? Why is it so prevalent, why is it happening to everybody? Literally everybody. How many people that had their hands up before run their Office 365 tenant with default settings? No one's going to put their hand up and admit to that, right? But most of you probably do, and for those of you that don't know and you're like, "Oh, I have to ask my Office 365 guy when I get back home," you probably do as well. And if you have your Office 365 tenant configured with default settings, your hand up before, you were the victim of password spraying, you probably also were the victim of successful password spraying.

So, if you take only one thing away from this talk, that's totally unrelated to the talk, you should go look at the Microsoft documentation around modern authentication protocols for their applications. If you're not using modern auth, then you're not doing it right. You really need to do that, and product marketing didn't tackle me off the stage yet, so I'm good to keep going. Yeah.

So, tangent aside, as I said, after you start containing the threat, the attackers are going to fight to retain or regain access. After you start kicking them out, you're probably going to see a resurgence of phishing emails as they try and break their way back in, and they may even potentially abuse the fact that they know you're responding to social engineer the user. "Hey, as part of our incident, please install this VPN update.exe." They know what you're doing, right? They do this a lot. So within Okta, you're probably going to want to lock down your Okta tenant a little bit during this stage to make it harder for them to get back in, and in this case that usually involves either network zones or policies.

So there's four bullet points on here, but two of them are things I'm not going to recommend, and two of them are things that I am going to recommend. So I'm just going to go down. Network zones. I've seen some people white list known good IP ranges and say, "Only allow logins from that range," which is a pretty good method if you control your corporate network, and they don't have access to your VPNs or your proxies. I've also seen people take the blacklist IP approach where you blacklist known bad, and this is a good tactical action, but you can't rely on it to protect you in the long term, and it doesn't really constitute an effective lockdown solution. And then the other one is policy-based, so you may decide to step up the aggressiveness of your MFA policy when you're in this kind of remediation stage and force MFA for every single login, all the time. And then also there's a thing, you can set MFA challenge requirements for specific application SSO access, so you may put an additional MFA challenge in front of some of your more critical systems.

And now we come to the other two bullets, and based on what I said before, two of them are good, two of 'em are bad. These are the ones that I'm going to call out as bad. I had a customer say that one of the things they do is they have a special suspected compromised group in Okta, and whenever they see weird stuff, they put that person immediately into that group, and remove 'em from all their other groups. And that group only has access to like, email and Slack, which is better than nothing, I think, but at that point when you believe that the user is compromised, you're basically leaving them access to your incident comms, and also, there's nothing stopping the bad guy from writing back yet, like, "Yeah, I am this person, I did reset my password from Bangladesh, so don't worry about it."

So, yeah, I don’t know. I don’t know how much I ... Like I said, it's an option that you could do, if you're willing to accept the risks, and the final one is my favorite, knee-jerk reaction, when you just go into Okta and you remove all your critical applications from Okta to prevent the bad guy from getting into it because they have Okta creds. Probably not really good idea. If you go back to my first slide about how Okta sits in front of all your other applications and why it's good to kind of focus your security controls on Okta, when you remove the app from Okta to protect it from Okta, Okta also doesn't log any access to that application anymore, because it's been removed. So you no longer have any visibility into what that app is being used for, who's logging into it, what are they doing, and you also lose the ability to put more restrictive policies and controls in Okta, in front of that application. So, it's like you have this app that your afraid people are going to access, so you remove it from the tool that provides all your security controls and monitoring ... You got to do what you got to do. Just saying, know the risks.

And then finally, the last step is going to be recovery and cleanup, and this is a really, really important one. You need to make sure that the passwords and the MFA factors associated with your users actually belong to those users, cause if you decide you're going to turn on MFA, and the attacker gets to it first and they register MFA, then that's no good either. So, you have all the ability to do all that kind of stuff.

And very quickly, I'm going to blitz through this slide, automation. I mentioned we had an API. Enough said. Go to developer.okta.com. We also support all the actions that I talked about in the remediation response step are supported by the API, so this is just a quick and dirty python script versus what it looks like in the admin console. So you can see here, you can suspend and clear session, or you can just run these python one-liners, they're pretty simple, and pretty self-explanatory. And as I mentioned before, I learned a lot of what I learned by literally just standing up a bug crowd tenant and doing bad things to it, and seeing what it looked like in the system log, so I highly recommend you do the same. If you find anything interesting, submit it for cash.

So, at this point, I'm going to turn it over to Jason to take over and talk a little bit about Motorola's experience with Okta and security.

Jason: Hi there. So we've been a Okta customer for about nine months, 18 months, nine months in active deployment, and I wanted to share with you I guess our experience from the time we started, how we chose Okta, how we've integrated it into our company and our daily lives of our users, and then how we've integrated it into our security operations processes as well.

So, we've had the pieces that Okta gives us for a long time. Almost 20 years we've been an MFA customer and MFA user, but it was a very segmented, separate piece, it was for remote access only. We've had single sign-on for almost 15 years. Started with SiteMinder years ago, and we've moved on, but we've never had them all in one piece. All in one package that gave us an easy way to get it out. So, this is the first time we actually got to see what we really wanted all come together at the same time.

So when we started, we have two distinct groups of users. We've got internal users, who are our employees and contractors, and we've got a large population of external users as well, and we knew that we'd never get this in front of our external users first, so our first focus was employees. We can communicate with them the best, we have that opportunity to make them do something without that end-user customer focus where our business owners are a little sensitive to what we do to our outside customers.

So, one of the things that was really important to us in this whole thing was that MFA becomes part of daily life for our users, and I really do mean daily. We don't trust passwords, it's been a long time since we've been able to trust a password. So with Okta, and the ease of MFA with things like Okta Verify or Yubikey and U2F, we've really taken the friction of multifactor down quite a bit.

We started off with a lot of SWAT apps, which was a little bit painful for us. It was a way for us to get something started, get Okta in front of the user, get them used to using the chiclets on a dashboard, and we hoped be happy doing that. And that's gone pretty well. And we've really rolled out, that's about done, and now we're onto-

Jason: We've really rolled out, it's about done and now we're onto our 5000 user, external user base, just beginning that project.

This is just a bit of information on we've configured at a high level. We are active directory mastered, we do delegate it off. We hide most of our apps by default so that Chickwood dashboard isn't too crowded and we have a process for user to bring those in. As I mentioned MFA is required for every logon, so session login with Okta, every single time. We have done very little delegation to our support organization outside our active team directly, but with the lightweight that Okta is, we've been able to handle that with just a couple people. Managing Okta is a solution for our company.

We want to see our users multi-factoring often. This camera mentions some of these apps that will ask you for 30 days again, once you get a session token for the application ... still have some heartburn with that, not much you can do about it. If the app vendor doesn't support something on the net for you. But we keep a 24 idle time out that mean our users will see a reprompt usually every couple of days, they’re going to get a repromoted for their full login MFA.

Something else that we did, I think it’s important from a security perspective ... the default login processor has a user enroll and NFA in their very first login. If you have that basic credential, that username and password you're going to get in the very first time instead of the MFA. We weren't very happy with that model so we created a custom registration app that requires the user to login to our registration app first, use the phone number that is stored in our directory as a trusted storage location and we do MFA enrollment for them before they even get in for the very first time into. So we've got a trusted factor out of the box and it's a pattern that we feel has been pretty important for us downstream.

For us also, authorization has almost always been done at the app end. We've done very little authorization up at the sign on layer so this is the very first time where we've had the capability of doing this in an easy way and while ... all of our legacy apps were all authorized down at the app layer. The minute we turned Okta on we had people coming in looking for an app ... some way of authorization outside of their app. It was just the perfect timing for us.

Couple things that we do to delegate that authorization control out, again we're trying to keep up pretty light crew on Okta administration, so we do a lot of delegation and with AD groups we create a pair of AD groups for the app, and we delegate out to the app owner. That gives them the ability to add or move users from their app without coming back to the Okta team, or an operations team to do that for them. The self service provisioning workflow is pretty handy too. We make some use of that. It's good because our app owners can authorize a user in, it's bad because only the user can remove themselves from authorization again, it can remove the chiclet from their dashboard. Doesn't give the app owner that ability to do that, something we really find important. Limited use. We do some authorization just based on directory attributes, what country you're coming from, what country you're part of, what department you're part of, things like that.

This is where we got ... where things get interesting for us. We started getting to the login reporting of Okta. The Okta system logs is ... Cameron mentioned, they're pretty good. The information is there if you know how to drill it out, it can be harder to drill it out once you figure it out. Exporting can be problematic. I don't know if anyone has tried to do the exporting of system logs from Okta, just be aware, you might get a week’s worth of data out before you start seeing truncation in your CSV. There's nothing to tell you that you are truncated and the number of lines is inconsistent, just something that you should know about if you are counting a today, and Okta logs and system logs being your number one source. For us the better solution was pull them out and put them in Splunk. All of our other security apps, as many of our enterprise apps as possible, we now break their logs into Splunk. This is where we do our historical work in searching. We did that with a Tech Add-on form Splunk. It's pretty good. This is how we are going to do our broad historical searches, anything over time when we do our regressions searches for threats that we find today that we are kind of concerned about having existed for longer periods of time.

Splunk is where we do all of our automated search and alerting, we don't attribute that to anywhere else. That's how it works out for us. There's one thing we have found just to warn to anybody who does do this integration if you haven't done it yet, is that for some reason all logs don't come out of Okta in the Splunk. We're missing a couple specific event types, things that we are a little concerned about but haven't solved yet. When we know that we are looking for them we have to go back into the Okta console.

These are some of things that we actually do ... these are the specifics that were looking for in our organization for monitoring. We were looking for anybody who is accessing sensitive apps, who were not authorize into the app but the Okta layer and we've found this a couple time, and you have to ask how a user would even stumble across the login url for some of these things but it's happened. So far mostly none of the things seem to be non-malicious but nonetheless we keep watching.

We do a lot of monitoring for known bad address. We subscribe to a lot of threat feeds so we get a lot of incoming address information and other TTPs from an everseries so Splunk and Okta really work well together here. We can do a lot of things with geo. They get a very good granular geo level so we get to see user account lockouts. If I see a lockout that occurred from a geolocation that is nowhere associated with that user, we take a second action but a lot of time its right there, it’s very clear that user is in their home base, on territory and we don't have to do any escalating.

We are looking for password spring. We are seeing this against all of our SaaS tenants across the board and Okta is not an exception here but again, because we do MFA for Okta session login we feel pretty good with the results that password spring doesn't end up giving us a big problem at least at the Okta layer. Another interesting pattern to watch for is, users who activate and deactivate their factors at a frequent basis. It's just not a normal pattern and we start seeing a registered factor and  twenty minutes later unregistered and go away. It’s something you want to be looking for in your Okta logs.

We've been only nine months in active deployment, we got a lot of consuming to do. Cameron's talk is going help us a bit too, other patterns to look for. There's other things were on our roadmap to get to. We've got a behavioral analytics platform were going to start ingesting all of our Okta logs there and hopefully it will help us draw out some of those patterns. Delegated support is something we haven't done yet. We have kept it close so some of those admin events that we know we maybe have to be more concerned about the bigger support org, it means there's only a couple of us that could possibly have made those changes at this point, all to factor required so we feel okay there. Finally were going to build a custom OTP integration, kind of a scratchpad notion if you've ever used google. We've got off, backup codes you put in your wallet and something that has been hard for our users is being stuck to a phone factors. A lot of countries we don't issue phones or we can't require them to use a personal phone so that's what on our roadmap.

That's it. Thank you.

Cameron: Okay, these are the lists that I was talking about before and the cheat sheet. I want to thank Jason for coming up and talking about the stuff that they are doing because all the things that really I was talking about like exporting it into a Splunk or like some sort of sim, not only are they doing that but they are enriching it with thread intel and looking for specific patterns associated with an attacker. I'm really glad that you came up here to-

Jason: Thanks.

Cameron: ... to present and talk a little bit about what you guys are doing. I think we started a bit late but were going to open the floor for to any questions.

Sure.

Speaker 1: Is it at all possible to share with us how you guys export this?

Cameron: It's not something that I think ... you're using the API, you would think it would be part of the certification process. It should be something that's included in how can you be Okta certified if you don't know how to export the system log? I think you're right in that there is no example code anywhere that actually shows it. I have some but it wasn't approved for public released in time for this talk. I was only able to get the cheat sheet through, I’ll try to follow up in that same repo so the cheat sheet ... maybe I can push through an example code repo. Things like the code that I showed for sessions ... I'm sorry, session kill and user suspend Its pretty basic, you hit the API pinpoint. It gives you two hundred events and then it gives you the next link to hit and you just repeat. It should be pretty easy to figure out with the documentation.

Speaker 1: Right but the only issue is then that there has been various limited ... if you were to do anything with your Okta Org the user to do anything, you can't do it through Okta API...

Cameron: Anything that happen-

Speaker 2: Can you repeat the question?

Cameron: Huh?

Speaker 2: Can you repeat his question or?

Cameron: I think that jus this question was, do things that you do against the API register within the system log? And I think the answer is yes. Just because you did a ... you created a user by the API versus in the console it should still be logged in the system log, if that answers your question. On top of that, what I thought what he was originally asking was, “do you have any sample code?” but no, I'm working on it.

Anybody else?

Speaker 3: Besides the app, the obvious for office 365 you were discussing, besides account lockout policies and say MFA for the Microsoft super user accounts, any other defaults that you were particularly mentioning when you were saying about password spring and the accounts probably being compromised.

Cameron: Yes so ... do I have a list of things that are insecure by default? No, that would be a great thing to have but I'm just picking on office 365 because it gets a lot of visibility and it happens quite frequently. I'm not aware really of any others. I mean there is so many edge cases. We have thousands of apps that we integrate into the Okta and I don't have a good list of which ones have poor default configurations, but it would be a list for someone to make. Maybe we could host ... get a repo somewhere and people can contribute to it when they find things.

Speaker 3: Last question then is, why are you so adamant then that chances are you have been compromised?

Cameron: We just have been, I mean ... not compromised, I'm saying is everyone that has an office 365 ... you have been password sprayed and if you don't have MFA turned on and you allow legacy authentication protocols, I guarantee you one of your users password one, two, three is their office 365 password. I guarantee it. There's been so many stats thrown around and all the keynotes surround password reuse and 80 percent of all passwords are compromised or 90 percent of all fishing targets credentials. There's a reason why Freddy and Tod are talking about password lists and zero trusts, it's because passwords clearly don't work. That's kind of the company marketing drive and just why do I think everyone has been password sprayed? Because username is really easy to guess, emails are really easy to guess, they're ... we’re seeing these dumps of fifty, hundred, two-hundred million, accounts from all kinds of places. S3 buckets that are full of personal information just left public, so it’s not hard to find valid emails and if they're behind office 365 and you don't have modern off enforced, then they can just connect to it with an I map or a Pop 3 client, and log right in with username and pass. Hope that answers your question.

Before we move on to the next one I got a quick plug for ... these talks are recorded ... I had a really interesting lunch conversation with a guy that presented yesterday, and it was identity under attack and he ... a lot of the things I'm talking about I think he has also talking about but from a customer perspective as well so if you have the recordings maybe check those out.

Any more questions? Sure.

Speaker 4: I think if you preregister all your accounts in MFA, so I just wanted to understand that. I just wanted to understand that, does that mean when the user actually starts using the system they have to reset it for themselves?

Jason: No, so Okta released a feature actually in August or September of last year that actually lets you as an org administrator pre activate a factor for the user, a phone factor whether it's SMS or call. What we have done so far and we've built this just before they released that feature but the user has number stored in our HR directory for example and they get pushed down into active directory in other places. We use that verified phone number that we know the user has previously signed into the company to be their first MFA factor so they come to our custom tool, they log in, they do first factor with username and password it's unavoidable, initial identity. Then they can only take and complete an MFA enrollment with that number then that's in the trusted directory. The complete that registration, they are now enrolled, they go to Okta and they do a very first time an MFA login instead of enrollment process.

Speaker 4: But then they can choose their own factor-

Jason: They can add factors later, yes.

Speaker 4: Got it.

Jason: We let them register verify you to after the fact.

Speaker 4: Thank you.

Speaker 5: We need to wrap up but thank you so much to our speakers and thank you guys so much for joining us. Please remember to fill out your comment cards and turn them in at the back.

Jason: Thank you.