Cyber Sentries: AI Insight to Cloud Security

Decoding Zero Trust Security for Cloud Native Environments
In this episode of Cyber Sentries, John Richards welcomes Zack Butcher, Founding Engineer at Tetrate, to explore the critical components of zero trust security for cloud native and microservice environments. Zack, with deep expertise from his time at Google and work with NIST, shares practical insights on achieving a zero trust posture.
John and Zack dive into the fundamental mindset shift required for zero trust - moving from implicit to explicit trust. They break down the five key policy checks that define runtime zero trust, and how these controls can enable identity-based segmentation. Zack illuminates how this approach allows organizations to boost assurance while strategically relaxing painful network-level constraints.
Questions we answer in this episode:
• What does Zero Trust really mean in practice?
• How can organizations adopt a Zero Trust mindset?
• What role does a service mesh play in Zero Trust?
Key Takeaways:
• Zero Trust requires making all trust explicit
• 5 key runtime policy checks define a Zero Trust posture
• Identity-based policies boost assurance and agility
Whether you're wrestling with Zero Trust definitions, microservice security, or cloud native challenges, this episode delivers a wealth of battle-tested wisdom. Zack's clear explanations and examples, combined with John's knack for extracting practical takeaways, make this a must-listen for anyone navigating the complex world of cloud native security.
Links & Notes
  • (00:04) - Welcome to Cyber Sentries
  • (01:01) - Meet Zack
  • (04:55) - Reflecting on the Journey
  • (05:46) - Deep on Security Aspect
  • (09:52) - Zero Trust and Definitions
  • (15:35) - Consensus
  • (18:09) - Availability and Assurance
  • (22:28) - Driving Growth
  • (25:44) - How AI Can Be Used for Security
  • (30:07) - Links and Finding Zack
  • (30:36) - Wrap Up

Creators & Guests

Host
John Richards II
Head of Developer Relations @ Paladin Cloud The avatar of non sequiturs. Passions: WordPress 🧑‍💻, cats 🐈‍⬛, food 🍱, boardgames ♟, a Jewish rabbi ✝️.

What is Cyber Sentries: AI Insight to Cloud Security?

Dive deep into AI's accelerating role in securing cloud environments to protect applications and data. In each episode, we showcase its potential to transform our approach to security in the face of an increasingly complex threat landscape. Tune in as we illuminate the complexities at the intersection of AI and security, a space where innovation meets continuous vigilance.

John Richards:
Welcome to Cyber Sentries from Paladin Cloud on TruStory FM. I'm your host, John Richards. Here, we explore the transformative potential of AI for cloud security. Our sponsor, Paladin Cloud, is a AI-powered prioritization engine for cloud security. Check them out at paladincloud.io. On this episode, I'm joined by Zack Butcher, founding and principal engineer at Tetrate. Tetrate provides a consistent way to connect and protect thousands of individual microservices. Zack and I will discuss how to know if your environment is zero trust and the five critical pieces necessary to achieve zero trust. We'll then look at how those principles apply to AI services to ensure they and your data remain secure. Let's dive in.
Hello, everyone. Welcome to today's episode of Cyber Sentries. I am absolutely thrilled to welcome a real pioneer in the world of microservices and security. Our guest is Zack Butcher, founding and principal engineer at Tetrate. Zack, thank you so much for joining us today. Welcome.

Zack Butcher:
Thanks for having me. I'm excited to be here. I'm looking forward to it.

John Richards:
Before we dive into more around the security, I'd love to hear how you kind of got into this role, founding member. What led up to being such a core piece there early on, and what was your journey to that spot?

Zack Butcher:
I started out working in Google Cloud. Actually, I owned projects, so if you ever go to Google Cloud, you make a project, that was my baby for a long time.

John Richards:
Oh. Nice.

Zack Butcher:
Kind of through weird historic artifact, that team was part of the team that was responsible for the API gateway inside it. So I was working on unrelated, kind of not on API gateway stuff, but there's a decent little bit of crossover between those parts of the organization. I had spent about two years on the team, and we shipped, basically, the Service Mesh architecture inside of Google to a hundred percent of the workloads there. It's another part of the team, and I got to witness the second right. I helped out a little bit with some parts of it, but I was mainly on GCP stuff. But I saw this ship, and I shipped, actually, a service on top of it a little bit later and saw some of the power firsthand.
Then, some of the folks that I worked with on that larger org said, "Hey. We're going to go off and start this open source project internally at Google on this Service Mesh thing. We didn't call it Service Mesh at the time, and it would be probably another eight or 10 months before we named that project Istio eventually. But I joined that as one of the original engineers on that project, and it was an exciting for me. I was like, "Hey." Inside Google, it's a, very much a walled ecosystem. And so being able to go and work on open source things was something that's really appealing to me, and I thought this was a really interesting problem set.
I actually originally worked on policy side, so mix. Istio used to have a whole policy engine and some stuff. It's been stripped out. I think it'll come back. I've given some talks about how I think it'll come back later. We saw that Istio solved a set of problems for users on the ground, but couldn't get some of our leadership to orient around some of those problems that we were seeing on the ground talking with users. Of course, that's frustrating, right, when big companies move slow.
And so myself, the original product manager for Istio, Varun, who's currently CEO at Tetrate now, as well as some other folks got together to start Tetrate to exactly try and solve some of the problems we saw users trying to solve with the Service Mesh, which wasn't this tactical, is like one of these, "Deploy it." But think we saw, repeatedly, this problem of, "I want to move to microservices. I want to get into cloud. I have some stuff on prem. I maybe have a footprint over there, but really, how do I start to connect these things securely? How do I understand what those connections were doing, and then how do I apply policy to it?"
That's a really compelling set of features wherever you're running your infrastructure, and I think it actually makes it easier to run your infrastructure across different sites. So that's really what we started to solve. That's how I got started there at the company. It's been six and a half years now, so we've been making it happen. It's been really good.

John Richards:
That's really one of the best startup stories, which is the stories where there's a problem, so we got together a bunch of folks and said, "How can we solve this? Let's just create a small group, move really fast, and try to fix this challenge that we see in the market." And so I love that story. I'm glad it's been so successful. How has it been being on that journey now, six years down the road, and going from scrappy, where you are at, to now, a big player in the space?

Zack Butcher:
Yeah. It's been really surreal, actually, in a lot of respect, and it's also been a lot of hard work. I joke with some of my co-workers, sometimes, it feels like it's been three months, and sometimes, it feels like it's been 15 years. You turn around, and it feels ... A lot of times, those are back-to-back dates. So it's been a lot of fun. It's been a lot of hard work, but, I mean, I think it's a good startup story. Because fundamentally, I think any successful startup needs ... You have to be driven by what a customer needs. Right? If you're not trying to solve a customer problem, then what are ... You know? We're just ... You're doing some science.

John Richards:
Yes. Yes. Well, okay. So you got involved in Tetrate, but you've also, specifically in this world of security, I know you've been involved with NIST. So how did you end up going so deep on the security aspect, and what's that look like?

Zack Butcher:
Yeah. So I mentioned I worked originally on the policy side of Istio and all of the security and all. I say policy, and people may actually hear security. When I say policy, I actually mean any decision you want to make at runtime at all ever. But as we were starting Tetrate, our other co-founder, JJ, who's CTO, had been doing research on access control for a while. He was at Twitter and was grappling with some of the problems around Twitter trying to move into cloud.
One of the first problems you run into, practically speaking, is, how do I map identities between these different environments, like service identities and runtime identities and things like that? And so he had gone off and had done some research around access control and different things and started to reach out to some of the NIST folks around some work that they were doing. It just so happened that, literally, the first week that Tetrate existed, we were meeting up in our office at the time in San Francisco. David Ferraiolo, who was the main guy at NIST, happened to be in the Bay. He happened to be there, I found out later, because he was receiving the IEEE Lifetime Achievement Award for creating RBAC.

John Richards:
Wow. Incredible.

Zack Butcher:
Yeah. We used to do a whole episode about him, and we can have him on. He's amazing. He's been doing access control since the seventies, and really, basically, every large delta in access control that you may know about. ABAC was a phrase he coined. RBAC, he wrote the book, literally. Great guy. We reached out to him to ask about some of the access control, because the Service Mesh with its sidebar next to every application is really well-suited to implement policy. And so that was some really interesting access control stuff that he was doing.
We started to develop a relationship together, and we got a collaborative research agreement with NIST as Tetrate from the very early days. Out of that relationship, we came, and I actually came to some of the NIST folks originally and said, "Hey. Look, we think that there needs to be some guidance around some of this microservices, some that move to cloud, some of the Service Mesh stuff, and and so let's write some SPs. That's what NIST does." And so we started to do that together, and there's a few series of SPs now that I've helped co-author.
There's the SP 800-204 series, and there's quite a few entries in that series today. That's really all about microservice security, and it covers stuff from just high level overview of what are some of the threats you need to worry about, down to lower level security, into ... I've been able to pull in excellent co-authors and probably some folks even you've had on the podcast to help co-author some things around stuff like supply chain security and [inaudible 00:08:53]. That's a great set of papers.
The second set that we work on together is 800-207 series. That's the zero trust series, and that one's an important one. That's front and center in a lot of people's minds because of things like the executive order was three years ago mandating zero trust. Finally, funny trivia fact, during college, I actually worked for Colonial Pipeline Company in their IT department, which was the organization that was compromised that resulted in the zero trust executive order. Subsequently, I've actually, then, written some of the zero trust guidance that ... So it's kind of a funny full circle piece, but that zero trust piece is a key one. With 207A, we really wanted to give a practical runtime definition of zero trust, because quite frankly, I was tired of a lot of vendor [inaudible 00:09:45] around what is zero trust and what is not.

John Richards:
Yeah. I've talked to a lot of people who are like, "Well ..." Because of these confused definitions, some people are like, "Well, it can't even exist," because they come up with a definition that, then, can't exist. Can you share some of the progress in that space to get around a more shared definition, and hopefully at a level that maybe if ... people who aren't deep into engineering, they can still understand and get an idea of what is meant when people are saying zero trust, and here's why it's so important?

Zack Butcher:
Yeah. Exactly. So there's two pieces that I want to split out. So when we talk about zero trust, fundamentally, it's a posture, and it's a way of thinking in the organization. It's not trust nothing, but it's make your trust explicit. I actually pushed hard for us to change the name to zero implicit trust, because I think that's actually much more representative of the mindset that somebody needs to be in compared to zero trust. Right? It gives the wrong ... But it's not as catchy. It's not as marketable. So what are you going to do?

John Richards:
Right, but I do love that as a way to help. I suddenly have a very different understanding even with just that short definition change.

Zack Butcher:
Good. That's awesome. And so that's a huge mindset shift, because it really encompasses people, process, and technology. 207A that I authored is much more focused, and I wanted to give a runtime definition of what zero trust means from a policy perspective. Right? So you can talk about all the process and everything that needs to go on top of that, but at runtime, people want to know, "Am I secure or not? Am I in the right posture or not?" Right?
And so I'll give the definition that we give in the SP. I think it's easy enough. I joke. It's five points. I joke we can count to it on one hand, but I'll also maybe give you an intuition that motivates it. So I'll start with the intuition, which is this. You in a zero trust security posture if I can pick any workload in your infrastructure and expose it to the internet, and the impact of that is minimized or mitigated. Right? That's really, because ... How would it be exposed to the internet? I don't know. Developers make mistake every single day. People misconfigure [inaudible 00:12:00]. You know? Any number of malicious or non-malicious ways, their infrastructure's been-

John Richards:
Yeah. I feel a little attacked, but it's also completely true. So I can't say anything.

Zack Butcher:
Hey. I make as many mistakes. I joke when we talk about the service which helps with reliability, the way I get up there, and I say, "Who caused the dox internally? I have." You know? That's the ... "Who's caused the security ..." and say, "Oh. Well." So we want that mindset of, "If my application is exposed to the internet, it shouldn't be, but if it is, what's the risk? What's the impact? Can I mitigate that, or how have I mitigated that?" When you can say with a straight face that, "Hey. My system is as secure if it's internet-facing or not." We can argue ... I give an extreme definition, but that's where you want go to directionally. Then, you're in the right mindset.

John Richards:
Yeah. That's a really nice goalpost to say, "Oh. Here's this spot I want to be at."

Zack Butcher:
Exactly, and so then, how would we ever get there, right, is then the next question. We focus at a higher level layer. So we're assuming you're doing good bookkeeping under the hood. You're keeping things patched. You're keeping things up updated. So now, what are the security things? We argue there's five policy checks you need. So one, all of your applications should be doing encryption in transit. Right? So even out the gate, for example, if you have an internal PKI, and it's exposed to the internet, you're not even going to be able to connect, because there's no trust. That's one of the ways we can talk about implicit and explicit trust. PKI talks about trust explicitly. That's the first one.
Then, services need to be authenticated and authorized. So what do I mean when a service is authenticated? We need a service identity that identifies the application, the thing that's acting, and we want explicit policy. We want to be able to say, "Hey. There's a front end, and there's a back end, and there's a database, and the front end can call the back end, and the back end can call the database, but the front ends cannot call the database." Simple. That's service identity. I gave you three identities, and I gave you an authorization policy, or three of them. Right?
Then, we want end user authentication and end user identity. Right? So it's not enough to say the front end can call the back end, and the back end can call the database. We want to say the front end can call the back end if there's a valid end user credential containing the correct scope, right, and the back end can call the database in the presence of a valid, when I say valid, I mean authenticated and end user credential with the correct scope. What I'm meaning in there is is authorized to access the resource under question. Right?
And so I'd argue if you have those five controls, and not just me, but we argue in SP 207A, if you have those five controls around all of your applications, then you are in a zero trust posture, or at least you're in the right mindset. There's more you need to do besides. There's the people on the process side and all of that. But from a runtime definition, if you can go, "I'm doing those five things," you're on the right track. That's exactly what we argue.
We want to argue a little bit more. We talk about how you can relax some of the network policy that exists today that historically, I see is a really big pain point that hampers agility and the ability to move quickly. And so we argue around how you can start to relax some of those network controls if you augment them with those five controls that we talked about on top, that what we call identity-based segmentation, is the snazzy name for those five controls.

John Richards:
I love it. Thank you for the easy-to-understand descriptions. Even I was able to understand those, so thank you. So I am curious, how hard was it to get okay, to get consensus around this idea of relaxing controls? Because I feel like in security, you never want to be the person who said, "We can relax this now," because sometimes, there's a bit of a paranoia that seeps in. I love the fact that it's almost saying, "Here is a better method, so much so that instead of these almost walls that you try to set up on your network, we're going to have this intrinsic authorization, authentication to really drive this instead."

Zack Butcher:
So there's maybe a couple pieces to pick apart. So one, why did we do the network segmentation and all to begin with? That's because the only notion of service identity we had was the network identity. So that was the only tool we had for service-to-service authorization. So an important thing I say, let me actually back up Meta. In these NIST SPs, the goal was never to introduce new ideas.
So those five things I've talked about, anybody who's worked in security would tell you, "Of course you need to authenticate and authorize, and of course you need encryption, and of course you ..." So the goal was never to introduce net new ideas, but the goal was to say, "Hey. We should be applying these things that we know about and are good in a best practice way."

John Richards:
So it's kinda like identifying people who are doing or groups doing best practices and really defining standards, saying, "Hey. We see that this is the future, the proper way. Let's expand this out even further."

Zack Butcher:
Exactly. Exactly, and that's part of the reason that it's valuable for NIST that somebody like me kind of helps. Because in my hat that I work here at Tetrate, I get to kind of survey a large number of organizations and how they're doing some of these things, how they want to do some of these things, and I can also flavor that with some of the work in GCP. I mentioned I owned projects. Oh. I didn't mention that I also worked extensively on the identity and access management system there, the hierarchy and all of that. And so for me, this has always been kind of an interesting area, as well, and Google does a bunch of zero trust things that I got to see internally. And so it's been a synthesis of all of this stuff that we're seeing and best practices we know about to bring together.
Then, the other thing I'll say is security is always a trade-off. Right? I joke when I give some talks live, "What's the most secure system? It's a computer that's turned off and locked in a safe." The problem is it's entirely unavailable. And so fundamentally, security is always a trade-off between availability and assurance. Right? Security always has to be thought of as a spectrum. You are always making trade-offs. It's never binary.
And so really, what we're saying is that if you are increasing the assurance at higher layers in the stack, and assurance is a key word that we've lost in the security language, I feel like, a lot of times. In risk-oriented organizations, I hear about assurance, but if you go back to some of the literature in the seventies, eighties, nineties, assurance is a big thing that we talk about a lot. What is your assurance that things are safe or not safe? Right?

John Richards:
So we're picking up on the idea of, well, you mentioned assurance, but being able to relax some of these network controls versus, yeah.

Zack Butcher:
Exactly. So we get assurance at a higher level, right, because we've added that identity-based segmentation, those five controls. And so the argument is, that we make in the paper, that where other lower-level controls like, for example, network segmentation then hamper agility of the organization, we should feel justified in trading off, because we've increased assurance elsewhere. That's fundamentally what we lay out, and we talk about even some runtime patterns. The parallel we give in the paper is the idea of VPN. What does a VPN do? We deploy some gateways around, and it allows us to connect to network domains. It allows us to transfer network identity across a boundary, and we use that policy to determine who can access what. Are you on the VPN? Well then you can access the resource. Right?
We propose, and actually, Tetrate helps implement a bunch of folks, a very similar idea, but at layer seven with application identity going over a set of Envoy gateways. Because Envoy's the data plane technology that we use that lets us link together different sites at an identity level. So where a VPN lets you link together different networks at a network level, here, we're linking these different identity domains and facilitating network connectivity so applications can go across. That is another example of a place where you can use a policy like that, where these gateways communicate, and there's simple firewall between the gateways, and eliminate the kind of crazy firewall rules that are required for end-by-end apps to communicate across the boundary. That's the same reason we use VPNs to access internal systems. Right? Because it simplifies that access model. So again, something not fundamentally new, but applying these techniques at maybe a higher, at a higher level.

John Richards:
Now, and then, I guess, the metric, it sounds like you're saying here, is you're like, "If you implement this, you end up with a higher level of assurance."

Zack Butcher:
Of assurance. Exactly.

John Richards:
And so then you're okay saying, "Hey. I lessen this, because my end result is I'm more confident in the connection and security we've got here."

Zack Butcher:
Exactly. That's exactly correct, and we're not saying, "Hey. Get rid of all your network-level security." But we are saying where it is painful and where it causes organizational pain because of process, because of slowdown, because of that. Then, you can justify relaxing it in exchange for these other controls. Then, maybe what is implicit here that we're saying as well is that identity-level controls are easier to manage, because they're closer to what human beings can read and understand compared to network policy like CIDRs. What's a CIDR? Which things are on the network tag? Who knows? But I can read front ends, and I can read back end. I can read the front end is allowed to call GET on the back end, and that makes sense to me as a human. Therefore, policy, we can be more confident in, we can offer faster. Right?

John Richards:
I love that. I love anytime we can make things easier for actual humans to understand. It lowers the chance of mistakes.

Zack Butcher:
Exactly.

John Richards:
People are able to onboard, learn faster, and kind of adopt that. That's awesome.

Zack Butcher:
That's exactly right. And so that really gets to the heart of what we mean with this relax the lower level, augment with these higher-level controls, and get agility out of it because you're able to move more quickly.

John Richards:
How much do you see, because you also had that work in the mesh, microservices space, how much do you see the growth and adoption of that driving some of these new changes? Because it seems like there's some connection here between these two.

Zack Butcher:
For sure. I mean, I see them go hand in hand. Right? I mean, part of it's because I work in one hand or foot and help write them in the other. And so of course I'm going to write about what I've seen, but I do think that we're genuinely capturing some of these larger trends. The other thing I'll say is while, and we've written about in the SP 204 series that we actually do believe that the Service Mesh is the best way to implement a lot of these. This goes back to some of the 1970s arguments around the security kernel in the reference monitor. If people want to go Google those things, security kernel is exactly where we get the idea of the operating system from.
So the idea is that you want a common layer that is high assurance, this is where some of the assurance language comes from, the idea of the security kernel, that does all these common security functions on behalf of all the other stuff that's running. That's exactly what your operating system kernel does on behalf of user space applications. So the NIST was very interested in the Service Mesh as in the idea of it being a common enforcement layer across all the heterogeneous applications in your distributed system.
And so when we said, "Hey. Here's the paradigm that we do things," and we were working on access control policy, for them, they looked, stepped back, and they said, "If I draw the architecture of the idealized access control system, it actually looks the same as the architecture of the Service Mesh." Isn't that wild? It's not a mistake that it looks that way. The two developed in divergent ways, but they have a common set of needs that brings you to that common architecture.
That's why the NIST folks thought, "Hey. The mesh is really compelling and really interesting. It lets us get back to some of these, at this point, half a century old ideas around how we want to secure systems that we've been using for half a century to secure our systems." So there's some there there, the ideas.

John Richards:
Yes. What is-

Zack Butcher:
That's why it was compelling, and that's why we had that crossover, I think, between the mesh and some of this more fundamental security stuff.

John Richards:
Well, I love that the finding is that security itself, the core concepts aren't what's changing. It's easy, as a new technology comes along, to say, "We need a whole new way of doing security to handle this," when often, it's more, "How do we look at what we're already doing and figure out how to move that into this space, yeah, adapt it over." So I love that. "Hey. We know this is a secure way to function. How do we make that happen here at a, obviously, much larger scale, but kind of still using those same concepts?"

Zack Butcher:
Exactly. Exactly, and that's way I ... I think that's when you're onto something fundamentally powerful, when you find this concept like that that can scale up. Right? That, for me, is one of the things that's really exciting about a lot of this work.

John Richards:
Yeah. For sure. No. Yeah. Teasing there about all the new technology. Obviously, AI is ... Everybody's like, "Hey. How is this going to impact things?" Are you seeing anything where this fits in to either help with the security here, or is it something like, "Oh. This is still a wild card. We need to figure out what we would do"? What are your thoughts about how AI can be used for security on this level of authentication and identity-driven?

Zack Butcher:
Yeah. So I see maybe two aspects around AI. So first, I'll talk about, how can it be used in some of this stuff? When I said, "Hey. You need to authenticate and authorize services and authenticate and authorize users," that's a very short thing to say that belies a lot of complexity and a lot of really hard and challenging engineering. One of the really interesting things is systems that do risk-based access. Right?
So, for example, hey, I happen to live in the US, and I access from an iPhone. Suppose I've been accessing a corporate system in the US from my iPhone for the past couple of hours, but I go offline. Suddenly, I pop up in, say, Eastern Europe on an Android accessing the same system. Should I have the same access or not? Well, that's an ... Inherently, it's riskier. Why is it riskier? Because you know my context. How do we then make that decision? That is an interesting place where I think we can use AI, and so this policy and decision making. It still needs to be auditable, obviously, and there needs to be a lot of ... There's a lot of stuff that goes into that, because people get really angry when you don't allow their access in the right way. But that's one of the compelling places where I think that there's some interesting policy decision making that goes in. Right?
The other big place where AI systems come into play here is that they need to be secure just like any other system that we're dealing with. Right? And so those five fundamental principles around building a zero trust system need to be applied to the systems that we're training, to the systems that we're serving AI with in similar. Then, maybe the final piece that I think is really interesting, and I think this maybe has been ... There's been some new stories from prompt injection and things like that, but what is the data provenance, and what is the data that's coming out of your AI systems, as well?
That's one where, additionally, I think, because the service meshes, the technology is in the data plane and can see the bits and the bytes that are going to and from the user, you're in a unique position to be able to report metrics and potentially even enact policy and do things like stop that data that's going out. I think that'll be another interesting area in the future, so this data-level security and implementing that. I think that's important regardless of AI or not, but given how AI systems are being deployed and used today, I think it's maybe especially relevant.

John Richards:
Yeah, because you don't quite know now what's ... Now, when you talk about this, is this plane happening in the layer where the AI is accessing the data or as the AI is transferring that data out to whatever the end recipient is?

Zack Butcher:
In the fullness of time, we will see controls happen at both places. So for me, with the Service Mesh, it's really where you respond to user traffic, because it's really more in the network linkage between different parts of the system. However, that data governance, data provenance, data labeling, and then how that is allowed to go out to the system, which is internal to the model in some sense, is essential. I think we can use a lot of similar techniques. A lot of the same kind of access control, for example, that we use for service-to-service is readily amenable to being used for doing data-level access control, as well.
That may be a quick teaser, because I know we're short on ... we're running up on time. So quick teaser I'll whisper for people is the name of some of the access control research that we do with NIST is called Next Generation Access Control. There's a data flavor of that called NDAC, Next Generation Data Access control. Those are really cool things. There's some white papers. There's an anti-standard around it. That's how we do a lot of the magic with service-to-service access in really sophisticated ways. It's an awesome graph-based access control system, and it's part of what I research with NIST.

John Richards:
Ah. Incredible. Well, that's a perfect, yeah, teaser here to end this on. Zack, before I let you go, thanks again, but how can folks get ahold of you? Anything you want to shout out that folks should check out? We can drop some links here to anything you mention in the podcast notes.

Zack Butcher:
Yeah. Yeah. Thanks for listening. Certainly, we'll drop some links for some of the NIST SPs for folks that have to work in the security space. I really try and write readable SPs. A lot of the stuff that comes out of NIST I know is painful to read. Trust me, I know intimately, because I've had to read them. I try to make them at least a little bit more readable than average. That's a low bar, but we try to do it. So please check those out.
If you're doing meshy stuff, if you're looking at Service Mesh, if you're looking at, "How do I connect and secure my workloads?"dDefinitely come meet me. Drop by Tetrate. We can help you out. If you're interested in learning, there's a bunch of stuff at academy.tetrate.io that's free, free training on Envoy and Istio, a bunch of stuff that's valuable there. So check it out, and John, thanks for having me today. It's been a blast.

John Richards:
This podcast is made possible by Paladin Cloud, an AI-powered prioritization engine for cloud security. DevOps and security teams often struggle under the massive amount of notifications they receive. Reduce alert fatigue with Paladin Cloud, using generative AI, the model risk scores, and correlates findings across your existing tools, empowering teams to identify, prioritize, and remediate the most important security risks.
If you'd like to know more, visit paladincloud.io. Thank you for tuning in to Cyber Sentries. I'm your host, John Richards. This has been a production of TruStory FM. Audio Engineering by Andy Nelson. Music by Amet Segui. You can find all the links in the show note. We appreciate you downloading and listening to this show. Take a moment and leave a like and review. It helps us to get the word out. We'll be back October 9th right here on Cyber Sentries.