Episode nine of the podcast, These Guys Literally Wrote the Book, features Rob Freter and Joe Brinker from True Zero Technologies, delving into the evolving implementation of Zero Trust principles across the Department of Defense, the Defense Industrial Base, and the broader federal government. They discuss the importance of starting with a clear problem statement and solution, emphasizing the cultural and practical need for a structured approach to security, including policy enforcement points (PEPs). Drawing analogies to cinematic sequels like The Godfather Part II, the episode explores how Zero Trust architectures have evolved to be even better with their second iterations, offering cleaner lines and easier readability.
True Zero Trust Ep. 9
[Tom Tittermary]
Did I go over? No. So over there, bullets.
Okay. Well, cool. Well, hey, everybody.
Welcome to another episode of Zero Trusts Given. As always, I am your host, Tom Tittermary, here with you this week to have a conversation about Zero Trust and how it's being implemented across DOD, the DIB community, as well as the general federal government. As always with me is my illustrious, intelligent, incredible co-host, Tom Gianelos.
Say hi, Tom. Hey, everybody. And guys, this is a big one.
This is a special one. I've been waiting for this one. The guests that we have today, I've gotten to know through industry for a bit.
I'm going to let them introduce themselves. We'll start with Mr. Joe Brinker. Yeah.
Joe Brinker, Director of Federal Services at True Zero Technologies.
[Rob Freter]
And Rob Frieder, also with True Zero Technologies. Currently, their Zero Trust practice lead.
[Tom Tittermary]
So the number of times in this podcast that I've referenced the DISA Zero Trust Reference Architecture V1, and literally asked people listening to the podcast to open to a specific page or look at a specific diagram, as well as the DISA Zero Trust Reference Architecture V2, is most of the podcasts, if not all of them. Across the table, guys, why don't you tell me what your involvement was with the creation of those documents?
[Joe Brinker]
Yeah. No, thanks, Tom. So we had the pleasure and honor and challenge of being tasked with developing this.
It was something that was brought to us by DISA senior leadership, proposed as a partnership between DISA, NSA, DOD CIO driving a lot of it, with Cyber Command being the requirement owner. And the challenge to us was, hey, there's this concept that's in academia and industry right now, it's called Zero Trust. General, now General Stanton, had the idea of, hey, you know, defense in depth is great, but it's not working like it's been designed to.
Breaches continue to happen. Adversaries are evolving. How do we get ahead of this?
There's this thing called Zero Trust. How do we take this concept of Zero Trust and apply it to the unique use case that is DODIN? So that was really our challenge of taking this, understanding what Kindervog did and what this concept was, and then really taking that, digesting it and then, I wouldn't say recreating, but really reapplying it to the unique use case of the DODIN infrastructure.
[Rob Freter]
Yeah, and I think what's interesting is, you know, we talk about the Zero Trust reference architecture development, but we don't talk a lot about, you know, before we said we're going to write a paper, right? And what's interesting is, and I think this stands true for a lot of folks, is how do we actually pilot this and put it into production, right? So there were kind of two thoughts when we started this process.
One was the mindset of, I have an idea and I want to build it. I'm going to leverage the Zero Trust term, right, at the time to go and build something. And as we started doing that, we started running some of these pilots within the department.
We quickly recognized that we needed some terminology behind this thing, right? We need words matter in the department, whether it's contracting language or you're an engineer reading a document, right? So how can we create something that will kind of live beyond a pilot and be applicable to additional systems?
So that's really why we wanted to derive, you know, the architecture was something that folks could reuse over a certain amount of time. We can get into kind of details if you want about the versions, you know, the difference between the versions, because a lot of folks bring that up. But yeah, I think principally, we recognized that we needed a authoritative reference for what this thing Zero Trust meant for the department.
[Tom Tittermary]
So I'm going to 100% geek out and say thank you at the same time. The number of times that I have put together or put in front of people, anywhere, people say, hey, Zero Trust is a big nebulous concept. It's like cloud, it doesn't really mean anything, right?
And I put, I just put in front of them the OV1 diagram from Zero Trust Reference Architecture B1. And I go, no, this is it. It's very clearly defined, it's in one place.
Like, every vendor at this show might tell you that they are the only vendor of Zero Trust, and they are the one and they do the whole thing. This is a clearly defined thing. There's hundreds of pages out there for you guys to read.
I mean, this for me is kind of the amount that I talk about Zero Trust. This is like a Marvel geek sitting in front of Stan Lee. So I'm gonna, I'm 100% going to take the opportunity.
So for the, let's start with the V1 document. So where did this all start? What did the discussions look like?
Could you walk us through like, what was some of that process? And then, you know, on the end of the process side of things, what was some of the reception like?
[Joe Brinker]
Yeah, I mean, it was, it was very organic. And I can say that it was, you know, it was a meeting of the minds of people that had a, an aligned focus, you know, an open understanding that we need to improve cybersecurity for the department. And how do we get about doing that?
And we all agreed, hey, you know, after understanding what Zero Trust is, you know, yeah, this is the future. This is what we need to be doing. So there really was not a whole lot of, you know, across the board, trying to win hearts and minds between the group, like we were all on the same page from day one that, hey, this is the right answer.
I think there was a lot of conversation about, you know, how do we get after this? How do we prove it out? How do we, you know, how do we approach it?
And there was a great conversation that went around that, you know, there was, there was a group of folks that said, we need to prioritize meeting the customer where they are meeting the mission partner where they are with the infrastructure and equipment and tooling that they have on their maturity plan. And then there was another thought of, hey, well, we should also be looking Greenfield, you know, for those that are coming new, what does it mean to roll out a Zero Trust architecture, and design from the ground up a true Zero Trust solution compliant out of the gate. So it was, it was a cool conversation and kind of work group to be a part of to have, you know, people that were strategic thought drivers in this space, looking at it from multiple angles, and then ultimately coming back, bouncing ideas off each other, seeing what stuck.
I'm not going to say there weren't points that weren't contentious, because there were, but it was never animosity. It was always positive, like, how do we grow? How do we get this better?
And ultimately, again, driving to that that aligned mission?
[Rob Freter]
Yeah, I think, you know, Joe brought up the term organic. And I think a lot of it was extremely organic. Because even before we thought of, you know, a DODAF compliant architecture, we were thinking, like, what are the requirements going to be?
Should we make a list of requirements, right? Because you have a bunch of geeks in a room, which I think that was a huge driver was we did have this, this joint space with the agency with Cyber Command with JFHQ, DODE and CIO folks in the same room able to talk about these hard problems for extensive periods of time. So it's definitely not done in a silo, which, which was very important.
But, you know, we start building these pilots, we start actually physically building systems, and we recognized, okay, let's build a list of requirements. Okay, then we went from requirements, we need something more abstracted to apply to multiple scenarios. We talked through use cases.
I think what's interesting as well is, you know, we can get into use cases later, but the remote, the remote workforce, right, we started shifting during COVID to this vast remote workforce. So use cases closer, like Google beyond corp, and some of their efforts initially was zero trust and, and driving, you know, security at home is equal to security on site, right? If you're at four meter, whatever infrastructure you're at.
So being able to have that that equivalent security was critical. But yeah, I think just having the time to sit jointly in the space, and that kind of naturally flowed from requirements, we shifted from requirements more towards an architecture folks could kind of understand, based on the Dota flying architecture.
[Joe Brinker]
I think that's a really good point, too. It was a unique situation to be in, right? Conversations started out about this kind of ethereal concept.
And, you know, how do we do this? Or, you know, back people's minds are like, how real is this? Or, you know, when are we, when are we going to be in a situation that's driving that?
Is that, you know, a year from now? Is that tomorrow? Is that five years from now, then all of a sudden COVID hit?
And I was like, wait, this is a real world use case, where this matters today. So it, there was a lot of cool things that kind of happened from that, right? Well, that one, there's the added pressure of that.
But to it, it made it took it from, you know, vaporware concept to know this is real, this is now, you know, and, and yeah, this is today, we need to solve this.
[Rob Freter]
Yeah. And I mean, to Joe's point, looking at the tenants of zero trust, right, we can talk about breach, we can talk about these other concepts. But when you're working from home, it really does bring that concept to bear you are on probably a very unprotected network, right?
You don't have guns, gates and guards stopping you from from accessing sensitive information. So being able to bring to bear that equivalent security, this was the time that we could geek out and think through what does that look like? And what is the future of zero trust in that space?
[Tom Tittermary]
I think it was really so you said you said organic, right? I think it was really interesting that COVID ended up being the compelling event that gave you the opportunity in that context. I'll use the words creative and innovative.
Like I watch a lot of different things that happen across the federal government DoD, which are 10% better. But this was I need to reimagine how this works away from like perimeters and walls and moats and guards and gates to know this needs to be inside out and least privilege and and top to bottom and then to be able to take that and get very granular. And it was very clear, like a lot of times you'll read a document like that.
And it's, you get to the end of the document, it's where do I start? Or what do I do? But like, the way that you guys broke it down into the individual pillars was super helpful for us out in industry at the same time.
[Rob Freter]
Yeah. And I think that's getting a little bit into the version one versus version two. We want to get something out there quickly, right?
Version one is a fantastic document. But the structure is a lot different, right? So we recognize the difference between version one and two was, well, first off, we have a lot of folks that have a lot they want to say about the first version, right?
So a lot of different mindsets on what zero trust is. And we had time to cache a lot of the lessons learned from architecture one, adjudicate the vast amount of leftover comments. And also the big focus was shifting it from, you know, if you look through version one, it's a lot of lists, right?
It's a lot of just, okay, go through this, and this, and this, and this, there's a lot of definitions and terms. To make it more compliant with DODAF in general, we wanted to shift that to these views, right? We have more CVs, we have more OVs, so it really describes the situation to the reader.
You know, we have problem statements in there. We have these other things. So anyone, even a non-technical person can read through this and understand the purpose of zero trust, its core tenants, and drive that, right?
We have better views of the subsystems in there in version two. We spent a lot of time on work. We brought some, you know, folks smarter than me that knew DODAF very well and brought in capability views that you could actually say, I can build something to this, right?
It's not just word salad all over the place and trying to kind of, you know, go from page to page. You have a concrete set of visuals to help folks build a system.
[Joe Brinker]
Yeah, I think that was the driver, right? Was we need to get something out. You can't wait for perfect.
And I think that's kind of what you saw with 1.0. 1.0 was good enough. It was good enough to start the conversation, to get the core concepts out there, the tenants, the pillars, what are we trying to achieve? And, you know, again, like we were here representing a much broader team, right?
That was beyond the triumvirate of organizations that, whose names are on the document. It's, you know, it was a lengthy process of getting feedback from, you know, some of the sharpest strategic cyber thinkers within across the department who were, who digested 1.0 and the drafts of 1.0 before 1.0 came out and gave tremendous feedback to the point where it was staggering for us to get through in order to get to 2.0. Yeah, I think to Joe's point, just the staffing process, right?
[Rob Freter]
We did not do this in a silo. I was looking back at some of my notes from, it's been a while now, but looking through the staffing process of this document, I mean, we went through 12 stages just to get this thing up to DOD CIO for approval. I mean, we had multiple CADM's tasks out there.
We had technical leadership involved. We had strategic leadership involved from all the MILDEPs, everyone else. So it was definitely not done in a silo.
And we knew kind of the process from one. So a lot of folks, you know, it was quick. We went from one to two, right?
Industry still has to adjust with these things, but we recognize the process. We were able to repeat a lot of the existing governance structures and do that for version two. So I think that helped expedite it and get it in a good place faster.
[Tom Tittermary]
I'm going to make a really silly allegory metaphor. You know, I'm going to make a comparison here, right? But the Zero Trust Reference Architecture V1 is the Godfather part one for me.
It lays the scene, it lays the universe, it lays it out. And then you hear Godfather part two is coming out. I'm not quite that old that I was at Godfather part two, but I'm going to continue with my age references as I do in every podcast.
But then Godfather two comes out and you're like, whoa, whoa, whoa, this is different. But it's better, right? Like it was an extension to me of the original.
And, you know, it's interesting that you guys went with problem statement and solution statement because you made it clear as a bell when you look at problem statement. I think it was a bold move to say IAP and BCAP in the problem statement because those are kind of the known things. But when you come around to the solution statement and you show, you know, SASE SDP coming across the top and the way that the architecture can change, it made total sense.
And you put those diagrams one page after the other, it makes complete sense. For those of you at home, Zero Trust Reference Architecture V2, it's in the first five or six pages. I encourage you to go look this individual piece up.
But was that an interesting conversation internally in building a problem statement and a solution statement? Or was that just like de rigueur for the activity?
[Joe Brinker]
I think you probably are closer to that than I am. I know there was, I think, we entered into it knowing that the audience for this document was going to be broad, right? It was going to be everybody from, you know, senior leaders that have been tasked with, hey, you need to quote unquote zero trustify your environment down to, you know, the individuals that are executing on it, right?
That need to know it more granular than that. So, we knew that when writing it in order for this thing to be effective, we couldn't make it read like a VCR manual. It needs to be, you know, consumable by people, you know, of all technical acumen.
And that was really the goal. You know, I think the colloquial term is, you know, kind of write it so that your grandparents can understand it. And that's how it's going to, you know, have weight and merit broader than just to, you know, that really skilled community that can, that is in that space that likes a technical document like this.
You're trying to make sure that it was, you know, accessible by people, again, of all technical complexities and experience such that they can understand it and really understand, hey, what are we trying to get after here? Like, we talk about this thing, there's, you know, large budgets that are being crafted and money is being set aside to move to this. What is this thing?
And not everybody who's in that decision line is going to be, you know, Toms and Robs here who can understand this stuff. You need people that are, you know, budgetary folks, programmatic folks, leadership folks that may not have a technical background that can understand it quickly. So, it was by not having that kind of, you know, level of accessibility in the front.
You know, what does it look like? Give me a picture. What does this mean?
Okay, what are we trying to get after? What is the problem today? You know, what are we trying to solve with this thing and how do we get after it?
So, yeah, it definitely was by intention to have that up front and to make that clear.
[Rob Freter]
Yeah, and I think a lot of it, you know, there's part of it that's the ease of read, but there's also, you know, you want to see the light at the end of the tunnel with the problem statement and solution, right? Culturally, you know, I know when we started this, a lot of folks, zero trust was a dirty word, right? A lot of times, it seemed like a negative.
It's going to cost more money. We're going to have to do a lot more things. Look at this long, extensive technical document.
Now I have another list of things to do. So, I think the problem and solution statement bring to bear, number one, there is an issue. We are moving to our remote workforce.
We have sensitive data adversaries in our networks, right? How do we address this? And then two, you can build a solution.
This thing can work. And I think that that was really important to bring to bear in the front of the document. So, folks can, as they're reading through it, not just see it as a checklist or additional security features they have to buy, right?
It is something we want to solve and you can solve it through these means.
[Tom Tittermary]
Yeah, I think the biggest thing for me with both documents was, just to clear as a bell, we're going to pivot away from, you know, proximity on or location on a network does not grant any access, right? Everything moves over to identity. I think everybody got that super clear as a bell.
We had Dan Miller from Ping in here, having a conversation on another one to talk about that piece of it. What really struck me though, was in the reference architecture V2, in the solution statement, you guys, I mentioned on the podcast, like we have talked about what we're going to talk about before we talk about it. We talked about this a little bit earlier, but there's a clean line kind of straight across the center for that PEP, that policy enforcement point model, that very specifically has written in their SASE and SDP, which to me, there just weren't a lot of places in the department that had executed on one or either of these individual capabilities.
What was some of the thought behind that piece about putting that across in the solution statement?
[Rob Freter]
Yeah, so I can start with that. And I think a lot of it has to do with, number one, we learned from version one and talking to industry and moving forward. What are some of the new technologies coming out there, right?
What are the key terms that we're going to leverage? SDN was used prior a lot. I feel like software-defined networking focuses more on how do we have that abstraction layer for the management of the network, right?
We want that management plane there. But the control of the policy enforcement point and SDP, in my perspective, provides a security overlay to that, right? It's not just to make networking easier or to control your bandwidth in certain areas, but we're actually leveraging a software-defined perimeter to say, it doesn't matter where you're functioning from.
What matters is that you have that control plane through your policy enforcement policy decision points. So it doesn't matter, right? I mean, the concept of, hey, I want to operate overseas in a potentially hostile environment.
That's going to be done through something like SDP, right? Because we're not going to control the networking there. So I thought that was critical to Barisazi as well.
I can't remember all the details from the joint conversations we had, but we found that these were known terms that were leveraged by industry, by standards, and we could start to bring them in. These weren't just kind of pulled from a particular vendor, but there was joint agreement that these were terms we should define within our architecture to use forward because that's the way that the world was going with technology.
[Tom Tittermary]
Yeah. I mean, one of the big pieces I talk about, when we talk about SDP as Zscaler, and it kind of conflates against, there's a product we have in the Zscaler house called Zscaler Private Access, ZPA. What I always, when I'm having a conversation with customers and it's like, all right, why ZPA or why SDP?
It's because every single one of the adversaries that we have out there, they have the same playbook. As they look for the front door, they exploit, they use a vulnerability, exploit the front door. They find their way in the network, they find a soft host, they exploit that host, and then they destroy your exfil data, right?
What if I could disrupt the playbook of every single one of my adversaries? And then SDP very clearly, you go, oh, no, that makes sense. And it all hairpins around identity.
And I could use all my attributes from my identity system. And then I can map it across a bunch of different PDP that I have from the host as well.
[Rob Freter]
Yeah. And I think one of the terms I've really liked in industry I've heard is infrastructure cloaking. I really do like that concept of, hey, it's not going to be available at all until you have this broker.
And I believe we break that out in version two as well. When we talk about, you know, SDP in general, we say, hey, there is a broker. And only after authentication through your service, or whether it's checking the vulnerabilities in your system, whatever it is, if it's a, you know, comply to connect solution, we're going to couple all this provide a risk score.
And we're not even going to broker the connection to that. Until all of that authentication is done. It doesn't exist to the internet, it has to come from this resource.
I think that's incredibly powerful and something we saw in software defined perimeter.
[Tom Tittermary]
Well, it's one of the other, it seems like a no brainer after you get it implemented. We've done this through a number of system integrators and then all of a sudden it clicks and they go, oh my God, why did we ever do it another way? The user doesn't need to know where a system is implemented.
They don't need to know if it's an AWS or Azure in a data center. There's no value to anyone but an adversary to know physically and on what network segment this thing lives, right? And then just to go back to the whole SDN, SDP thing.
So from a software defined networking perspective, I've seen a number of folks try to solve this challenge at layer three from a software defined networking perspective. But the phrase I always kind of hairpin back around and I just haven't had too much pushback from DOD is, I don't think the solution to this problem is more smaller networks, right? It's about being able to collect all this PDP data and then make one-to-one connections in an SDP model to be able to put a, to get users and non-users secure access to DAS, data applications, assets and services.
[Rob Freter]
Yeah, I can see the argument there. I would also say that the micro-segmentation, so we're assuming breach, right? I do agree with you from external end, but if there is a breach, I also think that the micro-segmentation comes to play.
That's where it gets more into the policy enforcement point architecture you want to deploy, right? I think strong micro-segmentation is critical to understand, hey, can these systems talk to each other, right? Can we limit that?
Do we have any type of micro-segmentation built in from like the ports protocols level between the front-end web server to the backend database, right? What are we restricting internally? I feel like you really have to baseline and understand your environment as well.
Then that helps drive where that entry point is going to be, right? So I feel like there's a balance between, yes, the technologies for SDP are extremely important to kind of move away from where is your network. But when we get there, if we don't have the segmentation, we don't even have the enforcement points ready to block it, right?
So whether that's done through like a control plane, like I know Zscaler has products that do provide that through like ZPA, where they can define the networking kind of for the user and they can only access those things. But you still have to build your definitions, right? There's still the, and I'm a huge proponent on, you know, don't skip the baselining.
Don't skip understanding where the keys of the kingdom are. Because if we just put and leverage something like a ZPA as a firewall, it's not really going to stop the adversary, right? But if we leverage it and architect it around, hey, this is the micro segmentation construct we're using from a technology like ZPA, it's incredibly powerful.
[Tom Tittermary]
So I'll lay out something that may come up in the work that you're doing as TZT, right? So when we're talking about solving zero trust for the DoD by 2027, there's a perfectly clean identity and fully correct attributes across all users in all contexts. We have to nail down host security.
We have to have a clean log mechanism to be able to collect all of that. We have to accurately tag every individual piece of structured unstructured and semi-structured data in the DoD, even as it's being produced. And then I need clean policies.
I need to know every individual application in the DoD to be able to associate those identities to those applications. It's a lot, right? Which one of those...
There's a thing that we could do on the Zscaler side that kind of eases some of the application discovery piece of it. Like we can run ZPA in a wildcard and it'll say, here's everybody that's touching everything. And then by the way, here's some recommended policies around that.
The data one is one that I've gotten into a lot. And it makes me... If we don't hit 2027, that's potentially the one where I have the most agita around hitting that.
But just offering all that out there. And you're working at TZT. Have you seen the same thing?
Any difference in that when you're having customer conversations?
[Rob Freter]
Well, I would say in general to start, especially in the commercial side with some of our customers, it's easier to scale, right? A smaller customer is easier to sit with. But I don't think it is much different.
It's just a larger problem for the department. So when we have a commercial customer, we still are doing the things where we're sitting with the different administrators. We're saying this is your role.
We're going to clean up your Active Directory, because if that's not tied properly to Zscaler-like solutions to provide that access, you're still kind of out of luck from a security perspective. So we do very in-depth interviews with our customers. We identify all the services they need to access so we can define those policies within Zscaler-like capabilities.
I think there's a lot of technology now that I think helps baseline. I think that's extremely important because we shouldn't stop staging the technology just because we don't know, like I said before, the keys to the kingdom or how we want to do micro-segmentation. We should still start building these technologies in.
A lot of them can be used passively, right? We want passive collection to understand our baseline of our environment. Then we can tune the technologies to start building the structure and control around our micro-segmentation.
[Tom Tittermary]
Yeah, and some of these things, it gets interesting, right? So especially when you're talking about the DoD and data authorization, data is being produced at a rate faster than humans can accurately tag it. So the immediate thing goes, oh, well, we need computers to tag this data, and then you get an AI and ML.
The big thing that I run into is, am I comfortable letting a system where I can't look at how it came to the conclusion touch sensitive data? Has that become a topic of conversation for you guys or how we go out and solve it? More to the point, if you want to name an individual vendor you think is doing a good job of automated data tagging, it's something I've been hunting around and looking for.
[Joe Brinker]
Yeah, I mean, I would say just kind of going back to the earlier part of this conversation about what the process was like. I mean, I think data tagging was always identified as that long pole. That was always the one that was going to be the hardest to crack.
What does that look like? How do we get to a same site picture, same tool, same approach to doing data tagging across the department? And to your point also about identity, identity had always been defined as this is the foundation of the Zero Trust framework.
It all relies on identity. And I think that's one cool thing that we are seeing in the work that we do is this openness within our mission partners to move away from homegrown systems for identity. Identity for a long time was just kind of like, oh, this is how we access our system and we can just build that.
And now they're realizing that identity can do so much more than just access and that there's extremely powerful tools that can really simplify and allow for identity integration of these outstanding tools throughout your system fairly easily with light lift. So we are seeing more and more kind of move away from an acceptance of identity as a security concept beyond just access. So that's definitely something that's been encouraging.
We've been seeing a lot of data tagging. I'm going to pitch that one to Rob because that was one that we've highlighted from up front. We had a lot of discussions internally.
We were driving 1.0 and 2.0 of what is the right solution? What's the approach to that? Not even looking at AIML and technology-based data tagging, how do we do that as a thing?
Because in the IC, they have solutions for that, more so that are put in place and more commonplace than have been widely rolled out within DoD, at least when we were sitting in our desk at that time. So I don't know if you have anything to add to that, Rob.
[Rob Freter]
Yeah. So I think it's interesting. I like what you did point out about how do we trust the AIML if we're leveraging this for data tagging.
It's interesting to me. Hallucinations, anything else that's coming out of a large language model, particularly if you're talking to it. But I do think that it's a key enabler, just like the term cloud or anything else.
I mean, we have so much data. And if you look at CISA's maturity model, they talk about towards optimal tagging structured, unstructured data. It goes through pretty much anything.
I think we do have a bit of a misnomer in the DoD that data tagging is just classification. Something I always brought up to leadership was, well, how do we address that if everything's unclassified environment? Right.
That gets after a harder problem because in the DoD, classification is, you know, the Bible when it comes to how are you securing your information, right? What networks can it be? Well, if we're ignoring network, where do we go?
So that makes it a lot more difficult. I do think, though, machine learning is a key enabler. I think there's going to be some time that it has to baseline the data.
And there's going to have to be some structuring around what that looks like in the confidence level we're getting it. But I think it's definitely a key enabler as far as kind of moving forward with data tagging.
[Tom Tittermary]
Yeah. This will be the third time I've talked about it on the show. So apologies if you're an avid listener and you listen to more than one.
I apologize in advance, but I think it's germane to the conversation. I'm an advocate and I've spoken about it before where I believe that I'm an old I was pre-med my first year in college. I don't mean to brag, folks.
I was going to be a doctor and decided, yeah, no, I can't do that. So if you think about taxonomy and you think about biology, right, there's an immutable structure in which anything that walks, crawls, swims, grows, fungus, mold, any new thing that we find, there's a place for it in that established taxonomy. And it's a top down kingdom, phylum, class, order, family, genus, species.
So I don't if that to me seems like what DOD or federal government is going to need at the end of the day to have a fixed taxonomy, Charles Linnaeus binomial nomenclature, whatever, something where all of these individual things can fit. But it gets to be a really interesting conversation philosophically when you're like, all right, what's the top? What's the kingdom?
Is that classification? What happens underneath that? Is it enterprise tactical?
Is it MILDEP? What are those individual pieces as you make your way down the mix? But I think until there's a like a defined immutable taxonomy that can expand when new things exist, then everybody's going to continue to have their own structures and then have issues kind of working together.
[Rob Freter]
Right? Yeah. Yeah.
And I agree with you, Tom, as far as, you know, kind of the lineage of where the different data tagging should come from. I also think there's mission relevance. I think there's mission that has to be tied.
I know we worked projects previously where we talked about just how are we going to talk about, you know, having a server name be aligned to the right duty component mission set down. Right. So even that was a difficult called enough conversation.
I also think when it comes to data, there's a lot of different types of data, right? We have the classification of the data or really attributes of the data itself, the classification of the data, the telemetry of the data, the data itself, right? Security meta tags, all these different things.
And there's different structures around that. So, I mean, I don't know too many organizations that even agree. Should I be using like elastic common schema?
Should I be using something else? Right. What is just going to be the data normalization we use to put this in here?
So that's a whole nother discussion is if we're talking just security data, can we normalize that across multiple systems? And what are we using to parse that out? So it's digestible by, you know, multiple vendors, multiple technologies.
[Tom Tittermary]
Yeah. So when you guys are doing your work as TZT, what is, what's some of the methodology that you walk into individual customers with? I'm assuming, you know, a lot of the conversations start with, we want to have a conversation about how we go from current state to zero trust.
What does that process look like for you guys when you go through?
[Joe Brinker]
Yeah. I mean, kind of going back to what we talked about before is meeting the customer where they're at and really having those open conversations about, you know, what are you trying to achieve? Ultimately, from our standpoint, you know, our focus at TrueZero is cyber resilience.
And it's been interesting coming over here and bringing, you know, Rob and I's background about, you know, from the DoD zero trust focused and talking with the TrueZero leadership team about their approach to cybersecurity. And, you know, we were talking zero trust, they were talking cyber resilience, but there is tremendous overlap and alignment between these two to the point where, you know, our president was basically said, you know, yeah, we've been doing zero trust before, you know, it was called zero trust. Like that was, you know, we knew that that was what Wright looked like.
And that's, that's really the framework that we use to really reach cyber resilience. How do we help our mission partners, you know, meet them where they are to advance their cybersecurity posture, to make sure that they're resilient, regardless of what the enemy is doing. We take a threat actor approach to analyzing and weaknesses in their security, gaps in their solutioning.
And then, you know, we try to stay product agnostic, and really try to meet them where they are. Every company's got a different budget, every agency has a different budget. Every agency has different tools and architecture that's in place today.
You know, kind of going back to what we talked about before, Rob and I kind of came up about this from a approach of not trying to rip and replace, you know, trying to meet them where they are, leverage the investments that have been made already, but tune those such that you're getting the mission results that you're looking to achieve.
[Rob Freter]
Yeah, and I think use cases is the word I think of a lot with our customers, right? Whether it's, you know, we have a commercial customer that that faced a breach or ransomware attack, right? A lot of times, sadly, it does drive investment in cyber drives rethinking the environment we're in.
Meeting them where they are is extremely important. But what is the use case, right? Is it because we now have a more remote workforce, and we were just using VPN, we don't have much more security than that, right?
How do we pivot that was extremely important in some of our customers. And also understanding, you know, we have a lot of FedSiv experience as well in customers where the models change, right? So there is a bit of a nuanced difference between a customer that is focused on CIS's maturity model versus the DoDs.
So bringing that kind of consulting to bear for them and helping them understand the key investments is critical. I think a lot of times it also comes into your key enablers, right? So even for the DoD, right, we have enterprise services that are procured through SLAs, or whatever it is for the entire department.
But then the for example, micro segmentation needs to be done more at the mission level. Big DoD can't enterprise a service to fix your micro segmentation locally to your mission, right? That's always going to have to have the expertise and mission understanding to drive, you know, security at that network layer.
So I think we kind of bring that to bear because we have like that white glove, high touch with our customers, we can actually look at their networks, we can help define that, as well as understanding their use case for zero trust in general.
[Tom Gianelos]
Yeah.
[Tom Tittermary]
Is there like a like an onboarding interview process where you spend a lot of time pulling data from the customer? Or do you start with, well, here's what we find good to look like, let's have a conversation about what your environment looks like against, like, where do you usually start? And then where does it end up going to, I guess, as part of the process?
[Rob Freter]
So I can speak to that. And Joe, you can follow up if you like. I think it starts with definitely understanding the customer's environment.
I wouldn't say it's as, it's not necessarily just a zero trust interview, we've done that we can get there, right. But understanding the customer's mission is always the start, right? A lot of our customers will start with, hey, we'd like to leverage TrueZero for a particular service, right?
We want to help deploy this solution. And as we understand the customer more, we're able to scope zero trust, right? Maybe they just wanted an endpoint solution deployed.
We quickly understand the environment, recognize that we're able to have the hard conversations on where should you invest more and get closer to zero trust. I think it's kind of naturally been adopted more by the commercial and FedSive sector as well, right? Obviously, we have OMB, a lot of the new regulatory policies coming out around zero trust.
But where DoD kind of has a bit of a benefit in this space is, you know, the work that they've done to have the control mappings, right? Something I can look and checklist what I'm building to. I think that's something lacking in FedSive space now that could really be beneficial is, you know, having something where we can say this is our build guide, right?
From a control structure perspective, not just more ethereal strategy and zero trust maturity, because it's going to be so subjective to every customer. Yeah.
[Joe Brinker]
Yeah. And just going back to what Rob talked about, too, is, you know, every customer that comes to us has a different driver for that conversation, right? It's, you know, like Rob was saying, too often, sadly, it's, you know, I thought everything was great until it wasn't.
And, okay, this is the situation I'm in now. Help me get out of this situation. Help me to, you know, rebuild my security, get the bad actor out of our environment, build back and put in place solutioning to prevent that from happening again, is to allow us to continue to move forward against what our mission is.
So a lot of the initial conversation is, you know, what brings you to us today? You know, what problem can we help you solve? And from there, you know, it kind of goes organically.
I would say also, to Rob's point, you know, about FedSive in the commercial space, it's also a bit more advantageous as well as a security provider to go in to offer, you know, that, you know, trusted advisor type role here. Hey, you came, you brought to us this problem set, we've assessed, this is what we've seen. However, you know, you brought X to us.
Through our research, we've also seen Y and Z. And, you know, these are areas we can help you out as well. And in the commercial space, there's, it's a lot easier for them to say, oh, that's a great point, you know, and maybe there's extra budget that we can attribute to that to write the course there.
In the FedSive space, it's often very much, hey, this is what, this is what the RFP said, this is what your scope of work is. And, you know, as much as we want to try and help and identify things we do, and we do help in other spaces, there are sometimes regulatory or guidelines that are put in place that, hey, you got to stay in this lane.
[Rob Freter]
Yeah. And I think also just the availability of the technology in the commercial sector helps, right? I mean, the ability to test a solution that might not have gone through the process of, you know, we are FedRAMP authorized or what have you from a regulatory perspective and test these technologies is extremely beneficial, right?
We can bring things to bear, we can test them with our commercial customers. And I think it really gets us to speed a security faster.
[Tom Tittermary]
Yeah. There's a bunch of stuff that Zscaler has available in commercial that I would love, love to talk to my DoD customers about. And it's, it's interesting because I think the commercial teams, when they're talking to our commercial customers are constantly talking about roadmap, about the products that Zscaler is developing.
All I have to do is tell customers like, no, try it out in the commercial cloud. That's the roadmap because that stuff's coming to DoD. It's just, all right, now it's a question of, you know, if the, if individual constituents in a, in a buildup or a co-comp can say, I need this sooner.
Well then I, that's a, that's my justification to go back to. And I don't think a lot of people recognize this, right? Like that, the order in which products is brought into our GovClouds and IL5 cloud is largely dependent upon signal and demand from, you know, the individual DoD customers.
[Joe Brinker]
Yeah. It's not just, you know, like a train one after the other, just in that order. Yeah.
That we can definitely influence what shows up in our clouds first. Yeah.
[Tom Tittermary]
Yeah. So just going back to, you know, what if the adversary is already in the network? So like the next one that's making its way through to go to FedRAMP and IL5 is our Deception product, which is not like, I almost didn't expect it to be that one.
It's a, it's a great honeypot technology internal for your networks to be able to find actors and stuff like that. But like, that'll be the next one that is making its way through the FedRAMP process and the IL5 process. But it's, it's interesting.
Like if I thought of like the one product I would love to have for the IC or the DoD SIPR side of the house, like that's the one like that would be amazing. But yeah. So moving along with, you know, with what TZT is doing, how, what's the best way to engage for individual customers?
If you've got folks out there looking to engage with, with TZT to kind of have a conversation and, and kind of talk about an assessment.
[Joe Brinker]
Yeah. You know, we are obviously go to our website, we're on LinkedIn, we're on social media, we're everywhere. TrueZeroTechnologies.com, you can get to us there. But, you know, we are a veteran owned small business cybersecurity provider, again, focused on applying Zero Trust concepts and architectures and frameworks to ultimately get our customers to cyber resilience. And so, yeah, as we talked about throughout this, you know, we have a passion for FedSiv, DoD, and IC space as a veteran owned company. But also, you know, we do a tremendous amount of work in the commercial space.
Also in state, local, higher education, SLED has been a huge area for us, which has been eye opening. You know, again, my background is DoD, and really the government space has been my focus, but, you know, getting more into the SLED space, it's exciting to see, right, because state and local has the same target on that federal government has, but oftentimes at a much smaller budget. And so it's been really gratifying and really awesome to see state and local governments and higher education institutions that are faced with really difficult challenges coming to us and asking us for help and us being able to deliver on that.
It's created some outstanding partnerships. And yeah, that's really been one that, you know, kind of talking about things that have surprised me since coming from government into industry. I really hadn't thought a lot about the SLED space, and that's just been a really awesome opportunity for us.
[Tom Tittermary]
Have you guys done anything? I always wonder, because I understand the CMMC requirements, and I understand the Zero Trust requirements. If you're working with commercial companies, if they're DIB or, you know, supply chain relative to the integrator space, have you ever worked with a customer where you've got to conflate those two or work together with those two?
[Rob Freter]
No, I haven't had any experience conflating the two, no, or kind of working with them together. But it's an interesting question, especially for, you know, the competitiveness of industry as well, right, with CMMC.
[Tom Tittermary]
I should take a second and say, hey, this cybersecurity maturity model certification, which is a clean set of controls that individual providers or manufacturers that are supporting the defense industrial base need to comply to if they're going to maintain their existing contracts. Sorry for the interruption. No, it's all good, Tom.
[Rob Freter]
And I feel like this gets back to some of my thoughts on the control mappings, right? So even CMMC developed a little bit before, or at least the development started before the Zero Trust reference architecture came out. I think that it is necessary to start mapping these things together, right?
Just like the 853 control framework, we need to understand what we need to build to, and we don't want those two to conflict either, right? So as we mature in Zero Trust, we should be looking at having those control frameworks tied directly, whether it's CMMC, whether it's the RMF process, we really should start looking at that as our way to authorize systems as you have to have these key Zero Trust functions in order to operate on the system instead of saying, hey, you've built to the legacy RMF structure, we now have Zero Trust where we have to integrate a lot of these concepts, have that a patchwork afterthought. And I don't think that that's the most appropriate method to go after it.
[Tom Tittermary]
So one other, I'm going to ask one other interesting question. I've brought up some other folks. I'm just interested in how you guys come at this one.
So talking about the bridge between legacy and Zero Trust, right? So I've been more aligned to the DoD. I'd be interested if this is happening in civilian also.
Pretty much every DoD solicitation RFP that I see out there says, and must align with DoD Zero Trust initiatives after 30 pages that here are the requirements you need to meet that have been copied and pasted over from what I would call the legacy perimeter reference architecture, right? And the controls and the individual technical requirements haven't been rewritten to include things like VPN, right? Or this has to be managed specifically by firewall.
And in the controls, the user being on this network means they can get to this very non-Zero Trust sort of things. And at the very end, you see, well, it must comply with Zero Trust controls. And how are you guys, I'm having a hard time coming at that conversation, right?
How are you guys, are you running into that? Is that something that, how are you guys handling that?
[Joe Brinker]
Yeah, I think sadly, that's kind of reality, right? I mean, I think if it was Joe and Rob could drive how contracting works, you would see a plethora of pure Zero Trust. Could you guys get on top of that?
Put it on my list, you know, pure Zero Trust RFPs that came out that were not, you know, quote unquote bolt-ons, right? It's a, or, you know, kind of a, after the fact, you know, 45th requirement on the list here. You know, we would love to see pure Zero Trust RFPs where organizations come out and say, hey, you know, we need somebody to come in who are experts to do a, you know, a cohesive, holistic assessment from a Zero Trust perspective of our entire environment, give us recommendations on, you know, staged phased approach to maturity model of, you know, quick, easy wins up front that are not going to disrupt operations, but will really move the needle on security, ultimately to really, you know, jumpstart us along our journey. But what we've seen is more so, like you were saying, you know, here's the requirement that's coming out.
This has been something that we've been planning for two, three years now. Okay, the RFP's hitting the street. Let's bolt-on Zero Trust as a requirement to it.
You know, ideally, we would see that planned throughout and really organic throughout it. Because if not, we are going to continue to see what we're seeing today where it's an afterthought and the integration between solutions that Zero Trust really is reliant upon, right? It's not just one tool that's going to get you to Zero Trust.
It's a conflation of multiple existing tools and capabilities within the ecosystem that have to work together, that have to integrate, that have to share information, that have to share security settings that ultimately would get you there. And if it continues to be kind of an afterthought, it just makes it harder to really ultimately achieve that goal.
[Rob Freter]
Yeah, I like that you're bringing up the RFP's, Tom, because that's something we've struggled with. Because I've even seen it to where they're proposing a particular technology acquisition, and it says, shall comply with Zero Trust. And I'm like, well, this technology is one component of the Zero Trust ecosystem, so it inherently can't do everything, right?
So if I'm getting a networking contract, maybe there's aspects of this, right? Whether it's software-defined networking, SDP, whatever this is, that can drive aspects of Zero Trust. But in totality, there's nothing written in to say, must comply with all of these other, integrate with all these other technologies, right?
So that's really interesting. Also just, I think, I got to give credit to the DoD, where credits do, is we talked about the control mapping that's come out. I think that's an extremely beneficial document.
But in a similar vein, maybe contracts have maturity goals, right? Where do we want to be and where do we want to focus across the pillars? That way, upon contract, you have an end state of where you want to get, because Zero Trust doesn't end, right?
Zero Trust is the strategy, the architecture around how we're going to build these things, but there's going to be continued refinement forever. So even the term Zero Trust compliance does irk me a little bit, but I see why it's a goal, right? Because that's the terminology we're used to.
We want to have something to build to, and that's important, but it is really a living process that's going to continue to move. So just to kind of bolt on Zero Trust, it's a little lackluster in my opinion, and I think it needs to be better defined, whether that's through identifying a maturity goal that you have, or identifying that this contract might just be a piece of the entire ecosystem.
[Joe Brinker]
Yeah, I think it goes back to, you know, just kind of our mindset of our culture, right? Like so much of what we do every day is, all right, these are the things that are on my plate today. It's my checklist.
All right, it becomes Zero Trust compliant. Check, okay, what's the next thing? And you really, it needs to be a mindset of shift to, okay, this is a constant state.
Think of it more so of not getting to be able to do, you know, 50 push-ups in a minute, more so a lifestyle of being healthy. So it's, it takes care and feeding. It takes, you know, a constant journey in this maturity model to really get to that, and it's really not getting to it.
It's really going to be an evolution, and continuous, and adopting that kind of mindset to know that, you know, if our adversaries were static, they were never going to change. If their capabilities weren't going to change, then yeah, it could be a checkbox. But given that we live in this dynamic, ever-evolving environment where technology is advancing, machine learning, AI is advancing, every other capability the adversary has to their advantage is going to continue to grow.
And things that are going to be here 10 years from now that we're not envisioning today. So, you know, Zero Trust needs to evolve, and our individual applications of that needs to continue to evolve and be a constant. It can't just be a, we met it, and we're done, and we're moving on to the next thing.
So I've used an example before where Zero Trust being more like a logarithmic graph, right? So with the x-axis being that ultimate 100% attainment of Zero Trust, is it fair to say that that, just like a logarithmic graph, that axis will never be crossed, or even touched, right?
[Rob Freter]
Yeah, yeah, I don't think at all. To your point, I think that it's never going to be completed. I think we can say we have all of the technologies and capabilities to meet a lot of the end states, right?
So you build the technology to have the capability, but just like a lot of enterprise tools, did you buy it and not configure it, right? Is there more configuration to happen? I think that those things are essential, but as your mission changes, so does that logarithmic curve, right?
And I think as your mission's changing, you need to adapt. Something I heard before as well is there's also the aperture to maybe have to tune down Zero Trust a little bit at times, right? The ability to toggle the controls and say, I'm going to open the aperture for security, whether it's because I need better reliability to network connectivity, whatever it is, right?
So your mission commander should have the ability to dial it up or down at times, depending on what the conflict of the day is. And I think that that can adjust, right? So we might have something extremely secure, and we say, hey, either something's been declassified, or this project doesn't need to exist anymore, and we tune it down, right?
And we say, this is more available. Maybe we don't need that factor of authentication. So I find it quite interesting, but yeah.
[Joe Brinker]
Yeah, I know with Zscaler, we can do that as well. We can actually tune based on the level of crown jewels that the application's being accessed, how many times users are compliant to connect, how many times they're requiring another authentication mechanism. Or you can just have your time card application that you log in every year, and you're fine, right?
I think your point about the logarithmic, that analogy is a very good one, right? Where that's the ideal, right? You up front in that logarithm, you're going to see the greatest amount of change, the greatest amount of improvement.
[Tom Tittermary]
That y-axis sort of defines that.
[Joe Brinker]
You get to that point where, okay, I've checked off. Again, I'm contradicting myself here, but I've addressed those most highest need issues, right? And what's the next thing in the maturity model?
Okay, that's the next level of getting to that. And ultimately to the point where, yeah, you're tuning it, and that margin is getting narrower and narrower, closer and closer to that x-axis.
[Rob Freter]
Right. Yeah, a thought I just had as well is, it's interesting because I was talking to CISA actually about their maturity model. For some of our FedSib space at True Zero Technologies, we help with assessing the maturity of particular systems, right?
So we were doing this project, a lot of interviews trying to understand because maturity is different to each individual and their specific mission sets. And I was asking, I was talking to CISA, trying to understand optimal better, right? Because the documentation is fantastic.
They put out the maturity models digestible, but a lot of it also comes from, now let's test it, right? Let's bring in cyber threat emulation, right? Let's actually try to pen test this thing to see.
So maybe the curve is, yes, we now have everything configured to what we believe is secure. Let's test it. As adversaries evolve, let's continue to test our zero trust architecture and consider that repeating process part of optimal, right?
It's actually injecting the threat emulation to do a pen test against that environment to validate it. Because we know our threat actors change, right? With post-quantum coming down the pipe, who knows?
Maybe all of our encryption's gone, right? Yeah, I love that. Talk about that another time, but yeah, we're going to have to pivot and that's only going to be done through threat emulation.
Really what I consider to be optimal. Great point.
[Tom Tittermary]
Yeah. I'll tell a funny thing and then I think I'm probably, guys, this has been a great conversation. I think I'm going to wrap it up, but it's when I was a kid, I'll see my dad tonight, but my dad, when I was a kid, wanted me to be a mortician.
[Rob Freter]
Interesting.
[Tom Tittermary]
Why did he want you to be a mortician? Never run out of business. So my dad had a shop.
He had an auto body shop in New Jersey. But yeah, he wanted me to be a mortician because you never run out of business and that's just cyber, right? You solve the problem, eh?
And my kids will ask me periodically, it's like, dad, are the good guys really smart and the bad guys really don't? No. There's really smart guys on both sides of this thing.
And that's the thing is you patch a hole, they make a hole. They patch a hole, they make a hole, right? So it's that never ending field of there's never not going to be cyber security.
You keep hearing about AI is going to solve for, they're going to have AI too and yada, yada, yada, right? So there's that whole angle of things. Absolutely.
[Joe Brinker]
I mean, zero trust. I mean, it's the goal, right? Is to make it hard, so hard that the adversary wants to go to the low hanging fruit, right?
It's not worth it for them. And really, I think that's the desired end state here is to get into that panacea of nobody can break into my network. I mean, that would be the goal, but that's not realistic, right?
So trying to get to the point where it is exceptionally difficult for them to do so, that's not worth their time.
[Rob Freter]
Right. Yeah. I think in a bit of closing, but one of my biggest zero trust mantras is reduce the impact, right?
With all things zero trust, if we want to mature, that's great, but we assume breach, adversary's there. How do we make sure if he does the wrong thing, whether he's trying to disrupt, whether he's trying to manipulate data, steal data, how can we reduce it to the smallest set possible? And that's done through zero trust.
We use blast radius. Blast radius, yeah, that's a good term.
[Tom Tittermary]
I'm always wary of terms like, yeah, we're going to time bomb out a policy or we're going to have blast radius. I'm like, whoa, whoa, whoa, whoa, whoa. Yeah, that's an impactful term, but yeah, consider your audience sometimes.
But yeah, anyway, guys, I can't thank you enough for coming in and spending the time with us today. As always, Tom Tittermurray, your host. Thank you again, Tom Giannullis, my illustrious, intelligent, incredible co-host.
And guys, so Joe Brinker, Rob Frieder, thank you so much for spending the time with us today. If you have any feedback for the show, always love feedback, zerotrustsgiven at gmail.com. If you want to drop a note there, Tom, you're talking too fast, you're sniffing into the mic, or you have a suggestion for us about, hey, guests that you think might be interesting or topics that might be interesting.
Also, if you want to ask a question, which you think is an interesting zero trust question in that email, and we address it in the show, we're going to try to put together a care package, like a zerotrustgiven care package for you guys. But again, so Tom Tittermurray, Tom Giannullis, Joe Brinker, Rob Frieder, and that has been Zerotrustgiven. Thank you much.
[Joe Brinker]
Thanks, everybody. Thanks, Tom. And go.
Cool. Guys, that was a great conversation. That was.
Tech.com, there's a, yeah, I got my phone here.
[Tom Tittermary]
It says, choose your tech.com, and then there's a button that says, it might be a little tricky, because I don't know exactly how you said it and where it started and ended when you did it. But I'll just say, what I could also do is be like, hey, I know you mentioned it before in the podcast, but one more time, how can people get in touch with us? I want to make sure they have the same access to you that we do.
And I can just tag it right at the end that way. Cool. So, hey, Joe, Rob, before we get wrapping up, I want to make sure that the audience has the ability.
I get a lot out of talking to you guys. I want to make sure that the audience has the same ability to be able to get access to you guys and take advantage of the services that you guys can provide. What's the best way for folks out there to get in touch with you guys?
[Joe Brinker]
Great. Thanks, Tom. Yeah, so absolutely easiest way.
You can find us on the internet at chooseyourtech.com. On the splash page there, there's a button that says, speak to a security expert. You click that and email.
You can just shoot to directly to our cyber technologists. Most likely, it'll come to my inbox. So really appreciate anybody who wants to talk with us, reach now.
Love to have a conversation with you about it. If you have any questions about what we discussed today, please feel to reach out there as well. But again, appreciate the opportunity to speak with you here today.
[Tom Tittermary]
Yeah, it's been great having you guys.