Transcript
what Zero Trust can mean in a WAN environment. First of all, if we look at traditional WAN environments, you will see several environments that will be connected to each other with an SD-WAN solution, an MPLS or a combination of them. And these connections ensure that everything can finally talk to each other. There are a few fundamental problems with this approach. First of all, it quickly becomes very complex. If I want to control all those traffic flows, it means that I have to place firewalls locally. These firewalls are very good at protecting their own little thing, but in general, there is very little idea about what happens in the rest of the network. An IP address is an IP address, you don't know exactly what that means. You can start doing things as a NAC to push users specifically into certain groups, but in the end, the problem remains the same. Especially in an environment where an IP address can be one application today and something very different tomorrow. If I start an AWS, there is no guarantee that the IP address will do the same tomorrow. Finally, it also means that all these environments must be routable. This means that I have dependencies based on IP. The IP address here may not exist there, but it has to get there. This means that if I have a new environment with existing addresses, it will be very difficult to connect them. And again, with cloud, this is actually the usual work. What does it look like in a real Zero Trust environment? First of all, we have the Zero Trust Exchange here. It is a central component where all these environments make a connection. For users, this is quite simple. I just have a client, and that client automatically makes a connection with the node closest to it. But I also have solutions for my other environment. First of all, I can build tunnels. Nowadays, we can also use branch connectors in these environments. Or cloud connectors, like AWS, Azure or Google Cloud. They work in the same way as a client. They look for the node closest to it and automatically make a connection. While this is happening, they get their policies. They get to hear what they have to do and what they are allowed to do. And in this way, they can exchange data and talk to the Zero Trust Exchange, so that they can actually make those connections. On the internet, this is fairly straightforward. I just make a connection to the outside world. The internet doesn't really matter what the original IP addresses were here. But of course, I can also make a connection with the applications that are used internally. We have a component there called an App Connector. The App Connector actually functions as a client and is therefore responsible for the connection to the internal application. In most cases, there may not be much need for an office environment to connect internally. But I think that in the case of a factory or a warehouse, if you want to talk to an existing OT, that happens regularly. The advantage is that the branch connector, which we have in a hardware form factor, can also connect the outgoing branch connector at the same time. But it can also host the App Connector. So together, it actually provides bidirectional traffic. The beauty of this solution is first of all that all these connections are actually independent of each other. This means that if I have a certain IP range here, it is not a problem if I use it elsewhere. Instead, we look at DNS and make the connections based on that. This also means that if I build up very flexible environments in the cloud, I can simply connect with them. This also means that if I notice that an application is initially in a data center and then moves to a cloud, I don't actually have to make any adjustments. I just have to make it known on the App Connector and then I can make automatic connections to all my users, as well as all my other environments. In other words, I can make those connections very flexibly and dynamically. I can do that based on performance. I can just see which environment works best for me. I'm going to use that. For offices and other environments where users are located, I will still let those users go to the right. That's easy. Then I just have an identity. I have authentication. I can follow much better. This also means that if those users move to it, I will still keep the context, the history of those users, so that I know very well what the risk profile is and that I also know very well what has been done in the past and whether I might have to take that into account. At the same time, I have an IoT environment here, for example. I'm going to let it run through the branch connector. If it is still necessary that I want to separate those environments further, for example, I have a payment system at the office and I also have a door access system. I have to put that on the network, but I don't necessarily want people to be able to communicate locally with it or even communicate with each other. We have seen in the past that access points were used to take over an environment. To make that possible, we can continue to segment here. And we can actually do that without having an impact on the devices or the network itself. So I don't have to make any further adjustments to my VLAN. I don't have to make any adjustments to my devices. I don't have to install an agent. I just have a solution that looks at the traffic flows, that can position itself in between and can check all those connections. And I can do that both in control environments and in the factories or warehouse environments, where there is more traditional OST. The advantage of the latter is that many of those OT systems are often certified. I don't have to make any adjustments to that. We even have certain fixed settings for things like IP addresses. We can handle that neatly. If you are interested, go to our website www.zscaler.com or contact one of our sales people who would certainly like to discuss this further. Thank you.