Building the Next Generation Network: Identity as the Perimeter

Sami Laine:  Good afternoon everybody. I'm Sami. I'm the Director of Technical Marketing for Security. I want to challenge you to think about identity as your new security perimeter today. If you look at where we've come from in the industry, we've come a long way. Organizations of different sizes, small and large enterprises all used to build data centers, set up servers and then, deploy their applications on those servers in that data center. That's changed. We're going one direction here only, which is towards the cloud. All the new applications that you're likely to build and develop today are either deployed in the cloud and infrastructure as a service or they're actually leveraging a SAS service. The user interface and the interaction point is most likely going to include mobile or in some cases, going to be mobile only as the user interface for that application. At the center of that we have our people. Now, this used to be for IT organizations, only the internal employees, maybe partners, but that's expanded now. With the digital transformation, we now have to serve constituents including customers, partners, third parties.

Now, if you look at the security aspect of this, what happened is we used to have a nice moat around our data center, filled with alligators and sharks with lasers. We had our intrusion detection, intrusion prevention, VPN, everything around it, but as we started going to the cloud, it all changed. Now, in the cloud, there is no perimeter. You have to authenticate into those services directly. This has put us in an interesting position as security professionals. This is the industry that I've come from for the last 15 years. How do you secure this in a way that is non-disruptive? What we posted here is that as the traditional perimeter is disappearing and fast, your people, the people that you're serving here are becoming the new center of this universe and the new perimeter that you can secure because all those people, they still need to, their identity, their authentication, their authorizations become that new security perimeter. You still have that chance now to look at the interactions they have with your systems and use that as your security perimeter. Why does this matter? Why is this important? It's because breaches happen.

Without being alarmist about it, if you look at the last year's data that Verizon just released for their breach investigation report, there were almost 2,000 confirmed breaches in 2016. What's interesting here is that the average cost isn't going down. Gemalto data from 2015 suggests almost 40 million dollars per breach, some other numbers that we've seen suggest even larger. The trend line here is not very comforting either. We're not getting better at this as an industry, but something happens if you look at the data a little bit closer. If you look at the actual categories on how those breaches were actually accomplished by the threat actors and you take the 2016 data that was just released and code it and say, "Which ones were related to credentials and which ones were some other technical means," you'll notice that credentials are right at the top. It's credentials again and again. Now, I want to pull up a specific number here. If you look at the thing that's at the top of a lot of the securities companies and a lot of security people's minds is vulnerabilities, new technical exploits.

I'm going to highlight the fact that there were six breaches that happened due to exploitation of a technical vulnerability and 653 through phishing. Phishing, still number two, yay, 2016. Why does phishing scams still work, why does this still work for the threat actors? Wait for it, it works because people are people. It's not that you just have a pointy-haired boss, who's falling victim for this, it's everybody who's at stake because if you look at like yesterday's news about the attack vector, utilizing a fake Google Doc invite for allowing you access to your Google environment, these actual phishing scams are getting more and more sophisticated that they're often backed up by other acts like for example phone calls going after you, prompting you to click on a specific enclosure, doing very targeted attacks. This phishing still works because there's a human factor that you can exploit and the attackers are getting pretty good at making them less obviously bad.

If you look at the breach metrics, it tells you something interesting, four out of five breaches used stolen or weak credentials. Then, at the same time, three out of the four passwords that people generate are duplicates of ones they've already used. Now that's horrible, but also in the other end, it tells us something interesting, less than 10% of the breaches leverage some kind of new technical vulnerability. If this works for the threat actors that credentials are still a fruitful tactic, it can also work in our favor because it means that that identity and access management is a very effective layer of security. Now, how can we make this better than just username and password? Well, we can do things that we saw here already today, remove the username and password for external systems and use SAML, use single sign-on into those, where passwords are replaced by PKI. Also, make sure that those systems are protected with something stronger.

My friend sent me this as a solution to weak credentials, maybe this is something that we could do. Let's just give everybody a jotter for Internet passwords and that way, they can write down all of their websites, the URL, the user name and the password into this book. Now, ironically this would improve the current state. If everybody had this, they had one physical copy in their possession with a unique password for every website, a lot of this problem would already be mitigated.

Of course, what we're talking about here today is multi-factor authentication, add something stronger to that first factor. If you look at what multi-factor means, you had something you know that username and password, the pin number, a credential, then you have something you have, a physical proof that you're in possession of some kind of a security token, could be a physical hardware token, could be Push notification to a mobile device. Then, it's the biometrics, something you are, like Touch ID on an iOS device or your facial recognition through Windows Hello. If you look at these factors, the challenge here is that deploying them has been hard. The cost of deploying multi-factor authentication has not been easy to swallow for a lot of applications because the infrastructure has been often on-prem and difficult to deploy and maintain. You had pallets of tokens with expiring dates and you were sending them back and forth to employees and partners, managing people, losing them all the time etc.

Second, it was difficult to integrate into cloud and web applications. Also, you had to usually integrate your multi-factor authentication to each application that you deployed. If you deploy 10 new applications, there's 10 new integrations to worry about. Last, the usability issue, too many prompts add complexity. It means that if you're challenged all the time when it's not really necessary, it's disruptive to the users and the user experience is not great. You also have different user populations that require something different. If we look at this from the perspective of what we should do, the recipe here for an effective multi-factor authentication starts from central deployment and configuration. If you can centrally manage your multi-factor into all of those applications and systems you need to protect and you have the flexibility to support these diverse user populations and you can give a great experience to the end user, giving them the choice on what kind of a factor they choose to use and then, give them very user friendly consumer-grade experiences on those factors that's the recipe that we can follow.

At Okta, our approach with this is the Okta Adaptive Multi-Factor Authentication. We built a robust policy framework that allows you to do just that. Set the policy for the users, the groups that they are in and the applications that you're protecting. Give the choice of comprehensive set of modern factors. You may already have invested into a multi-factor authentication tool. You may already RSA tokens, any other things out there. We want to protect that existing investment and give you a choice of the right authenticator for the right situation and I'll demo that in a second. Then, of course, you need to be able to do this risk based, understand the actual risk profile of the application and the user group, where they're coming from, what kind of situation they might be in, what device they're on. Then, last, make it so that you can integrate all those applications, both cloud based applications and on-prem applications like VPNs, so that you can have a single control point for all of this.

With that I'd like to show you a quick demo. I'm here logged in right now on a Okta portal. Eric already showed you the basic user interface and our multi-factor authentication is built right into it. Under the security tab, I can now, as an administrator, select what kind of authenticators I want to enable for my organization to begin with. Here, you see the rich set of choices that we have. I have here enabled for my organization the Okta Verify authenticator app with push notification and Touch ID support, but I've also enabled Google Authenticator, SMS authentication and U2F Security Key. Now, this is just basic underlying tools that I've now turned on, but then I can more importantly say for each one of these, where should these be used and under what conditions. I can set the policies for the different user groups.

We already mentioned earlier that you have the group's structure and you can logically group your users. I, for example, here have a group called Administrators. All the system administrators in my organization are required to use strong authentication. For them, I'm supporting Okta Verify with Push and I also support Google Authenticator and a physical security key that's U2F compliant. You notice that I've disabled SMS authentication for them, not just because yesterday's news showed the first in the wild SMS attack in Germany now publicly acknowledged, where the SMS infrastructure was compromised by basically a malicious actor in a telecom somewhere, intercepting SMS authenticators and taking money from bank accounts.

SMS remains a useful tool, better than username and password, but I may not want to allow it for every use case and for every user profile and risk profile. Here, I've disabled it for my administrators. I can also select where can they actually even enroll into this multi-factor authentication. My administrators can only do it while they're in the corporate office, in zone and not when they're working remotely. I can control that through my network settings. Whereas for example, for my sales professionals, I'm allowing them to use the Okta Verify with Push, but also enabling the SMS authentication because in some locales, in some countries and regions, it's just easier if you're dealing with that and allowing the SMS to be also available to them. For these users, I allow them to enroll into the system anywhere. I want to show you what that looks like. Why don't I log in here as one of my sales reps, so I'm going to log out of my administrator account and login as Beth Davis. Let's put in Beth's password and sign in. Beth was allowed to authenticate into the Okta portal without two-factor authentication. In my policy, I don't require that for the in-network users and I've defined this particular network here to be in-network for me.

Then, there are some applications, where I do want to make sure that it's really her. For example, I have all my pricing information and collateral information that is internal on my Box account, so I set up a policy that says when you go into Box, I want to make sure that that's done with multi-factor authentication. Now, Beth hasn't done that yet, so we'll see here if we could actually get an enrollment experience going. When I click on Box, it notifies Beth to say, "Hey, now it's time to set up your multi-factor authentication." Beth can have a choice here of Okta Verify and SMS authentication, let's set up the Okta Verify. I select the device type and let's go with the iOS here. Download Okta Verify from the App Store on to your mobile device. I've done that here and I have here an iPhone with the Okta Verify already installed. 

The next step is really just go through that enrollment. It shows you a QR code. When I open Okta Verify and provide my Touch ID and add an account, all I have to do is point that to the QR code and it actually goes and successfully enrolls me with Push notification. I see it there on the screen and now, I'm ready to do that first Push notification. When I send a Push, I see where this user is coming from. I see that we're here in New York, New York, coming in from a Chrome browser and I approve that transaction and I should be logged in.

Now, the authentication is verified in the back end and then, we're sent off to a Box login and I am signed into Box. This shows you how you can do enrollment on the fly. You don't have to force all your users to a specific path. You can meter out by user group and by business application. This gives you a quick insight into how that's done. Then, for the actors, like your administrators, if the administrator logs back in, if I go back in as an administrator, in this case, Sami and I'll provide my password here, then I will be forced to do a strong authentication to get into the portal because I have too much privileges there. I want to protect that access. As an administrator, I've enrolled here actually on this device into a couple of things. I have the Okta Verify with Push and I have a Google Authenticator and looks like my reflector may not be working, so let's see if I can go back and turn that off. Sometimes, the mirroring here is a little bit tricky. Anyway, the mirroring doesn't seem to work, but I can do it here and simply do a Push notification, here we go and I can approve that transaction right here. I've already authenticated this device with Touch ID and I can simply swipe down and say, "Approve." Same thing works on the Apple Watch etc.

This gives me really great flexibility in accessing these applications, provides me with a way of doing a more controlled, sensitive, risk-based authentication policy. What you saw there is me setting up the policy through a policy framework and if you look at that the idea was that you can do it based on the IP zones, where I'm in, on-premise, off-premise. Based on geo-location. I can do country based listing, state-level listing. I can do this based on the group that that user belongs to, their physical location done to geo-location of the device. Based on the device recognition, if we're enrolled into some kind of device management system and of course, per application because different applications have different sensitivity.

Then, you have the comprehensive set of modern factors. I enabled here several of them and you can protect your existing investments and use the right tool for the right choice. Then, lastly do it risk-based where the context matters and you're authenticating into the application, setting up the access, allow, step up, deny or even restrict scope if your application allows that. Now that's the quick demo and a theory. What I want to do next is bring up one of our customers, who's gone through this experience, rolling out and talks about the business aspects of it. With that come on up Joe.