 Hello, everybody. Thank you for joining us. This is Open DevCon and another really, really exciting talk. So this time we're joined by John, you know, the father of Zero Trust. We have Adi, you know, one of the key folks at Google thinking through Zero Trust methodology and Jonathan thinking through, again, key contributor for Zero Trust from LSA supporting AFRL. And they have a powerful topic here of, you know, how do we even get to step one and where do we go from there? Gentlemen? Thank you. Hey, why don't I stand here and you push slides and then I'll flip it for you. So, hi everyone. Thanks for having us. My name is John Kindervog. I'm the creator of Zero Trust. I did that when I was a forester. I'm with Jonathan, Honey. We work together on cloud security alliance stuff and doing some stuff for the Air Force. So let's go into a quick introduction to Zero Trust so that we can set the baseline of what Zero Trust really is. And that way you can move forward. So this was the original Zero Trust report. I was at Forester for eight and a half years, vice president and principal analyst over there. Then I went over to Palo Alto Networks for four years as the field CTO. And now I'm at a company called Ontuit doing managed services for Zero Trust environments around the world. And this was the original report called No More Chewie Centers. And it didn't really set the world on fire. In fact, the first speech that I ever gave was probably maybe this many people in it. And people came up to me and said, man, you're insane. This is a stupid idea. And they would come up and insult me and all that kind of stuff. But I'd done two years of primary research when I was at Forester. So I knew it worked. And so then that's where it started. And here's where we are now. So in 2021, the president of the United States issued an executive order where he said that all federal government agencies must adopt security best practices and advance towards the Zero Trust architecture. So in 2010, if you would have told me that 11 years later, the president of the United States was going to issue an executive order mandating to move towards Zero Trust, I would have told you, get back in your DeLorean, turn on that flux capacitor, get that thing up to 88 miles an hour and go back to Hill City because it will never happen. But it did. And that's the crazy story. And what happened with this is the president of the United States changed the incentive structure around Zero Trust globally. So a lot of us early on, I would try to get people to, hey, will you do a session with me on Zero Trust, like what we're doing now? No one would do it. They would want to do it. Like if I talked to Jonathan, yeah, I'd love to do that. Let me go get permission from my PR team or whatever. And they'd say, no, that'll put a target on our back. We can't tell anybody we were doing Zero Trust. So we used to joke that Zero Trust was like Fight Club, right? The first rule is you don't talk about it. And what changed is the president of the United States changed the Fight Club rules. And now you talk about it. You talk about it all the time. So last week, I was four days in Washington, D.C., International Monetary Fund. I did ATARC, if you're familiar with the ATARC conference. I did State Ramp, which is the CISOs from states all over the United States. And then I did State Department. Everybody's talking about it. So that's what the value of this executive order, beyond the stuff that's tactically happening, but the changing of the incentivization so that you could say, oh, it's okay to do this. It's okay to think this way. Next slide. So what is Zero Trust? Here is the concise authoritative definition from the person who created it, right? From the horses, whatever. On the horse, you can decide which end of the horse I am later on, okay? But Zero Trust is a strategy designed to stop data breaches. Now, what's data? Data is the new oil, right? Data is the thing that fuels modern economies. Now I'm from Texas where we pump oil out of the ground. And oil, the more you refine it, the more valuable it gets, right? So you have gasoline, you know, rock crude oil, then you have gasoline, you have aviation fuel, jet fuel, plastics, carbon fiber, nanotubes, all that stuff make it more valuable. Same with data. The more it's refined, the more valuable it is. If they just have my name, nah, no big deal, right? That used to be in the phone book. Who here remembers the phone book, right? I was talking about phone books one time and somebody who's a much younger person than I am said, hold it. What's a phone book? And I said, I explained what a phone book was. And she said to me, get out of town. You guys actually published PII? I'm like, yeah, that's what we did back then, yeah. The new phone books are here. The new phone books are here. I am somebody. Name the movie. The jerk. Come on, Naven Johnson. Somebody, no, you're not all that young. Oh, man. Okay, anyway. So, no, no, no, we haven't finished it, Jonathan. So it's designed to stop data breaches. Now, what's a breach? A breach, we used to say a breach is somebody got into our castle walls and they're poking around. But legal and regulatory entities like GDPR, CCPA, PCI have redefined what a breach is for us. And now a breach is when sensitive or regulated data is ex-filtrated, goes outbound from our networks of systems into the hands of malicious systems. So it's not about what's coming in. That's still important. But what's even more important is what's going out. And so a data breach, we want to stop data breaches because that's the only thing that IT can do to get the CEO fired, to get a leader fired. And the other thing zero trust can do is make cyber attacks unsuccessful. And it does that by eliminating trust from digital systems. We're talking about digital systems, zero trust, getting rid of digital systems. So there are two kinds of cyber attacks, successful and unsuccessful. Now in our practice last year, we had our first successful ransomware attack. And we'd stopped thousands upon thousands of ransomware attacks because you cannot stop the attack from starting because then you have to be the attacker, right? But you can make this attack unsuccessful. So that's what you're trying to do with zero trust. And we had a successful ransomware attack and we contained it very quickly, but it was very embarrassing. And we had to call the CISO and say, hey, this is what happened. We contained it, but we're sorry, we're investigating it. And he said, oh, that is the best news I've heard in a long time. Thank you so much. This is great news. And like, how is a ransomware attack great news? That makes no sense. And he said, oh, you don't understand. This is the company that we just acquired and they've refused to adopt our zero trust best practices. So now I can go to the CEO and force them to do the thing we've been trying to cajole them to do in the past. So that's the value of that. So we're just going to get rid of trust from digital systems. Next slide. So let's look at some misconceptions. The first one is zero trust makes a system trusted. That's false. How much trust should there be in a system called zero trust? Zero. I tried to be very explicit about that, but we have these terms explicit trust, implicit trust. And then if you do this, then it's trusted and blah, blah, blah, blah. We're trying to eliminate the trust model. That's the fundamental problem, this broken trust model. Next, zero trust is about identity. You'll hear that from vendors all the time. Zero trust consumes identity and policy. We'll talk about that in a little bit and you'll see some demonstrations of that. And then there are zero trust products. You've all had a vendor come up to you and say, hey, if you buy our stuff, you'll be all zero trusty. Right? No, there are products that work well in your zero trust environment based upon what you are trying to protect. And then finally, zero trust is complicated. There's really only nine things that you need to know. There's four design principles and a five step model of how you do it. And once you understand that, you will see how simple it is to get started in zero trust. Next one. So trust is a hard thing to define. But will you agree with me that trust is a human emotion? It's a human emotion, right? And it's been injected into digital systems for no reason at all. We don't know when that happened, but it becomes then a vulnerability. And what do you do with vulnerabilities in your organization? You mitigate them. So you have to mitigate trust because trust is not only a vulnerability, it is also an exploit at the same time. In fact, it's the only vulnerability and I was trying to get a general tool. Greg, for April Fools, we were trying to get a CVE done for trust as a joke, but there was some pushback over there at CERT. What's that? Right, right. Well, let's just say some other people. Greg thought it was great fun, but then anyway. So he works for Carnegie Mellon and we have some common friends. So trust is a vulnerability you're getting ahead of me there that is also an exploit. And so therefore the only entity who gets value from trust in your organization are the malicious actors who are going to exploit it. Think about that. It provides you no value, so why would you even want it? This is dwell time right here. The malicious actors hanging out in your environment and you don't know it. Why do we have dwell time? Because we have a broken trust model. So if we look at this broken trust model where the untrusted side went to the evil internet and you can build that out and the trusted side went to your network where all the good people are and everybody who works for you, they come to work on rainbow unicorns, don't they? Handing out candy to little boys and girls on the way. They're wonderful people. They would never do anything wrong, but look, what happens if malware crosses that ephemeral trust boundary? And you can put it on the right side of that green circle. Well, what's malware? Malware is just a collection of packets. What's a packet? A packet is a bunch of zeros and ones as represented by electrons or photons. So if I can get an electron that I control onto your cat's six cable on the right side of that diagram, you're going to give that electron elevated privileges and attributes of trust, right? Zeros and ones, photons and electrons. That's our entire business right there, in a nutshell. And so we got to get rid of that paradigm because suddenly at that point they become a malicious insider. And so there's a couple of malicious insiders that are so famous. I call them the Beyonce and the Rihanna of cybersecurity. They're one word people. Snowden, Manning, you know those names, right? They were trusted users on trusted devices, right? They had the right endpoint protection. They had the right patch levels. They had robust identity systems. They had powerful multi-factor authentication. And they had least privileges too. Yes, right. No, they didn't. And yet nobody looked at their packets post-authentication. This is why identity is consumed in zero trust. This is why MFA and identity systems are not equivalent to zero trust. They're part of how we build out zero trust. Because ultimately every data breach is an exploitation of the trust model because every data breach makes the malicious activity part of the inside. They become a malicious insider. Next. So we got to get rid of trust. No more trusted packets. No more trusted users. No more trusted systems. No more trusted devices. Now people will object to that and they'll say, John, you're saying people aren't trustworthy, right? Everybody has to throw a joke at, well, I'm not sure I trust you. So I've just done it for you so you don't have to do it after the thing is over. And I'm not saying that people are untrustworthy. I am saying something much more profound. I am saying people are not packets. People are not packet. It is the anthropomorphization of the network that's killing us. The idea that John is on the network. Well, I've never been on a network before. I've never shrunken down into a subatomic particle where I've been sent over the public internet to say a Zoom server or wherever. This never happened to me. It's never happened to you. None of you have ever been on a network, right? It only happens in the movies. Tron, Ron Moorman, Wreck-It Ralph. But even in The Matrix, they got to plug in, don't they? So we have to get rid of that anthropomorphization and realize that it's just a user, their identity is asserted to be generating the packets from a device. And then we look at those packets and say, are they doing what they're supposed to be doing? Should they have access to the right resource? Are they behaving in a way that is peculiar? Next. So there's four design concepts in Zero Trust. The first one is we want to focus on the business outcomes. You must understand what your leadership is trying to accomplish, right? We don't do this because it's fun. We do this to drive a business or to drive, you know, if we work for the Air Force, I mean, there's a mission involved in it, right? So we must focus on that. That's the first step. The second step is that we design from the inside out and instead of the outside in. How many people have ever gotten like a CCNA, CCDA, any kind of that certification, right? How did you learn to design the networks? You started at the edge, didn't you? You started at the CPE equipment. You started at, you know, you had to get the right handoff and put the right WAN card into the router because back when I started, you couldn't get an Ethernet handoff, right? You get X25 or you'd get T1 or whatever it was. ISDN, all kinds of crazy stuff. And so then you would design it. You build out the core switching, the distribution switching, right? Which I know is called Spine and Leaf Now, which I think is crazy, like pick a tree metaphor or a human body metaphor and go with it, but don't confuse the two of them. But anyway, that's what happens when you allow engineers to do marketing, right? And so once you built that, then you just let the business plug into wherever they wanted to go. And then the third thing is determine who or what needs to have access. You need to know least privilege. Honey made a joke about least privilege. Both Snowden and Manning had access to everything on that super secret secure network because they had authenticated into it. There wasn't actually least privilege. No one knew what they were doing. Snowden, PFC, Snowden went to the NSA person at the forward operating base in Iraq and asked, hey, are you looking for malicious activity on the internal network? And the NSA person who was in charge of that network says, no, we only look for malicious activity coming in from the outside. Crazy, right? What was the attack vector? The trust model for both of those. And then the fourth step is we inspect and log all traffic all the way up to layer seven. Why do we do it at layer seven? Because that's where the attackers live. Why would we do it lower in the stack? And it's one of the things a lot of people who didn't live through what people in my generation lived through, which is, excuse me, the proliferation of more and more sophisticated attacks don't realize how much of a step it was when we started to get layer seven visibility into what was happening. And so we do this so that we can instantiate zero trust as a policy. Next slide. That's what zero trust is. It's a layer seven policy statement. We just have to have some layer seven controls to enforce the policy. Okay, and then finally, not finally, but there's a five step model, right? So we had the four design principles. Now we have the five steps of how you deploy. So the first thing you're going to do is define the protect surface. What do you need to protect, right? And the answer is we protect what's known as a DAZ element. So DAZ is an acronym that, oh, I guess I took that out. I must have taken that out of the slide. An acronym that stands for Data Applications Assets or Services. So anything of one of those four things that are sensitive is generally what I say you should protect. And so you take a single DAZ element, put it into a single protect surface, and you build out your protect surface, or you build out your zero trust environment one protect surface at a time. This makes zero trust three things. Incremental, you're doing it one at a time. Irritative, you're doing it one after another. And non-disruptive. All you can screw up is one protect surface. Too many people try to do it all at once for their entire organization. And it's too big. You can't eat the elephant with one bite, right? You eat it one bite at a time. You don't swallow the elephant whole. I don't know, I've never had an elephant, but we all know that that's the same. And then we map the transaction flows. Why do we do this? We need to understand how the system works together as a system so that we can know where to put the controls. And that's the third step, architect the environment. Usually people back in my day, we started with a big reference architecture and we built a network. And we said to the business, plug in wherever you want. And they said, well, that's wonderful. You've given me this network with a bunch of round holes, but I have square pegs. What do I do? And we say, well, the vendor gave us a free whittler knife. So you whittle it down and make it fit to what we built for you. And that's actually how the cloud started. Because the business said, well, no, I got a credit card. I'm going to go to the cloud. And so we would talk about, we'd get frustrated. You know, we talk about rogue IT or shadow IT. Well, why did that happen? Because we were creating things that didn't fit the needs of the business. And so we're going to architect the zero trust environment based upon the protect surface. Every zero trust environment is tailor made for the thing that is protected, right? You can't just ubiquitously say, I'm going to do it all this way and then fit it in later on. It does not work that way. You look at what you're protecting and you build out from there. And we'll show this when Jonathan gets up. The fourth step is create policy. I'll show you that in just one second. And finally, we're going to monitor and maintain. We're going to take all the telemetry from this and re-inject it back into the system. And so what we can do is create an antifragile system. So if you're familiar with the concept of antifragility from Nissen-Nicholas Taleb, Tuleb, who wrote the book antifragile, he gave me the vocabulary to talk about what I wanted to build. A system that gets stronger and stronger will be able to build a system that gets stronger and stronger under load. So your human body is an antifragile system, right? I'm going to go home. I've been having a lot of gummy worms at the hotel and things. I'm going to have to get antifragile and get back to working out. And by stressing my body, it makes it stronger, right? That's what we're doing here. And then finally, here we have the policy statement. So this is called the Kipling Method. When, where, why, and how. Rudyard Kipling gave this to us in a poem in 1902. So we can create policies, whether we're going to the cloud or on premise. You can build this out, Jonathan, where we can look at who has access via what application, where is that located, and how should we look at the packet in order to make an allow statement. So zero trust is a set of granular allow rules. You notice there's also some time limitations when and why. So you're going to be there for later on when you get more advanced, but you need to know who should have access via what application, where is that located, and then how should you inspect that. And if all of those things meet a certain criteria, then you will allow it. Zero trust is a set of granular allow rules. And this is important because policy is binary. All you can do is allow or deny. You can have multiple different sets of criteria to make the allow rule. But all bad things happen inside of an allow rule. So if you're spending very much time looking at, oh, we denied something. Let's do an investigation of what we denied. No, you just need to, hey, high five the team. Hey, we denied that. Let's move on. Let's look at what we're allowing. Because everything that's bad happens inside of an allow rule. So there is a data breach at your organization. You were a co-participant in it because there was a policy that allowed it to happen. That's a hard thing to tell people. Right? And it's not purposeful. But it's the old model rearing its ugly head. Okay. So now I'm going to turn it over to Jonathan. He's going to talk about how you can build this out in Google Cloud. And thanks. Okay, so the first thing I want to talk about here is that when I started my zero trust journey about 2016 there was already a number of vendors out on the market coming to us at that time I was one of the big major global consultancies like John was a forester at HCL. And you had all these vendors who wanted to sell you their magic pixie dust for zero trust. It was just beginning to become a popular topic at that point. And so I began to think because I was working in all three clouds at that point. I had big corporate vendors that were looking for solutions in this front. And it was confusing as hell. I couldn't make heads or tails of any of it. All of the vendors had different definitions for all of the different components of zero trust and what was needed for inputs. None of them could give me a transition state for my architectures. And I started to think about what the fundamentals were and how I had to adapt the business of IT in my organizations to meet the requirements of zero trust. So I went all the way back to the very beginning 2008-2009 started reading John's original work. That's kind of how we met. Is that I went back to John's work and I started talking kind of publicly to CISOs and other people like that and evolved into this train wreck of marketing that had no relationship to the original principal tenants of zero trust that were articulated in John's work, Forrester. And so I was advocating at that point for people to begin to go back to the original documents. What is it? Zero trust is this simple principle of eliminating trust from digital systems. So at that point I started working with Cloud Security Alliance helping to guide the authorship of these documents that we use for guidance in establishing these. And over the course of the last two years I've been privileged enough to work with Rwanda here at Google in helping the United States Air Force to develop the first prototype zero trust environments for the research environments at Ray Protestant Air Force Base. We support 14,000 researchers and technical directorates and we do a lot of that initial work where there's industry collaboration and academic collaboration with the researchers inside the lab in Google Cloud. One of the reasons for that is because it's very difficult to get a professor at the University of Katkart in a week so that they can collaborate with a materials directorate on some new science project that they're working on. So with that said I wanted to outline what it is that basic zero trust architecture and how we do that in Google Cloud Platform. So next slide. The first thing, as John said, is we have to go to step one. What is it that we're protecting? So if you're going to build even the most basic, simple web application, a secure web application that only your users are going to have access to, the first thing that we need to understand is what are the DAS elements that compose that application. We've got a front-end service, we've got a back-end service and then we've got the application data which may live in say a managed sequence. Next slide. We then define the protect surfaces. So each of those, each of the protect surfaces needs a network to be isolated, to be micro-segmented from each of its other counterparts. So we identify protect surfaces for the front-end service, the back-end service and the application data. We then map that to ingress control. Next slide. And then we begin to map the transaction flows. So we have the external users outside on public networks. They hit some form of ingress control which in this case would be a load balancer. They hit the front-end sub-network which hosts the front-end services, say a go application, 12 lines of go running caddy2 that talks to some javascript sitting in a GCS bucket. And then that will then make API calls to a back-end service which will then communicate with your application data in a cloud SQL instance. Next slide. We then begin to align policy enforcement points to the protect surfaces. Now this is the part that's really, really important to understand. Once we've identified each of the individual protect surfaces, the protect surfaces that map to each individual DAS element, you need to have a policy enforcement point to effectively enforce policy within the environment. So in these cases we have firewall rules that are governing the passing of traffic using GRPC on TCP 051 and the back-ends communications with the database on port 5432. We're also requiring TCP443 control. So all of it has to be over TLS. Next slide. The next thing that we do is we bring identity to the perimeter here. This is where we restrict access for unauthenticated users. This is one of the main advantages of working in Google Cloud. Google Cloud has this concept of identity aware proxy. It's when you hit the load balancer, the load balancer is actually two components, a front-end component and a back-end component. And when you hit the front-end it then goes to a sidecar proxy and says, are these packets authenticated? Is this request authenticated? Do I know who this user is? If not it immediately sends you to a login screen and says, identify yourself authenticate yourself. Should I put your packets on my network? And only when that's happened do the packets get signed and that's a very, very important concept. The packets themselves get signed and then the traffic gets connected to the back-end which then passes it through the firewall to your VPC which contains the subnetwork for your front-end service. So that right there in and of itself is a perfect example of how you protect a single protect surface. And can you just tell everybody how the packets get signed with a token? Signing means different things to different people. I am going to hand that to Honey because... Thank you. Just a regular good old digital signature somebody using their private key that only Google has access to they sign it and then the recipient will make sure that, hey not only we want to authenticate you and authorize you but we want to make sure which door you've passed through before you got to us because some people might want to evade it and go directly without passing through this door. Did you really sign? Did you really verify if it passes you go through authorization hopefully at their subnetwork? Sure. And then on the web front-end typically what we will do internally is that we'll also have a SAML integration on the front-end that so as those packets come in that's what authorizes the user to access the front-end service. I can get into all of the nuance of the service accounts and the way that we authorize the front-end to talk to the back-end and the way that we authorize the back-end to communicate with the managed SQL instance but there'll be a this'll all be up on slides and in the speaker notes we're running out of time here but in the speaker notes there'll be some more details about that. Next slide. The next thing that we have to do is that we have to have a role binding for the users that you want to be able to access this application. The IAP web app user role is then bound at the project level for this application and that is what gives the IAP service the signal to allow their packets onto the back-end of the network. So in the final slide here in this sequence and this is basically what the complete basic architecture looks like. You've got a web application with ingress control that is identity aware passing packets back to a sub-network on which the front-end service live which then can communicate with the back-end sub-network and the back-end service which then has access by a dedicated service account to the application data in Cloud SQL which itself lives on its own network. Each of them each service, front-end, back-end and the SQL workloads all on their own sub-networks individually firewalled from each other and each of them individually permissioned using dedicated service accounts. So and then fourth all of this we generally accomplish using infrastructure's code so this is this is the project code it's very simple I will say this we all work in government our we are obligated to deploy things safely and securely but to also maintain them in a secure state if you don't have state you don't know what you have and so I'm going to point this out that if you're thinking about going forward on this zero trust journey one of the first things that you need to do is understand how you're going to know what it is that you have long term and ensuring that it is in the state that you initially configured it in that you can continuously ask novel questions of your infrastructure and get answers back that confirm its configuration is as you intend it to be so that means adopting Terraform adopting tools like Argo with the application layer so that you have declarative means by which to confirm that your infrastructure is as you intended it to be. Slide. And I'm going to pass this back to John here because this is where it gets really interesting this is where we begin to apply policy at layer seven which is where we integrate an IDS service and with that I'll pass it on to John. Yeah the key thing here about layer seven again it's where the attackers are right so if all I'm relying on is the access policy at the identity level then a malicious user Snowden Manning this Texaria the new the new guy they can still do bad things and so we need to be looking at those packets and in Google they have Google IDS which is really an IPS so IDS is unidirectional without state IPS the better term is when it's bidirectional contained state and looks at the full packet up through layer seven and then can block the bad things so you want to block bad things you don't want to allow them and then investigate them later don't worry about false positives they don't happen very much anymore occasionally we'll see a false positive but it's really rare because the technology is so good and understands what's happening at the packet layer so well that we don't have the problems that we had at the end of the 20th century the beginning of the 21st century where everything was a false positive I used to joke that every sock engineer was color blind because you got so tired of chasing your tail with the red alerts that they just became green and you quit looking at them well the world has changed so use those layer seven controls as much as you can and it's going to be dependent if you're in Google cloud here you're going to be limited to the things that can be deployed in Google cloud but there's a whole ton of things that you can do and so go ahead and work on that and so finally once you understand that process let's get fancy here's a very sophisticated one that's done in gcp maybe I can let honey who built this talk about that sure thank you john working hello so this is just a fancy diagram for a real life example of how things work again we can think about it as protecting a multi-tier application front and back and then a database we use multiple components and we start you know from the bottom where we go we have the gfe this is where we have some protections like the us protections and whatnot but then after we get there we go into the low balancer and the best part about this is anything that can be a back and service to an external low balancer can be protected using your trust and that's a big statement this can be something running on premises or something on cloud or something on another cloud and that's how we use those connectors and other services that will allow you to sort of even if you have something with a private ip on premise it will consider it a back end for this low balancer which is when this ip will be checking for context awareness and you don't want to check only for identity attributes you want to check for operating system is the device protected is it you have encrypted disk on it is the patch level the one that you wanted so there is so much more than just identity that you can check in here and once you're able to authorize and authenticate all again at layer 7 you go into the multitude of controls that can happen from the org policies on top and we have this hierarchy of heritatory policies that go from the organization to the folder to the project down to the resources so you're hitting things from an org level next you go to the vpc that's another isolation layer then into the subnets again you're isolating more and more and you have those firewall rules stateful and everything else that you generically get from any other cloud vendor so this is pretty powerful because it's allowing you to literally zero trust any application whether it's sample based even if it's a legacy based app the last thing we want to touch on and again this is a little too short of a talk to get into things like context based access control and vpc service controls but one of the key things that I like to tell especially my command leadership is that zero trust is a business enabler this is not something that is going to constrain your users when you enforce policy higher up the stack you have to deny more and more frequently I am protecting a multitude of things under a policy enforcement point if it's close to my ingress control but if I shift the policy enforcement down the stack to the things that I'm trying to protect I have more information I have more context about that request to be able to say yes and so when implemented correctly and when the policies are applied correctly what you're actually able to do with zero trust is say yes to user requests more frequently and that removes friction from your production environments for the end users and it makes everybody inside your ecosystem more productive so with that I think we love to take questions anybody in the audience has questions and thank you very much for joining us in that previous diagram I was looking at was that a client running on the device so how are you applying policy is it just at the tcpip layer or are you running a client on the device in our case at the lab we use Google Chrome generally as the client for all of our web-facing applications and we use managed Chrome profiles with the managed Chrome profile and the context-based access tools like Access Context Manager we have the ability to determine at the time the request is being made whether a user has is on a managed device if they have full device encryption enabled if they're logged in with their CACA card there's a number of important signals and so when you take a look at the this one when you start taking a look at Kipling Method Policy you see it as a six-dimension matrix and so at one end of the matrix in each dimension you're going to have this signal and you can accept signals of varying strength if you're running a web application that's publicly acceptable your identity signal may be completely acceptable it's not going to be weak are you decrypting SSL in browser is the question? no the SSL termination point is always the load balancer TLS to the LB so once you go through Google's front end those packets are passed to the front end of load balancer and then IP and then they're decrypted on the back end when they pass the unencrypted traffic well it's not unencrypted in Google that's the other thing it's going over macsec at that point because they're encrypting point-to-point hardware between the devices the question is it's kind of like more about design application with zero trust in mind because typically when people are talking with zero trust it's about the networking layer but it is requiring application support as well because we have to really tell the people we need to think about application also supporting zero trust if the application is supporting some signature mechanisms your networking will be limited taking so we have situations inside the lab where we have hardware that predates most modern controls that run on operating systems that would like curl the shorts of most IT administrators today but we need them those devices are no longer made they're critical for some kind of research some of our electron microscope are like that there are hardware solutions that address some of those that allow us to secure those applications in those cases particularly on prem I also believe that things like VPC service controls the fact that we sign the packets in ingress with IAP we do some very unique things within a service mesh that's another architecture stuff if you go to service mesh it's really application should support architecture you're then deploying but then you're off loading say the validation of the signed packets to the service mesh and then passing that down and to say your networking Kubernetes I don't think that I'll actually let John well so you know best case scenario you want the application to be aware of what's going on but the reality is there's a disconnect between security networking infrastructure and the people who develop applications thank you that's what I was looking for the year and so the people who develop applications have a different set of incentives they want to push updates as fast as they can they're the Ricky Bobby's of IT they want to just go fast right and so in general and we did this research at Forrester they don't really care about security so we're going to okay you don't care about security we're going to make your application secure even though you're not making the application secure and quite frankly it's impossible you can't get rid of all the vulnerabilities because you're doing your best job you can and then five years later somebody finds log4j and no one built log4j and it just turned out that times change things change and so yeah so yes exactly so second assumption is like when you look at the asset especially on the screen you think about the role-based access control is outdated then we have to do asset-based asset-based centric no no well we're going to do both role-based and attribute-based and all kinds of access control based upon multiple sets of signals I want to just ask the question who or what should have access to the resource and why is that happening and how should that be allowed right so sometimes role is still the best way especially if I haven't got more advanced identity systems and I'm struggling to just this group in Active Directory needs to get access to this resource that may be all I can do and then I'm going to add multiple layers on top of it to enforce that and it depends on what data we are protecting it absolutely does depend on what data you're protecting the problem is most organizations can't get to perfection there's something keeping them from it and so sometimes they're afraid to just start the process because they can't do it perfectly and I say wherever you are is the proper place to start just do it now panic start panicking now do something and that will begin your journey right so the journey of a thousand miles begins with the first step make that first step right don't worry about the things that don't work so well because you'll find a way to get around that it allows you to be creative yeah perfect example is that we had a workload in the lab for the cloud architects we're using JIRA and let's just say that Atlassian's deployment model is not ideal and so we had to do our best with that workload so it needed to be deployed above FedRap High for this environment it didn't touch CUI data or anything sensitive but we still needed to get controls around it so the first thing that we did is we took the standard deployment and we kind of decoupled all of the critical components of it the stateful parts of it that needed disk where we'll put into cloud cloud native storage the next part of it was the decoupling of the database and then the server portion and so we built that with Packer we had something that was in a known state when it was deployed we attached the cloud resources to it and then we secured it using this approach so thank you thanks so we're out of time thank you very much for coming we really really really appreciate it and we hope we can engage deeper with you later on okay