Well, welcome back from break everybody. This afternoon we've got a panel. We're going to be talking about Zero Trust, probably at a little bit higher level. We'll do a little review of that and some of my esteemed panelists include Sebastian Rohr, Katryna Dow, and Allan Foster. So thanks for sticking around for this. So I thought I'd just start off with a general question and we'll see where we go from there. So we've been talking about Zero Trust for a decade. Do you think the original mission of Zero Trust, never trust, always verify, is still valid today?
Well, of course. I sort of represent the network architecture because the full acronym would be ZTNA, right? Zero Trust Network Architecture, and it's all about micro-segmenting, so reducing the blast radius and stuff. So of course that still holds true, but where we started, that was just like a decade ago, and you all know what happened in the last two, three, four years. We are just no longer defending the parameter.
Yes, we understand we need to control a little bit more fine granular, but the target keeps running away from us. So yeah, of course it's valid and of course we are still trying to get there. So absolutely, we have all of those challenges from a network, an architecture, a device perspective, but we also now have another reason to have to say trust but verify, which is at a societal level, because unfortunately now we can't necessarily trust anything we read or hear or say to each other or repeat.
So things that we were trying to embed at a network level to speed things up, to increase security, is actually now an issue of society. And then we layer on top of that, shifting sort of geopolitical sands, countries, nations that used to trust, I think it was Mark Carney that used the word recently, rupture, and so things that have been at a policy level are starting to erode. And so the idea of trust but verify is kind of moving just out of network architecture and needs to move into society architecture in a way, and we don't necessarily have the tools for that.
I hate these questions where you just have to say, yeah, what they said, I'm going to agree with that. But I think that it gives us a more fine-grained view on the word trust. We were sort of arguing about this earlier, but if you think of the relationship with your bank, you have a trust relationship with your bank, and that's an ongoing trust relationship. You don't necessarily trust the phone call that comes from your bank at, I don't know, two o'clock in the morning asking you to verify something that people want money from your account or something.
So the individual transactions are not trusted, but we still work within an environment of establishing these sort of different tiers of trust, which still have to be there. These long-term trust relationships between servers, and we have them at SSL certificate levels and things like that, and so I think then it's not necessarily a choice. It's a layered approach in what are the things that can change and what are the things that we have to ensure are persistent. And I think we're layering that up further and further and further in the stack, yeah? We're laying it right up to policy level.
And if I just might add something to Alan's story on his trust relationship to the bank. I had a very long-standing trust relationship with my savings bank, and I used to know the branch owner, so we were exchanging messages if I, living 600 miles away, would need to have an urgent transaction being processed before the advent of online banking pervasive access. And it all worked well until one day she had gone away. She left for another employer, and one of my transactions didn't go through, and they told me, I'm very sorry, Mr.
Roy, we can't do that because the signature on your check looks nothing like the one we have on file. I said, okay, what's the sample date?
Yeah, well, 25 years ago. So, that was a signature I did when I was 15, of course.
So, trust but verify. Sometimes you actually need to challenge the trust relationship that has been designed or created like two decades ago and review it if the foundation of that is still intact. And we see that, unfortunately, on a geopolitical order also. And I think following on from that, John-Eric, just in the tract in the room next door, had a nice little presentation, a little video in his presentation where what we need now more than ever is this bidirectional trust but verify.
He did this little demo where it sounded like his bank calling him and asking him for really personal information, and his response was, how do I know that you're really my bank? And so, we focused on zero-knowledge architecture and network design because what we've wanted to do is say, okay, traffic is going this way, and for it to continue, we want to make sure that it's safe. But what we haven't necessarily thought about is the bidirectional because we, as individuals, actually want to be able to be confident with bidirectional traffic.
And I would say, over the last decade, we haven't made enough progress in that regard. So, if I may add on that, like going into exactly the opposite direction, deeper down into the technology, in this first decade of zero trust, yes, we have deployed loads of technologies, especially in the network architectural part where we, of course, buy devices of vendors and some of these vendors, through the geopolitical shifts, now seem to not be as trustworthy as we thought they were a decade ago.
Yes, we have all those functional technical policies in these devices, and yes, we have that blast radius really pinned down and we're doing good, but then can we trust the hardware that we're running these infrastructures on, the routers, the switches, the tools, the firewalls, are the vendors still trustworthy in the current geopolitical situation? Yeah, that's a very interesting point.
So, yeah, I mean, you're starting to get into the whole, how does sovereignty affect zero trust? Anybody want to tackle that? What's very interesting, earlier this morning, I was in a session from some German presenters, again, talking about some of the challenges, you know, just in terms of cloud and infrastructure, of being able to have something that you can actually say is really sovereign and every part of the compute to be as independent as possible, and I think that's one of the challenges.
I know there is much more of a move here in Europe to try and lessen the dependency on vendors or services from other parts of the world, and then what you have is you have somewhere in the stack, tick, tick, tick, and then you have, say, a dependency and you can't satisfy that.
Again, I think it was in a session yesterday around some AI capacity that Europe is struggling because it doesn't have the compute power and then it's routing something in order to be able to complete a transaction, and so it's the question of sovereignty, it's not just the policy or the intent, it's also about infrastructure, it's also about public funding, it's also about things catching up fast enough, and so the concept of it and the fact that there is a move towards that, particularly here in Europe, not all the parts are joining up at the moment and the constraints aren't necessarily technology, yeah.
And if I may add on that, like 15 years ago, 20 years ago, we were working on that trusted computing stuff, right? We were trying to establish something and I'm pretty sure most of you know what a TPM is, a trust platform module, where you would try to create an IT system that is trustworthy by putting layers and layers and layers of integrity checks on each other, but it usually ended at the bottom layer of the operating system.
And so, yes, there are architectural concepts there that make sure, and especially here in Germany, the CCC, the Chaos Computer Club, which may some of you have heard of, was challenging that because the keys to that whole system were predefined by the vendors of the hardware, which were mainly in China or the US, but only in China was Lenovo being sold there, and they even asked, if we are not the holders of the key, of the credentials that we use to onboard these devices, how can we trust them? How is that really trustworthy?
And that discussion was 20 years ago, and we're more or less doing it again today, but our heads have turned from that direction to that direction, not saying anymore, and it's crazy, right? There's lots of demand. We see lots of demand for European-based technology by our European customers here, but what Katrina said is absolutely true. If it's still running on Azure and AWS and some other infrastructures, what's it worth? I'm thinking back to your trusted computing thing, and so I just bought a Chromebook that was a glorious expense, $80 on Amazon, and it shows up.
You just have to get it right. But the interesting thing about it is it's basically a trusted computer in the way it's designed, right? If everything about it, you don't get any viruses down during the boot-up process, you can go and disable them, but if you're running that machine, you know you're running a browser that's not infected, you've got an OS that's not infected, and they've actually gone all the way up to give you a trusted machine to the app layer. It's kind of nice.
Of course, I'm in the Apple ecosystem, we can boo, we can share it, whatever floats your boat, but it's also at that trusted thing, you can't run apps that aren't trusted into it, and so I think there is that thing where you can have trusted environments. I think where it falls down is, especially at the hardware layer, when the trust comes from the level of expense that it takes to mimic it. If it costs you thousands or tens of thousands of dollars to build a data center to do the same thing, then your threat is much lower.
If it costs you $49.95 to go out and buy a Raspberry Pi and do the same thing, that's a much bigger threat model, right?
In the sprint session just before this, if you want to catch it, the discussion around the keys and the PID and the security and the use of HSM and trying to balance the security with the user experience with the cost and a transaction cost of using HSM and being able to say, well, how can we how can we look at use cases where the PID would be used and isolate those and bear the cost of HSM for that, but then where we don't need to do that, remove some of that friction, design a really nice UX experience, and have the keys in a more accessible, cost-effective place.
Part of it is also assessing the use case and the scenario and having the flexibility within some architecture or design or device to be able to say, if it's this, then I need to incur the cost and I need to increase, and if it's that, I can relax some things, but I can't relax it too much because then I've got an issue if I need to go the other way from a user point of view, and so I think, you know, right now with the EU wallet and the Sprint team said all those decisions they've made about the keys, the HSM and everything, it's all online, it's all open source, it's all open for people to explore, but, you know, they had some real challenges on finding that balance, ultimately trust but verify, but at the same time don't make it so hard that you can't get something done, yeah.
I have a question for the audience. Okay. How many people have a code word with your family to verify the EU? That's cool, not quite half, but it's a significant number, which is, I mean, it's really trust but verify, right? Exactly. That's an interesting take.
Well, okay, conceptually, what are the most enduring components of zero trust? I mean, we think on the network side, you know, you had micro-segmentation, VPN replacement, that was always a, you know, a big plus, but that authentication, fine-grained access control, what do you think, you know, ten years later has become, you know, the biggest focus when we think of zero trust today?
Policy as in policy-based access control, because we're trying to get, we're trying to reduce the mesh granularity bit by bit by bit, and, well, when zero trust started ten years ago, not a lot of the world knew that stuff like Sanzibar would go be a big thing and authorization fine granular would be, but, of course, we had policies. Of course, back then, you could define on your gateways and on your switches and on your network level these policies that would enable you to create smaller segments, but the policies have been there all the time. They're changing, of course.
The content of these policies change. The approaches move from RBAC to PBAC and ABAC and CBAC and whatnot. We're extending the arsenal, I would call it, of policy. I'm pretty sure that when in ten years we were sitting here and talking about zero trust two decades in, policies will still be there. They will definitely look very different from what we use today, and I'd revert that back to Alan, like the third corner of our little triangle, the identity aspect. We haven't elaborated on that enough yet.
The difference is, ten years ago, the network folks tried to do network segmentation, but were completely unaware of what the user layer was doing, and right now, we're moving there. We're like three, four years, we have identity security now, and we're getting there.
It's like, suddenly, it's XDR and whatnot, and why is it? Because we added the human factor. We were able now to have something that happens on the network layer and link it to the human factor. I wonder just how bad the COVID years would have been without zero trust.
I mean, if we think of what the COVID years gave us, they gave us the ability to work from anywhere, work from home, do the things that we were able to do, and we did that because we were now authenticating on the transaction level. We were authenticating. We're not making assumptions you can only do it from your desktop computer. Zero trust actually enabled us to keep a little, I'm going to say zero trust gave us a little bit of sanity during COVID. That's an excellent observation.
I think the big challenge now on the policy level, though, and this has been a theme over the last few days, obviously, is an agent or an agent spawning an agent that doesn't have a clear enough mandate that needs to get past a policy, because it has an outcome. I think if we're talking 10 years from now, a lot of, I guess, some of the hard lessons that we're about to learn will be if there's an objective and zero trust gets in the way of the hands and a machine is trying to achieve something, then are the existing things going to work?
Some of you may be aware of UIBA, so user entity behavior analysis, and what scares me a lot is that, of course, these tools have been designed to check for the usual behavior of a human.
So, we all know, I think, that we all are overprivileged, whatever we do, whatever our job is, but we're humans, and usually if we're not super duper hating our employer and trying to get back to them because they fired us, malicious, we are behaving as humans, and even if we're granted far too many entitlements, we seldomly go out and actively try to poke and see what else we can do, and what you just said, the agents will, in microseconds, and exploit everything we're giving them. So, yeah, ZTNA in the next few years will be so much fun, not.
Well, we're at time. Thanks to the panel. Thanks for coming in and doing this. You need to stay in the room for Andy Hindle, because he has one killer slide that will address this. It's probably, it's one of the best ideas that I've seen, so you have to stay for this next talk, because I think he's going to set the scene for, yeah?
Yeah, so you all know hell, right? I'm sorry, Dave, I can't do that.
So, I'm going to let Andy Thank you. I can't do that.
So, we'll all have to stay. So, maybe you just stay here.
I mean, it's first row seat. John, thank you very much for hosting this great panel.
Thanks, Sebastian, Katrina, and Alan for participating.
