Informal security chat with Beyond Identity's CTO Jasson Casey, Head of Global Sales Engineering HB, and our host Marketing Empress Reece Guida on if zero trust is really the minimal axioms of security trust necessary to prove outcomes.

Transcription

Reece

Hello, everybody, and welcome to yet another episode of "Cybersecurity Hot Takes" with me, Reece, the marketing person, and?

HB  

HB. I do global sales engineering here, and...

Reece

And?

Jasson  

And I'm Jasson Casey. I'm the CTO.

Reece

We think we'll get better at the end, but I kinda like that it's still a terrifying surprise. So, you know, what's on my mind today, guys? Jasson and I were just having a little chat recently and he said something that was super easy to remember and it's stayed in my mind and I wanted our listeners to hear it. And it's about zero trust. The hot take for today is zero trust doesn't actually mean don't trust anything. And there was a lot of negatives, so just think about that really quick.

So, anyways, back to the little story Jasson said, "You know, if zero trust were aptly named, it would be the minimal axioms of security trust necessary to prove outcomes." And that just stuck with me for obvious reasons. So, HB, what do you think of that hot take that Jasson said?

HB  

My God. The first thing I thought was jinx. I think the last time when we were talking about some of those, the topic was whether security analogies were a good thing or not.

Reece  

That's right.

HB  

And one of the topics that we sort of veered off to was that zero trust is a sort of hyperbolic explanation of what people are genuinely doing when they talk about zero trust today. And from my standpoint, you look at what Gartner was originally trying to focus on and what Google was trying to do with their BeyondCorp paper.

The idea of zero trust is really just to create a counterbalance and an alternative vision to the perimeter security and castle and moat stuff that everyone's been doing for, you know, as long as networks have been around. And so, in my mind, what we've ended up at is that people balance least implicit trust, least over privileging, and least breach impact. And so, those three things in my mind define a successful zero trust strategy, for what it's worth.

Reece  

Well, it's interesting because zero is a binary, right? It's zero or not zero. Zero or one, but least. That's more on a spectrum. So, where do we fit that into the reality of the zero trust situation?

HB  

I think, again, that's the hyperbolic part of it in my mind, at least that is it really possible to get to genuine zero trust? The idea is to move to maximum transactional trust and maximum kind of on-demand just-in-time authentication and verification and least privileging and whatnot. It's hard to imagine a scenario where you're truly at zero because then you've really solved the problem. But again, my perspective is probably drawn from a pragmatic read of the space. I just think that when you look at what people are doing, it sort of sits on this continuum of "I did nothing and I just called it zero trust." I tried a little bit to improve a couple of these things and now...

Reece  

Good enough.

HB  

...on my zero trust journey.

Jasson  

So, I have a different take on zero trust. And I generally don't like the idea of greater or least or maximal because, ultimately, that implies that there's a continuum and the reality, at least the way I think about zero trust is you either trust something or you don't, right? And a zero trust framework and the reason I had that kind of mathy statement is I do think it really boils down to proving a thing. Like how do I know a thing is true? And all of our formal reasoning, right? Whether it's the logic we do in schools or the proofs that we go through in college to prove theorems and whatnot, it always starts with a set of axioms or a set of assumptions that you assume to be true.

I assume that if I connect two lines in a plane, it makes a line. If I connect two points in a line. If I connect two points in a plane, it makes a line. If I span two lines, it forms a plane. These are axioms of geometry, right? Two parallel lines never cross. I can form a triangle of equal sides by finding the center, by drawing a line, finding the center of two circles that have the radius of the line of the bottom, and essentially, they'll form intersections for the other triangle. That's a theorem, right? It's a thing I can prove from the axioms, right? The four axioms that I started with.

All four proof systems, all formal systems, they start with things that you accept to be true, and they try and keep this as small as possible. And the reason they try and keep this as small as possible is because, once you start building your system out, proving the implications of those assumptions. The complex systems tend to collapse on themselves because you can very soon start to show contradictions, one equals zero. It's no different in a security world.

So, zero trust in a security setting is I want to have some sort of formal system that I can reason about whether I can trust a thing or not. If there's too many things that I have to trust in that formal system, then the formal system itself it's not a question of whether it's less good or better or not good enough, it's more of a question of, is it sound? Are there things that I'm taking to be true that in fact are not actually true? I've enriched my system so much to where it just collapses in on itself similar to...

Reece  

So, what would the basic axioms of zero trust be? And I think you said keeping it simple is important because you need to have a foundation upon which to prove things, but the security ecosystem, it's all about defense in depth and integrating systems, and increasing interoperability and visibility. So, that to me kind of seems at odds with maintaining a minimal number of axioms. So, what does that mean for practitioners?

Jasson  

So, let's stop calling it axioms because we're probably losing half our audience every time we say the word axioms.

Reece  

Axiom, axiom.

Jasson  

But let's say assumptions, assumptions we take for fact. I would say that no one is going to argue with the statement that you should have a minimal number of assumptions that you take for fact in a security architecture.

Reece  

Yeah.

Jasson  

That's probably not gonna be controversial. What you were describing in my mind is much more of the outcomes of reasoning about a minimal set of systems. And it's no different in good engineering design. Good engineering design isn't bespoke creations for every problem that shows up, it's recognizing that most problems can be broken down into a set of sub-problems.

And you only need a couple of tools that are composable, that can be combined in different ways to solve these larger and more complex problems. So, in the world of security, I think it's actually a valid question. What are, if we were to try and take this as a more formal methods process, what are the axioms of a zero trust architecture? What are the axioms of a design system? And then what is implied from that? And we already know the goals that we want the system to arrive at. So, you could also maybe look at it as working backwards, right? But I think one of the core things that you have to adopt as an axiom is you have to adopt almost like what manufacturers am I going to trust? And so, the practical example of that is we talk about at work TPM chips all the time. TPM chips type of enclave, it's either on die in a processor or on a board in a modern computer. It lets software create crypto keys where those keys physically can't move.

We are implicitly trusting the manufacturer of that TPM device to have followed the TPM specs. That is an assumption that we take for fact that the manufacturer did exactly what the spec says and nothing else. If that assumption were to not be true, some of the consequences that we depend upon of using a TPM ecosystem also become not true.

So, what are some of the implications of that? Some of the implications are the TPM works in the way that the spec says. The manufacturer also protects the process. And so, there's this thing called a root key, an endorsement key that actually lives on each of these TPMS that I can use to actually track back to the manufacturer. So, when I'm trying to, let's say that I wanna prove that in order to allow a device to connect to my network, I want it to prove that it has had an unlisted boot process, i.e., the boot loader, the bios, and the operating system are all OEM genuine and have not been modified in any particular way.

Reece  

Yeah. No tampering.

Jasson  

With a TPM system, I can get a structural proof that gives me that. Now, at the core of it, I do have to trust a small number of TPM manufacturers, but there...and there are one or two other things. But beyond those one or two other things I have to trust, I can actually use a protocol to kind of prove all the other implications and know for a fact whether I'm dealing with a tampered or non-tampered instance of an operating system.

Another example is in the certificate system. In the X.509 certificate system that we power HTTPS or most websites on, we do have a core root of trust, right? And it's essentially the root that our browsers use to trust CA roots. We basically assume that the CA, the organization that operates the CA is following security practices does not have...does not actually sign things with their root key, only signs things with intermediate keys, follows the appropriate, practices, etc. And then we use that almost to bootstrap our proofs along the lines that I am in fact talking to the website owner of name X who controls the private key that is endorsed by the CA system.

We don't have enough time to get into all of the mechanics of it, but we do have structural proof systems at work today. They're really minimal, and they definitely have gaps, i.e., things they don't cover, but they're consistent. And they're correct. And they do provide really, really strong foundations for building a better security architecture.

HB  

So, are you talking about strict providence assurance? Are you suggesting that zero trust is essentially whatever comes truly before the zero trust and that's the assured providence like...

Jasson  

No, no, no. I'm re-casting zero trust, right? So, you can also say I refuse your reality and I choose to adopt my own and that's fine. But I'm re-casting zero trust in more of a structural sense. For my mind being engineering-focused and math-focused, I want structural security protections. So, a structural security protection is something that I can actually have a proof for, right? Like a mechanical proof, whereas a non-structural security system is, "Trust me, all of my people are good people and you can look at my code, and surely if you can't spot the bug, there must not be a bug." We all know the fallacy of that statement I just made both from a practical sense as well as from something called the halting problem sense. But a structural proof is much more along the lines of, "I know a thing to be true because based on some sort of reasoning system with a very minimal set of core assumptions, I can prove it." That's really what I mean.

Providence in my mind would be a use case that you could use such a system to then prove that the chain of custody of this system and the chain of custody of this key, or the chain of custody of the software has been with parties that I trust.

HB  

So, would you feel okay if I changed it from least implicit trust to no implicit trust? No over privileging and no breach impact?

Jasson  

No...

HB  

No breach impact sounds weird, right?

Jasson  

Yeah. Clearly, this is a longer discussion, but it's...I guess the reason why least implicit trust doesn't quite feel right is because that feels more like a property of a system as opposed to making people really understand that there is a system and the system has a core set of assumptions. And from those...and it also has a set of reasoning primitives like and, or, negation, implies. And based on those assumptions and that reasoning, there's all sorts of consequential properties of a system. And then you can also look at it from a system design perspective. What are the properties that you want a system to necessarily have and nothing else? And kind of work backwards and then try and figure out what a system should actually be shaped up by, if that makes sense. I apologize. Some of these things are a little bit harder to work into analogy probably because I'm just not very good at it. But also, I spent this morning actually reading some of the technical materials where they kind of shun the analogy and jump straight to the stuff. So, switching between the two sometimes takes time.

Reece  

Yeah. You know how Phil Venables feels about analogies. I think this stuff that I'm really struggling to comprehend about this is a zero trust architecture is made up of many systems. And all of those systems have their own inherent assumptions that they operate off of. And some things are provable at a station within a TPM, but some stuff... Is it possible to have things within a system that aren't provable?

Jasson  

No. 100%.

Reece  

Yes, I think. And then does that mean it's a bad system or is it just...are systems like that sometimes?

Jasson  

So, there are some very famous proofs that in logically consistent systems there are true things that are in fact not provable. So, you have...

Reece  

That's like faith. I'm just kidding.

Jasson  

No. You have hit on some deeply profound insights that were first discovered in the...was it the '40s or the '50s? So, yes.

Reece  

It's time to time travel back.

Jasson  

There are absolutely things in systems that are unprovable. I think a more... So, what people have to understand when they're thinking about systems and properties of systems is focusing on the right things to prove.

Reece  

And with zero trust, if you had to pick three things, what would be those right things to prove?

Jasson  

Integrity of the hardware would be number one. Integrity of the operating of the application stack all the way down to the bottom. And so, what I mean by that, I did mean to make a Fineman reference, but now that I hear it out loud, I hear it. What I mean by that is in the TPM, you have this way of measuring software. And so, you can actually measure the software integrity from bios to boot loader to OS to application. So, when I say all the way down to the bottom, that's what I mean. So, hardware integrity, application integrity. And this is where the... and so now we're getting to the edge of the industry. I would love to be able to include configuration integrity. That doesn't seem to exist just yet.

At those three things, we actually start to solve a lot of common problems that are exploited. Clearly, key integrity, although I did...you limited me to three. But with those first three, what are the consequences of having those first three systems? I will always know, as both a resident on the system or resident off the system, whether I'm dealing with a molested system or not. I will always know if a system is going to operate, what its configuration is, and nothing else. Now, again, doesn't mean there aren't bugs in the code, doesn't mean there aren't bugs in the hardware. So, there are limits to things, but that's kind of a profound statement as a service provider. I know I'm talking the software I wrote as opposed to software that someone else is emulating. I know I'm talking to hardware that follows this particular spec and nothing else. Those are profound properties that have a lot...pretty far-reaching implications.

Reece  

Would you add anything to that list of three, four things, HB?

HB  

You know, as the dumb implementation guy, all I have to say is that getting any of those properties in systems broadly is super exciting. And that's a lot of what excites me about the way that our platform is being built. So, yeah. No. I think we're in the early Renaissance of formal methods and formal verification and like a broader range of critical systems. And I'm just glad that smarter people are working on these problems and solving them when I have a hard time fully comprehending them.

Reece  

What a time to be alive. The Renaissance.

Jasson  

On that note, anyone listening is actually into formal systems. We're always up for hiring good people and we actually do work like that in multiple areas of our product.

Reece  

That's a good plug to end on based on any particular roles right now.

Jasson  

So, obviously, all of our roles are generally software engineers. We are looking for product managers too.

Reece  

Cool.

Jasson  

But we expect our product managers to be kind of technically trained former engineers, or are deeply familiar with engineering problems. The types of problems that we work on that you have to...you almost have to be working on already. And we're just an opportunity for you to scratch that itch that you've had for a long time. So, like language design, properties of language, properties approving things about languages, but in real systems, cryptographic protocols with certain interesting proof properties, but again, with an eye towards application and actually building them into real systems.

Reece  

Nice.

Jasson  

Anyone who is into, excuse me, operating system development, driver development, again, with a deep understanding of how operating systems are composed and then like, what does it mean to have a trusted operating system? Yeah. No. Formal methods has been around for a long time, but practical application in industry is, I'd say is less than five years old and we're still in the beginning.

Reece  

Early Renaissance. Well, listeners, if you are that mythical technical being, please apply, but only if you like and subscribe first and check out next week's episode. As always, we don't know what we're gonna talk about, but we'll find out real soon.

Jasson  

We don't always know what we're talking about.

Reece  

That's also true. That's an axiom. Excuse me, it's an assumption. We'll catch you all next week. Thanks for listening. Bye-bye.

‍