Exploring the Past, Present and Future of Identity and Security

Announcer:  ... of identity, Karl McGuinness.

Karl McGuinness:  All right, last session. Hi, I'm Karl McGuinness, senior director of identity here at Okta. What I wanted to do is explore a little bit of the themes that we talked about today and sort of give a little hint at how we see the industry moving forward with identity and security. But before I do that, I want to take a step back and look at, as an industry, how we got here.

So a lot of us have spent years deploying a single source of truth in our environments for identity and call it active directory, right? We spent years aggregating all of the different identity stores under a central sort of LDAP-like directory; got a lot of advantages having a centralized directory. And if you can tell even just by the name of the MMC console, "Active Directory Users and Computers," it was a time when the amount of entities inside of our identity systems was finite; it was like one computer per person maximum, right? We didn't even have mobile phones or devices yet. And for authentication, we adopted a next-generation brokered authentication model with Kerberos that was really, at the time, next-generation at being able to solve a lot of the challenges of direct authentication, but it was still kind of tightly coupled to the on-prem environments.

When web applications first came on our networks, we were left with a challenge of how do we manage access to all these different web applications that weren't natively integrated into the Windows environments like our desktop applications were. Oh, back one. So we deployed web application access management technologies to give us a plane of control over access to those web applications. 

When we first started seeing devices in our organization, the only application at the time was mail. We didn't have app stores and the web browser WAP experience was very limiting, to say the least. And so what we ended up doing was building a perimeter-based security model for managing access to our resources. And so we tend to say that the DMZ was the perimeter; it was very much a hard out shell, and once you got past the perimeter, you were able to have free access to resources behind it, and it was sort of a full trust model where you trust everything that comes behind the firewall. 

And so as we talked about this morning with CIOs, the world is changing from a world where single vendor, single ecosystem to a world of multiple devices, multiple user types, where software is eating the world; where we're trying to figure out how to have technology help us be business enablers. And in this new world, we've managed to move our data centers from on-prem or colo to more cloud-based services, whether that's infrastructure as a service, platform as a service, or software as a service. And these applications are different in nature. They're much more dynamic and public; always available, always accessible via the Internet. They're not just behind a VPN. And these resources, as we deploy them, we have to start thinking about how do we secure access to resources where that IP address may not be the same IP address the next time I boot the VM, and my perimeter starts becoming much more challenging to manage access to.

And these identity systems aren't just looking at employee identity in a single type of credential, a name and password. We have to start connecting our partners, our contractors, our employees to multiple different kinds of identity providers, whether that's your partner's organization identity system, or a social identity provider to quickly onboard a user, or even in a global environment, even potentially national identity-based systems. And so we need a single identity system that allows us to onboard every one of these identity types and connect to many different types of technologies. And as Keith talked about earlier today, we're seeing new use cases. It's not just browser-based applications; we're now living in a world of connected devices with an API-based economy. Whether it's smart devices or smart phones, the types of applications running are no longer just browser-based applications that we can protect with a web access management technology. 

And what we're seeing is mobile's becoming the center of identity. Whether it's payments, authentication, the mobile phone is now becoming how we interact on the online world, and with that comes the consumerization of IT. An example here is actually we have a pretty cool solution at the Okta office where if I just want to get access to a new power cord or a new mouse device, I don't even need to engage procurement. I just go to the machine, type in the code, and I get my power cable. That's the type of self-service that customers are starting to expect, whether it's from our applications to our devices. 

And the challenge with consumerization in IT, obviously, is shadow IT. And when we survey our networks, we see that ten times as much SAS is in usage than we originally thought, and it's everywhere. And with the challenge of the proliferation of SAS obviously comes data leakage. 

So we say identity is now the new perimeter and a good example of this, a company that's done a really good job at trying to crystallize a lot of current thinking around this, is Google with their BeyondCorp initiative. And what they've done over the years is started moving to a model where they assume that the internal network is as dangerous as the Internet. There is no longer VPN in, free reign; it's moved to a zero trust model where we're always verifying and validating across every type of transaction. And so there is no longer preferential treatment given to sort of "intranet" access. 

So what does this look like in a modern enterprise? Well, we have multiple devices coming from multiple different user types, all connected to an identity system where we can look at authentication, how the users authenticate, step user authentication up. What we also know, as we learned in the previous session with Francis, we also can look at the devices and understand the posture of the devices. And given a combination of the device and the user authentication, we can give access to a resource. And whether it's a cloud-based resource or through an access gateway to a on-prem resource, we can remove the need for that VPN and base access based on the risk factors, and we're gonna talk about that in a minute. 

So there's four key ingredients to sort of move to more of this perimeter-less model; we need to have a model of Attribute Attestation Governance, Continuous Authentication, risk-based Dynamic Access Control, and Shared Signals. 

So I want to talk first about attestation and governance. So Aaron talked a bit about universal directory and how we're able to pull multiple attributes from multiple authorities, and so we call those attribute authorities, and for employee identity, being able to source multiple attributes from a system of record and have a view across it is a very powerful concept. But it's not just user identity; we need to be able to have authorities for device identity. And so whether that's Okta or another MDM provider, it's very important to understand when was the device enrolled, is it currently enrolled, does the device have encryption capabilities to protect data at rest?

And it's not just devices and user data, it's actually how users authenticate themselves; the types of factors that they're using for authentication are increasingly becoming attribute-driven. So if I authenticate with a TPM-based hardware security module, it's much different than a software-based module in the sense that I can't extract the secret, I can't replay the secret. 

So what we say is sort of attributes have facts. There's providence about the attributes. It's not just a matter of, "Hey, the username is X" or "Yes, the device is there." I want to know a little bit more about those attributes. I want to know the last time I checked that attribute. For that HR example we just saw, it's no good if the last time I checked the HR system was 30 days ago, right? There's a certain guarantee as you query the HR system that the employee status is up to date. The same goes with being enrolled into device management.

And with that comes a challenge of determining which attribute facts are important for which scenarios, and when do I need to pull those attributes in real-time versus keep them distributed. And what we're seeing is sort of a rehashing of the constant challenge of moving to centralize and decentralize models. If I pull all those attributes to a centralized source, I assume a lot more liability, and if I decentralize it across multiple systems, maybe I don't have as much liability but I have not much real-time or voracity to that attribute because it might be cached or delayed.

And what we're seeing is it's sort of a next-generation technology stack being introduced in different environments to take a look at these problems from a new perspective. You may hear these technologies as block chains or distributed ledgers, but the challenge is how do we support both distributed and centralized models and have the providence and the attribution about attributes so that we can make informed decisions to give conditional access? 

And it's not just about distributing the data; it's also the governance of the data. Different users have different claims on the data, so you can think, for example, in an IOT scenario where just because I'm using a device doesn't necessarily mean I'm the owner of the device, and maybe the owner of the device isn't the manufacturer of the device. The device is constantly sampling data, so how do I determine which policy applies in which context for which user? So when do I encrypt the data, when do I share the data, when do I hide the data? These all become challenges in a connected model, and so the identity systems aren't just about looking at the attribute attestation, but it's being able to look at the relationships between the users and building governance around that. And that's very much a next-generation identity system.

And we're seeing challenges to the model even put forth by more modern regulation. If you guys are global companies, you're knowing that this year is the year of GDPR, where everyone's looking at and revisiting some of their data governance challenges. And so the right to be forgotten, for example, is a new compliance; obviously we have our own here in the states, but looking at our identity systems now causes not just to be that active directory where I have a user and an LDAP database, but where is all that metadata? How can I leverage that into my systems? And that's sort of how we want to start thinking going forward. 

So we talked a bit about attributes and governance. I want to talk now about continuous authentication. So assurance, right? How sure am I that you are who you say you are? So if I authenticate you now, are you the same person if I authenticate you tomorrow? And so the common scenario is I come in in the morning, I sign into my device, and then I go get a cup of coffee. We say assurance decreases over time because I'm not necessarily guaranteed to still be at that keyboard; someone else could be. So my assurance decreased from when I first sampled you. And our assurance, back to our different user personas, isn't the same for every user type. Whether the user was identity-proofed in person, whether I came in with a passport or a government-issued credential, or whether I self-enrolled via self-enrollment flow are two different examples of assurance of a type of user about how they were proofed. And then there's not only how the user was proofed, but it was a bit about how I authenticated; did I come with an OTP or a credential? 

And what we need is, we need a much more modular way, an identity system to match the type of risk, the type of challenge with a type of assurance. And so there's been a lot of great work, as I'm sure being here in DC with NIST to sort of rethink some of the ways in which we model some of these problems. Instead of having sort of LOA one through four and try to shoehorn into a single model, we can start looking at maybe my identity assurance needs to be very different than my authentication assurance, which may need to be very different than my federal assurance works. And I can build a model where maybe I can have low identity assurance with high authentication assurance, because for my remote contractor or my self-service employee, that's the right model for the use case. 

And this gets to sort of the core security challenge, right? It's always been security and usability. So obviously everyone's deployed Windows in the past and sort of seen many attempts in the industry to try to balance these factors and not always quite get it right. And we've been sort of trying to get to this promised land of strong authentication for a long time, but we've always had to suffer usability, deployability, and security. And the real problem is that killing the password actually is much harder than we think. They're very cheap; they've very cheap to replace, they're very cheap to re-issue, users are already trained how to use them, and it works across every single application that has a name, password dialogue box. Rebuilding every single application that's been deployed in your environments to support a new authentication architecture is quite a challenge, so the passwords have been here for quite awhile and they'll be there for awhile.

But with the smartphone being the center of gravity for identity, there's a new model becoming emergent as sort of the gold standard, and that's being able to leverage years of PKI but done in sort of a more modern fashion. So what we do is we take an authenticator, such as a smartphone, and we register a certificate with the online server and we store that certificate locally on the hardware on the device so it can't be extracted. And then that device then can protect that certificate with biometrics such as touch ID or any of the other picture type passwords. And so local authentication to the device keeps the biometrics locally; we don't have to worry about someone hacking the cloud and getting access to your biometrics. And then from the device to the cloud, we can leverage sort of tried and true principles of public key cryptography to get really strong authentication, and we can deliver that in a very consumer experience.

And that's sort of what you see going on with the Fido alliance, is trying to move that needle of security/usability to no longer being a false trade-off; how can we be able to deliver that for any type of user. And we're seeing massive deployments of these technologies from Google to Microsoft.

Although we have strong authentication, we still want to be able to get stronger assurance, and so to be able to come back to the assurance question, we want to be able to not just think about authentication as a single event in the day, but think about authentication as something we do all the time. So we need to move to more of a continuous authentication model. 

So your user paired to a device that's paired to the server then has access to a bunch of different signals and sensors connected to that device, whether it's geo-lo, facial, a proximity, voice, heartbeat, connected devices, watched. You're constantly able to give a present test to the device, so that scenario where I walked away for coffee, the device now knows that, right? And if I'm still sitting next to it, it knows I'm still there and it's able to keep that assurance high. And what we can do then is move that needle from low assurance to higher assurance by being able to measure more accurately authentication, and more passively as well; I don't need to actively pull my phone out and do a 2FA sort of OTP dance. I can be able to just be present and it should know me, right? And that's sort of what consumers are expecting and being trained to do as they interact with new consumer experiences. 

But with sort of this continuous authentication model, it reintroduces some tried and true problem statements. If I'm always signed in, then if I get access to that token or that cookie, I can replay it, right? And that gives me man-in-the-middle and that defeats the whole purpose. So continuous authentication helps with the assurance problem, but we still have some other challenges left to address. So how do we make sure that these tokens can't be replayed? TLS vulnerabilities, everybody's seen sort of from Heartbleed to breach attacks, how easy it is to potentially man-in-the-middle the devices, so we don't want to build the next-generation model just on the fact that it's very easy to man-in-the-middle. 

So what we want to be able to do is how can we lock those tokens to those devices? And so our friends at Google and Microsoft and in the industry are about to sort of up-level the playing field where we can finally now have the technology to lock those tokens into that unique device to server relationship, so if I take the token off the device and try to put it on another device, it won't work. And so now we can have much longer assurance on the physical properties of being able to store those long-term sessions on those devices.

But we still got one last challenge, right? If I'm always signed in on these different devices constantly doing presence tests and knowing proximity, how do I do revocation, right? How do I revoke a user across all the different devices that I'm signed into, whether it's my Apple TV or connected devices in my house, whether from an employee perspective, all the different devices I've paired to different SAS accounts. When the security event happens, whether it's account takeover or termination, how do I do revocation, right? And so we go back to that distributed challenge. It's probably not feasible for every device to pull and synchronize state globally at the same time, lots of new open opportunities to apply new technologies, this coming back to the discussion a little bit about block chains and distributed ledgers, this is why you hear a lot of talking about these new technologies stacks, is can we sort of build a new infrastructure that can think about interacting with state and synchronizing on state across multiple different devices? So this will be something to watch out for.

So cool, we got attributes that have rich facts and attestation, we have a model where we're able to have higher assurance, keep users signed in with lower friction. Now let's combine that for a dynamic access control; different risk profiles for our different user types. If I'm signed in from my house and I'm categorized as a remote worker, and I'm always working from my same PC, from my same house every day, why doesn't the system know that? Why am I treated as sort of a foreign security event? Versus, you know, I take that dream vacation and I finally get there and I try to unfortunately check my email. That's sort of something where maybe I would be able to accept that risk profile as being something would require me to take action. Or there's that high value transaction that I don't normally do. You definitely want to spot that, and you definitely want to know when it's a Chinese Bitcoin attack happening, because that's definitely going to cut through some serious layers of defense. 

So what we see is that today's world needs more real-time identity intelligence. We're no longer just dealing with the same threat models that we dealt with for the last ten years behind our static firewalls. The constantly changing environments, applications, and threats are sort of Internet-scale problems. What we want ... There's scalable attack vectors; I can spin up thousands of compute farms on Amazon GPUs and leverage the compute power to do password cracking at a scale we've never seen before. Every day it just gets easier and easier to crack passwords, or to do attacks, botnet attacks or whatnot. And so humans aren't really well-adapted for this problem. We need to be able to leverage a new system that's more automated. 

And what we're trying to do is move the access control decision from that traditional sort of allow/deny/maybe set-up to that question of "maybe"; maybe based on context. What's the context of the transaction? What's the authentication factors? What's the device conditional context? What are the attribute facts? You can see now how the strong authentication attributes mixed in with the identity attributes give us much more context to make this decision with. So we call that more of a contextual aware or context access management scenario, where the identity, the applications the user's connecting to, the time of day, geo-lo, the protocols, the user activity can all go into sort of a more of a real-time learning system and it'll adapt a policy that's able to make that decision that maybe that is a set-up action or maybe that's an allow action, and we can sort of build a profile around the user on behavior.

And that gets us to that sort of automated learning or machine learning type models that's becoming much more common with the open source and cloud models of compute that's making democratizing a lot of this technology, as the data and activities being spread across all these SAS applications. When you're able to have identity systems like Okta in the middle, we're able to leverage all of our multi-tendency to be able to detect signals across multiple tenants to help feed some of these learning cycles as well as train for your individual users. And that really provides an intelligent layer to respond to some of these Internet threats.

And what we're trying to be able to eventually solve is how do I give access to the right people, to the right things, for the shortest time possible? That shortest time possible is sort of the challenge we've never really gotten to. We've been able to have attestation, and governance, and classic identity systems where we do 30 day, 90 day reports; we see the deltas and we try to reconcile them. But that's because we're giving people access longer than they necessarily need. How can we give people access at the transaction level, to something maybe at the minute level, or even the hour level, and then have the system automatically revoke that access as soon as that transaction's over? 

So we kind of over-provisioned access and have suffered the consequences from it. We've all suffered this on our sort of system administrator side of the house with Windows account privileges and things like that, and we've kinda been moving over the years for our admins to move to more of a pseudo or sort of set-up model where I only set-up for the admin action I'm trying to do, so I don't have access when I don't need it.

So let's walk through a scenario combining a couple of these things we've been talking about. So this is sort of a share scenario where I have a document that I want to share. I want to potentially share it with my partners, and they may have their own identity providers, or I might want to share it with customers logging in with a social identity provider. And now depending on the type of content that I'm trying to share and the risks that I'm willing to allocate to that type of content, I'm gonna want to be able to make a decision based on Device Attestation, Authentication Assurance, Identity Attribute Facts and Identity Intelligence. So for example, I want the device to have to have local encryption to be able access this document, I want to make sure that the authentication assurance came from a hardware-based module, I want to make sure that the user was enrolled and has a present identity that's been verified by an employer, and I definitely want to make sure that they haven't been going around trying to download a bunch of documents they've never downloaded because that's potentially a signal that they're doing data leakage. And that's example of a policy I just wanted to make for a particular user type, so I need to combine multiple parts of these together to sort of deliver on that, and then I can finally get to my more modular access model. 

And what's cool is, is that it doesn't just end there. We can reach back out to the end user and help train the model. So if we detect that maybe it's not quite right, maybe we can reach out to the user now with that connected mobile device and ask them the question, "Hey, do you really want to approve this request?" Or maybe to your manager, do they need to approve the request? And so the policy can kind of be updated in real-time and doesn't necessarily need to go back to that sort of static, open and file ticket; we can build the risk tolerance into that and allow set-up on the transaction, which will be really cool when we're able to do that. And that is all powered by the fact that we have connected devices all connected to our identity systems and we have the identity. 

So we covered attribute attestation, continuous authentication, combined those into a risk-based model, and the last part I want to close on is a little bit about talking about shared signals. So the key challenge in identity systems is really the account recovery channel; it's the weakest link, right? We say it's the double black diamond almost of authentication systems, is how do I recover, right? I lose my phone, I lose my password, how do I step back and then how do I recover from there? And there's been high profile attacks all taking advantage of the fact that the recovery chain is very hard and very weak. 

So looking at an example of the recovery chain, traditional recovery dialogue: "Hey, I want to reset my password. I want to send it to SMS or I want to send it to email." If I send it to email, I got a bunch of different email providers, some good, some bad. Some old school, some more modern. If I send it to SMS or a voice-based recovery, hey, maybe all I have to think about is my telecoms and maybe I just have to rationalize the security profile of my telecoms. It doesn't just stop there; we're in a VOIP IP-based world, so SMS and voice is no longer just tied to the phone. You can get your iMessage or Google Voice or WhatsApp, all those same text messages that you were thinking were only locked to your telecom provider now are any connected device that the user has ever also associated to the problem.

And then you go back a layer from there. How do I recover my email provider, my mobile phone operator, and my VOIP? I just have to get ahold of some service desk agent and convince them that I'm the user, back to identity-proofing, back to the same challenges, and if I can convince them that I'm the user, they will just port the number or reset the account for me because I don't have any other way of verifying my identity, right? And so this creates the challenge of the chain of recovery, is that there's no way to connect these different parts of the systems into a recovery flow.

And we still have those leftover accounts from years ago on our secondary email providers, that when we've changed the email from college, we probably still have accounts that's lingering around with. And it's even more complex in the fact that I may have authorized applications' access to my data that I've totally forgot about. So that sort of Facebook model where you give an app access on your behalf, that app now can go in and potentially even read your email if you gave it access to do that permission. So all of these sort of app economy kind of problem statements come into effect.

So what we need is more of a model where the identity providers and the identity systems can share security events with other parties in the chain, and they can respond to be able to deliver the scenario. So back to our reset model, I go to my identity provider and I kicked off that password reset flow. It's gonna send the email that you've all done to your email provider. Now I'm gonna click on that email provider and get my email; I'm gonna then do my password reset at the identity provider. But now the identity provider's gonna send a signal back to the email provider that hey, the user just did an account reset, and now the email provider now is a smart email provider that gives modern applications access to it over APIs and not just over traditional mail protocols.

So on the right here, I have a sort of next-generation smart application that's connected to my email application, say over like an OAuth type flow. So it knows all the different applications that it's connected to, and so it's able to relay that event back down to those applications and then be able to, for example, kill my account on those different devices. So that helps stop that lateral movement of an attacker being able to find one part of the chain, go down the chain, and be able to get into the system. 

And so that requires a lot of coordination behind identity providers and applications; being able to share information on the Internet about security events. So we're no longer operating in a silo mode across industry partners on how security is happening. We can't just take on that challenge on an individual vendor by vendor basis. We realize it's a network problem and we need to be able to share these types of events, obviously honoring PII and privacy, but this becomes another layer of the problem where you see identity going to handle those next-generation threats.

So to summarize the future of identity and security: It's a single identity system that connects not just your users and computers, but all of the different personas in your organization, internal, external, across all their devices' services and even going forward to their things. It's attributes that have authority, context, and attestation; I know a lot more about how I arrived at that data, how I trusted that data, when I want to trust that data, and then just the fact that it's in the database. It's continuous authentication that is both usable and deployable and adopted by our end users, giving us the ability to have higher assurance that the end user is who they say they are. And combining that into a dynamic access control model where it's based on the type of risk of the types of transactions we're trying to secure, so we're no longer forcing users to go through unnecessary security ceremonies to get access to low sensitivity resources, and they understand why potentially they're being asked to do a ceremony to get access to a high value resource. And then finally, we can break down the boundaries between the vendors at the Internet scale to be able to share security events and be able to respond more intelligently when a security event happens, such as a breach or account takeover. 

So that's the future where we see sort of more a longer term where identity and security's going. Thank you guys for coming out today, and we're gonna be all back at the reception and we hope to see you there. Thank you.