Shut The Front Door - A Risk-based Case for Zero Trust Authentication

Just in time, click our hand off. Hey, I'm super excited to be back at eic. This is literally my favorite event of the whole year. We get to be in a wonderful city, in the center of a wonderful city, so we can get anywhere. We get to have meat. Really interesting.

And, you know, super bright people have great conversations, eat good food and drink even better beer. And, and speaking of that, we've got, I think the, the beer comes after the awards, and I'll join you on that side today. The title Shut, the front Door is a little bit of a, a, an American euphemism for shut the heck up, but we actually mean it very literally here. Identity professionals have never been more important in this environment.

If you, if you, we, we talked a little bit about that in the last presentation. You know, if you rolled the clock back, I, I'm a cybersecurity native basically. So I come at it from that. I've done a couple of stints in identity companies and some big projects in identity management, but I kind of consider myself a cyber, you know, kind of the cybersecurity side of that. If you go back four or five years ago and ask the, the CISOs at the organizations, you know, about the identity team, it, it was really an afterthought.

I mean, let, let's just face it, it's not an afterthought anymore. It's front and center.

You know, we all talked, you know, all conference about identity first security, but any c so I ask now knows, they know ex exactly how important identity management is. I'm gonna try to make the case that stronger authentication is really the tip of the spear in, in that discussion. And so let me give you a, a, what I used to do when I was on the Analyst side of the house back in way back in the day, Martin, and I get a talk about that every once in a while.

The, I, like, I used to like to use something I call the magic wand test. So wait, if we waved the magic wand and we did everything that we do in identity management perfectly, you know, if I handed you all the wand and we made it, you know, our identity governance processes and technology stack was important. Pi Pam was implemented and, and well oiled. We had everything hooked up to our SSOs, you know, so that was all integrated, you know, all the stuff was done right? If we do authentication wrong, we're hosed. But that's, that's just where we are.

If we don't do authentication and we don't up-level that, we don't get the security we need. So I would do the same magic wand discussion for any of the security people who might be in the audience.

You know, if you do all the zero trust things really well, we've got, you know, sassy or network, you know, zero trust, network access, you know, whatever you want to call that space these days. Or if we do really good network segmentation, if we let the bad guys in, then it does none of that. It's all for not basically.

So, you know, auth ends up being important. It's why I chose to get back in the identity space. So what I'm gonna do is make a case for risk, risk-based, you know, authentication or what we're calling zero trust authentication, which is a compilation of a bunch of things. And if we don't, you know, if one of the reasons that this is so important is really the bad guys now are just logging in. Kurt Johnson, one of my, my former Analyst buddies and, and, and a coworker said that like three years ago.

It's like, the bad guys don't seem like they're breaking in anymore. They're just logging in with everything that happened. So let's start off and see what we can do to, to fix that problem. You know, they're just waltzing through the front door as as, as we like to think about. So here's kind of my laundry list of stuff that's kind of broken in, in identity. We know password stink, they're a pain in the butt to use.

And, you know, we're supposed to do longer, stronger, by the way, just for the record, there is no such thing as a longer, stronger password. It doesn't matter. That's not bad, guys don't crack passwords anymore. They either buy 'em or steal 'em and reuse 'em. So do you think a piece of malware cares if it's gonna, you know, pass back a four character, you know, a, B, C, D or 1, 2, 3, 4 password or a 4,000 character password with, you know, all the, all the, you know, different things that we want, you know, capital and lowercase and special. It doesn't matter, you know?

So it's, it's, that's where we really are. And then MFA was supposed to fix that problem, right?

I mean, we have a password issue in that. The obvious next step is, well, let's implement multifactor authentication.

And, and it just hasn't, at least the first generation crop of MFA is so easy. And I'm gonna go into a little bit more detail there. So I'll hold off on that. The next one is that, you know, in the modern world where we're ac accessing kind of cloud resources and apps from anywhere, any place, you know, you also have to know what's coming in, you know, to the, to the environment.

So, we'll, we'll talk a little bit about that and what you need to do and don't sleep on that. I'll, and, you know, we'll elaborate and, and then whether you're, you're having unauthorized device come in, is that device also secure enough? You know, is is do, it's not only do I wanna let Patrick in, do we wanna let the device of Patrick's trying to use to get in and access resources?

So the, the password side of it and the device trust side of it. And then the other big issue I I see kind of from an authentication perspective, it's a once and done proposition. We do the authentication transaction, you know, we do, you know, either first generation author or mfa or we do something a little bit better, and then we're in, and we've got a session timer that goes from, you know, hours, sometimes days, weeks.

There's actually multiple instances in, in our client base where we had folks that would turn on a session time for, you know, multiple months, which was just, you know, beyond me, if you don't think anything's gonna change in eight hours or you know, the, then you haven't been a cis admin in in the past. I mean, stuff changes, you know, kind of all the time. So those are the things that we have to kind of fix and the consequences are pretty dire.

We, we've kind of talked all conference the best, so I won't dig into too much here, but if you take a look at the Verizon data breach report, which is, you know, only successful attacks, right? Where they've actually breached and traced that back every year for the last decade. The single largest attack vector is reuse of reuse of credentials.

You know, a close second now ends up being, you know, MFA bypass attacks. I think we've, you know, other folks have talked about that, but there's a spate of MFA bypass attacks. Now for the last couple of years we've been up on stage, you know, kind of railing against first generation MFA and saying, Hey, we gotta do something better here. And I frankly got a lot of pushback.

You know, when I sat down with CISA and stuff, they're like, ah, Microsoft says use, or Google said just, you know, whatever MFA is gonna make it it better. And that's just not the case.

Now it's, and so the valid account on attacks is not just like the sophisticated actors that we see in the skull there. These are kind of some of the well-known actors that were most, most of them, not all of them are state-sponsored actors.

You know, the, the fund names that we give those threats, they use this same thing. Their initial attack method is to log in, steal credentials, bypass MFA, and log in because they don't wanna, they, they do some expensive and, and really interesting trade craft as well, but they don't wanna blow that.

You know, they'll, they'll only use that when they absolutely have to. They just rather log in. It's a whole lot easier now as do the common garden variety financial guys, you know, financially motivated attackers. I had interesting on the other side of this, you know, that's more like from an account takeover perspective, but if you look at it through the ransomware lens, it's, it's also interesting on, and I, and I lost this bet to my ceo, which I shouldn't, I'm more of a cybersecurity native than he is.

He asked, you know, he was saying, Hey, the, the most common way that ransomware happens is people are logging. I'm like, no, no, no.

They're, they're, they're clicking a link on a, on a website and downloading something or clicking a link in an email. He says, no, no. So that's that slide or that chart is literally copy pasted right out of the Verizon data breach report. I got second place, which was, you know, actually the, you know, the click, you know, the click bait kind of stuff. The single biggest attack vector, initial attack vector for ransomware attacks is also authentication fails. It's used.

People use, you know, the bad guy's using stolen credentials and logging into remote access stuff and installing ransomware. So, you know, those are the consequences of it. We all know. So I'm gonna spend a little time on this and, you know, come by the booth and talk to us.

You going, when I say that first generation mfa, let me, let me classify that. Anything that uses Frank, frankly a knowledge factor from a security perspective, anything that uses a knowledge factor or something I can ask you to give me is easily, easily engineered by a social engineering attack. I can get my, you know, my mom, my grandmother or whatever to get, you know, to give me, you know, both their password and with a, with a good enough ruse.

You know, I can get those, those things myself. I don't need skills, I don't need tech skills, I just need kind of verbal skills and a good ruse. So there's that whole class of things. One time passwords and you know, over SMS or over email, et cetera, et cetera. A second version of that is just the push, the prompt bombing and the push notification stuff. If I hit you with enough prompts, you know, try to log in a bunch of times, you know, more often than not, somebody's gonna say, yeah, just, you know, go ahead, let me, let me clear that alert that I get.

Cuz we all get so many alerts on our phone. So we, those prompt bombing attacks are just another form of social engineering. Then you get to what used to be the next one, the attacker in the middle, a class of attacks. And those used to be kind of a high bar. That was a little bit the degree of difficulty if you wanna use diving terms, was, was up there. Not anymore.

You know, the degree of difficulty back, you know, a couple of years back was you had to have real tech skills and be able to pull this off and build a proxy and, and, and all of that. Now you've got evil Engine X, it's a, a kit that you can download. It's open source with my rusty, you know, cis admin and engineering skills. I can fire up an EC two instance and get something up and rolling in less than an hour. And to make it even worse, more recently, we're now seeing this as a service.

You know, so the, we have services to do strong authentication. Bad guys have services, you know, to break authentication. So you don't even have to have any technical skills. You just have to have, you know, some money to, to put at the problem. So what does a solution look like? We would contend to have a strong modern authentication solution. It's gotta conte, you know, basically deal with the two most important things. The identity itself, the user identity and the device. So it has to take into account both of those sets of things. So what might that look like?

If we think about this in, you know, we're calling it zero trust, you can call it strong authentication. I like to think about it as authentication that rises to the level or the high level of what a zero trust environment should be. So the first thing is we have to establish high trust in the user identity.

You know, the, the real way to do that is use only strong factors that are really, really hard to breaks. And, and we've got those, they're available. Now we can use phyto PAs keys and I'm gonna come back cuz there's a, a caveat to that. Not not on phyto, but some of the implementations of that. But you can use a phyto ca paske, a cryptographic, you know, public private key scenario and you can use the built-in biometrics on most devices.

I'm, I'm talking more from a workforce scenario, but that also plays out in, in non-work in, in the SIAM solution. You, you, you know, you have to be a little bit broader because not everybody has a biometric on the device. So the public-private key thing is also available now because I've got a really good place to put the private key. It's called a TPM or an Apple world, it's called an enclave, it's a separate chip set. It sits off the main processor, you know, so the degree of difficulty to get at that thing to a get the device and then get like a private key out of the, the TPM is massive.

It's, it's a really, really high degree of difficulty. So, you know, that's, that's one factor. So tho those are two strong factors. The next thing is, is we have to establish trust in the device. And there's two, two pieces of that, and I'll go into a little bit more detail piece.

One is, is it an authorized device, whether it's A B Y O D or a work issued, you know, managed device. Is it a contractor coming in in any of those cases?

You know, step one is, you know, is this one that we wanna let in step two as part of that is, is it secure enough? So I'll, I'll hit that a little bit with a little bit of detail. And then we wanna make, you know, for this idea, zero trust authentication, make a risk policy based decision, but we want to be able to incorporate signals from a lot of other cybersecurity products. I mean that was was a really good point in the last presentation. We've spent a hell of a lot of money on, on cybersecurity. We've got all kinds of great detection and response capabilities.

What if we can leverage the rich signals at A E D R or M D M, et cetera for, to help us make a better policy decision? You know, that would be a real big win. We get a double down and, and get more value out of a technology we've implemented and make better authentication decisions. And then this, you know, to, to contend with the, you know, kind of once and done nature, you know, we do the transaction.

If we check stuff up front and everything checks out and we let somebody in and then we don't check again, you know, until the next time they log in, for example, then we're not where we need to be.

And then the last piece of this, if what we call it in the New York subway, they they, they say it as if you see something, say something, we like to think about it as if you find something, do something like if you find what looks like an unauthorized user or a device that's really going out of policy or anything, like do something, you know, take action and, and you know, don't let the bad guy do what bad guys wanna do.

They want to get an initial foothold on the, on the network somewhere in the, you know, on an endpoint and then move laterally through the network to whatever targets that they're trying to get to. I said don't sleep on that. Prevent unauthorized devices saying, I got a story. I had a have a good CISO buddy who's a CISO of a large multinational, his treasurer was off on a business trip down at breakfast one morning, got a call from his team, Hey, you have to move some money. It was a legit call.

It wasn't one of these business email compromising, it was actually a really legit thing and it was just above their pay grade. So he had to do it. He was down at breakfast, had his phone. Do you think he went up to the 22nd floor and grabbed his work, issued laptop?

Nah, he scooted right on down to what I like to call the pre compromised device in the hotel lobby. You know, it's, it, and he logged in, he was using mfa, he got his push notification. So there was, you know, some incremental level of understanding that it was actually him.

So that, that was, that piece was, but, but we let him log in from a device that clearly to do that kind of action was, you know, not something he wouldn't, he shouldn't have done what happened next? He moved the money, logged out, the guys were, had a presence on the device, the session cookie, you know, reestablished the session and move some money themselves and it wasn't to one of his approved bank accounts. So that's, that's real. The which device actually matters and then is it secure? We can't a, we can't actually answer that question. Is this device secure?

It's really an unanswerable question, but what we, the question we can answer are all the security controls that we want to have on enabled and working, and I'm not talking about just the little things you can get outta the browser context. I'm talking, talking about deep inspection, you know, everything from block screen and pin, you know, in, in, you know, active.

So, you know, if I leave my laptop or phone in a, in a cab, the next person that grabs it can't get in understanding if it's a by od or work device is maybe, you know, different policies on those kinds of things. You know, firewall and disc encryption and is it a jailbroken device, you know, for example. And then if, if, you know, not only there, there's two things with like MDM and edr, other endpoint stuff. First of all, are they working? You find all the time that, you know, one of the programs will go down, you know, and it's, you know, stop working or whatever. So add authentication.

Why don't we find out if it's actually running? Is that process running and up and, and working at the time? You can hit the process, you can hit the API endpoints and, and make those decisions, pull all that into a, a, a policy and, and we can prevent and secure devices. So what might that look like in action? I'll just kind of walk you through kind of a, a transactional view of this. So we've got, you know, our, our little user on the left trying to get to his applications. Let's assume it's a really important one. He goes through a single sign on that can be delegated.

O I D C was, you know, it was created so that you can have a delegated identity provider. So we, you know, in, in our case, they delegate that to us and we do the authentication.

So it, you know, the what their cloud talks to our cloud, our cloud then talks to our endpoint and you know, our little authenticator there and, and it answers a couple questions. First it gets the public private key crypto, you know, thing done.

Hey, send me a certificate so I can prove that it's Patrick and then let's take, take a look at that device and see are all the security settings that we want to have place. So we, you know, make sure the device security posture by the way, having that public-private key pair that device with only, and, and I won't get on my soapbox and talk about moving private keys. That's a, that's a different fighter, you know, oriented discussion. But if I've got my public private key pair, I get a two for out of that.

I know it's Patrick and I know it's a device that we've authorized him, we've registered, you know, for him. So, you know, it's that it, it fixes that one problem. I can't log in from something that, that doesn't have the authenticator and have a have the key pair on and I can control that through policy. So we've got those two pieces, but we're not done yet. Let's take those other signals.

You know, we're in, in our case at, you know, at work, we log in, we're, we're a mixed Microsoft and Apple shop. So we've got jam and in tune that we use so we can interrogate, you know, those things, find out if they're running and then then actually interrogate the endpoint and make sure that everything's hunky dory. Same thing for the edr, you know, let's talk to CrowdStrike. We can pull, for example, you can pull the score, what they call the zero trust score from CrowdStrike.

And hey, if it's over a certain threshold, you know, maybe we do a step up authentication, maybe we don't let, you know, maybe we just deny access altogether, et cetera. But you can control all that stuff to policy. And you know, once we've, you know, satisfied all of those pieces, then, then we can let 'em in and, and we're done, right?

No, because we don't want 'em, you know, things change, things can change rapidly. I can log in and turn off my lock screen.

I can, you know, log in and turn off my firewall, et cetera. So let's continuously go back and check, we can check user parameters for impossible travel kind of scenarios. And this is all outside of the O I D C transaction.

The, you know, the, the good thing about o is it happens and it gets out of the way. The bad thing about oth is it happens and it gets out of the way, right? So let's continue the conversation and you know, like I said, if we find something, you know, we find, you know, the CrowdStrike discovers something or we just see a setting that you know, shouldn't, you know, shouldn't be in, in that current form, then do something.

So, you know, there's different ways that we can do it with different technologies. We can just cut off the networks, you know, connection ourself. We can call out the CrowdStrike and they can quarantine the device. They've got an api they can do that. You can hit your ZT n a provider, you know, and, and have 'em drop the network connection.

Don't let, don't let the bad guy do what the bad guy wants to do, which is, hey, they might have a presence here, let them go to some other place. And then just to kind of complete the story, he, you know, again, zero trust is, you know, it's a team sport and so you've gotta provide, you know, really good data, you know, out to your security operations center, both on positive and negative events, right?

I mean, you want to, you want to have that both there and things to like the audit and governance stuff. So we've, we've already done the security, you know, in our case we've done the security op stuff up next is some of the, the tools in the audit in, in governing, because we can give you really pristine audit records.

You know, you can answer the question in your healthcare was every device that came in the door, did it have it have a discon encrypted at the time of authentication and then continuously thereafter, it's a question that is actually an audit question. So can we like, you know, push the button and answer that or can we give the data to one of those kind of tools so that they can actually, you know, use that process at date and provide ready-made reports.

So that kind of what it looks like in practice, you know, the way we think about it, you know, is, is a little bit like Einstein, you know, insanity is doing the same thing over and over again and thinking you're gonna get different results. And until we move to really stronger authentication, we're gonna still be hammered with these attacks that mostly come through the front door. So let's shut that door and if you wanna visit the booth, we've got a book for you. And then ask one of the guys to show the user experience. I just spent no time on that.

But if you wanna see like a slick, easiest thing ever, that would be some time well spent at the booth. So thank you for having me back. I really appreciate it. Thanks very much. You had the in unenviable task of bringing us to a close today, but you got through really well. Just one question though. Many organizations haven't even got to invest in first generation MFA and or they have invested and it hasn't returned. So how do you persuade them to make the leap to this?

I part of the, you know, part of that conversation is user experience and I love the fact that identity professional, well identity professionals have always kind of led the charge there. CISOs used to be, it's kind of my way or the highway attitude and everything we put in place tended to make bigger hurdles for the end user. So I think, you know, it's a little bit of carrot and stick and the, and, and the carrot really is, hey, I can really, you know, with this, you, you wanna do it strong, but I can do it. You don't have to compromise now security and user experience now.

So I think that's, that's really the sales meal pitch. Okay, Great. Thanks. Another round of applause for Patrick McRoy. Thank you.