Name: Zero Trust OT Security: How Armis & Zscaler Secure Factories
Uploaded: 2026-03-04T18:16:13.974Z
Duration: 1 h 1 min 8 s
Description: Zero Trust OT Security: How Armis & Zscaler Secure Factories

Transcript for "Zero Trust OT Security: How Armis & Zscaler Secure Factories": Okay. Are we good to start? Okay. Hello, everyone. I'm Rachna Raman, and I'm your host for today's session. We're diving into a topic that is rapidly becoming the make or break factor for modern industrial operations, securing the zero trust factory. So the reality is that the walls around our factories have essentially vanished. As we embrace industry four point o, we've interconnected legacy OT, IT, and IoT devices in ways that offer incredible efficiency, but also open up infinitely more attack pathways. In this high stakes environment, traditional security is just not enough. That is why we're here today to explore how Zscaler and RMIT are coming together to provide a new playbook for unified visibility, dynamic segmentation, and proactive threat containment. To lead us through this, I'm joined by two incredible experts, Carlos Buenano, the CTO of OT for Armis, and Umang Barman, OT specialist from Zscaler. They bring unique perspectives on how to close your security gaps without ever disrupting the millisecond precision timing that production lines require. So without further ado, Carlos and Umang, over to you. Thanks, everyone. Super excited to be here today. Thanks for the introduction, Reshna. Good morning to whoever and wherever you're joining from. I'm personally very excited to be here to discuss this topic on OT security. I just wanna open way by saying that last week, I was at a manufacturing conference in Europe, and OT security was one of the hottest topic. Everyone wanted to know about it. Everyone wanted to learn about it. So it's definitely top of mind for several people, and I guess that's why you're all here. So with that, Carlos, do you wanna quickly add anything to your background and how your experience was last week? Yes. So last week, you know, I was actually at S4 conference, and like you, I my perception was that, you know, there's a lot more awareness out there and looking at different angles, only from a technical perspective, but also from a psychological perspective and what it means from designing and preparing a security program and even incident response and implementing systems to basically prepare people to, you know, you know, to to a cybersecurity, you know, readiness. And there is a lot of conversations, a lot of technology, of course, but it's very interesting to to to understand how how the the industry is developing in such a way that we're here today. I'm very excited to, you know, provide you with some insights of not only our technology in separation, but also how we're working together as a community, which is actually the most important part that I'm seeing in the market so that we can actually provide that, you know, outcome that the customers or the community itself is actually looking for. Yeah. Likewise. Likewise. And I think this is where I want to start us off because in the last few weeks and months, I should say, when I spoke with our OT customers, our manufacturing customers, I wanted to share what are they telling us. And what they're telling us is that from their perspective, the traditional OT air gap is largely gone. And that's happening because OT is getting more connected to IT, to enterprise networks, and to the cloud. Let me give you a few examples. First example is every other conversation I have with a manufacturing customer. They're thinking about digital twins or or AI models, and they're doing that because they want to be more they wanna add more predictive analytics. They wanna understand how they can produce more products with fewer errors, and that means they need to send this data up into the cloud for better analytics. Second example, the factory floors themselves, which means the conveyor belts, assembly lines, they're getting more interconnected too for more automation. That means things that were not connected before, even down to Purdue level two and one, now have an IP address, which means they're getting more connected and more reachable. Third example, because they're adding these more specialized equipments on the assembly lines on the production floor, they want to ensure that the contractors, the specialized people who come and update and fix them can do it quickly and easily from wherever they are rather than having to fly them in, which was the case maybe a few years earlier. And last but not the least, there are more specialized devices that are coming not just on the factory floor, but just around the factory floor or on the shop floor. You have cameras, HVAC systems, different kinds of sensors, tablets, and that's an unprecedented number of connectivity on the factory floor that wasn't there before. And what that does is that increases the attack surface and provides attackers more pathways to impact factories. And, Carlos, what what what have you seen on your side? Yeah. So look. I'm I'm I'm coming from an operational background. Okay? As a control systems engineer, maintaining, you know, decent environments. And, you know, even though we typically focus on the control systems, the ICS devices, which basically we have, you know, everything, you know, on the on the on the catalog, PLCs, HMIs, DCS, sensors, actuators, and so forth. And and as you mentioned, they're all very, very well connected. There's a lot of other devices that, you know, we typically don't think about. You know, we we have, of course, the network infrastructure that allows us to connect all the devices. We also have the building management systems. And, you know, in in opinion, building management systems are actually as important as a control system because they basically keep the resiliency going on a floor plan. We're talking about HVAC, we're talking about UPSs, we're talking about even smart power boards today. And they're all very well connected. They are actually being monitored by specific network management systems to understand their reliability, to understand battery power so forth. But as well, we have other devices that, you know, are everywhere. You know, we have IoT devices. You know, we have displays that helps, you know, provide information, you know, from a production perspective. We have telephones, you know, VoIP systems, you know, even, you know, devices that help us keep access or provide access to keys and cabinets and so forth. It's a huge ecosystem of devices in an OT environment today that basically is exactly a you know, example of what you were talking about, Oman, of how all these devices are interconnected today. And beyond that, how they are serviced. The the new wave of servicing from a a vendor perspective is to do everything remotely. You know? Obviously, there is a lot of efficiency by, you know, providing direct connectivity to the OT environments, mean, to the point that even there there is a device to device connectivity to, you know, to the production devices. What that means is that, you know, we no longer have engineering stations or licenses for engineering stations locally in in the floor plan. We actually have it remotely from a, you know, from a vendor perspective so that they can connect across all the way to the end device to do the diagnostics, the maintenance, and even configuration changes. So all these actually create a massive increase of the attack surface from any of the environments. Right. Right. And, you know, it Carlos, you probably would agree that this this this is you know, it feels like we're preaching the choir because most people have and probably experience this every day. I do wanna kind of emphasize that, you know, it's less so that you may not be dealing with this problem every day. What I wanted to share through these what we wanted to share through these slides is that everyone is dealing with these problems, and so you're not alone. There's one other thing to think about as you start thinking about how to secure these attacks is that what we have seen and, you know, what we would see more is that what earlier used to take many months can now be done quickly through AI. So a few weeks back, Anthropic published a report where they where they where they outlined how a state sponsored actor orchestrated an attack, an intrusion across 30 plus organization. And the difference was that AI executed most of the steps in the attack life cycle, which meant that they did the the AI agents were doing the reconnaissance, vulnerability discovery, the lateral movement, and data exfiltration, multiple organizations were impacted. And the challenge for OT is that because you have fewer controls, security controls, as the device are more connected, the attack surface is more exposed, the the the networks are flatter inside OT, you need a different way to think about it. And that's what, you know, we wanna ultimately share and present to you today. And, Carlos, maybe you should start off by talking a little bit about Armis, and then we'll we'll we'll get into the details of the joint solution. Yeah. No worries. So I guess, you know, for what Oman was actually mentioning about before. Right? So it's all about, you know, understanding the tax rate surface, you know, in order for us to protect an OT environment. So we have a lot of challenges. The first challenge that we have is, you know, understand how or what devices we have in the OT environment. We mentioned the complexity of the OT environment before, but until now, we we haven't had a way to basically categorize and classify all these devices or c has assets. More more importantly, how to basically understand the security posture of every individual device no matter where they are in the in the predictive model, no matter what level they are. It can be level zero, level one, level two. And the reality is for us to basically protect these devices, well, first of all, need to understand, you know, what they are and secondly, how how they are behaving. And Armis is actually trying to achieve that. So we have several ways. On the left side is a what we call data sources. And the data sources that we have is basically, you know, from network traffic analysis so we can actually understand, you know, how this device behave to a smart active querying so we can actually use in native protocols. We can a nonpersisting can collect information directly from from the devices, specifically PLCs and controllers and so forth. But more importantly, you know, to add a lot more context, we integrate with a lot of systems and network tools, you know, to basically correlate that information and provide that unique visibility, know, across all the different assets in the OT network and in in this particular case, in every part of the network, including IT. So the whole idea is just to and I know it's a bit small. Hopefully, you know, you can see it. Let me see if I can actually put it bigger myself. So the whole point is just to do a continued threat exposure management, CTIM, where we can actually start monitoring, constantly monitoring, understanding the threat and the the vulnerabilities of the device, and then look at, you know, the prioritization, how we prioritize the mitigation or if we can in an OT environment remediation. And sometimes, you know, production and safety are actually paramount from a plant floor. So sometimes we're actually limited to what we can do, but then we can start thinking about other alternatives. And then that's the whole point is that we can start looking at, you know, creating workflows, integrating with other systems that, you know, first of all, it's gonna automatically update, you know, information. Every everything or every context that we create is actually shared across other systems like CMDBs or every anomalous behaviors we can actually send information to the SIEM. In this particular case, we use actually information, you know, to basically integrate with Zscaler to provide that value that is needed to protect the assets. It gets more complex, but I just wanted to minimize, you know, and give you an idea of how Armis works. Mike, just you you know? Sorry. Okay. Sorry. So the whole idea is then to understand, you know, the attack map sorry, attack path mapping of the device. So in this particular example, once we collect all that information that that I mentioned before in terms of, you know, what the device is and how it's behaving, how it interacts with other systems in the in the in the system in the network. So you can actually see, for instance, down below here, we have an entry point that is a device in the OT network sorry, in the IT network, you know, communicating, doing RDP communications all the way to an engineer station or communicating SSH to other other network equipment in into the into the OT network. So that you can actually start seeing, you know, from a from a path attack path mapping, you know, what are the hops that devices can actually take or attackers can actually take to get into a specific critical device within the OT network. In this particular case, an a7 controller that is actually a part of the airport controller in this particular scenario. So you can actually see how, you know, creating that visibility, understanding the vulnerabilities, understanding the assets and identifying and categorizing devices, it's helping us creating this visibility of how devices are actually vulnerable, you know, from an attack perspective. Yeah. Thanks, Carlos. And so if you now fast forward a little bit, as you saw with with Armis, there is a there is a rich engine that gives you device telemetry spec specifically in OT devices. Let me walk you through to the other side of the equation, which is what do you do with this telemetry? What do you do with this data? That's where Zscaler comes in. So if I take a step back and tell you a little bit about Zscaler, traditionally, if if you are familiar with Zscaler, you know it provides cloud based security and secure access to Internet and to private application to users. So if I'm a user, I wanna have safe, secure access to the Internet, I would deploy a small Zscaler connector client on my laptop. That client would send the data through Zero Trust Exchange where you would enforce policies. Similarly, second product called Zscaler private access or ZPA would ensure that a user, which is me, ensures connect only to specific internal or private application that I'm allowed to based on the least privilege access. And with that, you would mitigate or eliminate any attack surface. So if I was compromised, then the attacker only have access to this one application, not to the entire network. We extend the same zero trust principles down to the devices. And that's where this product comes in called Zero Trust branch, which is indicated in pink in your screen. So Zero Trust branch is a physical or a virtual form factor device that actually sits on the factory floor or in any branch, and it provides two critical capabilities. The first one is to ensure that any internal OT system, it could be, say, a PLC or a SCADA system or a camera can get secure access and a least privileged access to a application that's in your data center or on your private cloud. Now this functionality is very, very similar to what we call Zscaler private access, meaning that because these devices cannot run agents, you need the Zero Trust branch box to enable or broker the access to Zero Trust Exchange where you would enforce all the policies and ensure that the the device only connects to this one application. And because all the traffic is going through the zero trust exchange, you can ensure that you can monitor the traffic. You can eliminate any any any any any connection to command and control service, any other rogue service that they're trying to connect to. So you have full visibility into what these devices connect to, and you can do this without without using your traditional SD WAN. The second capability, which is which is which is even more critical, and every manufacturing customer wants to know and do is segmentation. Now segmentation has been tried and tested before, but it's really hard to do and really hard to execute. And I'll walk you through how it's done, but that's where the the Armis device telemetry becomes so much more powerful. So we have a simple API based integration where we get this data in from Armis, and we use the data from Armis to inform these segmentation policies. So now using these policies, you can set, hey. Should this PLC talk to the SCADA system or not? And that decision is based on your business policy, not based on IP addresses, which means they're more informed and more easier to do. Now that's just one aspect of it. Let's kinda walk you through the three main critical use cases where we see customers using our integrations together that makes it so much more powerful. And I'll walk you through the details of each of these. So the first one is, one, they get a comprehensive clear, unified visibility into OT and IT assets. We just talked to you a little bit about how these OT assets how Armis becomes the the engine to correlate the data. Zscaler has a lot of insights into users and applications, and we can share the data with each other, making it easier for companies to view all their IT and OT assets in a single place. The second one, which was we take the insights and data from ARMS about the make model of the device and enforce more educated policies, more informed policies on what this PLC or SCADA should be allowed to access and what they shouldn't in Zscaler, in the Zero Trust branch without having any cloud based policies. And last but not the least, we also have Zscaler also has a deception product that I'll tell you a little bit about, but it's like a honeypot that sit in your factories and mimics some of your factory devices like an HMI so it can say, hey. I'm a Siemens PLC. For an attacker, they cannot tell the difference between a real Siemens PLC and a decoy. Once an attacker gets tripped up, we send this data to Armis, and Armis can then use that knowledge to alert the SOC team, can enforce and isolate the device. And that way, you have these three distinct use cases, but they're designed to implement zero trust in factory with visibility, policy enforcement, and then strong detection. But we'll obviously get into the details, and I wanna pass over to Carlos to talk us through the first one, which is, I think, the the heart of the zero trust, which is, hey, visibility. If you don't know what you don't know, then you can't enforce anything. Right? Correct. And and we actually go through different steps on this process. Right? So the first step is basically, as I mentioned, Armis creates that complete catalog of devices across all the different areas within the OT network and outside the OT network to understand the correlation between the two and the relationships, how the communication goes. So then we have then a unified view of all the devices, whether they're OT, IT, and IoT. So then we actually ingest the data that is provided by Zscaler. So this basically, we're looking at the information from the communication perspective that are actually managed by Zscaler and we correlate that information. Okay? So once we have that asset plus the inline telemetry, so we really understand, you know, device behaviors as well as context of these devices. So this is actually when it gets interesting because then we start looking at, you know, from a policy perspective as you might explain before, we start looking at anomalies. And these anomalies can actually be different type of anomalies. But the whole idea is just to trigger a specific workflow to basically integrate with other systems that allows us to, you know, orchestrate the the specific actions. In that way, then we basically improve the security posture of the device. Now this is actually all based on the risk assessment. It's not that we're just gonna go and block a device. It all depends on what the actions need to be taken to minimize the risk from an asset and production perspective. Okay? So it all depends on what the risk assessment tell us and then we implement that in their policy, and then we take the action accordingly in a specific level of the network, whether it's the firewall, the the the the switch, or or simply just to send an alert to the SIEM so that we can actually look at the owners and trigger a specific action from an owner perspective to further investigation or even isolation when necessary. Yeah. Right on. And so, you know, now we get to the heart of the heart of the challenge for most OT OT leaders, OD security leaders, which is segmentation. Right? I think literally every compliance that I have encountered, whether it's IEC sixty two four four three or or NIST two or something along the lines, they want segmentation, and it's not that people in this forum haven't tried it. It's just that when you when when we look at when we look at Purdue models and in fact, customers come and tell us that they have very large VLANs in the the factory. And and in most factories, they also have firewalls. Now firewalls are are are great if you wanna do ITOT segmentation, but they're almost not applicable when you're doing this OT to OT transaction, especially if you're drawing intra VLAN and because you have large VLAN segments, it's very hard or impossible to do any segment inside the VLAN. That's where Zscaler comes in. So let me take a step back before I talk about the before I talk about how we use Armis and how it actually works. Now fundamentally, the the approach the architecture approach we take to do segmentation is very different than anything else out there. And the way it works is that we change the net mask of the device to a slash 32, which makes that device its own network or its own segment. Zscaler Zero Trust branch then becomes the default gateway for that device. And that means all the communication for that device go through Zero Trust branch. Now, obviously, the number one question comes there is, hey. What about latency? Because latency is very important, OT. We totally understand. We don't recommend customers go segmentation for all the devices right away, especially your Purdue level zero and one because you may have critical communication between your sensors in Purdue zero and a and a PLC or at at at level one. We we ask customers to say, hey. Let's look at all your critical devices in OT. And there are lots of devices that are critical in terms of its risk, but not critical in terms of latency, and we start segmenting there first. So it's it's it's very possible to segment your critical devices in slash 32, and all the other devices can have a different level of segmentation. So you can mix and match your segmentation policies inside your OT environment. But the idea is that once Zscaler becomes the default gateway for these devices and the traffic goes through it, we're able to enforce these policies which says, hey. Should this device be able to talk to this device? And if the answer and the business policy says yes, then it's fine. Otherwise, we block it. And so in the first few weeks, when Zscaler is deployed in this factory, we simply operate in observational mode. So the first few weeks, we monitor all the traffic, and you get this traffic map that shows this device in production line one can talk to 15 devices in production line one, but it's also talking to 45 other devices in production line two, three, and four that's not required. And now with these policies, you can start blocking these communication. But that's where Armis becomes that much more valuable because now you can enforce policies not just based on IP, but based on make, model, manufacturers, and more easier to enforce because now you know what the device is, and you should you will always know what this device would be talking to the other device. So does my conveyor belt or this camera on the conveyor belt should be talking to a PLC in production line four? The answer is no. Then you block that communication, which means you've taken a whole bunch of attack surface off the table and made it harder for attackers to move laterally, which is what they wanna do. It's like they wanna use the vulnerable and open ports and protocols to execute their attack and move laterally across the surface. Now, of course, I said a lot, but, hopefully, it gave you a little bit context on the fact that the zero trust branch helps you segmentation with with a slightly different architecture than you're used to, and you're able to to do segmentation inside the VLAN with RMIS, it becomes that much more powerful. So with that, there is another use case that that, Carlos, I would love for you to share with us. Yeah. So the the idea is that, you know, there is two integrations at the moment with Zscaler. The first integration is that they're sharing information across, you know, or between Armis and Zscaler, as I mentioned before. The other integration is a decoy integration which basically we actually get the information result from the results of the endpoint test on the communications to the decoy. So then armies can actually understand that information and what we create what we call activities. And these activities are going show us basically that there was an attempt, you know, of communication or not communication, but more like attack to the decoy. And then we can actually look at, first of all, the context of this information so we know the information that it came from the decoy. And then we can trigger a policy, you know, understanding who was the source of the attack. And as I mentioned before, then this policy is actually configured as part of the the risk assessment so that we can actually trigger an action. And the action can actually be as simple as an alert, you know, announcing that there was an attack attempt to a decoy in Seatscaler so that, you know, you know, the the owner of the asset can actually take control of the situation, or we can actually completely automate the process by integrating with a firewall or integrating with a SOAR, you know, to block that asset if, you know, if permitted, if if there was something that is possible. For instance, you can if it's a a machine that it has been it's a new machine in the in the network and then it it created the attack to the decoy, Armies will get that the comp will understand that context. And then because it doesn't affect production, it's not a business impact asset from a production perspective, then we could actually then, in that case, block that asset. Okay? And that's basically that coordination is done because, well, we get the information from Zscaler. We then analyze the information, put it into context, and then we understand what the workflow needs to be implemented to protect and contain the attack. Yeah. That's awesome. And it's it's not you know, it's with with most with most customers, they want to achieve this outcome. And so here's the example of a customer that wants to and that was able to achieve better segmentation and better consolidated device visibility through our miss and Zscaler. Now this is a a a major customer, Fortune 500 company, 25,000,000,000 in revenue, 145,000 employees, 100 plus manufacturing sites. So that would say that they are the mega mega manufacturing company. And as you can imagine, one of the biggest concerns they have is, hey. I don't want any unplanned downtime. I don't want ransomware attacks. I wanna block that. And they used RMS. They used Zscaler to ensure that they are able to identify these devices on their floor, including all the unmanaged devices that may be lurking around in the factory, and then use Zscaler Zero Trust branch to enforce policies and ensure that only only devices that should be talking to another OT device are allowed and block everything else. Now they were able to achieve this outcome across all their 100 manufacturing facilities within months. More importantly, they were able to deploy these solutions without disrupting their current operations. I know this comes top of mind for many customers is that when they're introducing new security tools in the factory, they don't wanna schedule downtime. Mean, that defeats the purpose of the products. And so we were able to deploy the solution without any disruptions. And most importantly, we were able to ensure that the scales to all the factories and doesn't require you to upgrade any of your switches, doesn't require you to change any switching in infrastructure or switching configuration. So it works seamlessly and integrates seamlessly with your environment, and that makes it much, much easier, much more palatable for companies to adopt the two solutions. Carlos, you wanna add anything based on what you know about them? Yeah. So, you know and one of the things that they asked us to do was actually to, you know, collect all this information in a passive way. So, you know, they they were actually working towards Industry four point zero, and they were having a lot of issues regarding to, you know, what they had on the platform because as you can understand, you know, from a historical perspective, you know, there is a lot of legacy systems. And, you know, until today, there is not one site that, you know, we haven't found legacy systems on the on the networks. You know, myself, I was actually involved in several projects, And, you know, the first requirement was to a vendor was to support assets for or or systems, platforms as such for thirty years at the beginning of of the project. So, you know, we're actually seeing these legacy systems over and over again. The other challenge, of course, is that having a 100 plus sites, and they needed to gain the visibility across all these sites in a scalable way and also with fast deployment and, you know, free you know, from a deployment perspective, they didn't wanna have any friction. So they just wanna make sure that they can actually deploy, as as you said before, without really changing anything in their environment. So there was a lot? of information in there that, you know, we needed to correlate and then understand how the devices behave, but also how what the devices were in the network. On top of that, then there was a risk mitigation that needed to pop in, but in order for us to mitigate those risks, we needed to understand the vulnerabilities, we needed to understand any anomalous behaviors across all the assets. And this was actually all possible because, first of all, we created that visibility, we matched the vulnerabilities and risk associated to the devices, And then we start creating some strategies to basically isolate some of the devices with actually high risk in terms of communication outside the OT networks and so forth. And of course to have a visibility across all the different handler sites in only one console, you know, easy to manage, you know, create policies, create dashboards, reports, you know, to facilitate, and minimize, the the action from from a user perspective because, you know, as you can actually see, they were actually running very thin, and they needed to automate as much as possible, you know to protect the environment. Yeah. Yeah. And that's a really good point, Carlos, about the fact that the devices are were legacy. Right? So that makes it challenging for many companies to to have any security around it. It's it's it's unlikely these devices have have the ability to have any certificates or agents on them, which makes segmentation a very effective control, especially as you decide to, you know, mitigate the attack surface. You wanna isolate the device. Of course, in in in manufacturing, you would never isolate the device because they're part of critical communication. But if if if it has to come down to it, if if there are some some policies you have to implement to ensure these devices communicate with with with only devices that are required to then doing doing it with is is so much more powerful. One last thing that I I wanted to mention and and and and add is, you know, at the end of the day, seeing is believing. Today or rather, using it is believing. Seeing it is not believing anymore. With AI, it makes it hard to see and and believe. But if you found any of this intriguing, I would encourage you to use this QR code. You can do it right now. Do sign up for a workshop, and we have this workshop on on Zero Trust factories where we would demonstrate where we would give you lab access to these products, Zero Trust branch and bunch of others, So you can actually implement policies. You can see how the product works. Everyone gets their own lab access for the two hours. It's a two hour lab. You would get your own lab access. You would have the product for yourself. You could play with it. You can use it. You can you can add policies to see how it works and ultimately makes it really, really powerful. And then after using it, you would know if this is for you or not. So that's one one recommendation I have if if if you found any of this intriguing. But I do wanna take it back to Rachna and see if you have any questions. Thank you, Carlos and Humang. That was very insightful. We covered a lot today, and, you know, the need of the hour is clear. Zero trust in our factories is no longer optional. And before we get to the questions, I wanna quickly summarize. So we saw how we can eliminate the attack surface by improve by removing legacy VPNs and jump boxes. We explored how to inspect OT to OT communication to stop lateral movement before it starts. And most importantly, we learned that we can achieve 100% visibility into every device from the oldest legacy robot to the newest AI sensor without disrupting production. So once again, huge thank you to Carlos and Umang for their unique perspectives and to all of you for joining us. If you are ready to see this in action, please reach out to any of us. And now we'll get to the questions. I know there's several, so maybe we should step into that slide which shows our integration because there's a lot of questions here specifically with respect to that. Maybe I will let me take this. I think John's question wasn't fully answered. John, Sam, well, if there is an API integration, can we use that with ZIA and ZPA without branch connector, or is Branch Connector a mandatory requirement for OMIS integration? No. Not a mandatory requirement. I think there are two different integration. One is you use ZIA ZPA and send the data into RMS, the the branch connector slash zero trust branch, which is the new name for the product. That is the Armis is the source of the device data that we use to enrich and inform the policies. I mean, without Armis, Zscaler gives some default visibility into Windows and Linux devices, but it's obviously with with Armis, it becomes a lot more richer, more contextual, more informed, and more educated. Thank you, Umang. We have another question from Roberto Lopez. Under this Modelo, Zscaler is this is Zscaler a source for Armis, or will Armis be a source for Zscaler, or is bidirectional communication required? It's it's it's we wouldn't call it bidirectional. There is an integration already. Like, as I mentioned before, there's two integrations in Atomys where it allows us to bring information from Zscaler from a communication perspective and links. And then we also send information to Zscaler about about context. When we say bidirectional, it's it's a couple of different things. We send different things to Zscaler as as, you know, to to augment the context, and then we get information from Zscaler to understand behaviors. And then we correlate that information on either system according to, you know, the the functionality. In our in our case, you know, we create that augment or context augment augmented information to understand, you know, what is seen by Zscaler with our context. And then, I mean, Oman, you can actually probably talk a bit about how what you do with the with the with the data that we send you. Yeah. Yeah. Of course. I mean, I think, like I mentioned earlier, I mean, the the the data that we that we get from Armis has has a very specific purpose. Right? Most customers would use it to say, I want to you know, obviously, the data is automatically enriched. Right? So it's and be known to the people underneath, what you might see as 10.1.1.5 will now be Siemens, PLC, and whatever else information we get from Armis. So once we have this data, now you know it's your Siemens PLC. It may be sitting on the production line one, and now you could use that to inform policy. So all this is happening underneath without you having to, like, do anything with it at the moment. But, ultimately, the goal is to is to enforce policies. Now imagine doing it in firewall with with the same 10.1.1.one. It's it's it it's not that it's impossible. I think most companies realize that because they're they're using these products for for many, many years, over ten years, people don't actually remember what policies are enforced or is this IP address even valid or somebody else overwrote it or maybe we poked a hole in the firewall for something to allow access. But now you can be more educated, more informed because you can exactly see what device is allowed and what communication is blocked. And that's not the only thing. Right? You can you can do it. You can also use your subnets and IPs. You can continue using whatever old models you have, but why would you use a less informed model if you have more device data coming in? Okay. I guess we can move to the next question. Thank you, Meng. Mark Tibet has two questions. Can we use RMIS for non person account research? And for OT assets, are accounts visible? Sorry. Can can you repeat the first? the first question, miss Shanna? Yeah. The first question is, can we use ARMS for non person account research? So I'm just trying to understand what that means. You know, from from an analyst perspective, we're looking at the perspective of assets. Okay? And we can actually just get the information from an asset perspective as, you know, and this is actually depending on what data source we're looking at. I guess if we actually use a, you know, an IDP in particular, active directory or something like that, we can actually, you know, bring the information from a user perspective and and and then correlate the information, user and device, and then look at, you know, what what a specific user is is associated to a specific device. And then that's actually I'm just trying to make sense of the question. But but that's that's what it is. Right? So it's it's all about asset perspective, and depending if we're actually using Viper, and it's it's all about, sorry, finding perspective. And then we can correlate the users according to the data that we've received from certain integrations. Well, that answers Mark's question. Mark, if you're still there, please feel free to use the chat. But we'll go to the next one because we have a whole bunch of questions here. Catalin has a question. What communication protocols are supported in this setup? It depends on what you refer to COM protocols. Right? So from an analyst perspective, you know, there is a ton of protocols that we analyze passively, but also, you know, from an smart active query perspective, you know, the native protocols that we query. And we can actually send you a long list of of these protocols. You know, from an OT perspective, we support c I p s seven common, d m p three, Modbus, and and the list goes on and on and on. Okay? Now if you think about the in the the the protocols between armies and how the information is transmitted, you know, in in and out Zscaler, we use REST APIs. Okay. Thank you. Michael asks, does this model assume that there is already some rudimentary segmentation between IT and OT? Yes. But that is I don't I'm trying to understand the intent behind the question. There's always some segmentation in the factory because, you know, you have VLANs, because there are firewalls. The challenge, although, is, like I mentioned earlier, when you have very large VLANs, it if you have a device set of devices inside the VLAN, it's very hard to enforce any segmentation between devices. And where this comes in is it gives you, with the architecture that I was explaining earlier, the ability to segment devices inside the VLAN and ensures that any device in OT that is critical, if it needs to communicate with other device that has to go through a zero trust branch where you can enforce these policies. So while it assumes some rudimentary segmentation, it it all depend on how the factories wanna move forward and what kind of segmentation they wanna have. From a from an analyst perspective, we don't have to. So you know, because we monitor traffic passively, we basically, you know, understand the communications as they are, which is actually a good point because then we can actually correlate that information with expected communications or behaviors of the devices. And then we can create zones or boundaries to basically graphically provide the information of how these zones communicate within each other. So we don't have to assume it, we validate it as such and then provide that information and use that information, you know, to detect anomalous behaviors. Okay. Moving on to the next question. Matt Smith has a question. What does the roadmap look like with Zscaler's acquisition of Red Canary for SOC and integrating RMS? I did answer that quickly on the Okay. You've. I see that now. Yeah. It was hidden. Alright. Then we can move on. What res what oh, this is a good one. What best practices can you share that have led to the most successful deployments? Carlos, why don't you go first? Okay. So that's a very loaded question. And the reason why I'm saying that is because, as I mentioned before, there is a lot of legacy systems out there. And so what worked in the past for us is just to have that support from the customer perspective so it it help us understand, you know, the the networks. And when we actually have, you know, the understanding of the networks and how to improve the visibility and and create and deploy the specific sensor for a specific use case. As I mentioned before, there is a lot of different data sources that we can utilize to improve the visibility, whether it's actually a sensor, and the sensor can actually be virtual or it can actually be a container or it can actually be a an appliance. But also there are some sites that, you know, they are so legacy that they don't even use managed switches so that we have other methods of collecting information to create the visibility such as SAQ or even other methodology that we actually use that we call it broker or even you know, creating, you know, one central place to actually send routable messages across all the network to at least just to have that specific visibility. Also depends on the use cases. Is the use case visibility only or you need to understand device behaviors? So from a from a successful deployment, you know, we have experience in how to, know, attack each individual scenario and then implement the specific, know, methodology that best fits the site. Yeah. I have a slightly different answer to this question and and to add this thirty more second. You know, between Armis and Zscaler, we have a wealth of knowledge. Right? We've gone through probably dozens of these deployment, so we know how to help customers navigate. We're also making these products better, so the deployment are are are spectacularly easy now than they were even six months back. The challenge, though, is that what we can control is internal buy ins. Right? So if an executive team or set of people who are responsible for OT don't believe that that this is a challenge, then I'd say then it's hard for us to come in and do anything. And there's this simple way to think about it is, you know, think about your factory. Think about what downtime means to you. And what we have seen in the past is, generally, if between ten to twenty minute of downtime in a factory can can cause you to basically pay for this tool, then the answer is, is it worth it or not? Because that's the case with most factories. Like, within minutes, maybe an hour, maybe a couple of hours, you would pay for the tool. So if you wanna take that risk off the table and you say, hey. I don't wanna see two hours, three hours of downtime, maybe even less because you're doing something very critical, and you're running your factories twenty four seven, then it's totally worth it. And then that's the conversation they should have with the executive and see, you know, we should do something like this. Because deployment wise, we can we can make things so much easier so much easier now than than even a few months back. Okay. Thank you. We have another six minutes, so we can take a few more questions. And there's one here from How will how is the segmentation better than VLAN based? Can you differentiate based on a few parameters? And then also he has a follow-up question. Is there LLM based model for anomaly detection? This answer to the second question is yes. That's something is in the works at the moment to have more AI based policy recommendation if that's what they they mean by LLM based where we can recommend policies. So let's say if this camera because we see all the traffic, we could say, hey. This camera hasn't talked to this PLC or has never talked to the PLC, but it suddenly starts scanning it. Then we can say, hey. This is an unusual anomalous communication you should block. That's that's something we're thinking about and and actively working on. The the first question is, how is it different than VLAN based segmentation? I mean, VLAN based segmentation is, like, you you you you put a bunch of devices in a VLAN, And if you go from one VLAN to the other, you go up to the layer three device. The layer three device would send the data back. In this case, every device becomes a layer three device, which means they go through zero trust branch where we enforce policies. That's really the fundamental difference. And and I just wanna add add something. Right? So I had the bit you know, the opportunity to, you know, create a a a VLAN type, not firewall VLAN in on on OT network in the past. And as as strict as we actually had it configured, you know, because everything that we actually created was whitelisted, there is a problem with management because every time that something came new into the network, there were inevitably policy firewall policies that needed to be, you know, changed, modified, updated. And, you know, there there were a lot of times where the whole policy was actually ruined by by the network engineer trying to implement the this new device on the network. So then if you don't have the validation, you know, you make the change and you don't have the validation, and then you could actually potentially even though you have your VLAN segmentation through firewalls, you know, you have the risk that the policies they're actually not monitored and basically is open up to the rest of the VLANs. With this particular scenario, so you're always monitoring, you're always validating and you're actually just doing the segmentation in a way that it doesn't depend on a network engineer making changes on the configuration, opening up the network. So that's what my experience was. Okay. Thank you. Andre Watts has a question. Does this model include protection of all SCADA models or critical infrastructure? Yes. I I the answer is yes, and I answered that also. But then we have one more question, Mike Reeby. Is the solution licensed off of assets that are proxied by the branch device or throughput requirements? Did you also reply to. that? Yes. You are you are way ahead of us, Wonderful. I actually. have an, AI agent that's answering these questions. I'm just getting this. I almost you. Okay. We have two minutes left, and I think this might be a good comments from Michael's Michael was the first one to to reply to all of our messages here. Thank you. Thank I I really love this audience. Thank you for being so engaging, so many great questions. I will reach out with a follow-up email for all attendees, and this webinar will be posted on armist.com. Feel free to add us on LinkedIn. I'm just offering this for Mung and Carlos as well. We're more than happy to connect. Questions are welcome offline, and have a great day, everybody. Thank you, everyone. Thanks, Thank. you. Have a good one.