In this week’s Pipeliners Podcast episode, Russel Treat welcomes back cybersecurity expert Clint Bodungen to discuss the importance of IT/OT convergence to support risk management in pipeline operations.

Listen to this episode to learn about how technology is enabling IT and OT to bridge gaps to manage risk, the differences between the cybersecurity needs for IT and OT, the role of CISOs providing executive level oversight for both IT and OT, and the role of compliance for both sides of the equation.

Ultimately, listen for an epiphany about the root cause of the differences between the IT and OT sides that could help solve this issue for companies.

IT/OT Convergence: Show Notes, Links, and Insider Terms

• Clint Bodungen is an ICS cybersecurity guru, the author of “Hacking Exposed: Industrial Control Systems,” and he teaches at the Gas Certification Institute (GCI). Connect with Clint on LinkedIn.
• IIoT (Industrial Internet of Things) is the use of sensors and connected devices for industrial purposes, such as communication between network devices in the field and a pipeline system.
• IT/OT convergence is the integration of IT (Information Technology) systems with OT (Operational Technology) systems used to monitor events, processes, and devices and make adjustments in enterprise and industrial operations.
• HAZOPs (Hazard and Operability Study) is a structured and systematic examination of a complex planned or existing process or operation in order to identify and evaluate problems that may represent risks to personnel or equipment.
• The CISO (Chief Information Security Officer) is an executive responsible for maintaining, protecting, and advancing a company’s information assets through the use of technology.
• The Iron Ring (known as The Calling of an Engineer) is awarded to professional engineers in Canada as a reminder of their obligation to protect the public through safe and ethical practices in their profession. The first ceremony took place in 1925.
• CISSP training is a form of training and education on quantitative risk analysis and risk management that focuses on identifying threats and vulnerabilities, while also implementing control.

IT/OT Convergence: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 45.

[music]

Announcer:  The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. Now your host, Russel Treat.

Russel:  Thanks for listening to the Pipeliners Podcast. We appreciate your taking the time, and to show that appreciation, we’re giving away a customized YETI tumbler to one listener each episode. This week, our winner is David Fernandez, with LOOP. To learn how you can win this signature prize pack, stick around to the end of the episode.

This week, Clint Bodungen returns to the Pipeliners Podcast to talk about the convergence of IT and OT, and its impact on risk management. Clint, welcome back to the Pipeliners Podcast.

Clint Bodungen:  Thanks. Good to be here again.

Russel:  We’re going to talk about IT and OT. I think probably most folks that are listeners understand what information technology is. Let’s start, maybe, why don’t you tell us what is OT, and how is that different than IT?

Clint:  OT, obviously the O stands for operational or operations. To most folks, that means the engineering side, the operations, or even production side of an industrial organization, whether that’s oil and gas, electric utility, manufacturing, or water, waste water.

There’s a whole cast of verticals under industrial that the O pertains to. That’s the manufacturing, the production, all the pipes, the pumps, the valves, the robotics, and everything that goes into making things, producing electricity or energy, or those kinds of things.

The T, obviously technology. That’s the technology that makes everything work. First of all, I have to say, my friend Tyler Williams, pretty well known in the industry, says, “You know, there really is no IT or OT. It’s just T. It’s just technology.”

We all understand what IT is, right? The technology is routers, it’s switches, and it’s computers. If you look at the OT, the digital part of OT, in a lot of ways, it’s the same. It’s routers, it’s switches, and it’s computers. What makes it different is the way that they’re used.

Let’s also expand that to mean embedded computers, little embedded computers and industrially-hardened computers that you don’t see in the IT, but they are still computers. However, they’re designed differently, and they’re more sensitive.

I think the biggest thing that separates IT from OT is that the process that they’re controlling, you’re no longer concerned with just protecting data or privacy. You’re protecting a process that can affect not only the business finances, but you’re protecting a process that can affect…

Russel:  Ultimately, it affects safety.

Clint:  Yeah. It affects safety, exactly.

Russel:  I’m a guy that I like to understand the history of technology, like where it comes from.

I’m old enough to remember when IT and OT were in different buildings on different mainframes so that all of the SCADA, telemetry, measurement, and all of that kind of stuff was actually on a completely separate infrastructure.

What’s happened is that over time, as technology’s evolved, improved, and got more robust, we took those mainframes, and those things went down to mini computers, and then they went down to pretty much everything’s running in a Windows environment.

You had the same thing happen where I’d go out to a measurement device, and I had one telecommunication drop connected for the real-time data to SCADA and another telecommunication drop connected to get the measurement custody transfer, and then those combined.

What’s happening now is that all of these specialized devices that ran embedded chip centric software at the remote, that stuff’s beginning to become — I’m doing air quotes now. I know you can’t see air quotes when you’re doing podcasting, but I’m doing air quotes.

Clint:  I see them.

Russel:  You see them in your mind’s eye, right? [laughs] They’re becoming computers as well. The start of that is when you drop an IP port on them. Ultimately, with edge devices and where technology’s headed, all that’s going to be Windows infrastructure.

That history has caused the technology to be largely the same, but the risk is really different. I think that’s the thing that is the primary difference between IT and OT.

I characterize this this way. If I’m working on an IT system, and I need to make an update or a change, I make that change at 7:00 p.m. on Friday evening. Everybody’s gone home. Nobody’s using the email, nobody’s using the accounting system.

I do the update then so if there’s a problem, I could fix it over the weekend before Monday when everybody comes back to work. Ideally, I’ll get it done Friday night and be able to have my weekend off.

Clint:  I think you hit the nail on the head. That’s the differentiator. The slash in IT/OT is risk.

Russel:  Exactly. If I’m working on an OT system, I make those changes first thing Monday morning so that if there’s any kind of problems or difficulty, all the people that need to be mobilized to straighten it out are already at work. They don’t have to come in on the weekend to get it going again.

All of those OT systems in our world, in the pipeline world, all those are 24/7. They need to be high availability, high reliability systems.

The slash is risk. That’s really it. That’s the distinction. There is risk on the IT side, but the OT risk is different.

Clint:  Exactly. I think when it really comes down to it, I don’t care what business you’re in, from industrial to retail, every business wants to know four questions.

It’s, “Where is and what is the risk to my business? What’s the likelihood that risk could be realized, and what’s the potential impact of that if it is realized?” Of course, let’s add the word consequence. “What’s the consequence of that?”

Then, “How do I deal with that risk with the resources that I have available to me?” That’s 3/4, 3.5 questions that every business wants to know.

Russel:  Right, and from a safety perspective, particularly from a process safety perspective, those questions are well understood. For those that do risk analysis and quantify that, they look at probability of failure and consequence of failure, and they are able to apply math to calculate risk.

The difference again, what does the slash represent? It’s the difference between the probabilities and the consequences of failure.

Let me ask this question, Clint. How is OT cybersecurity unique or different from IT cybersecurity?

Clint:  I think that’s an important question. One of the issues that we have whenever we see companies struggling with IT/OT convergence is it’s not so much a difference in technology, but a difference in nomenclature, I think, in terminology, because we know how to quantify risk in the OT. That’s exactly right.

In the operations environment, we’ve been identifying and managing risk in the forms of    whether you want to call it HAZOPs or a process hazards analysis or whatnot — fill in the blank risk assessment method for OT — we’ve been doing that for decades.

Now, whenever we start trying to add cyber to that, when you look at it, cyber is nothing more than yet another risk vector for the operations environment. For some reason, whenever we start inserting the cyber vector, and we start inserting this — I’m doing air quotes now — cybersecurity, everybody feels like that they have to change things up.

The important thing is is that it’s not different. We should not be doing risk assessments for OT any different than what they usually do in forms of a HAZOPs, except now you just have another risk vector, which is the cyber.

I think that if you can get the operations folks to understand that these risk assessments and everything that we’re trying to do in terms of cybersecurity, “Look, don’t think of it as cybersecurity. It’s just a HAZOPs with cyber as another vector.”

If you can get the IT folks to understand that these guys have been doing this for decades — it’s called HAZOPs — show them the HAZOPs and all the other risk assessment methods for operations, and show them that this is what you’re protecting. “It’s the risk, and this is how it’s done,” get them to understand that it’s not just cybersecurity for the sake of cybersecurity, and not all the threat vectors — another conversation, actually — not all the threat vectors are malicious.

Get them to understand that all you have to do is deploy the risk assessment where the cyber is another vector into what they’ve been doing for decades, I think you start to have convergence. You just have to make sure that everybody has an understanding of the common language and what it is you’re protecting.

Russel:  I agree with that. I think you have some pretty big challenges there. One of the challenges is the folks that are doing the operational risk assessment, and the operations people in general, are risk averse.

Change represents risk and unknowns. Doing something a different way represents an unknown or unquantifiable risk, and that’s problematic, right? For valid reasons.

The other thing I think you have is on the IT side, is that they are the speed of change in the IT world is an order of magnitude different than the speed of change in the process.

Clint:  I agree.

Russel:  That, just the speed of change is scary. I did the air quotes thing again. I do think that the speed of change is a factor that causes concern and anxiety for the operations folks. They like to be very methodical, and they’ve been trained through safety programs, process safety management approaches, and all of that, to be methodical.

The IT guys — and they may kick back on this, but largely, they’re not methodical. That particular difference is a problem.

What you’ve got to do is get the IT guys to understand the value and the importance of being methodical, and you’ve got to get the OT guys to understand that we’re not just going to do cybersecurity to limit your ability to do anything. We’re going to do it in a way that makes sense so that we manage risk.

Clint:  Exactly. Just one thing to add there. I think it’s important since we are talking about issues with IT/OT convergence.

I don’t want this to spin off into a separate conversation, but I think it’s worth noting that all that said, in order to help facilitate that in an organization, you need to have a pinnacle, top-down buy-in. You need to have someone at the C-level who has pinnacle responsibility over both sides, that has buy in to that concept.

Russel:  Yeah. You’re saying a mouthful there, though. The challenge is if I think about the chief operating officer and the chief information officer in a pipeline company of any size, those two roles have very different skills, experiences, and ways of thinking. This “bringing this together” conversation actually has to occur above that.

Clint:  What’s interesting — you’re right. It does at even a Board and CEO level, or even just Board level, really, you have to push it. However, I am seeing a new breed of CISO emerge in this industry, and I know a couple of them personally that, and a couple of them I work with at LEO.

For example, one of my friends, he worked in a CISO level position…

Russel:  Just a quick pause. CISO, for the listeners that don’t know, that’s chief security officer.

Clint:  Yeah, sorry. He worked at the chief information security officer level for a major oil and gas company, and he did this, I think it was along something like 10-18 years, or something like that.

I don’t know if he started with this knowledge, or he acquired it over time, but because he was at that pinnacle position over both the OT and IT in terms of security, he now has that skillset to be able to understand and converse with both sides, even as a top level liaison.

I’m seeing that more and more, where these C-levels that can put a foot in each and understand each. They’re still rare, but I’m starting to see that more and more, and I know a few of them, so that’s at least promising.

Russel:  I hadn’t thought about that, but that actually makes sense. You’re seeing things where these companies are establishing a relatively high-level operational excellence officer or chief security officer, which is kind of a new position, particularly in terms of the level at which that role exists in companies.

I think the thing that you and I are driving at — and I think that it’s important to understand — is that ultimately, safety, cybersecurity, physical security, and the infrastructure and systems around all that, that’s really what’s converging.

Clint:  Right, and by the way, just like I’m seeing that new breed of CISO — just to say it a third, different way now — I’m also starting to see a hybrid engineer.

I’m literally starting to see more and more professional engineers that are also well-versed in IT and cybersecurity, because of this convergence, because it’s yet still currently a hot career topic and career choice, and it’s under-served.

I do believe that as we move forward in the future — and hopefully not the too far future    that you’re going to see a merged career field and skillset to where you have dual capable CISOs and you have dual-capable, dual-skilled engineers.

Russel:  I think in particular, you’re going to see the universities that have automation programs, they’re going to have cybersecurity as a component of their automation programs.

Clint:  I agree, and…

Russel:  That’s already happening.

Clint:  Somebody’s probably going to flame me for this, but I think it needs to come from the engineering side, too.

I don’t think that you can successfully have IT programs, computer science classes, or computer science programs that adds in the engineering side. I think that you have to start in the engineering programs and add in the duality of the cybersecurity and the IT portion to that.

I think that the only caveat to that would be if you could pick a computer engineering course where there’s kind of a combination of both the IT and the engineering, the EE, that’s kind of what I…I’m not a computer engineer, but I think that’s where the convergence it.

Russel:  Why do you think that? Why do you think that, Clint? I agree with you, but I’m curious how you’ve come to that conclusion.

Clint:  The overall conclusion, or the computer engineering aspect?

Russel:  Why you think it’s an engineering role versus an IT role that we’re talking about.

Clint:  This is purely my opinion, but it’s based off of some experience. I’ve been in this industry, and I’ve been dealing with this issue since about 2003, which is more than 15 years. I’m dating myself again.

I’ve seen that the transition from one to the other seems to have been easier for the engineers to transition over to the IT and to the cybersecurity in IT than it has been for IT to transition into engineering. I think that has largely to do with the culture of engineering.

It almost goes back to your concept earlier. You said that engineers are more methodical. You can take methodical and teach a different “engineering message” / “engineering concept” to an engineer than what you can take an IT person and kind of retroactively impose the engineering culture onto them.

Russel:  [laughs] Here I’m going to tell you, I’m an engineer by education, and my degree’s in civil, and specifically in structural, so I went to school to learn how to build bridges and skyscrapers, basically.

I know a lot of civil engineers in pipelining that are not in civil engineering jobs. What engineering does as a program is it teaches you a way of breaking down problems in a systematic, thoughtful, thorough way. That mental discipline, that way of thinking, can be applied to many, many things.

I think you’re exactly right. Once you’ve learned that, you’ve kind of had that ground into your brain, you can take that, and you can apply it to pretty much any domain of technology.

Clint:  I think that’s also why I said that the caveat is if you’re in, instead of a computer science program, where they tend to be more data science-focused, the computer engineering programs — or even if you’re focused in the computer sciences, it’s going to be software engineering.

They implement that same methodical problem solving focus. I think the bottom line is an engineering mind is an engineering mind, no matter what problem you’re solving.

Russel:  There’s one other aspect, too, and that’s this, is that when you’re studying engineering in university, if there is a certain level of orientation around, what are the consequences if you, as a professional engineer, get it wrong?

In my world, there’s a number of videos that are out there that are bridge failures. In Canada, in fact, there was a bridge that was built, and it failed, and there were some people that died.

They take the steel, and when you get a PE in Canada, they give you a ring made out of the steel of that failed bridge as a reminder of the consequences of what you do, and the importance of doing it right. That way of thinking is kind of unique to the engineering curriculums.

Clint:  I think ultimately, that’s even why I made sure I additively threw in the word “consequence” earlier when I was talking about the three questions of risk that every business wants to know.

That is a concept — and I’ve found this to be over and over again — that when I’m talking to people about risk quantification, and they’re coming from an IT perspective, it’s amazing how I see the eyebrows raise, and the heads tilt back, and they have “aha” moments.

The typical IT risk quantification practitioners, they’re concerned with things that you can quantify, such as impact in terms of value and money, and these buzzwords when they say CISSP curriculum — “the annual rate of occurrence and the single loss expectancy,” etc., etc.

There are things that we in the operations world know that you have to consider consequence as an indicator to impact before you can even go down that road. It’s amazing to see the “aha” moment that you have when you start talking about consequence.

I think really maybe that’s where you start when you start talking about what’s the difference in risk, is that when you start trying to talk about this IT/OT convergence, is you start with enumerating the consequences and the impact when you’re talking to the IT folks. Maybe that’s a good training direction to go around.

Russel:  I think that’s right on point. I think that’s right on point that clearly on the IT side, people don’t understand consequence. I think on the operations side, it’s really more about they don’t understand possibility.

Clint:  There you go, yeah. I agree.

Russel:  Like how likely it is if you don’t do things right, how easy it is. That’s the disconnect. The IT guys, they talk possibility and don’t really talk consequence, and the OT guys, the operations guys, they think consequence. They’re much less thinking about possibility.

Clint:  That’s a great way to summarize that. I’ve never thought of it from that direction, but I think that’s exactly it.

Russel:  It’s not like it’s a zero for either side. It’s just that the focus on the operations side is much more about consequence than it is on the technology side.

It’s kind of like they’re coming at the problem from two different ways. If they could understand better how the other people are coming at the problem, then they’re going to work better as a team.

Clint:  We need Damon Wayans to pop up right now more than ever with the [falsetto voice] “message,” because — and not just in quotes — that’s a huge message.

That right there, you’ve literally just explained why we see over and over and over again the same argument of the IT guy being labeled as a Chicken Little saying, “The sky is falling.”

They’re telling the OT guys, “Well, this can happen, and this can happen, and this can happen,” and you have the OT guys saying, “Nope. Nope. Not gonna happen. Why hasn’t it happened yet?” etc., etc. That just explains that whole debate.

Russel:  Right. That is exactly right. It really is. It explains that disconnect. Wow, lookie there. We’ve just made an intellectual discovery on the Pipeliners Podcast.

[laughter]

Russel:  Let’s move to wrapping this up. What I’d like to do is kind of tie a bow around this, talking about compliance. How does compliance relate to this whole conversation? What are your thoughts on that question?

Clint:  I think that compliance has come to be a dirty word for a lot of people, and it doesn’t have to be. My thoughts are very simple on this. Compliance has come to be a check box exercise, and it’s also created a bunch of cliches such as, “Compliance doesn’t equal security,” etc., etc., etc., etc.

It’s gotten lost in the mix because of all of these cliches and it becoming a dirty word. I think that compliance can be a good thing in helping to achieve the goals of — and I don’t want to say cybersecurity. Let’s call it risk management, and I’ll tell you why in a minute.

I think compliance can help us achieve our goals if it’s done effectively. What I think is we need more effective compliance measures and regulation instead of compelling people that just want to check the boxes, and actually move further towards security or risk management.

That’s where we need to be. It needs to be done more effectively. How do we do that? How do we do compliance more effectively so it’s not a check box exercise, and it actually does equal security risk management?

That’s the key, is that you have to stop thinking of cybersecurity standards. You have to stop thinking of it as cybersecurity, and go back to what we originally talked about earlier, which is it has to start from operations, and it has to start with risk management.

If you focus your compliance and your regulatory efforts on actual risk management instead of just cybersecurity — because when you think about it, cybersecurity is only one element of risk management if you put it into the context that we’ve been discussing.

Cybersecurity is a symptom of risk management, therefore, if you focus your regulatory and your compliance efforts to gravitate towards actual risk management and not cybersecurity, then I think you actually move closer to solving a real problem that’s not single focused, and it’s pragmatic. You stop becoming such a check box exercise, and both sides can understand it.

Russel:  To me, Clint, this is actually a much larger topic. I like to frame it as operations excellence. Of course then, what is operations excellence?

It’s really you can define it a lot of different ways, but in this context, it’s every resource that the organization is utilizing to operate, is optimized for the outcome that we’re looking for versus of achieving that outcome, the risks associated with achieving that outcome.

It’s about looking at things comprehensively. What are the things that really matter in terms of moving the needle? That’s difficult if you take up pure compliance, because compliance becomes something I have to do, and consequently, the focus becomes getting it done versus compliance as a mechanism for me to audit my program.

Clint:  Right. Compliance is ultimately supposed to do two things. It’s supposed to be a guideline to help those that don’t quite understand how to get there, whatever “there” is.

Number two, it does, unfortunately, impose a bit of enforcement for those that don’t want to, so it compels those that don’t want to do it to have to do it.

Russel:  From a regulatory compliance standpoint, when it’s required by the government, it also kind of levels the playing field and sets, “At a minimum, these are the things you’ve got to do, if you’re going to be in this business.”

Clint:  Right, and of course, from a regulatory standpoint, it’s also meant for environmental and human safety, and all those kind of things because they set that standards baseline and everything.

Ultimately, I think the final message is that if you focus it towards risk management instead of cybersecurity, all of the sudden, you don’t have a difference between cybersecurity standards and operational standards in compliance and all of these different verticals of compliance.

If you look at it in risk management — because let’s get back down to the original concept. Why do we have compliance? It’s risk management, and so all of your pipeline compliance standards and guidelines, all of your cybersecurity guidelines, all of the sudden, they start to speak the same language when you talk risk management and not cybersecurity.

Russel:  It’s the unifying principle. It’s the unifying concept.

Clint:  Yeah. Now we’ve come to full circle. It’s a slash.

Russel:  [laughs] Clint, as always, this is fun. I love talking to you. It’s always fun when you have a conversation, and you kind of come to your own “aha” in the midst of that conversation, so this is awesome.

I want to say thanks for coming back, but before we wrap up, I want to kind of do my “What are the three key takeaways?” We’ll see if we’re in agreement about that.

I think the first key takeaway is that technology’s evolving. Our infrastructure that we use for operations is looking more and more like a computer infrastructure versus an automation infrastructure. That’s one thing.

I think the other thing is that there’s a disconnect. I think that’s probably the biggest takeaway of this episode.

There’s a disconnect between the cybersecurity folks and the process safety folks where process safety is looking at consequence of failure more so. The cyber guys are looking at probability of failure more so. That is a root disconnect in the overall conversation.

Then, lastly, this is all really about operations excellence, which is a comprehensive and effective and practical program of risk management. How do you think I did?

Clint:  Don’t forget I think the epiphany that we had was how IT looks at it from a possibility standpoint, and OT looks at it from a consequence perspective. I think that was the original epiphany that we had as to why this whole debate is all happening in the first place.

The final thing I would like to add is that as a result of all of this, I really am encouraged that I am seeing a merged interest. I’m starting to see merged skill sets in terms of what the C-level, the dual-capable and skilled CISO, as well as the dual-capable engineer.

I really hope that this starts to spawn more career fields that are dual-capable, and spawn interest so that this underserved industry kind of self-heals.

Russel:  I agree with that absolutely. I certainly think there’s a lot of reason to be encouraged by things going on in the industry. I’m hoping to get some episodes pulled together on pipeline safety management systems.

That is very much in alignment around this whole conversation we’re having, so for the listeners, be looking for that.

Clint, thanks again for joining us. We look forward to having you back.

Clint:  Thanks for having me always. Thank you.

Russel:  Hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Clint Bodungen. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing.

If you would like to support this podcast, you could do that by leaving a review on Apple Podcast, Google Play, or on any other smart device podcast app. You can find instructions for how to do it at pipelinepodcastnetwork.com.

[background music]

Russel:  If you have ideas, questions, or topics you’d be interested in, please let us 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.

Transcription by CastingWords