Podcast: Play in new window | Download (Duration: 17:56 — 12.3MB) | Embed
Subscribe: Apple Podcasts | Spotify | RSS | More
Manufacturers and producers across all industries know the challenges in keeping their operations cyber-secure. Industries such as pipeline transportation and electrical & gas distribution networks face additional challenges in the wide geographic spread of their operations and the need for reliance on public communications networks.
In this podcast, I’m joined by Emerson cybersecurity expert Steve Hill to discuss these additional challenges and ways the companies in these industries, suppliers, and federal regulators are collaborating to develop and implement best practices for strong cyber resiliency.
Give the podcast a listen and visit the SCADA Solutions & Software for Energy Logistics on Emerson.com and the AspenTech Digital Grid Management page for methods and solutions to improve your cybersecurity defenses and ongoing programs.
Transcript
Jim: Hi, everyone. This is Jim Cahill with another “Emerson Automation Experts” podcast. Pipelines cover a wide geographic area and require continuous monitoring for safe, efficient, and reliable operations. Today, I’m joined by Steve Hill to discuss the challenges pipeline operators face in keeping their pipeline networks cybersecure. Welcome to the podcast, Steve.
Steve: Thanks, Jim. Pleasure to be here.
Jim: Well, it’s great to have you. I guess, let’s get started by asking you to share your background and path to your current role here with us at Emerson.
Steve: Thanks, yeah. I’ve been in the automation and SCADA industry for about 40 years, started on the hardware design and communications that then moved over to software. And it’s nearly 20 years I’ve been with Emerson. I joined as part of the Bristol Babcock acquisition. My main focus now is working in wide-area SCADA as the director of SCADA Solutions for Emerson, and most of that’s working in the oil and gas industry, working with Emerson sales and the engineering teams and our customers as they design systems and products for the industry.
And also, alongside that, for the last few years, I’ve been collaborating with CISA. That’s the U.S. government Cybersecurity and Infrastructure Security Agency as part of the Joint Cyber Defense Collaborative.
Jim: Okay. That’s a nice, varied background. That’s really good for our discussion. So, what exactly do you mean by wide-area SCADA?
Steve: That’s a great question. There’s a SCADA system where the software is monitoring equipment across a very wide area. It might be a very large geographic area, like a pipeline or gas, or water distribution network, or perhaps a well field. I mean, some of the systems, for example, I was speaking to a customer last week who is monitoring an entire pipeline across Peru, and yet, their control centers are actually in Mexico. So, to do that kind of thing, the equipment is usually connected via public networks. You know, private networks don’t extend that far, and even the control centers may be widely distributed.
And as part of that, compared to in-plant control, there’s an assumption that your communications are clearly not gonna be 100% perfect. You’re gonna lose communications either momentarily, like with cellular networks, and when, for example, like we’ve got in Texas this week, with natural events like hurricanes can cut communications for hours. But because these systems are all critical infrastructure, such as pipelines or electrical distribution, the actual operations, the process, must never be interrupted. Today, we’re talking about cybersecurity, and that same sensitivity is why these systems are now the target to some of the most sophisticated cyberattacks.
Jim: Okay, that gives a picture of the breadth of these types of SCADA systems, and you had mentioned you’d work with CISA, the cybersecurity infrastructure defense agency, and the Joint Cyber Defense Collaborative, which I’ll just call JCDC for short. Can you give some more examples on that work?
Steve: Yeah. Really, I could give you a bit of background. Probably many of our listeners know that there’s been several successful cyberattacks against critical infrastructure over the last few years. Probably the most famous in the pipeline industry was an attack that’s referred to as the Colonial Pipeline attack. That was actually a criminal ransomware attack that resulted in gasoline and jet fuel shortage across the Eastern U.S. for several days, and that was criminals basically trying to get money. And it was almost a random attack, it wasn’t targeted.
However, there have been actual state-sponsored attacks, and probably the one that was most successful was prior to the Russian military attack against Ukraine. They actually instituted several successful cyberattacks against the Ukrainian power grid. And very concerning is, in recent months, the U.S. infrastructure, including pipelines, have been successfully infiltrated by a group that are called Volt Typhoon, who are thought to be from the People’s Republic of China. So JCDC and CISA are working hard to really counter and protect against these threats.
Jim: Wow. Well, that’s clearly a huge concern. What is the JCDC doing to address these challenges?
Steve: Well, in 2023, so last year, JCDC facilitated the development of something called the Pipeline Reference Architecture. Basically, Emerson, alongside other industry vendors and also pipeline operators, participated in the development of this Pipeline Reference Architecture, which I’ll refer to as the PRA. It’s a fairly short document that outlines the design and operating principles for SCADA systems in the pipeline industry. And one thing the government is keen to point out, it’s not a regulatory document, but it does set out the best principles and is intended as guidance for the industry. Really, they want to work with the industry to come up with best practices.
Jim: Well, it sounds like this PRA is another set of standards to address cybersecurity. Why is another document needed in the industry where a bunch of standards exist now?
Steve: Yeah, that’s a question I and other members get asked quite a lot. The main reason is that wide-area SCADA represents a very different set of challenges to traditional SCADA, which we refer to as inside the wire. So for example, a refinery or a manufacturing plant, everything is in one location. But as I mentioned before, wide-area SCADA has got a very wide displacement, physically. It also actually has a lot of remote field workers. There may be folks working on that system hundreds of miles from base, and you’re also using communications networks that are not even owned or operated by the owners of the pipeline. Though this PRA is really intended for the pipeline industry, clearly, it’s applicable to almost any wide-area SCADA, that’s water or electrical industry as well.
Jim: Okay, that makes sense. So those are definitely challenges that don’t exist for more automation systems, as you say, inside the wire. Tell us more about how the PRA addresses these.
Steve: Well, the big thing is segmentation, basically, taking the network and splitting it into different levels that represent different areas of the operation. For example, the internet would be what’s referred to as level zero, and moving all the way down to the bottom of the network, that’s level nine. And the levels in between that represent different levels of trust. Now, those who are familiar with cybersecurity and SCADA are probably familiar with something that is called the Purdue model, which I think first came out in the late 1980s, and that also splits up SCADA and control networks and actually business networks into different levels. However, when that came out, the internet was in its infancy. No one would ever have used the internet or even really public IP networks for their connectivity. So it doesn’t really take into account many of the things we take for granted today in these systems.
So the PRA is intended to expand and take into account the reality that, for example, some of this critical data will actually be transiting across a public network, right? And in order to achieve that with this segmentation, we’re using a concept called Defense in Depth, right? And as you go down the different levels of the network, the assumption is you can trust each item on that network better. So, for example, on the internet, you don’t trust anything, but when you get down, let’s say, to the communications between an RTU [remote terminal unit] and a gas chromatograph on a local serial link, you might completely trust that. Now, it’s interesting, although that’s part of the PRA model, that does actually conflict with a security concept called Zero Trust, which is something that Emerson has really based our products on. But both zero trust and defense in depth are valid.
Jim: Now, you had mentioned a couple of concepts I’d like to explore a little bit more in there, and let’s start with zero trust. Can you explain that concept to us?
Steve: Oh, yeah. Yeah. Zero trust is a concept where any piece of equipment or software should trust nothing. Don’t trust anything else on the network, don’t trust the network to be safe, and it should not rely on anything else for protection. And historically, SCADA was protected, for example, by firewalls. You would use insecure products that were known to not be secure because they were developed perhaps 20 or 30 years ago and hide them behind firewalls, and that’s really how we’ve handled security today. But there’s a realization you can’t do that. So we now need to design products so that they don’t trust anything.
But the reality is many of our customers, Emerson’s customers and pipeline operators, have devices that were installed perhaps 30 years ago. That’s the typical lifespan of some RTUs and controllers in this industry. So as a result, when you get down to the lower levels of the network, zero trust doesn’t work. So you do have to have levels of additional protection. So for example, if you had a Modbus link, which is basically insecure almost by design, that should be protected by additional levels of firewalls and so on. But if you’re designing a modern product, it should be designed so it doesn’t rely on anything else. And that’s the concept of zero trust.
Jim: Okay, got it. So don’t trust anything. Everything must be proven out. And the other concept you talked about was defense in depth. So, what does that mean?
Steve: Well, the phrase is most commonly used where we’re talking about a network with multiple levels in. So when you come from, for example, the internet into your business network, you would have a set of firewalls and what’s called the demilitarized zone. And then when you go from your business network down to your controls network, you’d have another set of firewalls. So it’s multiple levels of protection. However, that same concept should be used actually within products as well. And, in fact, Emerson takes that very seriously with our secure development lifecycle certifications, IEC 62443, and how we design those products.
Jim: Well, that’s good. As you get those two and as you put in more modern technology, that it complies and has that cybersecurity built into mind there. So, can you give us an example of how it’s built in?
Steve: Yeah. That great one. If I take, for example, the Emerson FB3000 RTU, that’s a flow computer and a controller device that’s designed specifically for the oil and gas industry, especially for pipelines, an obvious concern is that that may be attacked externally to modify the firmware. Now, at the first level, the RTU itself has secure protocols. It uses something called DNP3, which would, in theory, provide access to the device. But then the firmware, when we issue new firmware, we put it on a website so we have protection of the website, we also publish a hash, which is basically a unique key that the customer downloading the firmware can check. It hasn’t been modified by anyone attacking the website. But then, when they actually put it into the RTU, so they’re updating firmware, the RTU will check that that firmware was developed by Emerson and was intended for that device. It does that by certifying certificates on the load.
Now, once it’s in the device and it’s running in the field, you might say, “Well, the task is done,” but there’s an additional level of protection. It will continually and on boot, check that firmware, make sure the certificate still matches, it’s not being changed. And if it has been changed, it will actually revert to a known good factory firmware that’s basically embedded in the device. So you can see that there’s really five or six different things all checking and ensuring that firmware in that device was not compromised. So basically, multiple levels within the device, and in addition, there’s multiple levels on the network. So the bad guys have to get through a lot of different levels to damage or compromise the device. And we’re trying to do that with everything we design today.
Jim: Yeah. And with modern cryptography and making any change completely will change that hash and everything and make it impossible to slip something in without it being noticed. So that’s really a nice thing.
Steve: Yeah. And the fact that even if it detects it, it then goes back to factory firmware, which may be a slightly older version, but your operation will keep running. It will keep controlling, which is a very nice feature.
Jim: Yeah, that’s a great example there. I guess, going back to the PRA, what else does it include other than the segmentation that you discussed?
Steve: There’s about 10 high-level principles that cover aspects of the design and operation of the SCADA system. And for each of these, there’s various examples and guidance on how to actually follow the principle in a real-world system. So, for example, there was a whole section on how to manage third-party devices in the contractors, because on a pipeline system, you’re almost certainly gonna have, for example, engineers from Emerson coming in from third parties. So it gives examples on the real-world aspects of operating the system.
Jim: Are there other examples from it you can share?
Steve: Yeah. One important one is when you’re designing the system, you should identify and document all of the different data flows that occur. And that’s, when I say data flow, communications or conversation between different pieces of equipment. So, for example, this RTU may communicate with that SCADA platform on this particular machine and may communicate with a measurement system on another machine, document all of those data flows, and then deny all other data flows by default. Then, after the system is running, continually monitor it passively. And if you see an additional communication, say, between two pieces of equipment that normally never communicated or didn’t communicate on a particular IP socket, flag that immediately, because it may be something that’s going on that was unexpected. It certainly was outside the original design of the system.
Jim: This has been very educational. Thank you so much, Steve. Where can our listeners go to learn more?
Steve: Well, really a couple of places. If you go to the CISA blog, which is at www.cisa.gov/news-events, there’s details there. The actual PRA was published on March the 26th of this year. And also, if you want to discover more about Emerson’s involvement in wide-area SCADA and the cybersecurity associated with it, if you go to Emerson.com/SCADAforEnergy, you’ll find some information there.
Jim: Okay, great. And I’ll add some links to that and to some of the other things we discussed in the transcript. Well, thank you so much for joining us today, Steve.
Steve: Not a problem. It’s a pleasure.
-End of transcript-
