Chase Cunningham, Dr. Zero Trust, discusses zero trust and how it starts with authentication.

Transcription

Hi, I'm Chase Cunningham. Dr. Cunningham if you want to be formal. If you want to be cool, it's Dr. 

Zero trust. We're going to talk about how to think ZT. And this is going to be slightly different than what you've probably heard. There's lots of marketing, there's lots of conceptual stuff, there's lots of buy this technology to enable zero trust, etc. I'm not going to really talk about any of that, I'm going to talk about how I think about zero trust as someone who saw this as an opportunity when I was working for a research organization that would fundamentally change the game, and the reason for that is it's not about defense. 

And you're probably sitting there right now going, "Wait a minute, I thought zero trust was all about defense." No, it's not. Let me show you why. We're thinking about defense. We're always trying to strive for this perfect, 100% no breaches, nothing will ever happen to us, etc. That is not a tenant for zero trust. 

As a matter of fact, a tenant for zero trust, the reality is, is you must accept compromise. Sooner or later, somehow or another, some compromise is going to occur. For the defenders, that sounds like a losing proposition, but in reality, it's good if we can take this approach of accepting compromise and think about what the bad guy has to have to continually win and remove that. 

Let's take another step back at this and think about a different sort of approach at the concept. So, this is the bad guy side of things. Bad person over here with their machine doing bad person things. Now, the Lockheed Martin Kill Chain was one of the first frameworks you would accept as far as kind of a biblical reference in cybersecurity. Within the Lockheed Martin Kill Chain, there are things that the bad guy does to cause compromise. 

Ultimately, they're trying to get towards ones and zeros and zeros and ones and those types of things within an organization. The data, the gold if you want to call it that. They have to get towards some sort of compromise. They have to use those creds, they have to use those accesses, they have to use that network to jump and move their way through a system. We call this lateral movement. 

If they can do that continually, successfully, and get towards this golden resource at the end, it's not a good day for us. Now, the thing that we have to think about is, how can we interrupt this life cycle? And you may not interrupt this life cycle as early as you would like. This part of the life cycle over here, that's really where they're praying on human weaknesses. Phishing is a pretty big one, right? 

If we think about phishing, which now has moved into smishing and vishing and all these other things, whaling. You can't stop people from being people. You train them, educate them, etc., etc., but statistically speaking, 3% to 5%, and this is true, over 20 years of your workforce is going to click on a phishing link even if you glue their hands to the table. 

So, this is almost something that we can't have really good defensive or offensive capabilities, but we have to think about what does the bad guy need to continually get to those resources and win. Humans are the weakest piece of this chain, but there's a fix for that. We'll talk about that in a second. So, if the adversary can do these things, they are successful. Now, the one thing to remember is that the adversary, they do this continually. 

Why do they do this continually? Well, it's because ultimately, it equals money for them. If this bad guy can get to those resources and they can continue to try, and they'll continue to try until they get to that resource, it's because sooner or later, there's a payout for them. This is the inverse of the defensive side of things. 

So if we think about the defensive side of things, what we actually have and what we want is we're going to have a user or a device. Let's draw, you know, a user at their house or a device doing Wi-Fi things. And that's what we're trying to take care of, is this individual or entity. And I say entity because this could be a corporate device, it could be something that we have to defend, maybe not just a person, but an identity, an entity that's going to use some sort of communications medium on some sort of hopefully sort of secure internal resource. 

Maybe they've got their little firewall at house or whatever. It's going to run across some sort of network to ultimately work its way towards that resource. Now, a lot of times in the industry, currently today, you'll hear people talk about ZTNA. ZTNA is good because you're able to take a particular resource or a particular entity and do some things and get it towards a resource, and everything else is unavailable to it. 

That's good, but let's look at the two sides of this. What does the bad guy have to have here continually to cause this compromise, and what does the good guy need to continually use to get towards those resources? This is where we want to stop the intersection of those things. They have to authenticate at some point, right? 

This user, this device, this thing, somewhere along the way, it's going to have some sort of authentication thing that takes place to get towards that resource. That is what the bad guy wants to exploit. Now, the ZTNA side of it, even if you're using ZTNA, you will have some authentication that will work to make all this take place. 

All of that stuff, right? So if we're doing that, if we're using this control capability, we have to be able to counter the bad guys' side of the equation because we want to interrupt their ability to do this. We want to make it where it is not worth their time to try and come after us so that they can be successful and they win and they get the money. Also, on our side, we don't want to spend tons of money on things that actually aren't going to interrupt this process. 

The way that we do that is we take in lots of telemetry, lots of information. And this is a good example of how to understand kind of the scale of the problem when we're thinking about it. So, the user, let's just say that them doing what they do is a +1, the device is a +2, this other device is a +3, this network is a +4, this firewall is a +5, you know, this little network is a +6, whatever. 

And these are just random arbitrary numbers, I'm making this stuff up, but the point I'm saying is there's lots of data, lots of telemetry that should be being used over here that if we just kind of take it and lump it together, it's not really that useful. That just becomes a really big number. Let's just call it, I don't know, 350. Like, that's some random number that all that stuff would add up to. 

I don't have any context or any knowledge about what the value is of that information. Here's where we fix this problem. If I have a really good policy engine, which is what enables ZT, I can take all this telemetry and all this information, I can compare it and contrast it to what's going on in my system with context and I can begin to boil off systematically, mathematically, continually the things that the bad guy needs to be successful. 

So maybe normally this number always adds up to that or, you know, etc., etc. Cool. If all of a sudden something occurs over here, now that user that used to be a +2 is now, I don't know, a +4 for some reason, there's an issue. That's an anomaly, that's a blip in the system. Why did that occur? 

Well, that bad guy might have those creds, that bad guy's using those creds to get to that resource, I can interrupt their ability to be successful. And again, I have to do this continually. It might not be enough to stop them once, I need to stop them many, many times because again, they're going to keep coming, they're not going to stop. Until this process over here is strong enough to make them miserable enough that this is not worth it, I don't win. 

With a good policy engine that can ingest information from ZTNA, from the user, from the device, from the resource, from all those things and can control that because again, the commonality across all of this stuff is somewhere, somewhere along the way, there's got to be an authentication that takes place, if I can interrupt that with a policy engine, and if you look at 800-207, you look at all the documentation, publications, policy is what enables ZT, we can control that. 

Ultimately, what we're trying to get to is a space where this whole thing for the bad guy is so miserable that they will go away. It is not worth their time and efforts to make that money. They will leave and they will go do something else. This is not a space where a rising tide lifts all ships. 

If my process over here is better than the next enterprise down the road, if I'm able to do things quicker, better, faster, have better technology, integration, better understanding of what's going on, my organization will win. Guess what happens? The bad guy will move on to another business down the road that has more ones and zeros that they can go after. 

If you approach the problem thinking this way, you're doing things better and you're actually working to enable zero trust in your organization. If you can think ZT, not from the perspective of perfect defense, because this number doesn't really exist in defense, you will get to a place where you are making the bad guy unhappy with what's going on, and they will find another target. 

So, when you're thinking about ZT, thinking about zero trust, you're correct to think that you're never going to get towards no trust, towards absolute zero, but your policy engine, if used correctly along the lines of thinking like this, will take you from a place where you have 90% trust relationships taking place across that life cycle, down to one where you're 5%. 

This number is much more manageable and much lower risk than that number. This is what you're trying to get to. It's going to happen by using this approach, which will negate the bad guy's ability to be continually successful. You will make it not worth their time and effort to win that dollar, and they will go away. If zero trust is used correctly and you think along these lines, your defensive posture gets better, policy makes this a thing. 

Authentication is key to this whole capability space. Know that and practice zero trust with this in your mind. Hey, thanks a lot for listening. These are the way that I think about zero trust. I think that it's applicable for your organization. If you're trying to really have a better understanding of the concept, wrap your head around this. I think this is critical. 

Authentication is a key offering and a requirement for enabling ZT, policy is just as important. You can't do these things at scale without a good policy engine. I'm Chase Cunningham, appreciate your time. Keep thinking ZT.