In this episode of the Pipeliners Podcast, host Russell Treat talks with Nick Dresang, Director of Cybersecurity at Flow State, about how leak detection systems get their data and what that means for pipeline cybersecurity. They cover OT/IT integration across the Purdue Model, cloud deployment options, and the security tradeoffs operators face as more pipeline data moves off premises.

Why Leak Detection is Now an Integration & Cybersecurity Challenge Show Notes, Links and Insider Terms

• SCADA the supervisory control and data acquisition system that gathers pressure, flow, and pump data from the field and typically feeds it to the leak detection system.
• OPC a family of communication standards for exchanging industrial process data between field systems and software applications.
• OPC DA an older, DCOM-based version of OPC used for serial-level communications; increasingly difficult to run on modern networks and being phased out by Microsoft.
• OPC UA Unified Architecture, the newer OPC standard built for more secure, cross-network integration.
• MQTT a lightweight message-queuing protocol used for device telemetry, including from MQTT brokers that leak detection systems can subscribe to directly.
• Modbus a long-standing serial/industrial communication protocol referenced as a common source of integration headaches.
• Purdue Model (Purdue Enterprise Reference Architecture) the layered framework for segmenting OT networks from Level 0 field instruments up to Level 5 business/internet systems, used here to describe where leak detection integration happens.
• Defense in depth the layman’s description used for the Purdue Model’s approach of firewalling each network layer from the next.
• VNet peering an Azure networking feature that lets separate virtual networks connect directly, used here to link a customer’s cloud environment with Flow State’s leak detection platform.
• Mutual TLS a certificate-based authentication method used to verify the identity of devices and systems exchanging data.
• Data diode a hardware device that enforces one-way data flow, mentioned as one integration method for moving data out of a secure network.
• Microsoft Sentinel a cloud-based SIEM tool referenced for behavioral analysis and flagging devices that act outside of normal patterns.
• Pipeline cybersecurity requirements the federal cybersecurity directives that pipeline operators must follow; discussed as performance-based rather than prescriptive (see note above on agency attribution).
• Nested virtualization running a virtual machine inside another virtual machine, described as a way to isolate a Linux-based workload from an operator’s native environment.
• Containerization packaging software so it runs as an isolated process, discussed as Flow State’s platform-wide deployment approach.
• Docker Hardened Images minimal, security-focused container base images built to carry little to no known vulnerabilities.
• FIPS Federal Information Processing Standards, referenced in connection with certified, low-vulnerability container images.
• CVE (Common Vulnerabilities and Exposures) the standard system for identifying and tracking known security flaws, referenced regarding the current pace of disclosed vulnerabilities.
• CISSP Certified Information Systems Security Professional, a cybersecurity certification Nick holds.
• Negative pressure wave a physics-based leak detection method mentioned as an example of an alarm source that can be ingested directly into Flow State.
• AI-generated code risk (“AI slop”) the conversation’s term for functional but insecure or unscalable software produced quickly with AI coding tools.

Why Leak Detection is Now an Integration & Cybersecurity Challenge Full Episode Transcript

Speaker: Welcome to the Pipeliners Podcast, episode 458, sponsored by Flow State, providers of pipeline leak detection software built to remove barriers and empower operators. Flow State helps teams detect anomalies, reduce false alarms, and improve response with practical tools designed for diverse pipeline operations. Learn more at Flow State Solutions dot AI.

The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. And now your host, Russell Treat.

Russell Treat: Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time, and to show that appreciation, we give away a customized Yeti tumbler to one listener every episode. This week our winner is Ben Carlisle with Southern Star Central Gas Pipeline. Congratulations, Ben. Your Yeti is on its way. To learn how you can win this signature prize, stick around till the end of the episode.

This week we’re going to speak with Nick Dresang about how addressing integration and cybersecurity is critical in leak detection. Hey, Nick, welcome to the Pipeliners Podcast.

Nick Dresang: Hey, thanks, Russell. I’d be happy to be here.

Russell Treat: Yeah, so I understand you got voluntold. You were going to be a guest on the podcast.

Nick Dresang: Yeah, yeah. When your CEO says, “Hey, you get to do this really fun podcast,” you just go, “Okay, great, that sounds fantastic.”

Russell Treat: Well, there are many people on my team that would empathize with you, because I have recruited many of the people on our team to be on the podcast and kind of dragged them kicking and screaming. But everyone that’s ever done it, they always come back and say, “I’m glad I did it.” So hopefully that’ll be your experience too.

Nick Dresang: I’m looking forward to it.

Russell Treat: So I asked you to come on to talk about leak detection, integration, and cybersecurity. Before we dive into that, tell us a little bit about your background, what you do, and maybe a little bit about how you landed in that job.

Nick Dresang: All right, I’ll give you the abridged version. I’ve been in IT/OT cybersecurity since I was about fifteen. I started working for a local municipality here in town, and I’ve kind of been at it ever since. I got my master’s in cybersecurity, have a plethora of certifications, CISSP, all that fun stuff. About five or six years ago, when I was transitioning careers, Flow State was hiring. It seemed like a really good fit, so I moved over here. I quickly moved from cybersecurity analyst to director of cybersecurity for the company, and have done tons of OT integrations, IT integrations, and a lot of cloud work. I’ve been at it for, I don’t know, forever, it feels like now.

Russell Treat: Yeah, I’m old enough to remember when nobody thought about cybersecurity. They were just complaining about the computers.

Nick Dresang: One hundred percent. When it was back in the NT4 days, it was like, cool, we got networking, great, that’s awesome, we can get A to B, and that’s it.

Russell Treat: Right, right, right, exactly right. So did you work on the operator side before you went to the software vendor side?

Nick Dresang: So when I was at the city, I worked on a lot of different OT networks. They had a regional water treatment plant, a solid waste plant. So I was really exposed to the industrial control side of things. I was prepped for that.

Russell Treat: Yeah, so you’ve been doing critical infrastructure for a long time.

Nick Dresang: One hundred percent.

Russell Treat: Awesome. Well, you know, it’s interesting, I’m actually the cyber officer for our company. I manage all our cyber program stuff. I view it as one of the primary things that, if it’s not done well, could cause us grief I might not be able to recover from.

Nick Dresang: One hundred percent. It’s a killer if it’s just ignored.

Russell Treat: I’ve done a number of podcasts on cybersecurity. One of my favorites, in fact probably the most listened-to episode I ever did, was just me doing an episode on what every pipeliner should know about cybersecurity. And it was really more about personal cyber hygiene than ICS cyber hygiene.

Nick Dresang: That’s way cool. Yeah, I mean, that’s really where it starts for most of it. Like, how are you taking care of all of your best practices as an employee, let alone in the company itself?

Russell Treat: So yeah, well, let’s start by talking about what kind of data leak detection needs, what leak detection does, and how you get that data, because that’s kind of the fundamental integration issue, right?

Nick Dresang: Yeah, absolutely. Let me put the right optics on it. The only leak detection company I’ve ever worked for is Flow State, so I can speak from that perspective. But we use pressure, flow, pump information. Depending on if it’s compressible, we might have pressure or viscosity, etc., of the fluids, and all that stuff obviously starts out in the field. Getting that back in and ingested into the system can be quite a hurdle. We tend to get that either inline or after the fact with most SCADA systems. SCADA will ingest that data, whether it be OPC DA, OPC UA, MQTT, whatever, and we’ll subscribe to that same data either coming out of SCADA, or in some scenarios where there’s an MQTT broker, we’ll subscribe straight to the broker that’s listening as well.

Russell Treat: So I’m going to decode this a little bit for listeners that might not know what we’re talking about here. OPC is a method of communications, gosh, I don’t even remember what it stands for. Open Process… Framework?

Nick Dresang: Yeah, it’s interesting, because that’s actually leveraged off an old legacy Microsoft technology. It was OLE for Process Control, object linking and embedding. That’s old, old stuff. OPC DA is older than OPC UA. OPC DA is kind of DCOM-centric communications, so serial-level communications. UA is Unified Architecture, and that’s a newer standard. It’s not new anymore, I remember when it was brand new, but it’s a newer standard that provides additional levels of security and effective integration across networks, which OPC DA is not necessarily very good at.

Russell Treat: And then MQTT is kind of state-of-the-art for communications. That’s message queuing… transmission and something, I don’t remember.

Nick Dresang: Yeah, essentially they’re all message frameworks, between MQTT, and actually, I forgot Modbus, which is always a good one to know.

Russell Treat: I don’t want to talk about Modbus. I’ve spent too much time talking about Modbus in my career, particularly about why it ain’t working.

Nick Dresang: Yeah, I think we’ve all lost some hair in that chat. If you want to get really geeky, then you talk about Modbus, and you talk about high and low word and what’s the offset.

Russell Treat: Yeah, I think I’ve got gray hair from all of that. So anyways, you guys are supporting a plethora of ways to get the pressure, flow, and various status information around valve positions and pumps and such, that would impact what you’re doing to process the leak detection algorithm.

Nick Dresang: One hundred percent. Yep. You turn the pump on, that obviously creates a bit of an imbalance, because you have a built-in pressure as the pump’s running that builds up the line. We’ve got to figure out the offset. There’s check valves, etc., along the way. You need all of that information to have a complete picture of what the pipeline’s doing.

Russell Treat: Yeah, exactly. So typically, in my experience, leak detection systems are installed on-prem, so that integration happens within a level of the Purdue Model, and at that level, that integration is relatively straightforward, because I’m not cutting across a firewall or that kind of stuff. I’m right next to the SCADA machine on the network, I’m just getting that data.

Nick Dresang: Right, yeah. Normally at that L3 layer.

Russell Treat: Yep. And normally that data is going a single direction.

Nick Dresang: If anything’s coming back, it’s the alarm, raising the alarm.

Russell Treat: Totally agree. So I understand you guys also run your software in the cloud for some customers.

Nick Dresang: We do, actually. We have some larger customers with on-prem installations, air-gapped and all that other fun stuff. We have a chunk of customers in the Azure cloud.

Russell Treat: Okay, so that’s interesting. So what comes up for me is a question there: if you have a customer in the Azure cloud, are they building their own cloud infrastructure and you’re running kind of pseudo on-prem within their cloud, or are you running leak detection within your cloud and integrating with their network?

Nick Dresang: Well, yes to all of that. We’ve got some customers that have their own Azure instance, and we’ve done a myriad of integrations that way. So you can do things like VNet peering, where you can kind of coexist at that Purdue Model 3.5, and you can peer across VNets and let data come over into a secure container on our side. We can deploy that stuff on your guys’s cloud, and essentially, from our perspective, that’s really no different than if it was an on-prem install.

Russell Treat: So the thing that comes up for me with that, Nick, is it’s fairly simple, it’s fairly easy for me to visualize how I’d move the data one way from the SCADA system through the firewall and out to the leak detection system. What’s not clear to me is how I would move that data back into the SCADA system. I would think that if you’re doing that, I’m trying to frame a question here, so bear with me a second. I would think if you’re doing that, then typically you would have a separate screen on the controller’s console that was the leak detection screen, and I’m able to see it, but it’s disconnected from the SCADA system.

Nick Dresang: Again, I feel like I pride Flow State on the idea of being incredibly flexible. We have a myriad of ways. There are customers that will have a separate console that’s hitting the Flow State GUI and interfacing with us that way through the cloud. We have other customers that, for their integration, have a polling agent on the inside, typically on that layer-three level, reaching out and just downloading, so there’s not a way for anything to come into the secure network. It’s as if they were pulling additional OPC UA telemetry, as if it was another pipeline item. And we’ve also got customers where we have a data diode in there and they…

Russell Treat: Oh, wait a second, I’ve got to back up. So again, for the listeners, we had talked about what the Purdue Model is. The Purdue Model is a model for industrial cybersecurity inside the operational technology network. In layman’s terms, it’s called defense in depth, and it’s just that I firewall the instruments from the PLCs, I firewall the PLCs from the communications to the SCADA, I firewall the SCADA, and then I firewall from SCADA to the business, and then a firewall from the business to the internet. So five levels in the Purdue Model, starting with zero at the instruments and coming up, five being the internet. So that’s just a definition for people listening to this.

So what I heard you say, you talk fast, man, and you use a lot of buzzwords, which is cool, because I’m tracking with you so far, but I might have to ask you to slow down. Anyways, so what I heard you say is we can look like a PLC feeding data into the network at level one.

Nick Dresang: Absolutely. Yep, that’s exactly how.

Russell Treat: So then obviously wrap a ton of security around that.

Nick Dresang: So you’re right in Azure, VNet peering, firewalls, whatever, mutual TLS with certificates. There’s a million ways we can make that rock hard, that we don’t have to worry about penetration into that layer zero coming back up.

Russell Treat: Right, but that’s interesting, because I wouldn’t think about integrating that way. It’s an interesting approach.

Nick Dresang: Yeah, and like I said, we have a lot of flexibility in that manner. We have some customers that are okay with an agent reaching out, hitting an API on our LDS system, and then getting the alarms from the API, and it injects it in. I know we’ve got an integration with POEMS, where POEMS pulls the data down and ingests it that way.

Russell Treat: So it just depends on the customer. We pull in the alarms and do the alarm analysis.

Nick Dresang: That’s right, yep, depends on what the customer wants, really.

Russell Treat: Anyways, it’s interesting to me that you’re contemplating that level of flexibility. I mean, it makes a lot of sense that the data going to the leak detection system would come from level three, but the data coming back would go to level one. That’s a little bit of a brain freeze, but it makes perfect sense, right? Because when you talk about the data that the controller needs to be able to operate the pipeline from a leak detection standpoint, it’s just like the leak detection system kind of logically is a PLC.

Nick Dresang: Yeah, exactly. And it all comes back to the customer’s risk appetite, whether they’re willing to have that level of integration.

Russell Treat: Awesome.

Nick Dresang: Again, we have some where they want data to come out, but they just want text messages and email alerts, and they don’t want that level of integration back to the SCADA system, but they’ll have it running on another console.

Russell Treat: And that’s the other thing I think that’s true, is while all these pipeline operators are all having to follow the same cyber standards coming out of, oh my goodness, I’m spacing on that particular TLA, but the new D.O.T. cyber requirements for pipelines that are relatively new, they all have to follow the same cyber requirements, but those are all performance requirements. The guidelines originally came out, they were specifications, and they changed them to performance requirements. And what you find is there’s a lot of diversity in how these operators set up and run and secure their networks.

Nick Dresang: Absolutely, yeah. There’s a million different colors, and it’s kind of one of the things, like I said, we pride ourselves on that. We can kind of sit in all these niche, different ways that it works with everyone’s risk tolerance and their specific network needs.

Russell Treat: Yeah, that’s a really interesting conversation, because I haven’t actually dug deep into one of these conversations like this in a while. And kind of what you’re opening up for me in this conversation is, well, I’m a big, you know, I did a lot of systems integration in the past, and one of the things I learned is you wanted to come up with one way of doing things and do it that way, because if it was different for every customer, it became very hard to control costs.

Nick Dresang: Yep, right.

Russell Treat: Because the level of effort is different for a vendor providing a product, because you have different ways to realize or recover that cost, versus somebody just doing project work. So anyways, this is scrambling my brain a bit. I’ll just say that, because my answer to these things has always been: do it this way, this way works, this way is effective, this way is inexpensive, do it this way.

Nick Dresang: Well, one of the advantages it gives us is there’s a lot of our customers that have additional pipeline telemetry that they can’t get back in traditional means. Maybe they can’t get that VPN tunnel set up, or they can’t get wireless communication, but they can get a cellular connection, and maybe it’s on the public internet. If it’s strictly related to leak detection, we can ingest that data and bring it in, and they don’t necessarily have to have that pathing all the way back to their SCADA system. So it has offered a lot of our customers the ability and flexibility to bring in newer technology, because it’s leak detection-specific and it’s not necessarily something they see in SCADA, so we can ingest that too. And now the burden of how do we get this into our secure network without opening a door is kind of alleviated, because we’re able to ingest that in a secure manner, but it’s not affecting that level zero, one.

Russell Treat: So let’s talk about a specific, because I think that’d be helpful for me, probably for the listeners too. So what you’re saying is that if they have additional data that they want to ingest specific to leak detection…

Nick Dresang: Yep.

Russell Treat: So, for example, things like certain strap-on flow meters or certain pressure transmitters that they don’t need to operate the pipeline, but that help provide fidelity, reliability, and sensitivity to the leak detection system. Then, by taking the leak detection system out of their network, you can feed all that data in direct.

Nick Dresang: One hundred percent. We have a partner that has a cellular-based pressure sensor, we can feed that straight in and they don’t have to worry about getting that in. We have a customer that uses, I think the name of it is Watchdog, I don’t mean to plug anybody, but we can feed that data in, it kind of removes that layer of: well, how do we get into SCADA? Well, if it’s not necessarily operationally critical for the pipeline and it’s just leak detection, feed it right into us, we don’t have to worry about it.

Russell Treat: So that raises an interesting question. If I were running negative pressure wave and I wanted to bring in the alarm indications from negative pressure wave, could I bring that into Flow State, or is that outside of what you do?

Nick Dresang: No, absolutely.

Russell Treat: So you could take into Flow State some other kind of direct leak detection device and bring that alarm directly into Flow State?

Nick Dresang: Absolutely.

Russell Treat: Well, no, that’s fascinating.

Nick Dresang: Yeah, so it kind of gives you that one-stop-shop appeal, of we can bring everything in and culminate into one giant system for you.

Russell Treat: Yeah, that’s kind of fascinating, actually. I mean, you’re twisting my brain, because what you’re doing is opening up a lot of possibilities and opportunities that are outside of anything I ever thought about.

Nick Dresang: Yeah, and with that comes, obviously, because it’s kind of the theme of the show, right, the cybersecurity piece of it. There’s a lot of cybersecurity challenges to ingesting all those things. So we’ve done things where we do mutual TLS, so you’re doing certificate checks to make sure the device says who it is. But we’ve also done things where we use things like, Azure has a SIEM store application called Sentinel, and we’ve done it where we’ve sent devices into Sentinel, and it will keep behavioral analysis for that device, and if it acts out of normal, it’ll flag it and go, “Yeah, this device is not necessarily safe.” And one of the features we’re actually building into the next release is the ability to take a device off scan. So kind of the next logical evolution of that is, if a device is determined not to be a safe device, maybe it was tampered with or what have you, you could theoretically automatically take that device off scan if it wasn’t critical to the detection or flagging or whatever.

Russell Treat: Awesome. Yeah, the reason I’m babbling here is I’m getting blitzkrieged by Nick. I don’t know if everybody else is, but I’m getting blitzkrieged by you, dude.

Nick Dresang: It’s a good thing, okay?

Russell Treat: I don’t talk to people who live that deeply in this stuff very often, but I guess, you know, I’ve been working around leak detection probably for about fifteen years now, and I’ve done a number of deployments, never a Flow State deployment, but some of the other products. And I think because of that, I have certain preconceptions about what those things are and what they do and how they work. And it’s very hard to know what some new vendor is doing without actually getting an opportunity to work with a deployment, right? You understand that, right?

Nick Dresang: Absolutely.

Russell Treat: So what I’m hearing in this conversation is that it really goes to the topic, because it’s not just about how do I get the data to run the CPM. It’s about all this other data that’s related to leak detection but is not necessarily required for operations. Well, if I can move all of that out, I’ve got to manage the network and the comms and security for all that. That’s a huge lift for an operator.

Nick Dresang: Oh, yeah, yep. Our biggest challenge, actually, it’s funny, our biggest challenge is not the cloud, it’s on-prem, and the biggest challenge is Linux. The majority of our operation revolves around machine learning and running Linux, and you’d be surprised how many people are very standoffish about Linux. But we even have solutions.

Russell Treat: Actually, I would not be surprised. Linus Torvalds is probably upset.

Nick Dresang: We’ve done all sorts of, I call it VM inception, but you can do nested virtualization. We have a customer where they’re a little Linux-shy, and what we did is nested virtualization, and you could put Linux inside of a VM, inside of a VM, so it actually never touches the operational network.

Russell Treat: Right, but then you can still feed data in.

Nick Dresang: You can still containerize Linux inside of a classic, Windows environment.

Russell Treat: Yeah, exactly.

Nick Dresang: And then you remove the need for anybody to really worry about it, because it’s just a process running.

Russell Treat: Yeah, it’s just another piece of code doing its thing. The big leveler I always try to throw out there is, if you guys have any level of firewall, it’s probably running Linux, like Cisco’s on Linux.

Nick Dresang: I’m sure Fortigate is on Linux too.

Russell Treat: Yeah, but that’s not really the issue though, right?

Nick Dresang: Oh, for sure. The issue for an operator in their IT group is they need it to be something they understand, that they can manage within their skill sets, policies, and procedures.

Russell Treat: Exactly. So if I come in and I actually run a Linux OS, and I don’t have anybody on my team that knows anything about Linux, well, now I’m running a one-off. If I spend a little extra money and I containerize it inside of a VM, in a way that it’s just another app, then I don’t have to worry about it, then I have security questions.

Nick Dresang: Yep, right.

Russell Treat: But I don’t have support questions.

Nick Dresang: Yep, that’s the whole platform, actually. We moved to entirely container-based deployments about two years ago. Everything runs inside of a container.

Russell Treat: Man, you just throw this stuff around like it’s no big deal.

Nick Dresang: The really cool one, which is actually coming out this year, is Docker, the godfather of containers. They launched it, either early this year, late last year, Docker Hardened Images, these are FIPS-certified images, so they have zero vulnerabilities in them. They take a base, like a Debian or whatever, Red Hat.

Russell Treat: Basically, if I have a product and it may have defects in it, or may have security holes in it, then I can put it inside of a Docker container and effectively isolate those holes from the world.

Nick Dresang: Yeah, that’s exactly the whole point of it, is essentially they are certified to not have any vulnerabilities in them.

Russell Treat: Well, that’s interesting, that’s a little mind-blowing.

Nick Dresang: No, I’m exactly, so, looking at my face…

Russell Treat: He’s looking at my face, and he can see my wheels turning. Because what that means for a software developer is, it can change my approach to software development, so that I don’t have to spend as much money and effort on some of the secure software development standards. I still have to do some level of that, but I could back off a bit and make my standard implementation based on containerization and putting it all in Docker.

Nick Dresang: One hundred percent. And deployability now becomes super easy, instead of, you know, oh yeah, we’re running all this stuff. It’s a Docker container, you throw it in your Docker engine, you’re up and running.

Russell Treat: Yeah, interesting, really interesting. Well, here’s the question I want to ask: what mistakes would you say technology vendors and operators make when they’re looking at integrating with critical infrastructure?

Nick Dresang: Well, again, kind of speaking from Flow State’s perspective, the biggest kicker is under-scoping the amount of work involved in OPC DA. It is a bear. Getting DCOM to work in any sort of modern network is a nightmare, to put it easy. And I think internally we’ve become really good experts at managing that. But I think most vendors, from my perspective, if it’s not the communication protocol in terms of getting the right amount of time or understanding it with fidelity, a lot of times it’s the customer not necessarily having a great appreciation for how their assets run. You might have a pre-existing leak detection system, or maybe you have nothing, but it comes into your SCADA system, you know how to run it, you know how to turn it off. But that doesn’t necessarily mean, spinning up a new leak detection platform, you know what tags are your pumps, what tags are these pressure sensors, what tag is that check valve, is this the right tag, is it in this format, is it measuring barrels per hour or barrels per day?

Russell Treat: Well, yeah, and the other thing about OPC DA, I’m trying to think what year this was, probably a little over twenty years ago, this was before OPC UA was really proliferating, so there was a lot of old DCS and old SCADA systems that supported OPC DA but didn’t support UA. And I had to do an implementation to connect DA over a wide area network.

Nick Dresang: Oh, wow.

Russell Treat: So I ended up writing a twenty-page document that went through all the steps for how to install and configure DA in a way that it would talk. And in doing that, you actually had to kind of flip around some of the things that you wouldn’t want to flip around today because of security issues. You’re actually opening holes in the network to do that.

Nick Dresang: Absolutely. And it doesn’t help that, in Server 2025, Microsoft’s ripping out all the OPC DA, well, actually all the DCOM architecture.

Russell Treat: Oh yeah, they got rid of DCOM a long time ago, but there’s still a lot of remnants and other things.

Nick Dresang: Yeah, yeah, it is, it is, they are forcibly getting that out of the system.

Russell Treat: Well, that’s probably a good thing. Yeah, the things you’re alluding to, like I’m sure service accounts with local admin rights and all sorts of fun stuff to make… this is, I actually want to ask you this question, so this is something that’s been on my mind, not really related to what I asked you to come on and talk about, so fair warning, I don’t know if you’ll be ready for this question. But here: everybody’s looking at AI. Everybody’s doing stuff with AI, and you can go to ChatGPT or Claude Code or Copilot and so forth, and you can fairly quickly build an application using AI, and that application will work, it’ll be functional, it’ll look good. However, what I wonder is, how much of that stuff that’s going to get built by AI is just going to be fraught with security holes?

Nick Dresang: Hundred percent. Well, okay, I’ll be nice, ninety-nine percent, that’s my take.

Russell Treat: Because when I, I won’t mention the name to protect the guilty, but I looked at a guy who was a really smart guy, he built a very interesting application using AI, and I don’t remember which one he was using, but he was using AI to build it, and it did some really cool stuff. But when I started asking questions about scalability, about predictability, and the answers about cybersecurity, you know, all those kinds of things, it all fell apart.

Nick Dresang: Oh yeah. And the big kicker is, a lot of that AI, I think the industry term everybody’s adopted is they call it “slop.” But a lot of that AI slop, the cognitive load to be able to piece it apart and correct it and make it secure and safe and scalable and reliable, it’s immense. Like, to take something that somebody threw together, the level of work to get something functional is a fraction of what it used to be, but the level of work to get it from functional to reliable, what we’ve found is we’ve just switched it. Before, all the work was up front, you designed it, you engineered it, you constructed it, and then you did some testing on the back side, but that level of effort was small compared to the other. And now what we’re finding is, well, I get something functional, I can get a user experience, and I can get it to get kind of a good answer, but if I want it to really be right and do all the testing, that effort has actually exploded exponentially.

Russell Treat: Oh, one hundred percent.

Nick Dresang: Yeah, the cybersecurity world is imploding, exploding, whatever verb you want to throw in there, it’s busy. I don’t think we’ve ever seen as many CVEs coming out, exploit notices, and all that, than we’ve ever seen in the entire world of cybersecurity.

Russell Treat: Okay, well, you’re confirming, that’s actually a good way to kind of land this, is that while integration options are increasing, and while the technologies for doing that are becoming hardened, you still need to properly engineer things.

Nick Dresang: One hundred percent.

Russell Treat: Awesome. Well, Nick, this has been an awesome conversation. It was a lot more fun than I was thinking it was going to be.

Nick Dresang: It was a lot more fun than I thought it was going to be too. You’re scratching my geek muscle here.

Russell Treat: Good, good. All right, well, is there anything you would like to leave as a takeaway for the listeners, when they’re thinking about leak detection and integration and cybersecurity issues? How would you summarize, or what would you say your key takeaway is here?

Nick Dresang: I guess, well, there’s a bunch of personas there, right, from your engineers to your operators to whatever. But I guess if I was an engineer, the big takeaway for me is: how do I make my job have more time? Because I think we’re all kind of looking for and being able to lift and shift some of those responsibilities to providers like Flow State, where we have stuff in the cloud and we’re taking care of that security piece, the networking piece, the bringing the data in, ingesting all that stuff, it gives you more time and more availability to do what you’re supposed to be doing, which is running your side of the house.

So I guess going forward, as providers like Flow State and everything else that kind of comes around from all this AI innovation, that’s the route I would go. Everyone’s moving to the cloud, everyone’s going to Office 365, you’re shifting your cybersecurity risk to your vendors, which they’re happy to take. I mean, I’m very thrilled having Microsoft’s whole SOC team sitting behind me. If there’s some sort of issue, I can elevate it to their team of, I think it’s like fifty thousand SOC analysts, if there’s something I can’t figure out. And that’s amazing, like I can’t do that in an on-prem environment. I have to hope that their engineers are able and capable of playing the same game with me, so that we can get to the crux of something. Moving things into that more innovative, cloud-like atmosphere really opens the doors to do a ton in terms of integration, but it also opens the doors to do a ton in terms of security, and brings you into that next generation of leak detection.

Russell Treat: Yeah, you just said a mouthful there. And those people, those SCADA and OT folks, are going to hear all those things you just said, and they’re going to say BS. But I think fundamentally you’re right. I think the challenge is that we just haven’t built enough skills, understanding, and experience with the cloud yet for those OT professionals to understand how to leverage that technology. But that’s coming, and it’s coming like a freight train, and it ain’t going to get stopped.

Nick Dresang: Yeah, I think there’s an adoption curve for sure. It’s just kind of like Linux, it’s just going to take time. I know everybody’s moving that way, AVEVA, you name it, every company is kind of starting this cloud pattern, so it’s just a matter of time.

Russell Treat: No doubt, no doubt. All right, sir, well, look, thank you very much for your time, it’s great to talk to you. And we’re going to have to get you back, because, you know, about six weeks from now, this will all be different, and we need to talk again.

Nick Dresang: Yeah, sounds good. I mean, this time I guess maybe I’ll volunteer instead of getting voluntold.

Russell Treat: All right, man, thanks, Nick.

Nick Dresang: Yeah, cool, thank you.

Russell Treat: I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Nick. Just a reminder, you should register to win our customized Pipeliners Podcast Yeti tumbler. Just visit pipelinepodcastnetwork.com/win and enter yourself in the drawing. If you have ideas, questions, or topics you’d be interested in, or if you’d like to be a guest, please let me know, either on the Contact Us page at pipelinepodcastnetwork.com, or reach out to me on LinkedIn. Thanks for listening, I’ll talk to you next week.