Hey everybody. I'm Alexei whitener. I'm a, a director of identity security at Microsoft. And I wanna talk a little bit about how we're seeing trends in identity attacks, that kind of mandate a new way of thinking about how identity systems work together. And we're gonna talk about some specifics and how that happens. And I wanna start off with a story and it's a kind of a, you know, like gentle story. It's a typical organization. And you know, they're thinking about identity driven, zero trust, and they're, you know, focused on collaboration, productivity, and their organization, lots of people working together and lots of people working together with lots of different resources, right? Some of those things are sad. Some of those are deployed in, you know, like VMs in clouds like AWS or Azure, some are inside and owned and developed by the company. And some are, you know, external companies, right?
Pretty typical. And because all things that are important require collaboration, right? Collaboration is important for big tasks. This company collaborates, right. They collaborate with partners with vendors, they have subsidiaries. And of course, to collaborate effectively, they have to get access to each other's resources and to get access to each other's resource involves, you know, having some policies. Right? And so I have a policy about what a secure device is in my organization. And you have a policy about what multifactor off means to you. And to some level we trust those policies between the organizations, right? And we also have things about, okay, this is my expectations. Some things we can enforce, some things we take on trust. So this is a really typical environment, right? Like lots of people working together, lots of users, lots of policies, lots of different apps, lots of relationships. This looks like most organizations, right? It looks a, probably a lot like some of your organizations, it looks almost exactly like mine.
And this particular organization is invested in zero trust and it has pretty strict policies, right? It has a strict policy for device compliance to access corporate resources. It has strict policies around having endpoint protection on every machine. It has strict policies around multifactor off required to do things, right? So it looks pretty good, but there are some things that are happening in this organization, even though it's maintaining a fairly high bar for security that, you know, create some cracks in the story, some employees can run as admin on their machine crack. Some employees can use simple approval. So, you know, your phone rings, you press one you're approved, right? And some teams can add memberships to groups that have pretty broad implications. So another crack. And so, you know, for many of you, this might look pretty good. You say, well, those are minor problems.
Considering that, you know, as an earlier presentation was noting that, you know, 23% of users are using MFA globally. Right. You know, if you're just worried about what kind of MFA, that's maybe better than the average bear, but in our story, these simple issues play out in some pretty unfortunate ways. And what happens is a user in a subsidiary, on a device is running as admin, right? And so that's our first crack. And they click on a link. You're always one link away from malware and they get system level malware on the machine. And that system mal level malware is a token Steeler. And the token Steeler does what token Steelers do. And it takes the token off the device, right? So now the adversary has the access, you know, to pretend like they're that user now for what they wanted to do, which was download a bunch of content.
They needed more than just the token. They needed to be able to download content onto their own machine, which because of device registration policies would mean registering a device. And that required MFA. So crack number two appears, right? Simple approvals, pick up the phone, press one to approve, right? So in our, or in this case, a pin, so the user's registered for simple approvals and the attacker starts pelting the person who's token, they had stolen with MFA requests. Now just imagine this it's you, it's one in the morning, you're tired, right? Long day kids having trouble in school, maybe I'm projecting and you know, you're tired and somebody starts calling you over and over and over again. How long does it take before? You're like, fine, go away. Stop calling me. Right? So this user cracked and eventually approve the MFA request. Now these attacks are common.
And what we've found in our studies is that one in a hundred users will approve a simple MFA request unprompted on the first try, right? So we can maybe at least be compassionate towards the person that did it. Okay. So once this user caves in the attacker's able to register their own device, they have access to the network, right? To the corporate resources. They start looking for things to download and mostly lease privilege, access holds up. But there's our third crack, right? There's an organization or a team that has added a very broad membership group to their permissions list for the resources they control. They're not running access reviews, right? The government's governance, isn't where it ought to be. That's our third crack. And as a result, right, we get a bunch of source code downloaded and bragged about on telegram. Now this of course is absolutely nothing to do with the story of what lapses did at Microsoft, right?
But we're, you know, we're pretty sympathetic, right? Typical organization. So that was one token theft. One in the last six months, our team has detected over 150,000 stolen tokens and you know, the millions and millions of customers that we take care of. And when you think about the malware that steals those tokens, we've detected over 1.7 million malware infections, right? So this is pretty staggering. When you think about what that implies for our industry, like we've gotten from a place where, you know, the normal, Hey, I stole your password. I did a password spray. So I had an MFA while that didn't help here. Right? So if we think back a little while to the heady days of Christmas, a couple years ago, right? We saw these major attacks by nation state actors. And at the time everything seemed super innovative and cool. But the fact is that many of the techniques that are in this attack, things like going after the supply chain, things like going after application infrastructure, stealing tokens have now become commonplace.
And that itself should be no real surprise, right? Because attackers can publish new techniques in public repos like GitHub and the same tools of exactly can be picked up by other people. Now, usually it's good people doing good collaboration, right? People are generally good. But once in a while, you'll get a 16 year old kid in his mom's basement in Oxford who's downloading tools, executing attacks, becoming an international criminal, bragging about it on telegram and then going to jail. Right. Sad story of a, you know, a young life wasted. Right. Okay. So this is our new reality, right? This is the new canvas. Things are moving fast. So we've talked a lot about the principles of zero trust two years ago, kind of talked about that. Verifying every request, asserting least privileged access, assuming breach. And we did a bunch of updates to our architecture.
And the main thing here is to understand that we wanna have a flywheel that takes the security outputs of the system and puts them back into policy decision making. And that we wanna take the, the experience outputs of the system and put them back into policy decision making so that we get a positive spin here. And when we looked across all the different organizations, we support in zero trust and we looked at who was successful, right. We found that the most successful organizations had these kind of key characteristics, right. They were very focused on user experience. They were very focused on covering the entire estate, not just users, so getting all the way out to it and OT, right. They looked across the intelligence sources. They had, they were focused on governance to make sure they were working on clean data. And they were focused on automation as a way to reduce the burden on the security personnel and the identity personnel that they had. All right. So general talk. Siemens did an awesome talk earlier, and I'm really delighted to invite Thomas Mueller up on stage to do a little bit of a recap and talk about some of the stuff that they had talked about in their talk earlier on today and apply this a little bit more into reality, Thomas.
Thanks. Thanks. Thanks for having me here.
I mean, we already had a talk earlier today around the seal trust story, but let me, let me quickly summarize. So when implementing zero trust at Siemens, and if you would ask me some recommendations, what would be the three major parts, which I would like to share with you? First of all, I mean, we extended as our implementation activities, the scope, not only on it, we extended to OT and the requirements and the, the, the, yeah. The situation on the OT is completely different than in it. So be mindful of the differences, also similarities on in it and OT, if you want to implement zero trust there. Second, I mean, at Siemens, we have a variety of applications of platforms, which we need to support. So platforms on the one hand it's, it's our end user base. It's our developers, it's our Linux users, etcetera, but also the application landscape is quite different.
So we have modern web application. We have lots of legacy stuff as well. So also here, if you wanna protect your trust or wanna protect all of that with zero trust, that might be not a one that fits all solution, which, which might be applied. And last, I mean, we heard that a lot, quite a lot of time, SOS trust, that's a journey. You cannot just buy a product, even though from Microsoft to, to, to just license something, roll it out. And then you're done with my, with, with zero trust. So it will take some while we started early with MFA for everyone disabling legacy protocols and things like this, but yeah, there's still a way to go.
So we've worked together for a long time on zero trust. And on that, on that journey, where are the places that you're, you're kind of getting stuck? Like we've talked about this before, you know, things that it's hard for Siemens to solve on their own without some, yeah.
I mean, as every company, I guess, on the planet. So, so malware protection is, is key, but malware protection is not always perfect. So we need to identify, or we need to see how we can ensure that talking theft is, is prohibited or is at least does not, doesn't get breached. So that's one of the key things, what we are currently looking at, and we're still, there's some open gaps, I would say second. I mean, we always call it to get near realtime security. So in the past we have done lots of stuff in the, I would call it forensic security. So push lots of locks somewhere and do some forensic analysis now more and more, we come into the situation that we want to identify immediately and also have the immediate remediation afterwards. So here, we still also see some gaps to go to go into that area. And second, I mean, it, Siemens, we have lots of systems, every bigger vendor, I guess, here on the planet in the it department has sold some licenses to Siemens, lots of systems, and we need to bring them together. Right. So to really, to get the full power out of all of those, those signals last, but the least, I mean, a mechanism of, of verification and, and as a identification, Exxon sources. So looking into the area of decentralized entities and things like this.
Awesome. Yeah. All right. Thank you, sir. Appreciate it. Yeah. All right.
All right. So we have some homework to do, right? For those of us who are building identity systems, there are some things that I think it's, you know, it's reasonable to expect that we need to lean into and help out a bunch. And so I'm gonna kind of bring this around to, well, I think it's the central thesis here, right? Is that a, a fire and forget, introduce, and get outta the way identity infrastructure is not enough anymore to secure against the kinds of attacks we're dealing with right now, right? That the future of identity security in a world where the majority of breaches are identity breaches, the future of identity security is all about teaching our systems to be more effective at communicating with each other in ways that increase the security of the fabric. Right. So, and that's gonna mean that we have to collaborate too, right.
So I'm gonna talk about three things that we can do to help out with this. Right. We're gonna talk about demonstrated proof of possession. We're gonna talk about the shared signals and event framework, and we're gonna talk about yes. Verifiable credentials on her. It's okay. All right. So, so going on from there just very quickly, you're gonna touch on these three things, but I think they're important for us to be paying attention to as, as implementers of identity systems, as vendors and as standards as people. So for demonstrated proof of possession, the basic idea here is that we need to counter these attacks. And the way that we want to think about doing that is if we could find a way to gr cryptographically sign the request to the relying party. So you could tell for sure whether the token had been moved from machine one to machine two.
And so for that, we need a P pair in hardware, and then we give the public key to the IDP and the IDP communicates that to the relying party. So it can validate nuances from the app, from the client, right? So this is an amazing thing for us to make it much, much harder and raise the bar substantially on token theft. And again, this is an attack that is going wild right now. Like we're seeing more and more token theft. The second thing you know, is that we wanna talk about the shared signals and events framework, right? So the second thing to talk about is this, and what this is doing is saying, okay, all these scary things are happening, right? So with token theft and token binding, it's gonna be a while, like all things standards, you know, adoption is a thing and it takes a while to roll out.
So in the meantime we do detection, we can detect a stolen token. What do we do about communicating back and forth so that that stolen token can be stopped and we minimize the damage, right? And so that's where the shared signals and events framework specification comes in. It lets us talk about the scary things between the systems. There's two basic flavors, right? There's risk, which allows us to talk from IDP to IDP. So, you know, you're, you are using email as a proof on your account. I can tell you that that email account was hacked, right? So that's a super valuable use for risk Cape, lets us talk within the Federation environment in a way that we can pass information around that says things like, Hey, the IP address that this user was last seen on has changed. I can tell you that as a relying party, the IDP then can reevaluate policy, evaluate risk.
Look at the fact that maybe that IP address is being used by a threat actor, and then tell you, Hey, you should revoke that token or you should stop respecting that token. So we get real time revocation. So we move from a world where we're waiting an hour to see how much I can download in that hour to a world where we get nearly instant communication between the parties. And we can start doing that. Now we've started experimenting with this kind of pattern at Microsoft. So we're doing this like between SharePoint and defender endpoint. So somebody steals the token, you know, on your device. We can pick that activity up in the malware, notify the IDP, the IDP. You can then tell SharePoint, Hey, turn off the session. That's an infected machine, right? That kind of stuff is where we need to go. Right. That kind of realtime communication is where we wanna be going Cape and risk.
Give us a framework for doing that in the shared signals and events framework. So the last thing I'm gonna talk about cuz anchors here and I have to is decentralized identity, right? And specifically around verifiable credentials. And the thing that we wanna talk about is that from a security perspective, we're often in this game of kind of working up balance, right? There's the obviously bad and there's the obviously good. Those are easy in our business. The hard part is where the probabilities get tight. And do I challenge this user or do I let them through, do I block a good user? Right? You will find by the way that the tolerance for bothering good users is lower than the tolerance for letting bad users in like people super sensitive to friction. Right? So being able to give a reasonable way to bring a third party in and say, Hey, what do you think right.
To, to check with somebody else now, like a good example of this is, Hey, I'm I arrived to work. I didn't bring my phyto token. I need to get a pass for the day. Right. But work now is remote. So how do I prove, you know, I'm in my hotel room, how do I show something? So if I can bring a third party identity verification service into play that can really help me out to say, yep, this is the same person you employed. All right. So that's three examples, right? We talked about demonstrable proof of possession, demonstrating proof of possession. We talked about SSE and we talked about verifiable credentials, but there are several others that are super interesting in this space. When you think about the importance of having clean data for governance, right? Skim has a really important part to play there. When you think about the importance of having Federation relationships that are predictable and reliably integrated and are not too broad, right?
Fast fed has a super interesting part to play. So whatever you're doing, like whether you are an implementer, like who can push people like us to go get these standards into place, if you are a vendor, right? You can think about what you're doing in your libraries, your clients, your relying parties, your IDPs to start lighting up these kinds of capabilities. And then importantly, if you're in standards, like it is awesome that you're doing what you're doing. It's super important for the future of identity security. So please keep doing it. All right. So finally I have 35 seconds. I'm good. So finally I wanted us to sort of sum up that's the central thesis that we need systems to communicate better for identity security. This is super important, right? There are wayward kids living in basements everywhere. And if they're allowed to steal tokens and use these tools, they're gonna go to jail and these are lives wasted. So I'm begging you to lean in to the standards that help us with identity security, help us change the fabric so that these systems communicate better. Please enable MFA and do it for the children. All right. Thanks a lot.
