Federal Zero Trust Webinar: Why the Protect Surface Matters

Danny Holloway [00:28 - 02:23]
Hey. Good morning, everybody. We're gonna give it another minute or so before we get started, but thanks for joining the webinar. Alright. Good morning, everyone. It's 11:02, so we'll go ahead and get started. I'm Danny Holloway, public CTO at Mercury, and I'm joined by Don Yetkin, senior solution architect for our federal team. Don, do you wanna go ahead and answer the topic for today?

Don Yeske [02:23 - 05:02]
Sure. Good morning. So for those that haven't met, my name is Don Yeske. As Danny said, I'm a senior solutions architect here at Virtru. Prior to that job, in my last position, I led zero trust implementation for the Department of Homeland Security. And prior to that job, a couple of years back, I was one of the people leading zero trust implementation, at the Department of Navy, and had a hand in standing up, the DOD zero trust portfolio management office. So the topic for today is really, how do we get beyond the current conversation that we're having about zero trust in the federal government and move toward actual progress by focusing on protect surfaces. I realized the term protect surface might be new to you. And if you've been implementing zero trust in and for the federal government, that's to be expected. So what I hope to get into today, is a little bit of, you know, a little bit of background on zero trust. You know, I'll try not to linger on this, but what is zero trust? We'll move past that quickly. I promise. And we'll get to what is zero trust architecture look like, what is a protect surface, and what is the federal government's zero trust journey been like so far. After that, I wanna give you a quick background in the architecture that we came up with for zero trust at DHS. This is for internal DHS use. It's called the DHS zero trust capability framework. And the reason why I wanna give you a background in that architecture is because it is the only one anywhere in the federal government that talks about protect surfaces and operationalizes that concept. And then we'll wrap up by telling you how it does that. And the process that we're following and the protect surface concept that I'm talking to you about today, I wanna be very clear and upfront. These are not my invention. These are things that come to us from the people that invented zero trust and, specifically, John Kinderbock, who's a friend. And, the the the person credited as the inventor of zero trust during his time at Forrester, way back in, like, 2010. So Sure. Danny, I'm gonna miss some stuff, probably to start virtual. So you keep me honest here.

Danny Holloway [05:02 - 05:30]
Will do. Don, you started with a new concept. Yeah. You know, the government has been transitioning from traditional security models to zero trust security models. There's some key distinctions there that I'm sure you're gonna go through. But as it comes down to the concept of a protect surface, do you mind jumping in and kinda talking about the distinction between a protect surface and an attack surface and why that's important, particularly as we talk about it through the lens of zero trust?

Don Yeske [05:30 - 15:28]
Sure. Absolutely. So, to kinda get to the meat of this quickly, as I said, I'm gonna breeze past this. But if you have questions on it, please put them in the chat. An essential definition of zero trust, at least for the next hour, is, it's a different approach to cybersecurity. Under the old approach, what we paid attention to as cyber defenders was this thing called the attack surface, which is everything. It's everything that we own. It's everything that we operate. It's everything that we depend upon, that we don't own or operate, and anything that could be, vulnerable to attack, hence the name attack surface. In doing the job of cyber defense, historically, for the last generation plus, what we have typically done is we've, focused on the perimeter between the cyber terrain that we control and the cyber terrain that is the rest of the world. And within the cyber terrain that we control, we have varying degrees of trust. Sometimes we have a DMZ, right, that provides services that are accessible outside of our enterprise, like maybe the endpoints for our virtual private networks or our web services or our email services, and we kind of trust that space. But then we have an inherently trusted zone, our intranet. And if we're going to allow things to happen, we want them to happen on our intranet. Right? So we get people to join our network from afar, and that's how we trust them. This is the old way. And there are many problems with it. The main problem is that we assume we're facing outward, and we assume that bad guys are in front of us and good guys are behind us. And that has not been true for a very long time, and it's especially not true now. So in defining zero trust as a cybersecurity approach, our goal shifts. Our goal shifts from defending all of this and paying attention to everything outside of it and at the edges to paying attention to everything that we control and don't control with the goal of protecting our resources. In general zero trust architecture, that's called data assets, applications, and services, sometimes called DaaS. And so we think we treat that as our job, and we make a different assumption. In the old way, our assumption is the stuff happening outside of our network is bad and the stuff happening stuff happening inside of our network is trustworthy. In the new way, we don't trust anything, hence the name zero trust. We don't trust what's happening inside of our network. We don't trust what's happening outside of our net. And to get to the question you asked, I'm gonna come back to this slide if I need to. But, Danny, you asked about what's the distinction between an attack surface and a protect surface. In zero trust architecture, there are kind of three big pieces. You have the subject. Right? And the subject is the entity trying to access a resource. And that entity has an identity. It's a user or a non person thing. It is an application or it's using an application, some kind of workload or API or service to come in and get access to this resource. It's coming to us from a device. That device may be owned by us. It may be owned by the entity themselves. It may be owned by a third party, and it's coming to us over a network. The network may be owned and operated by us. It may be owned and operated by a third party. It may be the Internet, but but some network. That request goes to this thing called a control plane. And by the way, the rest of it is called the data plane. The subject and the resource live in the data plane and part of the policy enforcement point lives in the data plane. But, for this conversation, just to simplify things, three big pieces. Subject, trying to gain access to a resource, control plane, determining whether or not the subject can have access to the resource, and the resource itself. Inside of the control plane, you have a policy enforcement point. That's where you send your requests. That policy enforcement point knows something about your subject context based on your request. It knows something about the resource you're trying to access based on the resource itself, and it knows what our policy is and what's happening out there in the world around us that may look bad and that may look like a threat. And in that context, the policy decision point, the PDP, is the thing that makes a decision and says, yes, you can or no, you cannot have access to this resource. The attack surface is all of that and a bunch of stuff that I didn't describe. Not only the network you're using, but the networks around the network you're using. Not only the device you're using, but the whole supply chain for that device. Not only your identity, but everything around proving your identity. The attack surface is large and annual. And, you know, if the distinction that I wanna draw is that the protect surface, instead of being a perimeter built around everything that we own, operate, or protect, is a perimeter we build around one particularly important, particularly valuable thing. One resource that if we lose it, that constitutes mission failure. To put that in a nontechnical context, this photo and this discussion trace back to John Kinderbog. I am imitating it poorly. I do encourage you if you want the full effect, go on YouTube, find it, and listen to John describe it. Here's a poor imitation. On the day of Obama's inauguration, which is what this photograph depicts, during the parade, you have the Obamas in the back of a limousine being guarded by the secret service, and they're surrounded by four secret service agents as they go down the parade route. Around this limousine is a string of barriers, a string of people, and members of the general public. And on this day, which I think was the second Obama inauguration, the attack surface is the city of Washington DC, the surrounding airspace, the surrounding communities. The city of Washington DC, if you don't know, has a population around 750,000. I can guarantee you what didn't happen was the Secret Service did not vet 750,000 residents of the city of Washington DC, nor did they vet the however many showed up who aren't residents of the city of Washington DC, to attend this event, which was a large number. Whatever that large number is, I guarantee you the Secret Service didn't vet all those people. Also, you know, they can't really control every avenue, every aspect, every attack probability or possibility, within the city of Washington DC or around the city of Washington DC. So what do they do? Well, at any given time, the Secret Service knows where the president and the first family are. The secret service knows who, if anyone, at that moment should have access to the president and the first family, and why they should have access to the president and the first family. And they challenge anything or anyone else that tries to gain access to the president and the first family. So they always know where this thing is. They always know what this thing is. They always know who should have access to this thing, and they challenge any attempt to access their protectees other than people who are on a known well vetted list of humans that should have access to these people. That's the difference between an attack surface and a protect surface. Once you understand what a protect surface is, you deploy your controls as closely as possible around it. Now does that mean the attack surface goes away? No. It doesn't. The attack surface still exists. And you can see some level of perimeter defense happening in this photograph. You can see a line of, you know, park police, probably MPD, you know, uniform secret service, who are providing security to this effect. You can also see that it's cold, and it's January, and a bunch of these guys have their hands in their pockets. And they're just sort of standing there bored. And you can see that the barricades that have been put up to prevent people from rushing into the parade route, pretty much anybody could break through those barricades. You know, a large dog could break through those barricades. And you can see that even some of the police officers actually have their phones out, and they're taking photos of the parade. So is this security? It is to a point, but it's also kind of security theater. So the attack surface doesn't go away. We still pay attention to the attack surface, but we pay more attention to the protect surface. Don't know if I answered your question.

Danny Holloway [15:28 - 15:52]
No. That's great, Don. And you talked about the importance of prioritization. You know, to get beyond security theater, what are some of the mechanisms or frameworks that government agencies can work through as they're thinking about, you know, their subjects and resources and how to adequately protect, the the surfaces that they have, you know, most important or that might be most vulnerable to attack?

Don Yeske [15:52 - 24:33]
So, leading question, of course, but the only one that the only architect that I know of that actually includes a definition of protect surface in the federal government is the one that we developed for DHS. And it's also the only architecture that facilitates design of defensive strategies for protect surfaces, which we call protect webs in that architecture. Before we develop that architecture, though, we really had to characterize the US government's position and why we hadn't actually crossed that line. So it's important to understand, and these are names that we made up. Full disclosure, just made this up, to describe what was actually happening, but it is actually happening. We did within DHS, we described in developing this architecture and this strategy, what has been happening so far in zero trust as phase one. And in phase one, your focus is on the attack surface. I've asked Randy over at DOD this question directly, you know, hey. Are you focusing on protect surfaces? Are you focusing on the attack surface? To his credit, he thought about it. And he came back and he said, the attack surface. We've got to protect everything. That's not irrational, and it's not necessarily a terrible answer. And Randy Resnick is correct to, you know, as we are making this shift to zero trust, to stay focused on the attack surface, at least initially. And if you look at everything he was responding to, NIST eight hundred two zero seven does not define the term protect surface or the concept of it. NIST 1,835 does not define those concepts. There is nothing in o m b m twenty two zero nine or m twenty four fourteen that talks about protect surfaces. There are no tasks in those documents that tell us to know what our protect surfaces are or to design defenses around that. So was Randy wrong? No. He wasn't wrong. But that's where the federal government is and has been. We've gone from, you know, having perimeters that are defined by our networks and some to some extent by our identities To now, if you go to any government agency, they at least have an awareness of what endpoint you're using, what workload you're using. They're starting to do things like device level security, you know, caring about what network you're using, but not necessarily limiting workloads to be accessible only on certain networks. So we are making progress, but our focus is still on the attack surface. In that architecture at DHS, we had to describe something else, which is beyond this line, what are we doing? Once we have a relatively complete complement of zero trust capabilities, and once we have what we think is decent control and a decent level of maturity of those capabilities, then we need to start using them to protect really important things, and our perimeters need to shift down to focus on our critical data assets, applications, and services, which, by the way, is defined in 08/2007 and is the point of zero trust. We just have to get to that point. So sorry. I keep scrolling the wrong direction. It's okay. Yeah. So in that framework that you asked about, Danny, very quickly just to define some terms, we had to do some things differently, because everything we've been given up to that point had a few problems. It focused too much on products and not enough on people and process. So we defined the thing we were measuring as a capability, and we defined the level at which we were measuring it as at an organizational level. To explain why, DHS as a department has something like 2,000 major systems and applications that it manages. You can do zero trust. It's hard, but you can do it. Ask yourself, can you do it 2,000 times? Even at the level of a department as large and complex as DHS, the answer to that is no. The goal that we then set for ourselves was, okay, can we do it 14 times? We have roughly 14 major components. These are agencies and offices inside of DHS, including the headquarters. Could we do that? And we think the answer, the rational answer to that is yes. So if we task each organization to have some level of federated, and this is in the strategy that we published, it's open. You can find it on Google and on dhs. gov. We embrace the concept of federation. Okay? Each organization within DHS, your job now is to measure your zero trust capability. I'm not asking about a system you own. I'm asking about you. Who are the people in your organization who are responsible for this capability? How do you choose to perform that capability and what products support it? So we had to shift the focus away from the tech and more toward capability. So we did that. We also had to understand what was more important than what. As complex as some of these architectures are, and DOD's architecture is very complex, there is no ranking. There is no waiting. There is no concept of, there is a concept of sequencing because DOD's architecture is underpinned in large part by a schedule, and they developed a schedule to determine, can we do this stuff by '27? And the answer was yes. So there is a predecessor successor type relationship among the capabilities and activities in DOD's roadmap that does exist. But what DOD can't tell you is which is more important than what. If I have if I don't have x and I don't have y, where should I be investing? There is no answer to that in any architecture, including DODs, which I think is, other than the one that we developed for DHS, the most comprehensive and and, well per well put together zero trust architecture out there. So we had to answer the question of what is more important than what some way. And we did that by understanding, objectively, what are these capabilities and which ones do you have to have in order to have each capability, and which ones work better once you have each capability. So there's a concept of dependencies and enhancements among the capabilities in the framework, and that gives rise to a level of prioritization. So we can tell you, your investments need to go at the bottom level. You know, if if we're, if we're talking about, let me skip ahead, if we're talking about, you know, things at this level of of the framework that are, you know, basic and foundational and don't really depend on other things, those are probably the things you should invest in first. At each level of this, of this hierarchy, things get more complex. Things depend on more things. Things enable more things. And when you get to the top of the hierarchy, there really are only a few capabilities left, but they're highly dependent on everything else in the framework. And that means in order to, you know, have advanced threat protection, one of the, capabilities defined up at this level, I basically have to have every other capability on the map. So, the way that we answered that question of, what's more important than what is we drew out of Maslow's hierarchy of zero trust. Right? Just like Maslow's hierarchy, down here you have food, water, shelter. Right? Up here, you have self actualization. Right? I wanna have good relationships with my family. I wanna, you know, I wanna have a great career. And those things are important. But if tomorrow if tomorrow you don't have food or you don't have water or you don't have shelter, where are you going to invest? You're going to invest in solving that problem. And then the third thing, go ahead. Sorry, Danny. I feel like I'm getting off track.

Danny Holloway [24:33 - 25:07]
No. You're you're good. I just wanted to say it sounds like you've got a framework for assessing priorities, defining your protect surface, and then looking at it in terms of where are you at from a current maturity level and where do you need to be from a target maturity level. What are some of the the mechanisms, that you might go through to do that as is assessment and then map out and sort of drive your prioritization to get to that, you know, to be architecture you're striving for when you build out your zero trust solutions?

Don Yeske [25:07 - 29:10]
Yeah. So there's a sequence there's a natural sequence of events. This is just a a blown out view of one of those dependency chains to explain how it works. But, we aligned those activities that people had to go through into the phases. So, in the architecture that DHS uses internally, in phase one, the activities that you go through are capability inventory, which is figure out which of these 46 capabilities that comprise zero trust you actually have. And the answer is you have it if you can identify without qualification. If you can identify the people responsible for doing a thing, if you can identify how you've chosen to do that thing, and if you can identify what product or products you use to do that thing, then and and if the capabilities upon which that one depends also exists, you have those answers for those other capabilities, then we determine that that organization has that capability. So thing one is just know what capabilities you have. It should be a very simple exercise. We found people overthought it quite a bit within the HSS as we were doing it, but we did get through it. And in fairness, they were doing it while we were inventing this frame. So, you know, it got a little complex. The next thing that we asked organizations, not system owners, not, you know, individual service organizations within DHS to do is assess those capabilities. Okay. For the list of things that we've now determined, you have those three answers. How well or poorly do they work? There were three methods of doing that in, in the DHS, framework. One of them is to rely on CISA zero trust maturity model. If you've already used that to assess yourself, there's a level at which you can kinda map that to what capabilities are in this framework. Another way that you can do that because, you know, bear in mind, the coast guard is part of DHS, and the coast guard's networks are still largely organized under DOD. So, we had to allow for, you know, the use of DOD zero trust implementation road map, so we map to it. If you've completed these activities in DOD's road map, you probably have these capabilities at this level of maturity. If you have neither of those things, which did happen, we provided a third option. That third option was to directly assess the capabilities that you do have against the series of controls. Regardless of how you do that, and the maturity models that, you know, maturity level one through five, just like any maturity assessment anyone here has ever done, it's all based on CMMI. We translated those results depending on which method you used into a percentile score. Anywhere from 0% mature, like, you have answers, but you're not doing it, to 100% mature. Everything we can measure, you're actually doing. We had to do it that way because it's not always possible to achieve a maturity level of five. So those are the activities in phase one. In phase two, you shift your focus to protecting things. And that is where that is where we build protect webs. And the way that you build protect webs, actually, we'll kinda go through it. I'll kinda go through it here. There is a process for this thing that we've notionally described as phase two within DHS. There is a process for it. That process, by the way, also comes from Kinderbod, in the sort of commercial inventors of zero trust. I've linked here to a report, which is the only other government document I could find anywhere that actually defined the concept of pipe protect surface and suggested a way to use that concept in the US government. So we've referenced that here. So to walk through that process.

Danny Holloway [29:10 - 29:13]
That's helpful, Don. Thank you.

Don Yeske [29:13 - 41:32]
Yeah. To walk through that process, it's five steps. First step, figure out what your protect surface is, which I think is the question you asked me ten minutes ago, Danny. Sorry. I had to get here to answer it. So, what you do is you ask yourself a question. Which of the data, assets, applications, and services that your organization owns, if they were compromised, would constitute mission failure? Now this was a very clear answer when we were talking about the Secret Service on the day of the inauguration and the first family sitting in the back of the limousine. That is a very, very clear, very, very easy example. This turns out to be not as easy for federal agencies to do. And, you know, the kind of go to things that we heard from DHS components was, well, I have a list of HVAs. You do their systems, and you have hundreds of them. And, you've correctly answered, like, based on the technical definition of what a high value asset is, you've correctly answered that. But I'm here to tell you, you don't have hundreds of things that if you lost them, you lose the mission. You simply don't. So it's hard to think critically about what is most important to an organization. You know, put yourself in the position of, like, FEMA or the federal law enforcement training centers or customs and border protection or ICE. For any of those types of organizations, what's the most important thing to them? There are lots of many important things. Is it their national security systems? Is it their high value assets? Those are kinda too big. What we're talking about is what data, you know, what applications, what critical interfaces. If you lost them, you lose the mission. The premise was that you really should have a very small number of those things that they should be, pretty easily defined and you have to put them in a priority order. So I'm sorry, Danny. I don't have a great answer to how people do that because they're still doing it. But the guidance we've given them is, they and I left DHS in July, and the task that I'm describing was due at the August per the cybersecurity strategy at the department level. I have every reason to believe it's been done. I'm not privy to the results, but there should be a list now of protect surfaces defined at least one, defined by each component. And where they have more than one, it should be in priority order. What's most important? What's second most important? The guidance we gave was keep it to a single digit number, please. You know, please don't go over nine. That turns out to be really hard. Whatever that list is, phase two, as we described it, is really defined by that list. This is your backlog for phase two of zero trust. These are the things you have to do. For each one of those protect services, you gotta go through these four other steps. So the next step is mapping the transaction flows. Right? If we understand what it is we're trying to defend at a very fundamental level, the next question is, just like the first family in the back of the limousine, who has to have access to that? When do they have to have access to that? And how long, how do they have access to that and why? If we can answer those questions, then the protect surface is small enough. And this is one of the gating criteria for what a protect surface is. It's very, very important. If you can't answer the questions that we just posed, who's everybody who has access to that? Person and nonpersonality. Why and how and when? If you can't answer that, it's too big for you to consider it a protect surface. So I see some of the questions coming up in chat. That's really the answer is that's a gating function. You have to understand. You have to be able to get your arms around a protect surface in order to call it a protect surface. So, once we understand that, we should be able to cleanly map, And we have capabilities in the framework for doing this at DHS, so baselining and data flow mapping. But really data security posture management, there are lots of ways, and tools that you can use to understand for a particular piece of data file something, what is accessing that thing, when and why. You can draw that list using tools if you need to, and you probably need to. So once we have that, then we move on to, let's build an architecture around that. This is, this is where the architecture we built for DHS really, really flies because we have an understanding of what capabilities exist. We have an understanding of what they depend on. We have an understanding of what they enhance. So if you can create a list, what we called in this architecture tier zero capabilities, what are those things that have to exist in direct contact Either with the protect surface or with the subject. At the moment of access, what are you doing? If we understand what those capabilities are that we call tier zero capabilities. The rest of a protect web flows entirely out of that. You can draw it based on the dependencies and the criteria. So, what does that result in? It results in a block, a functional block diagram of what are all the capabilities that you have to have in order to protect that protect service you've now successfully described. And they all have to work together. So if they exist and they work together, you have the basics of a protect web. No one else has ever given an answer to this question. We're not saying it's a great answer. We're not saying it's a poor answer. There is an answer on the board. So if you're doing this work for the federal government, in the federal government, I would encourage you to reach out to DHS and grab this because it's the only answer I know about. And if people come up with other better answers, great. Until they do, here's one. Once you have that, the next step is to create policy. We're gonna create policy around the concept of access to that protect surface. If we understand the transaction flows from step two in this process, who has to have access, when do they have access, why do they have access, we can write policy that says exactly that. So the policy should, one to one, map to and mirror whatever your transaction flows into and out of that protect surface is. This is the only place in this brief where I have a shameless plug. I do have a shameless plug. If you're not familiar with Virtru, there's a reason why I came here. And it is because this is the only company in the world that I know of that is actually attacking data centric security at the level of data objects, by which I mean, based on an open standard, Virtru has its product called a data security platform, and it's built on an open standard called Open TDF. And, essentially, what that does is it takes that policy that you write and encodes it, and cryptographically links it to an object. So the policy actually travels with the object. I don't know anybody else who's doing that. Certainly, no one else is doing it at scale or for the federal government, and those things are being done here. And that was hugely exciting to me, and that's why I, you know, sought Virtru out, when it came time to leave government service. And, I do think it's unique. I do think it's valuable, and I will insert a shameless plug here that, you know, if you're not familiar with Virtru, there's a lot that you can learn on our website. There's a lot that you can learn at open tdf. io. You can literally download this stuff and play with it. So, but, you know, all of that just to say, we do have an agenda and it's selling our product. Back to this process. So it's step four, you create a zero trust policy. Final step, I promise. And I think this is also my last slide. How do you know it's working? Step five is monitor and maintain the network. So in the architecture that DHS has now at its disposal, there are two ways that you can monitor and maintain. One is that protect web is made up of individual capabilities like, phishing resistant MFA is a capability in the framework. It can be done well. That can be done poorly. There are levels of maturity, one through five, that you could measure around that capability. Once it's part of a protect web, part of your job is measuring and remeasuring that level of maturity and seeking to improve it. And you should be making those investments as an organization, and they should be highly prioritized in your IT budget. So first thing, measure your capabilities that make up the Protectweb and make them more mature. The ones that are least mature should receive the most attention because that all has to work as a unified machine to protect the thing you've now said is so important you can't lose it. Second thing you can do, and, actually, DOD has some good, I think early, guidance on this, and DHS is kind of a fast follower in this regard. We should be purple teaming this whole thing. So within DOD, those environments that they've now said have reached threshold or, you know, advanced, right, target or advanced level zero trust in their framework. The way that they do that is essentially through a sequence of purple teaming events. Within DHS, there's a vulnerability assessment team that is an enterprise capability, and it does that work for the enterprise. What we had started to do in July when I left was prioritize the events that would have to take place once we understand what the protect services are and we have protect webs around them for that vulnerability assessment team to do the work of, actually trying to get into those resources through any means possible. And I mean any means possible. One of the best practices here is to assume breach because that is an assumption of zero trust. Never assume that the bad guy can't get into your network. Assume that they can. Assume that they are. Assume that they are already in there and they've already found a way to move laterally and start at that point. If you start there, this becomes really, really valuable. And the other best practice is do it over and over again. So we should not be doing this once calling it good or calling it bad and taking a fix. We should be doing it regularly. This is also another reason for limiting the number of things you consider a protect surface. Everything you consider a protect surface, you're now taking on a job, and your job is to go do these assessments. Over time, you have to assess the capabilities that are part of that that protect web, and you have to assess the viability, of the protect web itself for protecting the asset you're trying to protect. That is my last slide. And if you have other questions, please ask them and I'll go back and try to Absolutely.

Danny Holloway [41:32 - 42:04]
Yeah. I've been keeping an eye on the chat. We've got a couple of questions in here. One, as it relates to post quantum cryptography. Sarah talks about misguidance. You mentioned DOD guidance. We've got frameworks and policy. But does post quantum fit into this, and if so, how? Or is it a completely separate initiative, between where we're heading with zero trust architectures and the mandate executive order to implement them across federal agencies?

Don Yeske [42:04 - 45:43]
It does fit. I don't have slides on this. So let me just answer off the cuff. There are, as of August, a couple of newly approved, algorithms that are considered to be quantum resistant resistant to a, quantum, a a cryptographically crypt analytically relevant quantum computer, CRQC, the absolute worst term for an acronym I've ever heard. But, there are a couple of algorithms now that we consider to be secure against a a CRQC. Those just kind of got released by NIST, last August. What's happening right now is vendors are building those things into products. There's kind of a prevalent view, which I think is wrong in our community of a threat of collect now and decrypt later. Could that happen technically? Yes. We could scoop up all kinds of transactions that are flowing across a wire that are encrypted right now. And when we have a quantum computer at our disposal, we can test that quantum computer to go break the encryption around that. And if it is, it's important to understand what's actually susceptible to, a a c r q c. The general thinking right now is that asymmetric encryption, which is the type of encryption that underlies PKI, is more susceptible to a CRQC than, symmetric encryption like AES. It's not that AES isn't susceptible. It's just less susceptible. So for those, sorry. I got a little lost in my own head. For those algorithms that are susceptible to a CRQC, there are solutions now. Those solutions are being baked into products now. Is all of that part of this? Absolutely. I think that the threat of collect now, decrypt later is overblown. In general, we don't really have the storage at scale we would need to operationalize that. I doubt even our major adversaries have and are going to task that level of infrastructure to do that level of storage. You know, some number of petabytes per day of, you know, encrypted data flows across the Internet. It's just kind of crazy to think that someone would store all of that now and then decrypt it in ten years or whenever there is a CRQC. But do we need to be aware of it? Yes. Do we need to be working toward it? Yes. How does that work for Virtru? Danny, I'm gonna count on you correcting me if I get this wrong. My understanding here is that the payloads inside of the TDF, the encrypted object, are encrypted symmetrically. The keys to decrypt the payloads are encrypted asymmetrically. So, are we susceptible to that? Yes. But just like many other commercial applications and products, encryption is kind of pluggable to us. So, and I think we've even done a proof of concept of using those new algorithms, to construct a TDF and to decrypt it as part of our last hackathon, couple of months back.

Danny Holloway [45:43 - 46:02]
That's right though. Yep. Okay. Yeah. We call it so agile, but, the ability to plug and play and and adopt new cryptographic algorithms for securing and protecting the payloads is absolutely essential to the Virtru data security platform. So.

Don Yeske [46:02 - 47:01]
Yep. And so, Sarah, I see your question. The answer broadly is yes. It falls under ZTA. I think you do have to be aware of it. I think you do have to put into your backlog the implementation of those new algorithms. I think the time to do that is the subject of reasonable and rational debate among experts. I am not an expert in that particular field. My understanding is that those opinions of experts range from couple of years to a couple of decades, and the Kentucky windage average is something in between. If you are a federal agency or working for a federal agency, the thing that defines your timeline right now, is CNSA two point o, which is cryptographic national security algorithms two point o. And that draws a timeline that runs out to 2035, but has us doing things as early as next year. So that should be in your place.

Danny Holloway [47:01 - 47:31]
Thanks, Don. You define the last phase as sort of monitor and maintain. Does the protect service itself tend to adapt and change and grow over time, or is it a more of a defense in-depth where you're continuing to add, maybe new security capabilities? Or is it a hybrid between the two where you're looking at a constantly evolving architecture as well as expanding capabilities to, you know, counter or or prevent new threats?

Don Yeske [47:31 - 48:59]
The last one. I I would think that it's both. So you can think of a protect we have to have a practical example in mind in thinking through this question. As a practical example, let's say that our protect surface is defined by certain records or certain tables in a database. If we lose these records, if we lose this table, mission's lost. You can imagine scenarios where new technology comes out. There's a whole new capability we hadn't even considered, that could contribute to the protection of that particular protect surface that was not part of our architecture before because it wasn't a capability that was generally available. Someone just invented a new capability to protect records in a database that didn't exist before. That would be an adjustment to architecture. You can also imagine a scenario where, the thing being protected actually, the needs for that change. Right? It used to be that the records in the database that we're protecting were accessed by these two or three, you know, direct actors that are part of these applications. But lo and behold, the US government determined that that data was also useful for some other purpose, and it was legal to use it that way. And so now there's an interface to a third thing. Right? So in that case, the protect surface itself could change, and that could drive changes in your protection. So I think we're dealing with both.

Danny Holloway [48:59 - 49:21]
That's great. Thanks, Don. It looks like we got through most of the questions in the chat. I don't see any in the q and a tab. So just a reminder to those on the webinar, if you have questions, feel free to drop them either into the chat or q and a, and we'll give it another minute or two to see if any more come in.

Don Yeske [49:21 - 50:53]
Yeah. I love them, I'm just looking through the comments. I love the comment about Apollo thirteen because that is exactly the type of thinking that we were engaged in in coming up with this. It was, hey. You know, the job is very simple. Don't lose this. Right? The life of the Apollo thirteen astronauts who were trapped and had to get back to Earth, and had just suffered major damage to their spacecraft, was very simple. They either find a way to get these guys home alive. Right? And use everything that they've got. The simplicity of this approach is its power. The idea that we can do a better job of generally protecting everything, and I think that we are. I think that we've moved the needle in the federal government. I give credit to the many agencies and departments that have done their work to do the things they were told to do under m l o m b m twenty two zero nine, by the CISA zero trust maturity model. All of these were good things. This is all goodness. But have we done the job? That's the critical question no one has answered. Right? That's why there's a phase two. You know, kind of the so what dangling at the end of all that, was, okay. What if someone gets in anyway? What if what if we lose something anyway? What happens? And where are we really focusing our efforts? Mike.

Danny Holloway [50:53 - 50:56]
Okay. I'm not pushing it, but you want me to read it, Don?

Don Yeske [50:56 - 50:57]
Please. Please.

Danny Holloway [50:57 - 51:25]
Sure. So with the pervasiveness of cloud, do the hyperscalers have a responsibility to attest to their implementation of zero trust? You know, so effectively, are there inherited controls that we can assume as system developers or program, managers based on the inherent controls of the cloud, cloud service providers and the the cloud services that they provide for us.

Don Yeske [51:25 - 54:18]
Hell, yes. And I would go beyond that to say it's not just cloud. So let's back up a step. AWS really pioneered this, but all of the major cloud service providers implement it. There's an idea of a shared responsibility model. Whenever you are using a cloud service, there is some level of responsibility that falls on the cloud service provider to have and maintain and do things that are required, not just for security, but for, you know, usability, for, ease of use, etcetera. Right? So there are some responsibilities that fall on the cloud service provider to do their portion of the job. There are some responsibilities that fall on you as the consumer of that cloud service to do your portion of the work, you know. So for example, if you're hosting medical data, you might say that encryption of the workload, in order to be compliant with HIPAA requirements, is a requirement. Whose job is that? It's probably the cloud service provider's job to actually apply some level of encryption either in a, you know, database as a service or infrastructure as a service, encrypting a disk, whatever it is. It's also incumbent upon you as the consumer of that service to invoke that encryption requirement on the cloud service provider. Right? It's their job to make sure it works. It's your job to tell them to do it. So that's a very simple example, but there's a shared responsibility model that exists between CSPs and consumers. I would tell you that the same thing exists for every enterprise of any particular size or depth. And it certainly existed at DHS. It certainly existed at the department of the navy. And the way that we saw that, I think, most prominently was in the idea of enterprise services. That, by the way, is the basic argument for how we chose to define capabilities in our, in our architecture was the idea that most things should really be implemented as shared services at the organizational level. If they are, and if you're a system owner in this case, then you're dependent on enterprise services, probably identity services, probably some level of hosting services even if it's being done on prem. Right? You can think of many things that could be enterprise services that you have to consume, and you have to count on and inherit the implementation of that from the service provider. Exactly the same as it would be with a CSP. It's just that within organizations, we tend to be less mature about it than commercial cloud service providers because they do it for a living.

Danny Holloway [54:18 - 54:48]
Thanks, Tom. That's great. We've got one question from Ian about software supply chains. You know, we're constantly hearing about new, supply chain compromises and packages, things like NPM and and other distributions for open source or third party libraries. Do you have any thoughts on how that fits into a zero trust architecture and specifically within the construct of a, protect service?

Don Yeske [54:48 - 58:22]
Yes. In the architecture that I've been giving you as an example here, there is a supply chain security capability. Importantly, it's not a software supply chain, it's a supply chain. You can look this up on your own. Back in gosh. I wanna say it was the early twenty teens, like, 2012 or so. There are credible reports, open source intelligence that indicate that the Chinese Communist Party was placing hardware devices, chips the size of a grain of rice, into commercial IT products. And that these chips were doing things like recording keystrokes and sending logs, you know, back home. Hardware is just as important as software when it comes to supply chain security. It's just overlooked, I think, more often right now because our most recent example, and we don't tend to have long memories, is more of a software supply chain example, and it's from the SolarWinds incident. Right? So, that was part of the underlying premise of executive order one four zero two eight, which was also the same order that implemented zero trust as a mandate for the federal government and is still enforced, has not been rescinded by the current administration. So, is that capability important? Yes. How do you actually operationalize that? I think we're still struggling with that. Within DHS, there's actually a team responsible for supply chain security and vetting supply chain. That doesn't mean that it's done well at scale or we know everything about it. The best advice I could probably offer to anyone who's interested in software supply chain and supply chain security in general, would be to look at the concept of in total, which and this is particularly for software supply chain. In total is a standard that goes along with an SBOM and gives the SBOM some teeth. So, in addition to having an SBOM is a software bill of materials. It's a document, should be a human, machine readable document that makes certain assertions about how a piece of software was built, what went into it, what practices were followed, what testing was performed, etcetera. And a bomb by itself does very little. There are recent studies that suggest that an s bomb by itself will avoid something like 20 or 30% of, software supply chain, attack vectors. When you add something like in total, which is an open standard, that that, allows a third party to cryptographically attest to some of the things that the s bomb says, then we get more toward, like, fifty, sixty, 70% of the attack vectors, in that piece of software. We now have a reasonable assurance have been addressed. So, not a topic I was expecting to discuss today, but I'm happy to offer my thoughts. There is a capability for that in DHS's framework. It is defined as a capability you can be good at or not good at. Did we get that right? You know, it's still pretty new. And I would tell you that everyone is kinda struggling with that question.

Danny Holloway [58:22 - 58:53]
Alright. Thanks for your flexibility and agility to kinda come in and out of the original further of what we had decided to talk about today. Looks like we've got about a minute left. So I wanted to thank you for making time and being a participant on the the conversation this afternoon. Any closing thoughts, as we continue towards 2027, the final days of this push to zero trust realization?

Don Yeske [58:53 - 01:00:01]
Well, the 2027 timeline is unique to DOD, but I know a lot of the people here are DOD or supporting DOD. Here's what I would say. DOD did great work. I'm to the extent I contributed to that work, I'm proud of doing it. But that said, DOD did not do this. And if we want to get to the so what of zero trust, if we wanna get to the point of saying, we actually are more resilient because we did this thing called zero trust, At least some part of what we do has to be this. We have to understand what our protect surfaces are, and we have to defend them. This is definitional to zero trust, and yet it has not been integrated in all of the work that the federal government has done. I would encourage anyone who can hear the sound of my voice and take action on it to please consider that in their plans, in their strategies, and in their cooperative, efforts with their customers. And by the way, Danny's pinch hitting here for Shannon. So, Danny, thank you for stepping up at the last minute for your flexibility.

Danny Holloway [01:00:01 - 01:00:09]
No. Happy to do it. It's always a pleasure. And, with that, I guess we'll call this one a wrap.

Don Yeske [01:00:09 - 01:00:12]
Okay. Thanks, everyone. Thanks, Don.