AI for OT Cybersecurity: Real-World Strategies to Protect Critical Infrastructure

Intro and Vivek's career arc

Aaron Crow (00:01): Hello. Thank you for joining me for another episode of the PrOTect IT All podcast. Today I've got my very good friend Vivek with me. I talk about this all the time on these shows. A lot of times I'm talking to folks that I don't really know that well. OT is such a small niche anyways, so there's not that many of us technically, but there are some of us that see each other at all the conferences. We smoke cigars or whatever the thing is. And, fellow Texan, so he lives right down the street. Actually went to college here where I live in Austin. So Vivek, thank you for joining me today, brother. We've known each other for a while. I think this is the first time you've been on the podcast, which is stupid. But thank you for taking time and joining me today.

Vivek Ponnada (00:42): Of course, happy to be here. Really excited to be finally on the podcast.

Aaron Crow (00:47): Exactly. So why don't you tell us who you are, a little bit about your background and what you're doing now.

Vivek Ponnada (00:53): Awesome. Hey, Vivek Ponnada, based in Houston. And like Aaron said, I went to UT for my MBA. Back in the day, I was a controls engineer, started off in the OT industry. I was a gas turbine controls engineer. So I traveled the world, commissioned gas turbines and power plants and oil and gas, LNG and refineries, mostly for compression, as you can imagine. That was my world until I said, enough of this worldwide travel. I went to business school, got my MBA, and then GE hired me as a sales guy to Houston and I did gas turbine controls and cybersecurity upgrades as a go-to-market person for them for about seven or eight years. Then I went to the services side of GE overall, been in the OT cybersecurity space for the past 12 or 13 years. And I was at Nozomi Networks for three years prior to joining Frenos, where I currently lead the go-to-market again. We're an AI-based tool for the OT security space. So that's the background.

Credibility on both sides of OT and IT

Aaron Crow (01:53): It's funny that we talk about all the changes and your trajectory and how we've, you know, a similar background, different but similar in how I got into this space. I didn't just start out in OT. Folks ask me, how do I get into OT cybersecurity? I'm like, well, usually it's not a direct correlation. You're not usually getting a job first out in, like, you're finding a way through a side door or you're doing a lateral move or something like that. It's not just something you're thrust upon. Hopefully that changes with training and schools and things like that, because obviously we need more folks. But the experience that you had from the operations side is crucial to you being successful and being validated in the current space, because as we know, people don't trust us in this space. OT folks don't trust us. What do you know about this? You're just a sales guy. When you can talk about your experience and where you came from, they're like, oh, okay, you understand what I'm talking about then.

Vivek Ponnada (02:56): That's a big part of our day job, I think. Establishing credibility for an OT security team is crucial because they need to talk to the actual industrial controls people. They need to talk to the IT people, talk to leadership, and every one of them will question why. They have to do something that they didn't do for a few decades. So establishing credibility is important. Now granted, if you come from the industrial side, of course, establishing and validating your status there is easier. But it gets difficult on the IT side. And vice versa, if you come from IT, it's a lot easier to talk to your fellow IT people, but it's just as difficult to talk to the ICS people.

The two camps in OT security

Aaron Crow (03:35): Exactly. And we talk about this all the time. We talked a little bit before we started recording. OT is so far behind the eight ball from IT. We have old devices and maybe our security policy isn't the same or at the level that we would want it to across the board. We have legacy equipment, et cetera. And so much of the time, and I talk so much about this here, I just spoke at DEF CON. I speak, talk about this all the time. The fundamentals, the foundation of things that most people need to do in these OT worlds, it's basic blocking and tackling. It's firewalls, it's asset management and inventories and secure remote access, those basic things that they need to do. But on the other side of the coin, we've got all this cutting-edge stuff that's getting thrust upon us, and most specifically, especially around OT, is vulnerabilities and this Mythos thing that has come out. So we've got two camps. Hey, I haven't done anything for OT. I need a firewall. And, I've been doing this stuff for 10 years and now I want to get more advanced. And both people are asking around these things and they're concerned about it. But this is where companies like you guys, that really were generated and started from an AI lens in this space, which is so vastly different than the rest of the folks out there. You know, I was the CTO of Industrial Defender. Like we were one of the first OT products in the space. They'd been around for more than a decade, which is a long time in OT because we hadn't even called it OT for that long. So how is that going and what are you seeing as the struggles and the wins and all that kind of stuff in that AI cutting-edge side of the conversation?

AI in OT and the cloud-adoption parallel

Vivek Ponnada (05:23): Yeah, I think you're spot on. So we have the vast majority of the industrial base still dealing with lack of basics. In fact, it's funny, even today, some people still don't agree on what those basics are. So we have this constant debate, something on LinkedIn, something on in-person events, but what you would consider as basics, getting your firewalls in place, IT and OT separated, and segmentation, and like you said, secure remote access, they're not commonplace. And if you haven't invested in them forever, it's hard to get justification from a business side, get the investment, get to scale this across the company. Because even people that have invested in some of the tooling that is quite common and established right now in OT security, they've only done that for partial, right? Some of their sites, some of their locations, not all of them. And then on the other hand, we have this, you know, AI or what is currently called AI, the evolution of machine learning to the current generative AI, to local models. All this is kind of a pathway that is similar to what happened in the past. So think about cloud. For a long time, OT meant completely disconnected. There was no connection to even within the network. But then IT was dealing with completely transitioning off of in the data centers to the cloud. So in the beginning, OT was like, whoo, there's no way we'll connect to the cloud. So now after years of IT using cloud for many, many things, OT has also started using the cloud for many things. So maybe as a management layer, maybe in a big supervision level, but at the same time also using cloud for backups and other kind of analytics, if you will. So AI, I think, is very similar where, yes, we have a lot of missing basics, but because IT has already evolved much further into using AI for many things, OT is also seeing, hey, what's possible out there? Can we replicate some of that while also adjusting to our nuances? So you can't use the cloud just like what IT does. Similarly, you can't use AI just like what IT does. But there are applications and there are some additional advantages in OT because we have huge data sets. In fact, compared to any other data sets in the world, OT data sets are much longer and of high quality. Training the models is going to be a lot easier.

Vivek Ponnada (07:48): As long as your use case is established and you know exactly what you want to achieve, training the models and tuning the models is a lot easier. So I think while these things are not going to happen at the same company, some companies are so basic that they've never even touched asset inventory. They've never segmented their networks. Well, they don't have the right kind of visibility, that kind of data sets to do anything. However, if someone is at least somewhat interested in them, maybe they've done a few sites where they have sufficient asset inventory, have sufficient asset management capabilities, and they're trying to understand what they could do next. Or they talk to their process people and they're like, okay, we can maybe improve our process, reliability, quality, operations, safety, or at the same time, security. Maybe there are so many use cases where you can use AI. So I think these things will always be a laggard compared to what IT does. There's no question about it. But we have some unique use cases and also unique advantages, especially given the resource constraint. We don't have, like you said before, we don't have a lot of people in OT security. So what if AI is the way we can reduce the number of people that we need for any given job? So that's my thought.

Standardized stacks, digital twins, and safe testing

Aaron Crow (08:58): Well, I mean, the sky's the limit for it. And to your point, I always go back to Sun Tzu, Art of War, use my strengths as weaknesses and my weaknesses as strengths. In OT, our environments are usually fairly static. We know that, you know, even across multiple sites, I've got an Emerson site, I've got a Foxboro site, I've got a Honeywell site, I've got a Toshiba site, GE Mark VI, whatever those things are. Yes, there's differences. They're not all identical, but an Emerson site looks like an Emerson site. So all of my Emerson sites are very similar. I don't have a lot of tablets being plugged in and all these different things. So in theory, I could line up and map out a specific environment and it's going to give me 70, 80 percent of the coverage and understanding of what an Emerson site looks like across my fleet. Granted, there's third-party controls and there's all these other things that connect to it. But still, I'm going to have a pretty good understanding, which you can't walk into an IT site and say, hey, I pretty much assume you've got this, this, and this and know those environments. So because my tech stack is very kind of standardized, with, not counting the outliers, that can really help me in AI tools mapping and going through those data sets, like you talked about, and going through, looking at the vulnerabilities. Hey, we know we have this particular Siemens S7 PLC at all of our sites. We know we do. We've got them everywhere. Or we've got this control processor for Emerson, or whatever these things are. So then we can go through and start using tools like AI and digital twins and things like that to really start game-playing, hey, what are the attack vectors in our spaces? We know we have these things. We know that we're not updating them or patching them or changing them. That's where it really gets exciting, especially for those advanced places that maybe they've got a lab, maybe they've got some additional equipment that they could set up and run things through. Because we know good and well there's a handful of people, but for the most part, we're not going to go actually do a full red team pen-test attack on a live power plant or manufacturing facility while it's running. It's just too dangerous. The risk outweighs the reward.

Aaron Crow (11:19): AI gets us to a place where we don't have to do that and we get a lot of the benefits without having to actually hit and attack a live system that has the potential to break things.

Vivek Ponnada (11:29): That's spot on. We have this huge focus on safety for a reason. For 30, 40, 50 years, we've developed safety standards and started using more and more safe operations because we don't want people to get hurt. We don't want equipment to be damaged. And like you were saying, we're lucky that we have a scientific process, we have a deterministic network and a fairly low variability in our tech stack. So that's a beautiful thing because you can detect anomalies a lot easier, which is why anomaly detection has been fairly commonplace and easy to implement and tune in the OT stack. Now, pen testing, as you can imagine, in a traditional IT sense, it can be done safely in certain instances, like if a power plant is down for an outage. And, yeah, sure, there's no impact to the operation. So you can run some vulnerability assessment. You can do some maybe active pen testing in the network. But when something is operational, this is what a lot of IT people don't understand. You and I have to deal with this all the time. In fact, I recently asked a person, in fact, I ask this question often, but I recently asked this person if they've ever heard of a work permit. And they thought I was talking about visas and stuff. No, I said, okay, in a power plant or an oil and gas installation, before you do anything, you have to take your work permit. I mentioned the cold work permit and the hot work permit, and I explained the differences, and I said, okay, this is what they have to deal with. If you want to do a logic change on a controller, you can't just go ahead and do it. It's not just your traditional change management in IT. You have to work with the operations team to isolate things, to make things safe before you can actually operate or change the logic. The actual work might be a 10-second problem, but it might take three days to get the work permit because everything else has to be accounted for. So for someone to just say, hey, this IT tool can work just as easily, I can run this pen test, it's going to be safe, they just don't understand the breadth of what the other side needs to assess before the permit is available for the work. So that's why I think anything that can fairly model what you have and then do whatever simulation or whatever pen testing in the simulation is going to be a lot more palatable. Because then, even if you have to do an actual pen test later on on the site, you've actually prepared yourself with all the possibilities. Good and bad, to say, here's what, because that's what you need to provide to that operations manager. To say, hey, this is what I'm going to do. These are the possibilities. This is how things could go wrong. If this goes wrong, this is my backup plan. You have to offer all of this before you can get the permit to do anything. And that's the challenge. So we certainly can, and to your point before, if you can do this safely and you can build credibility and provide this as an independent option, then you actually get to do something real. Even if you have to update a PLC because that vulnerability is so severe that you could be at risk. Or if the workstation needs to be rebooted at Sunday at 4 a.m. in the morning, you could get that permit to do it because you've demonstrated the risk as an independent verification. And then let somebody else make the decision for their operational safety to say, yep, this is good enough for me, go ahead and do it.

"Guilty until proven innocent" in the control room

Aaron Crow (14:46): Dude, I remember it was probably 2012 and we had an outside consultant come in and IT decided they wanted to extend the red team or pen test into the OT space, which obviously we weren't going to let the vendor do that work. So they sent me because I had the trust and I understood the OT side of the conversation. I remember we were sitting in a power plant and they were getting ready to have an, like it was a ramp up, ramp down. So they were ramping down for the afternoon, or actually after the morning, so mid-shift in the morning, it was going to be offline so we could actually go in and do the work. We're sitting in the break room doing a pre-job brief, the work plan. So we're doing the pre-job brief, talking about the things that we're going to do. We'd just gone through and gotten everybody's sign off. Yeah, we're going to start at 10 a.m. after we get approval, blah, blah. We'll give you the go ahead, this is from the plant. So it's like 8:30, so we've got like an hour and a half before it's going to happen. We're sitting in the break room eating donuts. We don't even have our laptops out. We're just sitting in the break room, which is right behind the engineering workstations in the I&C control shop. And all of a sudden the plant trips.

Aaron Crow (16:02): Running plant, it trips. What's the first thing they do? They run into us and say, what did you do? We're like, we haven't done anything. We don't have our laptops out, they're sitting over there. Like we haven't touched it. They had to prove and understand because obviously in that environment, they want to understand what happened, what caused the outage, what caused the trip before they start it back up. Can we start it back up? Is it okay to start it back up? Because we need to get back online for this next hour and a half if we can. Absolutely, but they can't do that unless they know they can do it safely, that they're not going to damage equipment, et cetera. And they needed to verify and prove that it wasn't something that we had done. Now granted, obviously it wasn't because we were sitting in the break room. But still their first thing is, what has changed, what is new that is not normally here? Those guys are going to be doing things that we talked about. Did they do anything already? Of course we hadn't, but that was the first hurdle that we had to get over. We're guilty until proven innocent.

Vivek Ponnada (17:06): That's the life of ICS engineers in the first place, and then my extension to OT security people. And definitely, if even an IT person walks in without having some validation or that established credibility, they will be the first person to be pointed at. Because they don't trust them just yet. And in the past, we've done this. That's one of the problems that caused this in the first place. Like if an OT device, a laptop, connects to a PLC and it needs to be in a certain version of Windows or a certain version of firmware, and IT unknowingly updates the OS version and now you cannot talk to the PLC. Well, there you go. You've caused me four extra hours of heartburn, so next time don't touch my stuff. And, you know, we're like elephants in that case. We rarely ever forget. 20 years ago, this thing happened. And to your point, this 2012 story, that plant, that site is never going to forget it. Even now, if an IT person walks in and the plant trips, they're going to repeat the story to say, last time, you know, we had this problem. You guys didn't do it at the time, but you might have right now. So they still are. It's always been that way, that you always are the outsider. So having to establish that you're there for helping them, not essentially working against them.

From physical labs to digital twins

Aaron Crow (18:25): Well, and that is one of the reasons why I started building, again long, long time ago in this process. I built one when I was an asset owner. I built it for multiple large power utilities. And what I'm talking about is a lab. And at that time, we had to build physical labs. So I had to get an Emerson control system and a GE turbo control system and a Toshiba turbo control system. I had to recreate all of the hardware and the network layer and everything in a physical environment. And I did the same thing for a transmission substation. So had all the blue SEL equipment and the Eaton stuff and did the same thing for the distribution environment and the same thing for the gas environment. So we had a representation, not of every device in the field, but the most common, the big picture thing. So we could get that 80/20, we got 80 percent of coverage by doing those things. And the reason we did those was multiple reasons. A, it was to prove to the operations folks, hey, we've done this, bring your people, see that we have the same equipment, the same hardware directly from Emerson. Went through an FAT, like, hold on yards, it was a complete control system. And we could run these tests in a live environment that had no implications of a power plant because it wasn't actually connected to anything. It was just the controllers and the HMIs and the operator workstations and the networking layer and the security, like all of those things. So we could test it in a safe space so that we knew that we weren't updating the laptop so it couldn't connect to the HMI or the PLC. We were able to test it in that way. And it helped us immensely with having that conversation with those folks. Because their first question is, how do you know it's not going to break my stuff? And we were like, well, here's how. And we would show them. Hey, we've tested on this way. And that's where I see what you guys are doing now with digital twins and things. Because again, back then I had to physically build those things, because I couldn't have a virtual version because it just was too different. I wasn't proving the things that would make them feel comfortable. But now AI and the way that you guys can do things, that attack path, all the things that we can do now make it be able to go faster, be able to do more, more quickly, without having to physically reset things. So talk a little bit about some of those use cases and what you're seeing and what you're excited about with that side of the bleeding edge of things, especially for OT.

Vivek Ponnada (20:52): Yeah, no, I think you're spot on. So back when I was at GE, I was on the other side of you. We were supplying those training controllers, if you will, or lab controllers, if you will. And this gets very expensive because especially in a site where you have the Emerson, the GEs, the other PLCs, to recreate the whole thing as a true replica costs a lot of money, takes a lot of time and resources and maintenance. Because if one thing changes, like the upgrades or whatever, every year you have to keep up with it. Now for some true validation, like if you want to play a patch and make sure that the patch actually has no negative implications, you have to have a physical replica. No doubt. But for a lot of other use cases, especially for security use cases, you mentioned attack path. So can you go from this network to the other network based on firewall rules? Or can you use the service because you know that the service is enabled or this port is open? For a lot of those things, you don't actually need a physical replica anymore. As long as you can model those assets or those networks in your digital twin environment, you don't necessarily have to have a physical replica. That cuts down on initial investment, that cuts down on the maintenance, that cuts down on the constant babysitting of this replica environment, because that's not your day job. Your day job is to protect the real assets. You want the digital twin or the replica model to be as representative as possible, close enough for a security standpoint. In our case, what we do is we just use the information that's already available in the site. For example, if they have an asset inventory tool that can export to a CSV or a JSON, or maybe they have an API connection, we can connect with that. Similarly, the firewall and segmentation information that they already have, as long as you can provide a JSON file or a CSV file, we can import it. So that way, the amount of time it takes to build this replica environment is next to nothing. We're just talking about 10 to 15 minutes. Build this and keep up with it as well. If you connect with the API, then you're not necessarily having to redo this every week or every month. As soon as things change in the environment, your asset inventory tool is updating it, and then we can connect with it to get that information.

Path validation and the perception-versus-reality gap

Vivek Ponnada (23:33): Now, the key use cases we found were two of them. We have multiple use cases. A lot of people use the tool for different purposes, but the main ones were path validation, because a lot of times people just assume that because they have this IT, OT, separated via DMZ, they're like, that's it. This is our perimeter. This is our protection. There's no other connection. There's no other way you can get to our OT assets. That might be true in a very limited case, but in most cases, there are many paths that they did not discover or they didn't remember the last time somebody connected these two networks, or maybe there was an exception to the firewall, or a vendor connected via third party, or this IoT device is connecting them directly to the cloud. All these external connections, and you've done so many of the assessments yourself, so you know this firsthand. And back in the day when I was doing it, for every time a customer said they have no connections, usually you'll find three. And if they said they have one connection, it's like six or more. So it's not even a, you you forgot this one time. There's usually multiple connections, multiple pathways. So that's the number one use case. A lot of people are using this for path validation to make sure what they think is true is the perception versus reality. Their perception is that they're not connected any other way, but now they can see how many ways they're connected and what is the biggest risk.

Vulnerability prioritization at scale

Vivek Ponnada (24:27): The second is vulnerability prioritization, because in OT, we've had the patching cycle, we can't really patch things the way IT does. We're constantly behind the curve. Obviously, even in really critical installations, most of these workstations go unpatched for years, if not more. When you suddenly have to deal with a patch or you have to update something, you have tens of thousands of them to start with. How do you prioritize where you should start? If you have 50 sites and each site has a thousand vulnerabilities, now you have 50,000 of them to think about, and you have no time or resources to do all of that. The compensating controls that you have in place, whether it's whitelisting or segmentation or some of the ways that you've been currently mitigating the risk, oftentimes that might be enough to not worry about the vulnerability, because that vulnerability might not be easily exposed. Meaning that asset is deep into your network. You have other isolation or segmentation that's protecting you from anyone reaching into that network. Well, in that case, that is not the vulnerability you'll be fixing first. There might be another vulnerability very early on, meaning that's the one that's causing the exposure. That's the one that is a pivot point for people to go from one network to another network. So that vulnerability should be prioritized. But right now, the existing tool set in the OT space doesn't provide you that contextual analysis. You have to do it manually. Again, you've done this many times yourself. If you sit with a network architect and industrial controls engineer, look at their architecture diagrams, you can map out multiple pathways. You can say, okay, this particular device is more critical. By the way, you have a Windows XP machine here, so this other compensating control is probably not valid enough. You might need to add one more. You can do all this for one network or even network manually, but how do you do that at scale? When you have, again, these 50 sites and you have thousands and thousands of networks, it is not that easy to do it manually anymore. And it's just impossible to keep up with it, which is why I think that vulnerability prioritization is another key use case where you can say, of these 50,000 vulnerabilities, these five are most relevant for me because I don't have any other compensating control and I need to address this right away. Again, it's all about risk perception and risk tolerance. At the end of the day, because they can do all 50,000, they have to prioritize their resources, their next dollar on whatever they can, and we're able to help them prioritize those.

Patching risk: when the cure is worse than the disease

Aaron Crow (27:12): And that is huge. The other side of this patching and vulnerability thing is, once you get to a certain point, like I've got a system that hasn't been updated in two years, how many patches are available that are needed for that one? Let's say it's a Windows machine. How many patches are available? I'm old enough to remember when patching a system could mean a blue screen of death. So we're talking, in an OT environment, that may have 50 to 100 patches. How many reboot cycles does it take? In every one of those, I'm crossing my fingers that it doesn't crash or it doesn't break something. Like, it updates something, now a driver that is broken, that used to work, and now it doesn't. So now it can't communicate to the control processor, which is its whole purpose for existing. So yeah, now it's secure, but it doesn't do the job that it's supposed to do. So now I've got to roll it back from a backup, and get it back to a known good state, which is before the patches were applied. And now I'm not touching it again, because the operations team is like, yeah, good luck. You had one shot and it broke. Get out of my space now, because we're sticking with it like this, because we know this works. And that's where we're at with an OT world. Like, we have to be able to quantify and understand that risk and what is the real risk. Because the risk isn't just that China is going to potentially attack us or a bad actor is going to attack us or whatever. The real risk is, is this machine going to take down my network? A patch can be just as dangerous and probably more dangerous than a bad actor, because that's the thing more likely that has taken down environments than not patching. How many times has Russia attacked my power plant? Probably zero. How many times has a patch taken down a system? More than zero.

Vivek Ponnada (28:57): Spot on, man, spot on. The risk of a patch doing something positive versus not doing something positive, we've all been through this calculation and the time it takes. You're talking about one workstation needing two years' worth of patches. You've probably accounted for four to five hours of multiple patch application, multiple reboots, and with the risk of not actually talking to the controller. And we have dozens of these workstations per power plant. So you're always crossing your fingers that something doesn't break across all those in one site. So it's not an easy thing to keep up with. So that's why we were always dependent on compensating controls. And that's, going back to one of our early thoughts about Mythos. Mythos and many other AI models will obviously be able to find more vulnerabilities, which is why I would consider that the focus on perimeter protection only is not going to help anymore, because they will find a way.

Project Mythos and assuming the attacker is already in

Vivek Ponnada (29:56): Historically, we've always seen the Mandiant folks say the theory of 99, IT-to-OT crossover is how most attacks happen. We've seen that happen. Ransomware on IT maybe crosses over to OT, or some other insider threat or some other malicious USB or something like that can happen within the OT environment as well. But those were the more common ones back in the day. But now with everyone getting access to all these more advanced models, I think getting across the IT-OT DMZ, that's going to be a lot easier because they let the models run. So the perimeter focus is not going to save us anymore. But once you're inside, our approach doesn't need to change. That's another advantage that we have in OT. Our approach needs to be what can happen regardless of how people got in. What are the connections? What are the pathways? What is really exposed? What vulnerability can be exploited once people are in the environment? What can they get to? If you have a counter for that, then it really doesn't matter how the attacker got in the first place. So that is a huge advantage that we have in OT, in that we always accounted for compensating controls. We've always accounted for not being able to patch, which is a very different approach from IT. In the IT space, if it's exposed, if it's connected, let's patch it. Because that cycle is constant. My phone, it's just impossible to keep up with those app updates. They update everything every day. Literally, there is no currently supported phone out there that's not updating every day. Now, that is how they're dealing with most vulnerabilities. They're not dealing with compensating controls like we do in the OT space. We have that advantage. We're fundamentally designed differently because we can't be dealing with patches in the first place.

Defenders should know their networks better than attackers

Vivek Ponnada (31:47): However, the big gap I see is that people have just assumed what the network would be as opposed to validating it. People have not actually invested the time and effort to say, here's how my network should look like. This is how the network should behave. In fact, yesterday Rob Lee was on a webinar saying we should be able to defend it because we built this network. We should know. Like we were talking about before, we know the process. A power plant, it's a Brayton cycle. The thermodynamic cycle is not going to change. You can't get 2,000 megawatts off of a gas turbine. It's just not going to happen. If someone randomly punches numbers and the megawatt meter reads something strange, or even, you know, they're doing something so crazy and unique from a level-zero sensor and then pushing electrical signals to show you 2,000 megawatts, that's not going to happen. There's no possible way that a power plant that was built for 1,000 megawatts can produce 2,000 megawatts. So we know the thermodynamic cycle and the limitations. Then we also know what tech stack we have. To your point about Emerson controller and GE controllers, we know exactly what millisecond the scan time of the PLC is. We know exactly how many times it updates and how many times it refreshes, and how many times it cannot refresh. So if you're seeing a very high-frequency change in data updates, you know for a fact that's not possible. Similarly, if you know that this network is segmented a certain way and it only talks this particular OT protocol to this other network, you can model that to say, now my connection paths are between A to B to C. A cannot talk to C directly. But if I'm seeing that, okay, there's a problem. Or if A and C are connected by mistake via an IoT device or via some other network path, because there are many other firewalls or VLANs or any other network segmentation products in between, and you're able to validate to say, I have a counter for these hops. I have a counter for these transitions, and I know this cannot happen, you're in a good spot. And you can do this all with automation. And we've been a huge automation user. That's the whole point of automation systems in the first place. This is why we moved from the 3 to 15 PSI to electrical signals to where we are currently with all the digital technology. So we are like cutting edge in many ways that people just don't know. And so I think our AI use cases are so much more reasonable and realistic. It is not like, hey, ChatGPT, write me a story about the moon. Our use cases are actually fun. We're protecting the power plant, we're protecting the oil and gas locations. So we have actually a lot more reason. When you ask for that $5,000 GPU, you're not asking to write stories, you're actually protecting the power plant. So this is what is exciting, in my opinion.

Bypassed firewalls and dual-homed workstations

Aaron Crow (34:45): That's right. It's so funny. And the other piece to this, right? So I've walked into these places and to your point early on, they think they have no remote access. They think they have no connection. They think everything's going through. I literally walked into a power plant and they had an OT firewall. And when I looked at the rule set and I looked at the things and I started mapping the network, nothing was actually routing through it. It was just sitting on the corner and it was connected to IT, but no OT assets were actually, no traffic from OT was actually going through that firewall. It was going around it. And it was because they never actually swung it over when they implemented it. So it was just sitting there doing nothing. And that's a prime use case. But the other side of the coin is how many times have I seen these spaces where, you know, today it's great. I run the assessment, everything looks perfect. And then tomorrow they're troubleshooting something, and they bypass something. They plug this HMI, they dual home it. It's not working. I need to connect to that network over there. I don't know how to configure that because it's not working. I'll just plug, it's got an extra network connection. I'll just dual home it, and I'll plug this Windows machine that's plugged into the plant control network. I'll plug it into this third-party control network. Well, now you've just bypassed the firewall. You've turned that Windows machine, which does not handle routing very well whatsoever, you basically bridge that network. And we see that all the time. Walking through a manufacturing facility with the operations guy. And he's like, yeah, this system, we have problems. We have to have the vendor kind of remote into it. I'm like, yeah, so how do you do that? And he pulls out like a 3G or a cell phone modem. And it's a USB. He goes, well, I just plug this directly in and then it links up and then they connect to it. So he just bypassed everything. He went straight to the internet with his OT device that is not patched. And he just plugged it directly in the Wild Wild West, and that's how they gain access. These things happen all the time and we, as OT people, can't keep on top of it. Not an operations guy, the guy that's running the plant. They're doing the best that they can, but as we know, things change. Things don't change that often as far as, I'm not installing patches, I'm not installing new applications and that kind of thing, but I'm constantly making changes to improve the process in a power plant or a manufacturing facility, et cetera. So I'm constantly enhancing, I'm adding switches and valves or whatever the thing may be. So all of those changes can have downward impacts. So when I go back to a plant after six months, things are different. Not the same amount of percentage-wise that are different in an IT world, but there's still differences. Compound that over 20 years, which is when the as-built documentation was put in 20 years ago when the plant was built, how much has changed since then? So this is another way to keep on top of this, which is why we have tools and AI just really helps us. And the use cases you talked about really help us to understand and to get a better grasp on, I know I'm not going to patch all my systems. So how else can I protect these things? How else can I know, hey, that Windows machine is actually bridging that network? Let's kill that. And then this whole thing gets a lot better. And then let's build a firewall rule so that that Windows machine needs to talk to that device on third-party control, but it doesn't need to go directly. It needs to go through the firewall so we can restrict access and only allow the traffic that's supposed to be there, not other things that can then use that as a pivot point to get into my environment.

Culture, charging stations, and designing out the workaround

Vivek Ponnada (38:20): I mean, that's spot on. I think we have two distinct problems currently in the OT security space. One that's got a lot of history. One is the lack of OT security as a culture. We can't fix it overnight. If an operator is not supposed to plug in their phone into the workstation to charge their phone, that's a cultural thing. You have to train people over time and you have to make sure that they don't do it. On the other hand, we can fix things. If you put a charging station next to their workstation where they can officially charge their phone, you have solved a problem. Similarly, if you use AI or modern technology to help them really avoid those opportunities to make mistakes in the first place. To your point, if they need connectivity to the vendor and if there's an easier way that is established already with clear rules to say, if you need vendor access, you push this button and the vendor gets their access, their login, that was already pre-configured, that they can log in and do it. And after the session, that is killed and you don't have to worry about it. Life is good. We haven't designed these systems with that security framework, if you will. We've designed things with safety in mind. That's why you'll never see an operator walk out into the plant without putting their safety boots on. That's a culture and also resource availability. There's no way they will walk out without a hard hat on, without their goggles on, without the ear protection on, because on top of training for many, many decades, we've given them all the resources. It's right there. There's no way they're not going to put on their hard hat. In fact, they might not even walk out if their hard hat is missing. However, in OT security, that's not the case. They will find whatever it takes to connect to the vendor or connect to a network, because they need to get the plant going, because that plant operation is number one priority. That's how collectively they make money, we make money, we all exist. Both as critical infrastructure operators and of course, as business people. So I think in the OT security space, one, we didn't get a lot of funding for a long time because we were not primary for the business to run. But now I think in 2026, we can't stand behind it anymore. We have to say, hey, there's a safe and secure way of doing it, and there's an unsafe and insecure way of doing it. So let's do it the secure way. Now, again, going back to our initial AI discussions, we just don't have that many people. Like the one common theme is, who is that person that can stand up at a site and say, we're not doing this securely? Well, there's no one. Because the ICS person is not trained in security, the IT security person is not an OT security person. They don't understand the OT implications of security. So that's why I think we need to use a lot more automation. In this case, automation includes AI, it includes other compute, maybe even cloud, because we can fundamentally improve the infrastructure in place for all the basics. We talked about secure remote access, we talked about segmentation. All this can be done at scale, and we have all the products in the world. We have all the resources in the world that can do it at scale, not at each site. So the limited number of resources that we have available as technical experts can implement these things and make it run almost flawlessly or smoothly for a longer period, no different from any other computer at the time. It's not like these OT sites are not maintaining their PLCs or not maintaining their workstations for other functional upgrades. They do upgrade Allen-Bradley PLCs every year. They do change the firmware on their IO modules every couple of years or whenever they have to. So adding one more thing on a reasonable timeframe every year, every two years, is not a problem. It's just that they need a lot more things to be designed better in the first place. And I think that's why AI becomes so critical, because if you haven't done anything in a long, long time, we need some more automation to get us there faster.

Trust but verify, including your vendors

Aaron Crow (42:28): Well, and something that just hit me as you're saying this, it's the other side of that coin. Because we don't have a lot of OT folks, a lot of resources that are focused on these things, a lot of the times these sites are depending upon vendors. And that may be the OEMs: Emerson, Schneider, GE, Rockwell, whomever. Also consultants like myself that come in and help them as well. And a lot of times the sites obviously have built that trust, that as we know, they very much trust their vendors, which they should, but also they shouldn't. I can say multiple stories around how the vendors made mistakes and how that impacted them. But this is another use case for the trust-but-verify. This is the other side of the coin. Because we don't have all these OT folks, and against Sun Tzu, Art of War, because I don't have all this availability, Aaron is not configuring everything in the site. I've got multiple people doing that. How do I validate that? Hey, I know it was good before you left because we use this tool and we validated the attack path and how things are getting in and out, et cetera. But you just came in during an outage and made a change. How do we confirm that nothing changed on those things? If I have to do that manually, and Aaron has to go to every site and manually do a pen test or validation of network path and all that kind of stuff, that's a lot of work that I have to do every time it's done, which means it's not going to get done very frequently. So it's a once-a-year, once-every-other-year type of thing. And that's not good, because I want to detect that as soon as it is changed. Because every day that it's like, you know, I forgot to lock my door, I want to realize that I forgot to lock my door or I left my door wide open before the dogs get out. If I just leave it wide open for a day, a week, a month, a year, how many things have gotten in that I'm not aware of? And I want to detect those things as soon as possible. This is where the technology side and the tool side of things and AI is exciting for me, because those are all things, I know we have a resource limitation in these spaces. I know we have a skill gap in these spaces. How can we use tools to help the operators, to help the management, the plant owners, et cetera, to bridge that gap?

Aaron Crow (44:47): Yes, you have to trust your vendors, but you also need to validate the things that they say they did. It's not that they're going to maliciously do things, but they made a mistake. They're human, mistakes happen. So if they made a mistake and accidentally left an any-any rule on the firewall and you didn't know about it, or they dual-homed this workstation because they were doing a temporary workaround and forgot to undo it. These are all things that you won't know, unfortunately, many times until it's too late.

Vivek Ponnada (45:13): Yeah, that is exactly right. So vendors could be responsible for a few things, but at the end of the day, the asset owner is accountable. They are the owner of the end result. They have to then not only validate, but also ensure that the plant is operating in the way they expect it to operate. So there's no getting around it. You can't completely depend on the vendor to configure your network or make sure that your policies are being implemented correctly. So you have no way but to somehow try to do it yourself. And yeah, definitely, I think scalability and the range is where AI can really help. It is surprising though, a lot of people are still underestimating what AI can do for themselves because they think it's somewhere out there in terms of technology. This is something that I think you and I can definitely attest to: you've got to try. This is one of those use cases where, man, just give it a shot. Maybe create a lab environment. And now you don't have to invest in all these new controllers and workstations like in the past. You can come up with your own local model. You can use completely isolated local models, feed data that you already own and the operation that you already are aware of. What the outcome should be, like creating guardrails and tuning the AI tools is a lot easier for you in the OT environment because you know what the limitations are, you know what it can or cannot do. In the real world, replicating that in the AI world is a lot easier. And it's the only way for us to be able to do anything, I think, going forward. Because the attackers are increasing by the day. Literally, the ISA way of thinking, the nation-state attackers versus ransomware or APTs versus the script kiddies, I think those differences are dying by the second, because now even the script kiddies have access to these advanced models, so they can behave more like APTs or they can behave more like nation-state. It'll be very hard in the near future to differentiate between which attack came from a more sophisticated actor versus which is not, because almost all of them will have access to the same AI tools and technology. So it's just the persistence and who wants to do what, that'll be the difference, versus who the individual actor is. If that is the case, defenders also need to step up the game. Because now, instead of separating yourself to four different types or different levels of securing yourself, you're securing yourself against everybody at the same time. Because the scale and the efficiency on the offense side has increased so much, defense needs to scale up just as much. If not, what will happen is we'll end up being caught on the wrong side. The worst things can happen in our world. Like if an operation is shut down and you can't come back up for a week, that's a huge production impact. Now, if an oil and gas refinery is shut down at the wrong time, and because of that there's an additional flare or maybe a chemical leak or something like that, because those things can happen regardless of why the event happened. Those negative consequences could be life-threatening, could be equipment damage, could be people hurt. We don't want any of that. We have a, this is not only an ethical justification, this is clearly a business justification too. Because if in the past you said, hey, I don't care for all these remote attacks because the likelihood of that happening is so low, if that was the only reason why we're not investing in your security products, now that likelihood is increasing day by day. You can see the growth. You can see the reports from different vendors. You can see the report from different national labs. The government putting out, like CISA putting out, almost every week some new information suggesting that we have to do something because the attacks are happening and increasing. It is not just vendors trying to pitch you a product. It is actually a reality of our world that the attackers and the sophistication is increasing by the day. So for defenders, we can't just sit back and say, it's not going to happen to me. I think that was a career choice for some people, but not in the near future. I think now more modern defenders will have to step up and say, yep, I'm going to defend my network. I'll understand my network better and I'll defend it regardless of who's attacking it. That way I'm not concerned about how sophisticated they are on the other side. I'm just making sure that my operation is reliable. And oh, by the way, if something goes wrong, I know of a safe way to fail or a safe way to continue operation. That is, regardless of how the impact was in the first place.

A real lab on the wall, and AI for firewall configs

Aaron Crow (50:00): Well, the OT wall that's sitting behind me, if you can't see it, the audience has probably seen me at ICS Village at different places. It's an example, very simple OT environment. But I've had to rebuild it a few times and troubleshoot it, all that kind of thing. And just thinking about how else AI can help us, on the positive side and the negative side. So this has a firewall on it and I've been a firewall admin. I've done all those things. I know how to do those things, but it just takes time. And this is a lab environment. So I'm not protecting anything. I will obviously never do this with real data, but I said, hey, I need to build this network. And I've got a WAN connection. I've got a DMZ. I've got multiple plant networks on it. I'm like, hey, here's what I want. And this is the type and model of firewall. Here's the existing configuration. And I dumped it into AI and it created an output that I was able to go in SSH CLI and copy paste and it created all the firewall rules. Obviously I had to do some basic setup. I had to set up the interfaces, things like that, but it was able to set up the firewall in about 15 minutes. It would have taken me a few hours to do it. Again, it wasn't difficult. It was just, I was able to put in a generic firewall and it was able to do that very simply. And again, this is a lab environment. There's no, it's not protecting anything, so there's no risk in there. I wasn't putting any proprietary information in there, but there's no reason we couldn't do that in OT as well. And what I mean by that is obviously I'm not going to take my production firewall and put it in there, but you could do the baseline. You could set up the basic things on it. You can also use online or offline models and local models. And there's all sorts of things that we can start in. And what you guys are attacking, the use cases you're going after, those things have benefit to troubleshooting as well. Like that's the other side of the coin. Back in 2010, when I started this stuff in OT, when I was going to these sites, I was not telling them I was bringing them cybersecurity, because nobody cared. I would talk about how I could help them with operational availability, troubleshooting, things like that. I was getting logs from all these systems going into Splunk. Yes, I was doing it for cybersecurity purposes, but on the flip side, I could also help them troubleshoot their network. So when the vendor came in and something wasn't working, I could come in and figure it out. There's a port flapping, there's a misconfigured firewall, there's a misconfigured whatever, and I could troubleshoot, I could see the packet loss, I could see DNS isn't responding, I could see that you've got a service failed over here, all those types of things. We're looking at this sometimes the wrong way as OT cybersecurity practitioners, because obviously our main primary focus is stop the bad actors, stop the bad guys, but there's all these other things that come from a benefit of it too. I'm proving that my system is working. Again, looking at your use case, the network path. Yes, if I have a network path that goes the wrong way, it goes past the, yes, there's security risks to that, but there's also a time and latency, and we know how important latency and time is in an OT environment. So if I can make it more efficient by going this path instead of, it's like Waze. If you go this path, it's 20 minutes, if you go this path, it's 25 minutes. That five minutes makes a difference. So we're going to go the faster way maybe if it's got a toll. We make that decision. All this rambling to say, there's all sorts of operational benefits that the plants and locations are going to get from these tools and AI and all this efficiency beyond just cybersecurity. Yes, cyber is an absolute outcome of this that we absolutely have to maintain, but there's also operational benefits to the sites that they can, instead of just being cyber, a cost and a negative on their bottom line, there's some benefits that we can bring to those folks as well beyond just the cybersecurity and lowering cyber risks.

Multiple value, the "security plus" pitch

Vivek Ponnada (54:15): Yeah, you're right on many accounts here. In fact, saying most people don't care about security. I mean, that's true still. Because if there are operations, you care for production, you care for quality and safety, you're not really thinking about security. Which is why I think oftentimes the investments need to show multiple values, where, yes, there's a security use case, but there's also the other use case. In fact, that's how the network security monitoring products succeeded, because they were able to provide asset inventory to the ICS people. They were able to provide packets to the SOC people, but on the operations side, they had additional value for matching firmware with all their spares and all these other use cases that they had. Same thing for us. When they start thinking about AI tools, oftentimes, like I said, the perception versus reality, that is not about security. That's about their IT, OT separation. That's about who controls what. Because IT might have Palo Alto, OT might have Fortinet, and these are all different people managing different things. Now, if you have a contract and if you have someone that is responsible for a certain segment and they let something fail, you are not responsible for it. They have to go fix it. And so you need to find who is accountable and let them fix whatever they have to do. Same thing with the costs associated with doing anything in OT. And that is not security related. Like oftentimes we take an outage for three days every year, and you need to get a lot of things done in those three days, which means that you can only prioritize whatever makes a difference and whatever can be done in those three days. That is not all security related. If you're able to prove that you can only do these three things, and those three things will be the most impactful for your production and safety and quality, by the way, you get extra security benefit by doing that thing. That's wonderful. Because a lot of people, that's what they're looking for. They're looking for, where can I put my guy to do this in the next hour or the next dollar? Because you have limited people and limited resources. That's regardless of whether the security is an application or security is a reason why you're doing it.

Risk-based prioritization: the ice machine vs the turbine

Aaron Crow (56:29): Yeah, the use case earlier about the patches getting out of hand. I remember one customer. I won't name the name, but it was a manufacturing facility and they had 80,000 endpoints, OT endpoints, and they were all behind on patches. And the problem that came to us was, the CISO came to us, is like, look, there is no way I will ever keep up with patching 80,000 systems. Never, I just can't. I can't do it. Like Windows, like the IT side where I have every Friday, I have an outage window and we patch everything and we reboot it. You just know that's part of the process. That's never going to happen in OT space. So we're always going to be behind the eight ball. So patching is not the answer. How else can I do it? And it really gets down to risk quantification and understanding which devices are the most risky. And it's not just this device. I think you've probably heard me say this, but if you haven't, the audience definitely probably has. I've got two PLCs. They're the same firmware, the same Siemens or Rockwell or whatever PLC you want to pick on. And they have the same CVE score. They're the same risk, the same firmware. One controls the ice machine in the break room and one controls the turbine. They're not the same risk to my organization. Just because they have the same patch vulnerability, whatever. One of them I don't give a shit about. The other one is super important to my business. One of them, I just ignore if they hack it or turn it off, you know, you got some warm water. It's not the same as tripping a turbine. It's completely different. And obviously a PLC is not controlling a turbine, it's just the understanding of what it's controlling matters more than just what the vulnerability is on the CVE score.

Vivek Ponnada (58:12): Yeah, it's interesting. This is not a new discussion for us. What you're saying exactly is how functional safety standards were developed. Functional safety said, hey, this controller is configured to operate a critical loop. If something goes wrong with this particular critical loop, it could be impacted to production, could be impacted to safety, could be impacted to equipment and environment, all that stuff. So that controller, that loop needs to be designed in a certain way, that it fails in a certain way. And that's why the functional safety as a standard and a product toolkit evolved. Security is no different, to your point. If that PLC is controlling a critical piece of equipment, there is no way you can treat it the same way. You have to have other compensating controls, maybe redundancy. Maybe a fail-safe backup option if something needs to be reported. We think through all this a lot of times for safety, but never had to think for security. That's the big difference. In the past, we had the challenge. Now we don't have to, it's not an either-or, like with many things in life. We don't get a choice to say, I'll kick the can down the road for one aspect of it while only thinking of all the others. We don't get the choice anymore. I think we as an industry, we're lucky so far, because we haven't met so many OT-focused attacks. We've seen in the past few years, different hospitals not being able to onboard patients and having to turn away people from registering. We've seen that. We've seen manufacturing hit really hard by ransomware, and then being done for a few days. We've had maybe a few, like Colonial Pipeline, where they shut down operations manually for a week, just so that they can be proving that they're safe and they can build the customers. But it's not happening even today, every day. But you and I can foresee that happening, because it's kind of like the environment for those things to happen is already there. When will it trigger? When will that scale? When will attackers start exploiting even more OT systems? When will production and safety be impacted even more? That's just a matter of guessing. It could be tomorrow, it could be a year from now or five years from now. However, the recipe for all the bad things to happen exists today. And a lot of it is completely known. We can't obviously, as professional engineering people, as professional business people, can't justify not doing anything, because the recipe for the disaster is already in the making. So we just need to be prepared and say, okay, I've assessed my risk. At the same time, no one is saying you have to invest in all these tooling, all these technology at the same time. To your point, you don't invest all this on the ice machine PLC. You only invest where it matters to you. On that gas turbine PLC. So the big problem I see is that a lot of people have not assessed what is important for them, what are the crown jewels that they're trying to protect, and what are the important paths they need to protect. Which is, I think, understandable, just based on historically not requiring to do it. But now I think there's no justification. They have to do it. And if they don't have resources, they don't have to complain anymore, because now they can use new technologies to help them with it. And technologies like ours, we're finely tuned for a security use case. We're also tuned for certain other vulnerability use cases like we talked about before. There will be other tools like this for other use cases. At the end of the day, you might need hardware that is capable, like GPU or whatnot, for local compute that can do a lot of things. No different from how, right now in your lab, you will run multiple VMs. You'll run a VM for a particular application, you'll run another VM for another application, or maybe a container. It's no different. So you'll use a tool such as ours for a lot of use cases, for maybe five or six use cases in your environment, but there might be half a dozen other use cases you can run on the same hardware, for your own purposes. So I think this is how the future is going to evolve, into where, no different from VMs, people start using GPU and local compute for a lot of interesting OT use cases that I think are developing. The only thing I can say is that people that haven't tried it yet, they are the laggards. I think that historically being laggards was not a big problem in OT. It was okay to be a fast follower for some people and maybe a late follower for many others. But because there are so many things happening externally, because the offense is getting more and more resourceful, more and more capable every day, I think any laggards right now in OT are going to be really hit hard. That's the only concern I have, in that if they haven't tried something, please go ahead and try something on your own. Whether it's trying something out for yourself, where maybe you're capable and you can tune your own environment and use cases, or get additional help, but try something right now. Because otherwise you're going to be a laggard, and in this case, you'll be the first person to get hit.

OpenPLC, Raspberry Pis, and democratized AI labs

Aaron Crow (01:03:17): Yeah, and it's amazing. I'm literally building out labs to take to ICS Village to do CTFs, sell these labs because everybody's wanting to come in. Hey, I want to build out. So building out OpenPLC and building out with just a Raspberry Pi. So I've got a Raspberry Pi that I've built with a container and it has everything self-contained. It's got a PLC built into it. I've got a hat on it. There's a couple of options. There's lots of options, but you can put a hat on it that's got just, you know, IO inputs and outputs, digital and analogs. You've also got relay ones so I can control a light or a motor or things like that. You can have an AI hat that you put on it that obviously it's not going to be an Nvidia 32-gig thing, but you can run local models on a Raspberry Pi 5 with an AI hat for under $500. That's cheaper than you can buy a GPU and a desktop machine. For $500, you can do a lot of testing, and yeah, it's going to be slow and yeah, you're not going be able to use the big models, but you can still do some things that are value add. And in a lab in a safe environment where I'm not damaging things, I'm not, obviously you don't want to put this stuff in the Claude or ChatGPT and put your proprietary or PII or whatever those types of things are in that space. But there's lots of ways that you can do this and benefit. Like every consultancy in the world is using AI to manage their systems. Like, of course they are. I think EY, I'm former EY, EY, I think they put in like a billion-dollar effort around AI internally. And this is not cloud-based or external internet facing. It's a private AI focus to help them be leading edge. And I work for Arcova, which is a lot smaller, but we're focusing on AI and all this different stuff. Like how can we use the, because at the end of the day, to your point, the laggards, it's going to be a problem. You know, used to, you could wait around. I remember rolling out a virtualization and how much that was a lagger and people just didn't understand how virtualization worked and all that kind of stuff. But you could spend a few years and, I'm going to wait till Bob installs it. Once Bob installs it, it works okay, then I'll understand it. But that curve is happening so fast now. Lagging now is going to be a few weeks or a few months. You can't wait 10 years like we used to be able to do.

One concern, one upside

Aaron Crow (01:05:35): With that, what do you see as the biggest concerns and maybe one big concern and one big positive coming from all of this stuff, good and bad, on all this related to the OT side?

Vivek Ponnada (01:06:05): Well, let's start with the concern. The one that I already mentioned. I feel like the big concern is that a lot of people are still underestimating or not evaluating their OT risks. That should go away. At some point, people should be able to say, I know what my risk is, and I've chosen to implement these things because that makes sense for my risk mitigation. And I've chosen not to do these other things because I don't care. I don't care about those assets or those sites, or I'm quite happy with that being down for a week. That I think is the biggest concern. The positive side is, I think we are finally coming of age where we're going to be neck and neck with IT security. We're going to be just as efficient, just as fast because the kids that are coming out of college right now, they're not going to not use AI tools. They're not going to not use technology. It's, you know, ask anyone of our generation to build something not in PowerPoint, not in Excel. We wouldn't be able to do it. Now there was a time when we used Lotus 1-2-3, or even WordStar back in the day. But now we can't. Similarly, I think the one beautiful thing is the current generation is going to be AI-native, is going to be very technology-savvy. They're going to ask the key questions, say, why are we doing it that way? Oh, we understand. We understand things to be on-prem, things need to be hybrid, maybe only management layer on the cloud, but they'll be able to really grasp the key problems and solve them in different ways that historically we didn't. So I think we will be seeing less of kicking the can down the road versus, let's fix this once and for all. So that's, I think, is a positive thing in the future.

Aaron Crow (01:07:45): That's awesome. I agree. I think there's a lot of good, but only if we jump on top of it. Because it's not a, you know, well, I just don't need internet. I'll just disconnect the environment. That was the old days of, security is an option type thing. It's not optional anymore. We've got to jump on this bandwagon because it's coming at you from the bad actors. You have to use it to your benefit. You have to wield the weapon that they're going to be using against you.

Where to find Vivek and Frenos, plus the Mythos webinar

Aaron Crow (01:08:11): So, call to action. What are the things, how do people find out more about Frenos, find out more about you, all the things. What's the call to action?

Vivek Ponnada (01:08:18): So easy enough to find me on LinkedIn. I'm pretty active there, Vivek Ponnada. Frenos is frenos.io. We have a YouTube channel as well. We do sometimes Frenos Friday that you've been on a few videos yourself. But yeah, so frenos.io. We're also on LinkedIn, easy to find us. Just hit up the request demo if you need to talk further, or just reach out to me on LinkedIn if you need to discuss further.

Aaron Crow (01:08:43): And then real quick, you guys had a fireside chat or something yesterday with Rob Lee and all those. Talk a little bit about that. What was that? What did you all dive into?

Vivek Ponnada (01:08:50): Yeah, so yesterday Rob Joyce, who was the ex-NSA director, Rob Lee, CEO of Dragos, Harry Thomas, who's the CTO of Frenos, along with Hollie Hennessy from Omdia, we had a webinar. The key point was, what is Mythos meaning for OT? Where are we as a collective society, as an industry, as a vertical, defending ourselves against the likes of Mythos? And it was a good discussion, so I recommend people, if you haven't seen it, go find it on YouTube or sign up for the link and you'll get the recording. Either way, the key discussion there was that the industrial control systems that historically have under-invested have to be better prepared for it. Because the massive changing of vulnerabilities and everything in the perimeter is just porous at this point. So the key discussion there was, how do you defend? Well, the conclusion was, our defense doesn't have to change in terms of structure, in terms of design, because we've always been able to defend against what is known and our understanding of networks. But we just have to do more of it and be more disciplined at it. We don't have to be like, yeah, something new is coming and we have to be worried about it. As long as you have your basics right, your fundamental understanding, your network, and understanding of what could happen in your network, you will be able to defend yourself regardless of what's out there. So that was the discussion, but it was an hour-long discussion. There were a lot of interesting nuggets. I would recommend people to go take a look.

Aaron Crow (01:10:18): Awesome. Definitely go check that out, guys. I'm sure you probably know Rob Lee and all the things. These are good conversations that we know we need to have. That's why I have conversations like this with you, to get that message out. We've got to continue fighting this good fight. So no matter where you're at in the fight, if you've done nothing, if you've done little things, whatever, there's definitely things that you can do to move that ball forward in your environment. So, thank you, brother. I appreciate the time. Love always talking with you and chatting and can't believe this is the first time we've done a podcast episode. So I'm sure there'll be more coming. So thanks again for your time and I'm sure I'll see you very soon.

Vivek Ponnada (01:10:59): Man, enjoyed it.

Transcript lightly edited for readability.