Cisco Systems, Inc. (CSCO) Earnings Call Transcript & Summary

Good morning, and welcome to today's SANS webcast, ICS Asset Identification: It's More Than Just Security, a SANS panel discussion. Sponsored by Cisco, Palo Alto Networks and Tenable. My name is Carol Auth at SANS. Today's featured speakers are Mark Bristow, a certified SANS instructor for the ICS515 course. He will be moderating today's webcast. Marc Blackmer, Product Manager for IoT Security at Cisco; Marty Edwards, Vice President of Operational Technology Security at Tenable; and Del Rodillas, Director of OT Industry Solutions at Palo Alto Networks. [Operator Instructions] Please note that this webcast is being recorded, and a copy of the slides and recording of this webcast will be available for viewing later today and can be found on the SANS registration page. And with that, I'd like to turn the webcast over to Mark.

Thanks very much, Carol, and thanks to Marc, Marty and Del for joining me today on this. We've got a really important topic. And thank you for everyone who has joined us today to listen to this panel discussion. So a couple of weeks ago, we put out a paper from SANS that -- the links there and the slides if you are already familiar. Talking about a really critical topic of asset identification and talking about not only how we do asset identification, the types of methods of asset identifications or physical inspection been passive, discovery configuration analysis and using active techniques. But ways that you can boot-start your program on a budget, things like starting small, scoping the environment, defining the data points, I understand you have that lexicon, kind of what data sources can you grab that you already have or may already have, how do you plan to scale, how do you leverage tools in order to support you in this. Just really talked about a lot of the different ways that we can bootstrap and bring that asset identification program up. But really, maybe more importantly, we talked about what are the benefits of cybersecurity doing asset identification, right? Obviously, this supports your cybersecurity efforts in that kind of, "protect, detect, respond, recover" framework where you're -- you all can make sure that you have covered your vulnerabilities. As we were discussing before, the webcast, just a whole bunch of those vulnerabilities kind of seem to be coming at pace these days, at least on the IT side. How can you detect, how do you know you can't really protect things you don't know you have? How you can accelerate your response times in cyber incident response and how you can recover better are some of the key things that we talked about on paper. But one of the things that is really under-addressed in the community, and I talked about on the webcast for the paper is that we need to be more effective at communicating to our key stakeholders on the business side about how there are 9 cyber benefits that actually can positively affect the bottom line of the organization, how can we -- how can better asset identification give us better mean time to recovery, better failure analysis, how can it increase our safety factors. Those little key things about how we can articulate value to the business beyond cybersecurity, I think, is something that is really critical to really secure the resources needed to get your cybersecurity asset identification program bootstrap. So we covered a lot in the paper, and just kind of want to really -- just recap some of those things there. But really, you're not necessarily here to hear from me all day today. It's really kind of get this out to our panelists and get some other perspectives on how this -- how to get these programs going.

So we've got a couple of quick questions that we have set up. [Operator Instructions] But the first thing, the TF question that I want to put up. And Marc, if you can address this one first for me, that would be great. We talked a lot about -- in the paper about the value-add for not just security, but how do we show the business to value the business? And the cybersecurity kind of is an accepted thing, but what non-cybersecurity value do you think a comprehensive asset identification program provides, from your perspective, Marc?

Yes, sure. I would actually even -- the way I kind of look at it, which may sound odd from a security guys to invert that, you're going to end up with better security if you're doing the foundational things well. So I look at it, number one, for asset identification as being key to the business. I mean, I think how do you make sure you're running efficiently if you're not even aware of what you have? So I think just from that perspective of just understanding what you have in the environment is helpful from a process perspective, from a business perspective. Looking at that, too, just even you think dealing with support and contracts and things like that, if I know I've got a PLC with firmware that is out of date and I can't get support for, that as -- well, I don't say nothing to do with security, but the first thought is, if I can't get support on my devices, then I have a problem. And of course, then we're looking at vulnerabilities and things like that if something's out of date. So I really see that as just being core to being able to run your business, run your operations efficiently. And then, well -- then security is going to come out of that, good security is going to come out of that. So that's how I tend to look at it.

Yes. Great. I think that, that's a really good point about how this is really fundamental to just the efficient operations of our environment. That's -- yes, perhaps -- certainly it's a great way to look at it. How about your perspective, Marty, what do you see as a key value-add here?

Yes. Very similar to Marc, but the way that I tend to articulate it is that if you look in an industrial plant, at something like rotating machinery, I mean we have lube oil -- lubrication analysis programs where they're scheduled and predictive and proactive maintenance routines that you perform on these expensive machines. And I believe we have to have something similar in cyber. So I tend to call this cyber maintenance, right? So having real-time data on your assets, so it's not just the identification part, but it's having that real-time data feed on how your assets, your cyber assets are performing can really help you from an optimization and economics perspective within the plant. You also referred to the recovery time from a failure. So being able to go into these kinds of systems and determine the causality of something, was this a mistake somebody made in misconfiguring a device or was this an actual cyber incident can help you recover a lot faster. And I think that those are really tangible nonsecurity benefits that go right to the ROI of these types of investments. So I think that we've kind of mis-sold this in the whole security space that, "Oh, yes, these defensive kind of technologies really don't have ROI." And I think when you look at it outside the context of security, they certainly do.

Yes, Marty. I think that's a great point. I like that cyber maintenance kind of lexicon. It really, I think, it's something that our operators are already well familiar with how you have to do maintenance on the process already, right, and making cyber special maybe is probably the wrong way to do it. Just talk about how it builds into the system. And then, yes, I think that point about causality and getting that root cause analysis quickly is absolutely critical. Del, how about you?

Yes. I kind of look at this in a couple of buckets. One is the usefulness when you identify just what you have and use that information. The other one is the additional context that you get when you think about network engineering, optimization and troubleshooting. So you'd have tools today that can tell you, "Okay, what kind of traffic is on the network." But when you are able to correlate that to what device is actually on the ensuing communications, what's causing the chattiness, what's causing this type of abnormality, that's really powerful. So you could use that in different phases of the life cycle of the plant when you're validating the initial deployment. So you can validate, "Hey, this is what I expect to see and this is what I'm seeing or not." So you could actually adjust the way you're deploying your new system if need be. The other scenario would be where you're troubleshooting some kind of issue. We've seen cases where you may have had some kind of weird outage in the client environment, and you're able to identify which device is kind of misbehaving. You might start seeing some kind of persistent or periodic warm restart on a PLC. And then you can say, "Oh, somebody forgot to remove this bit of code and the lateral logic that's causing that to happen." So you can identify things like that when you're able to correlate the network traffic with actual device much faster. We've heard of cases where people installed from a print servers on HMIs and that caused some network storm. So you're able to see the storm, you're able to see it's tied to the traffic going to the HMI itself. That'll help you in terms of improving the availability of the network. In the case of the PLC, that's more about some kind of actual outage. So it's really about making sure that the availability and potentially, safety concerns are addressed. So I think that's pretty important. Now it could be even as simple as, "Hey, I lost track of this asset." We have health care customers to -- sometimes they have these roaming insulin pumps and whatnot. Like where the heck is this insulin pump, which is on a cart somewhere. So you can say, "Oh, it's connected to this access point on second floor." So you can much easily find these assets that are potentially nowhere to be found. From a more simplistic standpoint, in terms of what -- getting inventory, right? So Marc mentioned asset management linking it up to your CMDB or connecting it to things like that automate ServiceNow or even a SOAR product. But more out there, use cases, we've actually heard our users talk about is financial analysis. They want to get inventory on the assets for depreciation on the balance sheet, right? They may be usable for future planning in terms of what assets potentially don't have enough hardware resources to support an expansion. And the other thing that's kind of rising in importance is supply chain is -- it's not necessarily cyber. But do I have -- if somebody asked you the question, do we have any devices in our network from this blacklisted supplier? It's going to help you answer these kind of things that management is asking about. A little bit more out there, but people sometimes say compliance is not cybersecurity. So compliance, meeting compliance, cybersecurity insurance, this might be able to help you with reducing cost of insurance. So a lot of other things, but it's around just knowing what you got and optimizing the availability and safety of your environment.

Yes. Thanks, Del. I think that those are a couple of really great points. I just kind of wrote a couple of things down here. I think the first thing that I took away from that was that yes, how can you secure what you don't know you have? You can't do anomaly detection unless you know what normal is, right? And that -- I think that's dead on. A lot of different business impacts in the ways that we can do that. And one, I think, then I'm going to highlight that you kind of touched on the end there was the depreciation factor, right? That's something that the business understands on how we can leverage that, how we can make that in our planning. Again, mind you, any time you can really interact with the CFO on something that benefits security is -- in a positive way, it's going to be something that's worth doing. The last one that I want to just kind of highlight, too, is that compliance angle. Yes, compliance is not security, but compliance is business risk, right? I mean compliance is something that we have to do, and so there's business risk there. And I think that's another avenue, especially, as you mentioned, insurance, is potentially a way where we can find ways to articulate the business, how we're supporting other efforts with this asset identification. So really, really great points there. I appreciate that, though. So moving on to kind of the next question, right? And this has been a hot topic in this industry for a long time. We've come a long way in the technologies in the marketplace that's available to support asset identification in an active way. Running NMAP against your control system was an absolutely crazy proposition 10 years ago. It's still something I wouldn't directly recommend, especially because NMAP isn't really tuned to work with control systems, but you're going to have a much better experience these days. And really, things that our control systems have matured their technology. But more importantly, the community and the marketplace has a lot better technologies to actually support scanning actively of industrial control systems in less risky ways, right? So I think that, that's really a great way that we've moved forward and kind of our -- maturing our capabilities, I think, those parallels to IT, where back in the day with IT stuff, there wasn't a robust asset identification kind of platform. And now we have a lot of tools out there. So I think it's really a great change in the industry. So what, from your view, and Marty, I'm going to go to you first on this one. What from your view, Marty -- what really has changed in the marketplace here? And what drove that change? How did we get to a place where it's not crazy anymore to run active scanning in your environment?

Yes. Well, it's -- as you know, I've been one of the drivers and people behind some of that change. But you're exactly right, taking a tool like NMAP or even our own Nessus tool and just pointing it at random control system assets and scanning every available port and every available protocol can really overwhelm the limited communication stacks that exist in some of these ICS and OT products, right? And there's all kinds of horror stories from a decade ago of robot arms moving around by themselves because they were pinged or because they had some sort of scan. And so I actually would argue a little bit about even using the terminology to scan or not to scan. I don't think you should scan per se, your ICS environment. I think that you need to gain a certain level of baseline information about what kind of controllers and what manufacturers and what protocols do you have in your environment, and most contemporary OT security systems can do that through passive listening. But then, really, where the needle has moved is that there now exists the technology to communicate with the OT devices in their native language, and I don't consider that scanning. So if you have Rockwell, Siemens, et cetera, controllers on your network, we basically determine, "Oh, well, we hear Rockwell SIP protocol." So we will go out then and actively query or ask in the appropriate protocol, "Hey, we noticed that you're using this protocol, what type of controller are you? What's your patch level?" And basically elicit a conversation with the controller. And that's a very reliable and efficient and safe method to get this type of information. The vendors themselves have been configuring and maintaining and diagnosing their controllers using their own protocols for decades, right? And they've designed these protocols to be very efficient and very safe. So you now see the OT security vendors. And at Tenable, we believe we were the pioneer in this technology. But basically the mimicking or leveraging the exact same protocols to talk to those controllers, that gives us much better granularity of asset information. So it's not just the identification part, but we can actually drill down and baseline the actual running config in the device, which then gets you into that whole cyber maintenance type of conversation, right? So I really think that this technology has evolved. I had an interesting conversation with Dale Peterson about this. And if you went back 15 years ago, people would say, "Oh, you can't run antivirus on an HMI. It just won't work." And it was just not used. Well, now everybody has some sort of endpoint protection on their modern HMI, right? I mean the vendors have strategic alliances with the endpoint protection vendors. So I think we're going to go the same way with this active querying type technology passive. We'll still have its uses for network analysis and network traffic and everything. And -- but I think when you want to really get in-depth information from the endpoint, you're going to have to -- in the controller level 0, 1, 2, you're going to have to use the indigenous OT protocol.

Yes. Marty, thanks. And I think that you made a couple of good points. And I'll take and admit the feedback that perhaps I was inartful in my attempt to be accessible within to scan or not to scan. Because, yes, the nuance there is incredibly valid, right? And it's not really scanning. Scanning has an implication that we're just kind of spamming out to the universe and not really in a controlled way. And yes, and I think that your kind of perspective on how the active querying tools, or whatever you want to call them, really have matured. And I think, to me, a big differentiator has been the leveraging the actual industrial control systems protocols themselves and interrogating them in the language they expect. Because a lot of the horror stories boil down to, well, you did something that the controller was never really expected to do and so -- and then it just fell over. But the control protocols are generally very robust. So I think that's an important point about how things have kind of moved on. And I think that your point, too, about how we -- this is valuable beyond asset identification is absolutely spot on. Obviously, the paper was focused on that, but there are a lot of other values that we can drive there. And the market really -- your analogy to AV, I think, is also spot on that, that was also something that was crazy at one point. And in reality, we've accepted that. And as the vendor community and the provider market space moves on, I think that's a really great point about how it's really been maturing. So appreciate that. Del, how about you? What's your perspective?

Yes. I think I have -- I don't know if it's different or opposite view. But from my standpoint, and I'll answer the question to scan or not to scan, its -- we're not very focused on active scanning in our technology. So that's not really an area that I have insight into. But I can focus on what my opinion is on the scanning. So it's not a black or white answer, in my opinion, on whether to scan or not scan. So I think the decision really has to be some kind of risk-based decision where -- and focusing on what your tolerance is as an organization. You need to consider different factors, right, well, like what is the likelihood of the assets itself to crash and the age of the asset, greenfield, brownfield, hybrid, how well maintained is it, the kind of assets you have, what kind of resources from a computer memory and the load on the asset, that definitely impacts the capability. The time frame, when are you doing this? Are you doing this during the production or in the maintenance window? Certainly that certain times are better to do this type of probing or scanning. And you may have modern systems, but what are the adjacencies? Do you have, on the same network, which could be a flat network, systems that could be impacted by a scan? So how isolated are they from the other assets? Very important things to consider. The most importantly, probably, what is the risk or the impact if something bad were to happen, monetary, environmental, reputation, worst case, loss of life, right? So I used to work as an engineer in a semiconductor environment where we work with dangerous chemicals like HF, hydrofluoric acid, which could really cause some serious situations for health and human safety, right? So I'm a little bit more conservative based on my prior experience and just kind of the approach, we believe so. There are definitely techniques that could mitigate that, as Marty pointed out. But from my personal standpoint, we would not -- we would consider the risk and make decisions based on that. I don't think we would ever prescribe or advocate scannings in safety critical environments I want to make sure that at the end of the day, everyone goes back home safe to their families. And we do believe that there are certain advancements in the passive approach where it's being more precise, looking at different -- 1,000 parameters under the network to get high confidence determination using things like machine learning. So -- and the other approach that we've seen applied is trying to make use of the intelligence from the crowd-sourced device learnings to make it ultra-precise. So net-net, if you're going to do it, again, consider the risks, be there to support the team, right? Don't just bolt after the install. We've seen cases where issues don't arise until a few days later because of a cascading effect. So if you're going to do this, you better put some skin in the game and be around to support the team over a period of days when you do that.

Yes. Thanks, Del. I think you're spot on there with the risk management. I think with all things, the right answer to all questions tends to be, "it depends." And yes, your -- I was just kind of taking notes as you were saying that. I wrote down the same thing that you ultimately mentioned, which was evaluating the risk and -- versus the reward, especially like going after a safety system, for example, and doing active scanning, considering how small those systems are generally, it's probably not worth it because the consequence is so high if -- or potentially so high. If something does go wrong, even if you think that it's -- and you've tested it and it's low probability, the consequence is still really high, right? And that's where that risk model equation comes in. And I also agree with you that the passive technologies have also really upped their game as well as the active technologies over the years. I mean when I kind of started in this field a number of years ago, there wasn't really much of a marketplace of control system-specific technologies on any topic. And I think that it's also true that, that's evolved. Although to me, I do think there is a place for scanning, especially where there is some technologies that like lie dormant in a control process or not very noisy on the wire or those types of things. From an asset identification comprehensive perspective, really, I think the combination of a variety of techniques is needed. But to your point, the passive stuff has gotten a lot better than it used to be and it can sometimes interpret that as well as leveraging the community to understand. So I mean those are some really kind of good points as well. Marc, what are your thoughts on this topic?

Yes. I guess I'm going to play the part of Switzerland on this one because I'm sitting here listening to Marty going, "Yes. Yes, I agree." And I'm listening to Del, going, "Yes, I agree with that, too." I think, again, I guess, to the point of scan, even within our technology, you get just a little peek behind the curtain, we were originally going to call it active scanning or engineering, so we had active scanning project and I was like, "No, no, no. Don't call it that. We're going to call it Discovery." Because I think there's still that -- the sensitivity of scanning per se, right? It's the same thing, but it's just kind of how you want to label it. But I do think it shows the maturity. Well, actually, I don't want to say it that way. I think it shows the growth of how things have come along in this space when it comes to the cybersecurity stuff. We talk about putting endpoint protection on HMI and I think it's taken, really, security vendors speaking as one to understand what somebody really needs on the operations side; that you can't just slap in, like you said, NMAP and go nuts. It just doesn't work that way. And I would hear horror stories from customers or the ops folks could go to lunch and the IT guys would fire up the NMAP while they're away, and they take part of the system down. So I'd like to think that we're advancing beyond that. There's enough understanding that security is obviously needed. Some of the techniques are needed, or the concepts, but they'd have to be applied in a way that's appropriate in the control space. And I think, Del, you bring up a really good point about the safety systems. And I think, again, us as vendors or we as vendors, it's really important to give the customer that choice. You may have an area where you can go out and probe a device, of course, using native protocols, but the customer should have the choice of what to do because this is, for all the reasons that Del laid out, could be very, very, very dangerous. I think -- all in all, I think it makes sense. I think, again, it's shades of gray because it's got to be done in the right way and in a way that helps the situation, not interject more problems. But I think if you would ask me a couple of years ago what I thought about it, I would have said no way. But, too, my thinking over the years has changed as long as it's done appropriately. And I see that, that's where the market's going, thankfully, so that I'm much more of a proponent on it now with those caveats.

Mark Bristow, I'd like to just interject a final comment here. I think another key benefit of this type of technology, where you're doing this active discovery, active querying, whatever you want to talk about it, is there tends to exist a certain complexity in passively instrumenting a system to get access to all the data. You've got to put sensors or SPAN ports or stuff all over. And we found that if you'll have a routable -- if you have a path to route to the device, you can elicit that conversation using the native protocol and we've got implementations or installations where one, basically, engine sitting in the right place can go out and touch dozens of networks that you'd have to have passive sensors or aggregation points to capture the traffic. So I think there's a lot of growth and maturity that's going to happen here, but I do really see it as the way to the future.

Yes. Thanks, Marc and Marty, for those comments. So I think I really need to apologize for using the S-word in this conversation because I think it can pull you all off by using that reference and...

It's 4-letter -- it's a 4-letter S-word.

It's a 4-letter S-word. It's fair, totally fair. But -- so I'm going to turn that into a positive here. And I think it's great that we're having this kind of conversation about why lexicon matters. And Marc, you hit on it. I think the way you started off about actually having that dialogue with operations and understanding their needs, but part of that is effective communication, which happens in both directions, right? And lexicon is a big problem. In my career, going between a power plant and a water plant, it's like they speak 2 different languages. They might run the same vendor, but they have different words for everything, right? And so I think that, that's important to speak in a way that -- where you can be understood and where you understand and then be sensitive to keywords, and maybe I'll start using discovery instead of scan.

So Mark, if I can just -- so I told you I started in IT and then I was on the vendor side and moved over focusing on OT when I started at Sourcefire. And early, early on, I was on the call with a customer and just on the phone, actually, to give you an idea how a while ago it was, but I made the comment about, "Oh, we have a private cloud option." And as soon as I said, cloud, like just -- I couldn't get a word in for the next 5 minutes. And I just remember the customer at the end said, "Son, never say that word again." But we've progressed. Now you can actually say cloud and you probably won't get anything from it. So don't worry, scan, it may come around.

Yes. And you know what, we're going to have a whole other webcast just on OT cloud, probably in the future.

I knew it. I will recommend that one because I definitely have thoughts on that. I did want to do a quick reply, Marty, to the one, I think, you said about the challenges in instrumenting in environment for some of these -- for passive technologies, which I think is a valid one. And I think your point was spot on, but I want to provide a counter-narrative example as well. Because earlier in my career, I was doing some -- I was doing SIP auditing in the electric power industry. And I was working with a customer who was in the process of -- had a whole bunch of nonroutable communications with their field devices, over substations, so a lot of dial-up and that kind of stuff. And they were actively ripping out -- well, they weren't ripping it out, but they had laid fiber between all of their substations to increase the reliability of their system. And they were in the process of turning all that fiber off because they were trying to get around the nonroutable SIP exception, which didn't actually work, but that's not relevant to this conversation. The point that I want to make is that sometimes we have some unintended consequences in enabling that access for that visibility, for the passive monitoring to actually create risky pathways that you otherwise didn't have because that was in serial com before. And now we have fiber to that area, and so now we've created potentially a risk vector. So I guess it falls back down on the Del's point of it all depends, and it's a risk tolerance discussion. Because at the end of the day, there's negative consequences to some of the security things we do and -- or there can be. And we need to mitigate the risk we introduce just as much as we mitigate the risks that we're trying to do from bad actors, right?

So yes, totally valid point. And again, so really forward leaning, the way I think that we'll end up solving that is with integration, right? So there's no reason for those pathways to be open, 100% of the time. So our security tools should be able to talk to the next-generation firewall devices or the perimeter devices and be able to open that channel just when we need it and then tear it back down. And I see us going that way as an industry.

Yes. And I think you all made this point to some extent. And then I'll just pile on that, yes, I think it's the integration of multiple names, multiple techniques and then using the right one where appropriate based on the risk management decisions and then really integrating those types of technologies with our defensive measures as well as bringing it back to create a comprehensive picture, I think that is -- the best path is probably a little of each -- kind of take investment brief from all the different types of technologies out there and having an integrated approach. I think that integration is where we'll get a lot of dividends. And I think that the IT community has kind of gone through some of this evolution already. And I think the OT community is waking up to some of those needs. So good points kind of across, everybody. So we want to talk about this, too. This is one that I think comes up a whole lot is that, is scoping, right? When you're trying to get this going and perhaps you've convinced your management to buy a tool to help you do this or to start a project to do asset identification. And then you step back and you look at that plant and you go, "Man, where do I start?" The plant's huge. I have all these assets." And it's just this like overwhelming feeling of dread that, "How am I going to accomplish this task," right? And it's really a challenging thing because they are not really -- at the end of the day, you want to get a comprehensive answer. But if you try and chew the entire elephant at once, you're probably going to fail. And this is, I think, one of the areas where a lot of people struggle is, "Okay, well, what scope is the right scope? What's ultimately in scope? How do I get started?" We talked a little bit about that in the paper about maybe even ticking something that's not even really your process control system to refine your capability. The building they track, right? That's kind of a control system. How do you scope it, right? And how do you avoid what I see as one of the biggest challenges, which is going down the rabbit hole and just not being able to get yourself back out and kind of losing the purpose in the detail? And I think that, that's really at risk in immature programs to kind of have that challenge. So Del, I'll go to you first. What are some of the strategies that you think can be effectively leveraged in scoping, not only your initial activity, but then making sure that you can expand that, taking into account all the different data and things that you can bring to bear? How do you approach this problem, Del?

Yes. I mean, like with a lot of things, you begin with the end in mind and identify what is your objective. Are you trying to just have some kind of asset inventorying? Or are you trying to assess risk or want to go to the point where you're stopping threats that you may find? What kind of assets are you protecting? Is it just the old stuff? The new stuff? Or a mix? Ultimately, you want to have more of a monitoring-only stance or enforcement that there's some integration considerations when you look at that. And the other thing is a lot of these solutions that are starting to address both IT and OT and IoT, right? Are you -- is that part of the scope that you need to get to where you have a unified approach to just call it device security across the entire enterprise? And from there, I think it's important to look at what asset environments are appropriate with that goal in mind. And I think that will help you really with defining what is the scope and trying -- there's going to be some changes as you kind of progress, but minimize that scope creep and try to stick to this goal as close as possible. I don't -- just because you have a goal, it doesn't mean you're going to get the buy-in. You're going to need to get that support with the OT side of the house. So I explained the benefits of the technology. We talked about some of those noncyber type of benefits, but that plus the cyber to get buy-in before you can actually even access these assets environment. So in terms of, let's say, you have a plan and you needed to kind of start, you're not going to probably just start dropping sensors or monitoring components across the entire environment. You're going to want to start small, right? So if possible, find like maybe a cell or a line. You mentioned BMS or BAS systems, building automation systems, right? That could be a good, small bite-size piece. If possible, it's something that you could walk and visually confirm the components that are also there to compare with what you have. Again, just going back to how I answered the second question, avoid safety critical. It is good that you're not going to get buy-in from the OT guys if you start there. And if possible, leverage existing tools, there's many ways to get this type of technology. And there, our approach is really to bring it -- make it available as a service on the next-generation firewall. So if you already have a firewall that DMZ, between IT and OT, that might be a way you could easily tap that access switch, where you have the PLCs and HMIs connected to and get visibility to layer 2, layer 3 -- level 2, level 3, level 1 Purdue, right? So maybe we'd use existing packet brokers that are already getting these kind of feeds and feedback to whatever sensor device is going to -- that ingest that and make use of it. So I would say that's kind of some of the starting point considerations you need to think about before you start going big.