@BEERISAC: OT/ICS Security Podcast Playlist · 2026-07-02 · 13 min
Key moments - from our scoring
Substance score
36 / 100
Five dimensions, 20 points each
Dan Ricci, founder of the ICS Advisory Project, distinguishes between basic asset lists and comprehensive asset inventories in OT/CPS environments. While asset lists provide enumeration of devices, IP addresses, and physical locations, true inventories add contextual layers: firmware/software versions, vendor vulnerability advisories, patch status, compensating controls, data flows, criticality ratings, owner accountability, vendor support status, and last-seen timestamps. Ricci explains how tools like Wireshark, Network Miner, and CISA guidance enable both automated passive discovery and manual validation, emphasizing that CISA's OT inventory guidance provides essential framework for organizing, regularly updating, and physically validating assets. The conversation covers how baseline configurations derived from solid inventories enable rapid anomaly detection, incident response acceleration, and identification of compromised devices - whether through unauthorized setpoint changes, unexpected device communications, or outbound connections to public IPs. Ricci stresses that maintaining asset inventory requires treating it as a living document through asset lifecycle management, organizational roles and responsibilities, automation where possible, and scheduled physical validation. He argues that security success in small and medium OT environments isn't measured by tool count or assets discovered, but by whether risk actually decreases over time - shifting organizations from hope-based postures to resilience-driven operations where every alert feeds into continuous prioritization and action cycles.
An asset list provides basic enumeration of devices, IP addresses, and physical locations. An asset inventory adds contextual data including firmware/software versions, applicable vendor vulnerability advisories, patch status, compensating controls, data flows between devices, criticality ratings, asset owners, vendor support status, and when the asset was last seen on the network.
Open-source tools like Wireshark, TShark, and Network Miner can perform passive asset identification. CISA and vendor websites provide vulnerability advisory data. Passive packet capture, flow data analysis from routers, and switch configuration analysis can all help identify firmware versions and data flows between devices.
Inventories must be treated as living documents through asset lifecycle management, identifying responsible roles and stakeholders, automating collection where possible, scheduling annual physical validation, integrating operations and maintenance contractor data, and ensuring all alerts and scans feed into continuous prioritization and action cycles rather than remaining static.
With known baseline configurations documented, security teams can rapidly detect unauthorized changes like modified setpoints, unexpected device communications, connections to new devices, or outbound connections to public IPs - enabling quicker root cause analysis and confirmation of actual compromise versus legitimate changes.
According to Ricci, success shouldn't be measured by tool count or assets discovered, but by whether organizational risk actually decreases over time and whether every alert, scan, and asset discovery feeds into a cycle of prioritization, action, and validation that moves the organization toward resilience.
Our reviewer’s read on each dimension, with quotes from the episode.
The asset-list-versus-asset-inventory distinction is genuinely useful and covers meaningful attributes (firmware versioning, communications relationships, end-of-life status, owner/responsible party), but the 13-minute runtime is dominated by a structured enumeration of known concepts rather than novel ideas. Most of the guidance is standard OT practice with little that would surprise an informed practitioner.
what's the criticality of that asset, you know, what's the process impact rating of it, Is it a crown jewel?
if there is something that does occur in your environment, if uh, your, the asset is a, is um, is manipulated in a way that is off its known baseline. You can identify that rather quickly
The entire episode recycles well-established OT security doctrine - inventory as a living document, passive monitoring, people-process-technology framing - with no contrarian or first-principles arguments. The closing sentiment ('hope's not a plan') is a well-worn cliché that exemplifies the episode's reliance on familiar platitudes.
asset inventories are an asset management in general is, is, is, is a living document, it's not a static document
it kind of moves the organization from a posture of like hope to uh. One of ah resilience
Dan Ricci is the founder of the ICS Advisory Project, a legitimate practitioner credential that signals real domain immersion in OT/ICS vulnerability tracking. However, the transcript reveals no evidence of having run OT security at industrial scale inside an asset-owning organization, and he explicitly declines to speak to how operators behave in practice.
ics uh advisory project supports it. You can use CISA directly. You can go to the vendor's website
I wouldn't be able to speak directly on how um, how many like asset owners are actually uh, going in that direction
A handful of open-source tool names are cited (Wireshark, T Shark, Network Miner) and CISA guidance is referenced, but there are zero named customer examples, no metrics, no dollar figures, and no timelines. The guest openly admits he cannot quantify adoption, which underlines the episode's dependence on abstraction.
There's passive tools out there that can help do this asset identification uh such as like Wireshark, T Shark, you can use uh Network Miner
I wouldn't be able to speak directly on how um, how many like asset owners are actually uh, going in that direction
The host asks logical sequencing questions that keep the conversation moving, but every question is anticipatory or validating rather than probing - he frequently completes the guest's point and moves on. There is no pushback, no challenging of vague claims, and the episode functions as a promotional discussion of a pre-existing article rather than an interview that extracts new thinking.
So that really becomes like a business impact discussion at that point.
And that's the goal.
Computed from the transcript - who did the talking, and the words that came up most.
Podcast : Nexus: A Claroty Podcast (LS 32 TOP 5% what is this? ) Episode : Dan Ricci on OT/CPS Visibility and Risk Reduction Pub date : 2026-06-29 Get Podcast Transcript powered by Listen411 - fast audio-to-text and summarization ICS Advisory Project founder Dan Ricci joins the Nexus Podcat to discuss how to turn operational technology (OT) and cyber-physical systems (CPS) visibility into actual risk reduction. Dan describes the need to distinguish between asset lists and actual asset inventories, what those differences are, and how to make the most of the information made available. Device data such as firmware versions, protocol identification, and more are vital to other aspects of the OT and CPS protection program, including exposure management and segmentation initiatives. Dan wrote more on this topic in this article: “ From Inventory to Insight: Turning OT Visibility into Concrete Risk Reduction .” This interview was pulled from Episode 4 of Nexus Digest . Subscribe and listen to the Nexus Podcast here . The podcast and artwork embedded on this page are from Claroty, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.
Transcribed and scored by The B2B Podcast Index.
Speaker A: All right, welcome to episode four of uh, Nexus Digest. Dan Ritchie, the founder of the ICS Advisory Project and uh, a Day One Nexus contributor, joins us today. Dan, uh, and I are going to discuss an article he wrote recently that was titled From Inventory to Insight. And basically the article talks about how to leverage OT visibility to achieve concrete risk reduction. So it's great to see you, Dan. How you doing?
Speaker B: Doing well, thank you Michael. Great to be here.
Speaker A: Thanks. Yeah, thanks for uh, giving me a few minutes. I'm glad the audience is going to get to hear from you on this. Um, so let's talk about your most recent contribution. Really great stuff. It's going to be linked here, uh, in the video, uh, and I urge everybody to read it, share it internally. There's a lot of valuable information in here. So basically you start off talking how a lot of organizations get these asset lists from their tools, whatever they might be, and they kind of think of that as an asset inventory and you distinguish between the two. So tell me, I think it's a good table setter kind of question. How do you view the two in terms of differences?
Speaker B: Well, asset list is your basic enumeration of the, your devices, the IP addresses assigned to those devices, if they're assigned with static IP addresses, the physical location, device type, whether it's plc, hmi, historian, vendor, ah, model. But like getting into, like when you start to get into the asset inventory site, that starts to have like higher, highly more contextual data. Now we're looking at, you know, the firmware and software versionings associated with it. Are there um, specific um, advisories, vendor vulnerability advisories assessed attached to that, that are applicable to that asset? Are they been patched or not? Right. What the patch asset or they're not going to patch it, that's fine too. What are the compensating controls that are in place to protect it? Uh, what is the communications relationship between that asset, the data flow between that device and the, and the rest of the ot, uh, environment, um, whether it's communicating with another PLC or communicates only directly with the, with the uh, SCADA server. Then you got to look at uh, what's the criticality of that asset, you know, what's the process impact rating of it, Is it a crown jewel? You know, it's essential to that, to the uh, business, industrial operations or not, uh, what's the owner, who's the owner of that asset and the responsible party who maintains the operation and maintenance side, uh, process control engineer, uh, instrumentation control engineer that might be responsible for that Device uh, what vendor support status. You know we talked about whether this, it's um, whether it's an end of life product. So if it's end of life there's no longer patch support for it or end of service or that uh specific control um system uh asset is no longer supported by the system integrator or the company went out of business. That's very possible as well. And then you know when was the last time that asset was seen on the network. So there's a lot more to just having you know asset device list. So hopefully that's uh, um a help helpful distinction between uh the two, two pieces here.
Speaker A: Yeah. And how good are existing tools in providing all that context? I mean how much of that is automated versus manual I guess is what I'm asking.
Speaker B: A lot of it can be automated uh with a lot of the products that are out there. There's passive tools out there that can help do this asset identification uh such as like Wireshark, T Shark, you can use uh Network Miner. There's these are all like kind of open source products that you can help to start to build the, the um, the asset list and the rest of the asset inventory data you'd want to bring into it. Uh then you have tools uh that can help you start to identify the. The vendor M vulnerability uh data ics uh advisory project supports it. You can use CISA directly. You can go to the vendor's website uh for the asset. If they're still, they still exist. Then uh, you can also look at um using um that vendor to also help identify the you know what the most current firmware version that should be running on that software.
Speaker A: Right.
Speaker B: Identifying it um within the environment. Within your environment. You might be able to identify it through passive packet capture, full content um doing. Identifying the data flow between those networks. You can look at your flow data between uh and that can be done all passively using uh, your
Speaker A: um.
Speaker B: Your existing um uh network infrastructure. Um uh you can use um uh your logs from your, your your router here. From your router you can also look at your switch configurations. I mean their configuration analysis is very powerful and trying to fill these gaps and trying to provide that asset inventory picture. So um, I mean we could, I could go on probably a lot longer about this.
Speaker A: You in the article too you referenced um ciss's OT inventory guidance and you mentioned that inventories should be organized, regularly updated, physically validated. How difficult is that are those steps and, and how often are organizations actually going that, that extra mile? If it's an extra mile.
Speaker B: I wouldn't be able to speak directly on how um, how many like asset owners are actually uh, going in that direction. But I will say that CISA does a very good job providing the step by step guidance, although it might be high level, gives you the, a great starting point for uh, building your asset inventory. I want to say it very much aligns with you know, giving asset owners the foundational information to, to uh, to scope, you know, understand the objectives. Uh a point that I really didn't touch on in the last, last piece is like you know, how do you identify the uh, your crown jewels? And that a lot of that comes down to understanding what the uh, risk of uh, to that specific asset is to uh, you know, your organizations or business operations.
Speaker A: So that really becomes like a business impact discussion at that point.
Speaker B: Yeah, yeah. I mean it's classified by you know, function and criticality. Uh, um the cisa, um ot, uh asset inventory guidance hits on it as hard as like creating a taxonomy right of classifying by function and criticality. And then you know, another piece is you know asset inventories are an asset management in general is, is, is, is a living document, it's not a static document. So you looking at you know, managing that data, uh, and implementing a asset life cycle management, you know, tracking it to end of life, you know.
Speaker A: So m. Once you have that inventory, give me some examples of what it can be used to enable in terms of the rest of the security program. Obviously it's very foundational and you probably can't start anything else without a decent inventory and visibility into what you have.
Speaker B: But well I mean key point of having an asset inventory or is understanding what your organizational risk and then how to defend it and how you can actively defend it. Because now you have the ability to understand what the baseline configuration of those assets are. Uh, which is. So if there is something that does occur in your environment, if uh, your, the asset is a, is um, is manipulated in a way that is off its known baseline. You can identify that rather quickly. It helps tremendously in incident response uh because that way you're, you're able to really know for sure. You know there, there was, there was definitely a change made but who made the change, what was. You could, you can start to do the root cause analysis of understanding what happened. Uh because you know, uh, you know based off of like the known configuration that uh, something happened on the device that tampered uh with the current configurations. Like a set point was changed, a um, um connection or configuration to uh um. Devices that it normally does not communicate with, now is communicating with it or it's making connections out to uh a uh public IP when it should only be communicating on private IP addresses within the environment or it's communicating with a device that's never communicated with before. So having uh. That asset inventory allows you to detect uh. Possible indications of compromise.
Speaker A: And so just kind of as a last thought, I mean how do you. How continuous is this in. In terms of. As a, As a process, as an exercise? How do you keep it from being just kind of a point in time thing that really isn't useful? How. Just give me some advice on that in that direction.
Speaker B: I think that's more than. More than a technical, more than just a technical challenge. It's a, It's a people and process challenge. Right. And having a. Identifying uh. Those roles or responsibility that can enable and sustain the management of ah solid asset inventory.
Speaker A: Leveraging uh
Speaker B: technology to automate and reduce uh the amount of time it would be to uh. Gather and maintain but also develop a schedule that would address uh, what can't be covered by uh. Passive monitoring like a physical uh inventory that's maybe done annually to kind of help keep uh. This alive over. Over time. Also I mean uh. Some organizations um. Are contract out a lot of their um uh. Icsot, uh um uh operations and maintenance. So uh. Looking at their contract and seeing how that might help them um maintain and track their. Their asset inventory and hit on maintaining a baseline uh configuration ah information and ensuring that's documented. And maybe out of that uh they produce a uh uh file that can be integrated with the current asset inventory or uh. For management. It's the only way I think organizations could really stand top uh and manage uh risk because you know visibility only matters when it drives uh real and continuous uh risk reduction. Right, right. Small and medium OT environments. Security success isn't measured on you know, how many tools they have deployed and how many assets are discovered. It's measured by whether risk is actually going. Going down over time. Right. Uh, and also uh whether you know every alert, every scan, um, every uh. Asset should feed uh into like their cycle of prioritization and action and validation. Um, it kind of moves the organization from a posture of like hope to uh. One of ah resilience.
Speaker A: And that's the goal.
Speaker B: Right?
Speaker A: Resilience.
Speaker B: Yeah, it's, It's. It's not um. Something that uh. Is. Is hope's not a plan.
Speaker A: Yeah.
Speaker B: Having a plan. Having a plan is key to uh. Being successful uh in recovery in a lot of these situations.
Speaker A: All right, Dan, I think that's a good place to leave it. I want to thank you so much for coming on, and I, uh, appreciate the great work on Nexus. Always.
Speaker B: Likewise. Thank you for your time.
Speaker A: All right, Dan, Take care.
Speaker B: It.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.