As organizations shifted to a primarily remote workforce, the security of the network has become increasingly more important. Many have begun looking to the increasingly popular Zero Trust strategy as a means to secure networks and prevent data loss. But how do you translate a strategy, and something that has become a popular cybersecurity buzzword, into a practical implementation? Join Nir Zuk as he discusses different deployment scenarios for Zero Trust, and considerations for technology used in Zero Trust environments.
Transcript:
Hi everyone, Nir here, Founder and CTO of Palo Alto Networks. In this presentation, I would like to discuss Zero Trust and how Zero Trust can be applied throughout the entire infrastructure. How is that different than what others are calling Zero Trust? And more importantly, how Zero Trust can be the guiding principle in designing cybersecurity architectures.
Maybe before talking about Zero Trust, let's start from the beginning. If you really look at our industry, the cybersecurity industry, the main goal of the cybersecurity industry is to help customers reduce risk. Risk is not going to be zero. We don't want it to be too high. We want the risk to be balanced versus cost and what we can lose in case of a cyber attack. And over the last 25 years I've been developing, and the industry has been developing, products that help customers reduce risk.
Now, there are different ways to reduce risk, for example, encryption at rest, right? If you encrypt content at rest, you reduce the risk of that content being stolen or at least if it's stolen, that content being useful for the adversary and you reduced risk. There are many other technologies like that. However, if you look at most of the tech that the industry has been producing and selling and you've been buying over the last many years, that tech was focused on one thing, which is establishing trust and by that, reducing risk.
So for example, in the beginning, at least the beginning of my career, when I started building firewalls, we needed to establish trust for IP addresses. So how do you trust IP addresses? How do you trust port numbers? You put a firewall. We needed to establish trust for files. How do you establish trust for files? Well, back then you put AV software on the endpoint and if the file is not in a well-known list, or it doesn't have a well-known signature, then you can't trust it. Not super smart, but hey, 25 years ago, that's what we had.
So really if you look at many of the products that you're deploying across your infrastructure, network, endpoint product, now cloud security products, vulnerability management products, and so on, they're all about reducing risk through helping us to decide whether we trust something or not, right? And, there are really four different things that they help us decide whether we can trust or not.
Users, can we trust the user? Can we not trust the user that's trying to access something in our infrastructure? Endpoints and workloads. So user endpoints and endpoints as servers or containers, VMs, and all type of other inputs that we're seeing today. Can we trust it? When an endpoint tries to communicate with another endpoint, can we trust it? The third thing is applications. Can we trust applications? Applications running on these endpoints, whether it is our user endpoints or cloud workloads and so on. And then the last thing is, can we trust content? Can we trust the file and so on?
And of course we can map those to different products running in the infrastructures. So for example, as I mentioned before, we use antivirus to decide whether we can trust an application and sometimes whether we can trust content. Can we trust the PDF document? Can we trust the PowerPoint presentation? We use IDS to decide whether we can trust the packet or whether we can trust an operation on an endpoint, if it's in host IDS. We use URL filtering to decide whether we can trust a URL. We use a DNS security to figure out whether we can trust the domain name on all that. Proxies in some cases, help us do those tests.
We use different technology to decide whether we can trust a third party software that we use. Can we trust an open-source package that our developers are trying to use in their code or deploy into our cloud environment and so on. So really if you start looking at your cyber security budgets, you'll see that the vast majority of it, probably north of 90%, it really goes to deciding whether we can trust something or not. And the interesting thing is that I think that some of the fragmentation here in our industry, where we have so many different vendors doing so many different things is a result of the need to establish trust, right?
So we started with the firewall. We started with the antivirus. Great. Now we can trust IP addresses, we can trust port numbers, we can trust files, but can we trust packets? Can we trust what the firewall has allowed? We can't, so let's put an IDS and an IPS. But good, now can we trust a URL that users are trying to access? No. Okay, let's put URL filter. And over the years, this thing grew and grew and grew into today where most of our customers would use many dozens of products from many dozens of vendors for mostly one goal, deciding whether you can trust something or not.
In order to explain, end-to-end Zero Trust, I'll be using the following example in my presentation. What you see here is a user using an application on an endpoint and the entire path that they take until eventually they access sensitive information sitting, let's say in a database running as a PaaS service in a public cloud.
From the user endpoint and the application, we're seeing packets going through the internet, into public cloud, into a web server running inside that public cloud, that is the front end of the application. And behind that web server, there is a big application that's made of many microservices that are running as VMs, as containers, maybe a serverless functions, implementing the application. And then some of these microservice components, VMs and containers, serverless functions at some points, access the database with the sensitive information that in this example, again, is running as a PaaS service.
And we want to show how Zero Trust has to be done end-to-end, all the way from the user and the application and the user endpoint to that PaaS application. And the main idea behind doing Zero Trust across the entire infrastructure is that each of these components that are being used in order to eventually get the user to access the sensitive information that's in the database, is responsible for their own security. They cannot trust anything that happened before they cannot trust anything that happened after.
Nir Zuk:
So for example, the web server cannot trust any security checks that were done before packets hit, before a connection got into the web server and cannot trust anything that happens after it, a little bit like this paranoid person that we see here in this picture. So you can imagine it as every little component having a wall around it, that's responsible for checking users, applications, endpoint/workloads as well as content and only allowing it if it can establish full trust without trusting anything else.
That's why we call it Zero Trust. We call it Zero Trust not because there is no trust, we call it Zero Trust because at every step of the way, and we just don't trust anything. We have Zero Trust in anything that happened before us, in anything that's going to happen behind us, and we're going to do all the checks at each of these steps in order to establish trust.
So now that we understand the concept of Zero Trust and how Zero Trust needs to be done end-to-end with all the components participating in it, let's look at some specific use cases, some specific real world examples of Zero Trust and how Zero Trust should be applied to the infrastructure. And I want to start with the most famous Zero Trust component, which is called Zero Trust Network Access or ZTNA.
Some vendors would like to present ZTNA as being Zero Trust. We believe that it's a component of Zero Trust and specifically it's the component of Zero Trust that is between the user and the front end application. So in this case, we want to make sure that the user is whomever they say they are, that the content that they send or receive is what it's supposed to be, and some cases, maybe we can verify the application that the user is using through post profiling. And specifically the way we implement that is using a lot of network security technology in the running on-premise or running delivered from the cloud. In some cases we would call these remote access technologies, but the important thing is that we have to look at everything.
We have to identify the user. We do that using strong authentication, usually right after identifying the content. And we do that through technologies like IPS and anti-malware and sandboxing. We have to verify applications that are being used. We do that through host profiling, we do it through URL filtering to make sure that when traffic comes back through that ZTNA portion of Zero Trust, it goes to URLs that it's supposed to be going to, means that it's supposed to go to DNS security and so on.
Zero Trust Network Access is an important component of Zero Trust, but certainly not the most important and not the only component of Zero Trust. So let's look at a few others. Before we even hit the portion between the user and the web server through the internet, through the network that's in the public cloud, we have an application running on an endpoint and the user using that application. And we have to make sure that the application is good, meaning it has no exploits in it, that the user is whoever they say they are, which the ZTNA verifies, but not to the right extent. I'll explained that in a second.
We have to make sure that the endpoint itself is not owned by an adversary, and we're also, of course, looking at content on the endpoint using endpoint security products. So ZTNA verifies the identity of the user, once it sees the packets coming out of the endpoint, but since we don't know if these packets were generated by an action that the user took or an action that was taken by the adversary, we have to extend that to the endpoint itself and verify that all the operations that we're seeing happening on the endpoint are being executed by the user, not by someone that pretends to be the user.
The endpoint is the only place where we can do that, and therefore we have to extend Zero Trust to the endpoint. It has to start there. We cannot trust any operation on the endpoint, we have to verify that it's the user doing it. So what Zero Trust networks Accs, is establishes zero trust between the user and the web server. As you can see here, there are steps that happen before the packets that are generated by the user even hit the internet, and the rules of Zero Trust is that we can't trust things that happen on the endpoint. We have to be on the endpoint in order to establish trust in those earlier stages of the path between the user and the important data that's sitting in the database, again, that in this case is a PaaS application.
So to do that, we have to make sure that the user is really the user. Yes, we have authenticated the user and ZTNA verified that the user is authenticated, but is it really the user? I'll show you in a second, that there is a question around that. We have to verify content that appears on the user endpoint. We have to verify that the endpoint itself is secure, and of course we have to make sure that the application that's running on the endpoint is really the application that it's claiming to be, a web browser, and not an application that's a malware that appears to be a web browser.
So for that, we have to take these two and establish Zero Trust around them, and of course we do that with endpoint security software that has to be part of the bigger Zero Trust path. And specifically regarding the user, as I said, yes, Zero Trust Network Access has verified that the user is authenticated, but how do we know that packets coming out of the end user endpoint really were generated by some user activity and not by an adversary that hijacked the user identity or hijacked the connection after the user has authenticated and is now doing things that they're not supposed to do?
From Zero Trust Network Access perspective, we can not tell that unless we see it in the content, but generally we cannot tell that on the endpoint, relatively easy to do that. We look at system calls, we look at activity, we look at the behavior, we look at the different things and make sure that they are indicating that it is the user that's performing the operation and not someone that hijacked the user identity or the user connection, performing that operation. So this is how we extend Zero Trust to the user endpoint.
We also have to remember that there is another type of endpoint, IOTs, and in many cases it will be an IOT that is going to communicate with the network. The IOT can be the camera that I'm using right now to record this over Zoom, it can be my microphone, which I'm sure is running some sort of software on it, it's a high-end microphone, and the IOT can be of course, many, many different things that the enterprise might be using. Things that have to communicate with applications that have sensitive data in them. We've seen IOTs of course in robotic surgeries, we've seen cars that are IOTs, we've seen many medical devices that are IOTs, and of course, many, many examples of IOTs that need to communicate with sensitive data. And we need to secure them well, before we can perform Zero Trust Network Access for those IOTs.
For that, we're seeing an emerging market for IOT security and really it's about protecting the IOT from a Zero Trust perspective, the same way we protect the endpoint, with exception of not really having a user on the IOT. We have to protect the IOT itself or establish trust, sorry, for the IOT itself. We have to establish trust for the application running on the IOT, and we have to establish trust for the content coming in and out of the IOT, to make sure that it's not malicious.
These are the goals of IOT security, and when we're designing our cybersecurity architecture, when we're designing our end-to-end Zero Trust, we have to take IOT security into consideration and make sure that IOT number one, the IOTs perform Zero Trust checks for content, for application, for the device itself, and second, that we don't trust traffic coming out of the IOT in further stages of the path, for example, in the Zero Trust Network Access stage of the end-to-end Zero Trust path.
So that's for IOT security. Now that we have established Zero Trust for the application and the endpoint, the top left side of this slide, and we established trust for the user going through the internet and the public cloud to the web server with Zero Trust Network Access, we're getting to the next stage of Zero Trust, which is the backend application running behind the web server, which in many cases is made of hundreds, thousands, and even more microservices implemented as VMs, containers or serverless functions. And we need to establish Zero Trust there, meaning first we cannot trust anything that's getting into that ecosystem from the web server into that ecosystem of microservices. We cannot trust anything outside of that ecosystem in this case it could be the PaaS applications.
But even within that ecosystem of microservices that make up a backend application, we're finding that it's very, very useful for different components of that microservices architecture for each microservice, not to trust other microservices as well. So if we have my one microservice, that's talking to the database and we have another microservice, that's talking to the web server, when the microservice starts talking to the web server, tries to talk to the microservice, that's then accessing the database, we need to establish trust between these two. That's not easy, but very, very important in any Zero Trust architecture.
How do we do that? Well, probably we need to run an agent inside every microservice, inside every VM, inside every container, inside serverless functions. Those agents help establish an identity for each of the microservices, such that when microservice A tries to talk to microservice B, we can be assured that it's really A trying to talk to B. Both A can be assured of that, that it's really talking to B. What's after it, you can't trust anything after you and B making sure that it's A talking to it. You cannot trust anything that's happened before you. You can say, "Well, it's probably okay, because if it's communicating with me something tested and checked that it's okay, that it was okay before." No. Zero Trust requires that A doesn't trust B, B doesn't trust A, and we use the identity that we established for A and B to make sure on both sides, that A talks to B and B talks to A. That's how we enable Zero Trust for the microservices themselves.
Now we need to establish Zero Trust for the content. So when A talks to B, A sends information to B, B sends information to A, we have to make sure that there is no, I don't know, command-and-control traffic in it and no malware, and that the content inside is really the content that it's supposed to be. So we have to also establish Zero Trust for the content between A and B, and usually we will do that with some network-based, cloud native network-based security product that can... it can inspect the traffic between A and B and make sure that it's okay.
And we also have to establish trust for the applications that implement microservice A and microservice B, and the way we do that is with the agent that's running inside, as well as by shifting left to the stages before even deploy those microservices, where we look for vulnerabilities. We look at the application that's being deployed and make sure that it's really the application we're trying to deploy, and nobody has hijacked the deployment infrastructure. We make sure that the software that we deploy, if it's open-source, came from the right source and so on.
And also if we do run-on-time checks while the application is running, we do run time checks to see that the operations that the application is performing are the right operations, what we expect from the application, and nobody has hijacked the application and is now trying to circumvent it. So by having an agent cross all the components of the microservice architecture, meaning every microservice in every VM, every container in your host at least, and every microservice, we're able to establish Zero Trust, both for the microservices themselves, for the workloads themselves, for the content, the information that the microservices exchange and for the applications that implement the microservices.
Now, as you can see, there is also a PaaS component after the microservices and those microservices that talk to the PaaS application, which in our case is a database application that has sensitive information in it they need to make sure that they're talking to the right PaaS application, to the right database and that nobody of course, has somehow found a way to exchange that with a mock or a fake PaaS application and we're now reading and writing data to a database that's not the right database and it's under someone else's control.
So there has to be Zero Trust also between the microservices that use the PaaS service or PaaS services and the PaaS services themselves from the microservices perspective. And the same thing is true for the PaaS application itself. So now that we move to the PaaS application, the PaaS application has to make sure that the microservices that are communicating with it are the right microservices that are supposed to be communicating with it. The application itself that makes up the PaaS application, in the case of a PaaS application that's running in the public cloud, of course, is under the public cloud provider responsibility.
Maybe there are ways to establish our own Zero Trust around that and make sure that it's really the application that we're expecting. Maybe we can go through the configuration of the PaaS application, and we also have to look at the content in the PaaS application and make sure that that content is not malicious. That maybe there is a PowerPoint presentation stored in the PaaS application, it's a storage PaaS application or a blob in the database PaaS application. That, that PowerPoint presentation in my example is not malicious, and once it makes itself back to the user, might hurt the user.
So establishing Zero Trust within the PaaS application is also very important. The PaaS application cannot trust anything that's communicating with it, nothing that communicates with it can trust the PaaS application, and we cannot trust the content within the PaaS application, we have to establish trust for that as well.
So now that we've established trust throughout the entire path, all the way from the user and the user's endpoint and application that they use to the database in this case, that stores sensitive information, there's another layer to Zero Trust. And the way things have evolved over time and rightfully so, we don't trust the Zero Trust. And what I mean by that is that in some cases, Zero Trust decisions cannot be made in real time. And in most of the cases, if you look at the path here that the communication takes all the way from the user to the application, we don't have a lot of time to make the decision.
We have milliseconds to make a decision, whether we can trust something or not, whether we can trust the user, whether we can trust the content, whether we can trust an IP address or URL or domain name. In many cases, we can make that decision in a millisecond, but there are cases where we can't. In some cases, we would make the wrong decision because we only have a millisecond to make the decision. So of course, what we've done over time is we've established another layer on top of all of this, a layer which we call the security operation center, which looks at all the Zero Trust decisions that have been made and all the decisions that couldn't have been made because of the real time nature of the work versus the non real time nature, that some Zero Trust decisions require.
And we take a second look at everyday and that's what the SOC does, right? The SOC collects data, the SOC looks at alerts, it hunts for attacks and it tries to look for trust decisions that have been made that were wrong. For example, the IPS has decided to trust something, but it shouldn't have, it was an export. We allowed the user to go in through Zero Trust Network Access, but maybe it wasn't really the user because we've seen the user. This is a famous example, everybody uses that. Because we've seen that user within a few minutes working into different parts of the world.
Has the firewall allowed something that it shouldn't have allowed? Has the endpoint security software missed something it shouldn't have missed, and it's trusted some file on the endpoint it shouldn't have trusted? And so, right, in every step of the way here, we could have made a trust decision. We could have made a decision to allow something, to trust something, even though we shouldn't have and the SOC, the security operation center, is using all these different technologies that you see at the end. And the SOC is the last piece of an end-to-end Zero Trust architecture.
The SOC together with everything that we've seen before, around endpoint security, IOT security, Zero Trust Network Access, everything that we do in order to establish trust within the backend application, across all microservices, where there are VMs or containers or serverless functions and PaaS applications, and I haven't even mentioned SaaS applications here. We need to establish trust with SaaS applications and our other things where we need to establish trust. We cannot trust them. We have to assume that they are untrusted and we need to establish trust. All of that is very, very complicated and requires many, many different components.
We believe that the easiest way, and really the only way to achieve end-to-end Zero Trust is to have a well-coordinated architecture and solutions that perform all the Zero Trust for end-to-end. That's exactly what we do at Palo Alto networks. We have Strata that enables Zero Trust Network Access, if you want to do it yourself. It enables IOT security. We have Prisma Access that enables Zero Trust Network Access as a cloud-delivered service. We have Prisma Cloud, which enables all the different aspects of Zero Trust for public and private clouds across all computer form factors, all the way from CICD to VMs, containers, serverless functions, and PaaS services across all public clouds and private clouds.
For the security operation center, we have Cortex that takes all those different components, puts them together and allows a lot of automation around establishing Zero Trust or verifying trust for the different trust decisions that have been made by Strata, by Prisma Access, by Prisma Cloud, and if needed changing those decisions in near real time through automation, by going back to the infrastructure and stopping or undoing a distrust decision, that's been made hopefully few seconds, a few minutes before.
Thank you very much for listening. If you want to hear more about end-to-end Zero Trust, if you want us to help you architect end-to-end Zero Trust, if you want to dive into some of the solutions that enable Zero Trust in different areas of the infrastructure, Zero Trust network, access, Zero Trust in public clouds, Zero Trust for endpoints and so on, we'll be happy to meet one-on-one and talk to you. Please contact your sales team, or just send an email to sales@paloaltonetworks.com. Stay safe, and I hope to see many of you in person very, very soon. Bye.
