This week’s Pipeliners Podcast episode features cybersecurity expert Pascal Ackerman of ThreatGEN discussing unique requirements and challenges for pipeline operators with host Russel Treat.

In this episode, Pascal explains his professional background and how he got into cybersecurity as a profession. He also explains the difference between traditional cybersecurity and ICS cybersecurity and how ICS cybersecurity directly applies to pipelines.

Additionally, Pascall gives advice on building a new network from scratch for pipeline operators and the importance of monitoring, analyzing, and responding to data in cybersecurity. Listen for more information on cybersecurity and pipeline companies.

Pipeline Cyber Security Requirements: Show Notes, Links, and Insider Terms

• Pascal Ackerman is a Principal Analyst in Industrial Threat Intelligence & Forensics and the author of Industrial Cybersecurity. Pascal is also part of the ThreatGEN team. Connect with Pascal on LinkedIn.
  • ThreatGEN is a virtual reality (VR) industrial cyber-physical range for physical threat response training, process improvement, and team events.
• ICS (Industrial Control Systems) encompass the control systems and instrumentation used for industrial automation and process control. These systems are used in oil & gas and other key industries.
• Cryogenics is the production and behavior of materials at very low temperatures.
• PoC (Proof of Concept) is an attack scenario that proves a vulnerability (a security flaw in software or hardware) can be exploited. 
• Patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it.
• PLC (Programmable Logic Controller) is an industrial computer control system that continuously monitors the state of input devices and makes decisions based upon a custom program to control the state of output devices.
  • NIC (Network Interface Card) is a computer hardware component that allows a computer to connect to a network.
• Uptime is a measure of computer operating system reliability or stability, in that this time represents the time a computer can be left unattended without crashing, or needing to be rebooted for administrative or maintenance purposes.
• IP Network is a communication network that uses Internet Protocol (IP) to send and receive messages between one or more computers.
• RTU (Remote Terminal Unit) is a microprocessor-controlled electronic device that interfaces objects in the physical world to a distributed control system or SCADA (supervisory control and data acquisition) system by transmitting telemetry data to a master system, and by using messages from the master supervisory system to control connected objects.
• Proprietary Protocols are a communications protocol owned by a single organization or individual.
  • DeviceNet is a network protocol used in the automation industry to interconnect control devices for data exchange.
  • ControlNET is an open industrial network protocol for industrial automation applications, also known as a fieldbus.
• Rockwell Automation is an American provider of industrial automation and information technology. 
• CPwE (Converged Plantwide Ethernet) is a set of manufacturing-focused reference architectures to help accelerate the successful deployment of standard networking technologies and convergence of manufacturing and enterprise/business networks.
• Purdue (PERA) Model is a 1990s reference model for enterprise architecture, developed by Theodore J. Williams and members of the Industry-Purdue University Consortium for Computer Integrated Manufacturing. 
• WAN (Wide Area Network) is a telecommunications network that extends over a large geographical area for the primary purpose of computer networking.
• HMI (human-machine interface) is the user interface that connects an operator to the controller for an industrial system.
• DMZ (Demilitarized Zone) is a physical or logical subnetwork that contains and exposes an organization’s external-facing services to an untrusted network, usually a larger network such as the Internet.
• VPN (Virtual Private Network) extends a private network across a public network, and enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network.
• OT (Operational Technology) the hardware and software dedicated to detecting or causing changes in physical processes through direct monitoring and/or control of physical devices such as valves, pumps, etc.
• NIST (National Institute of Standards and Technology) is a physical sciences laboratory, and a non-regulatory agency of the United States Department of Commerce. Its mission is to promote innovation and industrial competitiveness.
• NERC (North American Electric Reliability Corporation) is a not-for-profit international regulatory authority whose mission is to assure the effective and efficient reduction of risks to the reliability and security of the grid.
  • CIP (Critical Infrastructure Protection) plan consists of 9 standards and 45 requirements covering the security of electronic perimeters and the protection of critical cyber assets as well as personnel and training, security management and disaster recovery planning. 
  • DHS (Department of Homeland Security) is a cabinet department of the U.S. federal government with responsibilities in public security.
• Choke Point is a single point through which all incoming and outgoing network traffic is funneled, allowing to (packet) capture this traffic for inspection and aid in troubleshooting. Some tools that fundamentally rely on passive inspection (packet capturing) include:
  • Claroty is an integrated set of cybersecurity products that provides extreme visibility, unmatched cyber threat detection, secure remote access, and risk assessments for industrial control networks.
  • Indegy is a company that provides a comprehensive set of enterprise-class OT security capabilities with unmatched flexibility and scale, we help ensure the safety and reliability of complex industrial control system (ICS) environments. 
  • CyberX delivers industrial cybersecurity platform for continuously reducing IIoT and ICS risk.

Pipeline Cyber Security Requirements: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 92, sponsored by EnerSys Corporation, providers of POEMS, the Pipelines Operations Excellence Management System, SCADA, compliance, and operations software for the pipeline control center. Find out more about POEMS at enersyscorp.com.

[background 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. I appreciate you taking the time. To show that appreciation, we are giving away a customized YETI tumbler for one listener each episode. This week, our winner is Jessica Nesvold with Colorado Springs Utilities. Congratulations, Jessica, your YETI is on its way. To learn how you can win this signature prize pack, stick around until the end of the episode.

This week on the podcast, we have with us Pascal Ackerman. Pascal is a control systems engineer who evolved into a cybersecurity guy.

We’re going to talk about some of the unique requirements for cybersecurity and unique challenges for cybersecurity for the pipeline operator. Now, I’m going to warn you, we use the term ICS a whole lot. ICS simply means industrial control system.

I offer that to hopefully make this a bit easier to listen to and understand. With that, let’s welcome Pascal. Pascal, welcome to the Pipeliners Podcast.

Pascal Ackerman:  Thank you, Russel. Glad to be here.

Russel:  I’ve brought you on, because your experience is a little unique when it comes to cybersecurity. Maybe a good place to start would be just tell the listeners a little bit about your background, how you grew up in business, and how you go into cybersecurity as a profession.

Pascal:  I actually started my career as a controls engineer back in Holland in the late 1990s. At some point, I was involved with a project over in the U.S., and the company offered me a job. I took the plunge.

I came over in 2003 with a food and beverage industry company, started my career in basically designing automation systems for plants.

Russel:  Cool. It’s always interesting when you talk to people, because I actually, when I got out of the military, I spent a brief period of time working in cryogenics, as applied to food processing. I don’t know. I don’t think that’s a conversation for the podcast, but maybe it’s a conversation for another time, [laughs] just to compare notes.

How, in your experience, is business, classic cybersecurity different than ICS cybersecurity?

Pascal:  ICS cybersecurity differs from regular cybersecurity in that, basically, with ICS cybersecurity, you don’t have the luxury of implementing the latest and greatest in protective controls. For example, if you have a PoC, it was never designed to house the controls that would allow you to implement, for example, password checks, authentication, or authorization.

Apart from that, because the installations in an ICS are critical and often need to be, uptime requirements of 99.999 or better percentage, you don’t have the time to implement updates. You don’t have the time to do checks on it.

Furthermore, it’s hard to engage in these ICS installations with pen testing or risk assessment, because they’re very touchy devices often. If you start probing with regular IT scanning tools, they tend to bug up and to fall over.

It’s really hard to get to a security posture, or even to assess what your security posture is at the moment.

Russel:  That’s exactly right. The other, if you think about how quickly and how often Windows sends out patches, they send out patches pretty much every week. If you’re running a business computer, your IT department’s probably applying all those patches to all of your machines every week.

It’s probably happening when you’re not even aware of it. It’s happening overnight, that sort of thing. Where, with ICS, you might have a NIC card on a PLC, and that thing may have been out there 10 or more years, and never gotten any kind of software patch.

Pascal:  Or not even rebooted, sometimes.

Russel:  Yeah, exactly.

Pascal:  I have seen uptime timers of 5 to 10 years on some of these devices.

Russel:  Yeah. Absolutely. They’re designed to do that. They’re designed for that kind of reliability. There’s this, I think, fundamental disconnect between those systems that we can take offline and update, and take offline and update, and those systems that we really can’t take offline.

You made another really good point, is that a lot of the things we do to monitor, and test, and maintain in the business network, if we implement those same tools and approaches in the ICS network, we can actually call this process, upsets.

Pascal:  Think about it. If you have a database that you accidentally takedown on the IP network, oftentimes, there will be a cluster of databases, so the next one will take over. If you’re taking a PLC network card down, then that takes down the whole process. Most of the time, there is no backup for that.

Russel:  It’s never good to take a process offline, and not do that in a stepwise, thoughtful, or orthogonal way.

Pascal:  No. Trust me. No. [laughs]

Russel:  Probably all of us that work in automation, have some story about the one time we got the significant emotional event of not having it go the way we planned.

Pascal:  Yes. I have a story with a Koala Scanner that I had to have, and I had to try it on the ICS network. It didn’t turn out that nicely. We had some downtime after I played with it. [laughs]

Russel:  Exactly. We talked a little bit about how cybersecurity is different than ICS cybersecurity. My next question is, how is standard ICS cybersecurity different than pipeline ICS cybersecurity?

Pascal:  As we said, with an ICS network, because it’s often proprietary devices, and because it’s off limits, a lot of times, it’s harder to get to. At least with an ICS, with a typical ICS, it’s all enclosed in one building. You can put a firewall on the edge.

You can make sure that you do your due diligence, so that traffic between other zones within your business like I’m talking of, for example, the office network, is all restricted. You can control that, at least at that level. Within the ICS, it might be a little bit harder, but at least on the edge, you can still protect and monitor your device and your traffic really well.

With a typical pipeline installation, you have substations all over the place. You might have substations in remote areas, where people don’t show up for months at a time. If there’s anything to probe or if there’s anything to infiltrate, the attacker that’s focusing on that area will have all the time in the world.

I’ve seen pipeline stages where they have an access point sitting there. Basically, once you walk up there, you can probe, or you can scan, or you can try to break the encryption for that access point until you get in. If it takes a day, if it takes two days, or if it takes two months, it doesn’t matter, because people often don’t show up on there.

Once you do get on there…because the way most of these pipeline installations are wired up. Once you’re on the network, you’re on the internal network. That means that you can tie it back to the headquarters. You can tie it back to the core network for the ICS or for the pipelining ICS installation.

Russel:  Again, that’s a really good point, Pascal. I try to always come up with simple models in my mind, of ways to think about this. If I think about a process facility, I can limit the point of interface between everything that’s inside the process control system, and the telephone network, the Internet, to one physical wire, going into one port on a firewall.

I can’t do that in a pipeline environment. In a pipeline environment, I probably have as many connections to the public network as I have sites in my system.

Pascal:  Unless you spend the money to do leased lines to all this space, of which I haven’t found a single pipeline company yet.

Russel:  No. There’s all kinds of reasons for that. There’s all kinds of reasons. That’s actually a whole ‘nother conversation around communications and legacy versus future. Everybody’s like, “Well, IP, IP.” If I’m inside the company…this is the other way to think about it.

If I’m inside the company network, and I can use tools to access PLCs, and RTUs, and flow computers, and I can monitor and change configurations, and all of that because it’s an IP network, and I can do all that from my desk, that means that anybody who gets inside of your network can do the same thing.

Pascal:  Like I said, if this inside reaches out to all your substations, and all we need to do is infiltrate a substation, and we’re on the internal network.

Russel:  Exactly.

Pascal:  Then we can hop back to all the other devices, yes. Good point.

Russel:  That makes pipelining very unique, because there are so many points where this is true. It’s a challenge.

Pascal:  I’ve been involved with a pipelining organization who crossed the borders between Canada and the U.S., and that makes it a nightmare to do these kinds of things, because you’re involved with two different governments as well on top of everything else, you have to do.

Russel:  No doubt, no doubt. Before we get on the mic a little bit, we talked about your involvement with CPwE. Maybe you could unpack that a little bit for the listeners, talk about what that was and a little bit about the process and such, if you would.

Pascal:  That actually started when I was involved with a company in Seattle. We started implementing IT networks to replace proprietary protocols like DeviceNet and ControlNET.

Eventually, we started tying all of these systems together over IP because we could do it. Now we could go to corporate, and we could program all the PLCs in our remote plans.

I started thinking to myself, “If we can get to all of these devices, what’s preventing a virus or an attacker of doing the same thing?” I started researching the ways of how to implement that securely.

At the time — and I’m talking 2005, 2006 — there wasn’t very much involved yet. Eventually, I came to an organization called Rockwell Automation. 

They had done some of the work in this area. They had collaborated with Cisco and with bandwidth and come up with the converge plan by Internet models.

It’s basically a set of documentations where they describe recommendations on how to properly subdivide your ICS from the office network, and how to tie those together and make it so that you can safely get information out and safely still control them.

I ended up starting to work for them. I worked in the commercial engineering department that did the documentation cycles on that, so I helped them out for a while.

CPwE is something that everybody should look upon when you’re building a new network, because it helps you visualize through the Purdue Model, and helps you implement security as an architecture.

Russel:  That’s actually one of the places I wanted to go in this conversation, Pascal. You talked about, you said Purdue Model, so maybe you could explain to the listeners what is the Purdue Model?

Pascal:  When you start tying the ICS to the office network, and then sometimes the office network ties over a WAN to the business network, you’re already talking about three levels of the Purdue Model.

The Purdue Model is basically a model that describes how the interrelationships between the ICS network and the office network takes place. At the bottom line levels, there are always where your sensors and your actuators are sitting in the production floor.

Level one would be the HMIs that control those sections. Level two would be your SCADA system. Level 3 is basically your pipe database collection, and then level 3.5, which was an afterthought, is your industrial DMZ, or the OTDMZ that makes for a secure communication between the ICS network and the office network.

The office network is locally to a plant. For example, that’s where your email systems are sitting, and that’s also where your VPN, back to the level five headquarter network is.

That’s the Purdue Model in a nutcase.

Russel:  That’s actually really good. We’ll link this up in the show notes, and provide some resources.

One of the things that’s interesting to me about this conversation around the Purdue Model and conversion to Ethernet, and the reality of many connections to the public network versus very few, I think that very few operators actually have an accurate understanding of their inventory of equipment and their inventory of things attached to their network.

Pascal:  I believe that to be true as well. I blame our relationship with IT on that, because OT and IT —  OT being operational technology and IT being informational technology — a lot of times, these are two different entities within an organization.

When an OT person wants a connection to one of his substations, he goes to his IT guys and says, “Hey, I want to go from A to B.” They set it up, and however they do it, that’s the way it’s going to be. There’s no conversation of, “Hey, this is what I’m going to do. What do we recommend to add on for security in that?”

I think — and I’ve seen it — that the companies who do OT or ICS security the best are the companies that have a really, really well-defined relationship between OT and IT people. Sometimes that is the same division.

Russel:  That’s absolutely right. It depends on the nature of the company and the nature of its operation and its culture, and a whole bunch of other things. It goes to, there needs to be some defined policy and procedure, there needs to be some defined architecture, and there needs to be practice and controls around how the architecture is protected.

Said another way, I could design the perfect architecture, and I could deploy it, but if I allow people to just connect up how they see fit in the most expeditious way possible, then I might be able to get the work done, but I may be creating other risks.

Pascal:  You’re talking to an OT person here as well. I was in the same position, and whatever it takes to get those two things to talk to each other, whatever it takes to get my process running, that’s what we did. Security was an afterthought.

Russel:  That’s right.

Pascal:  We’re all guilty of that, and I think one…

Russel:  There’s lots of valid reasons why that’s actually the case, right? When you’re trying to get a process up and running and producing revenue, that can often be a very, very important thing to the health and sustainability of an organization.

Pascal:  Absolutely, and we’re not the only ones guilty of it. If you look at most people, most organizations that develop IoT devices or software, security is still an afterthought, because you get a deadline, and you need to get your product out to your customers. Guess what’s going to go first? Not security.

Russel:  Yeah, I know. It’s, “I gotta get the new shiny sparkly thing out to market,” and security is not shiny or sparkly.

Pascal:  No, unfortunately not.

[laughter]

Russel:  Maybe we could talk a little bit about documentation. Obviously, I mentioned the need for a comprehensive inventory. We’ve talked about the need for an architecture that’s understood. We’ve talked about policy and procedure. In your experience, how are organizations addressing those needs?

Pascal:  I’ve seen people adapt IT procedures for this where they basically go out and say, how do we do this in the office network? They take that data and they make an ICS spin to it. They start pumping out these rules and regulations for people to use. That’s one way to do it.

There’s also organizations who don’t have that and have to start from scratch. If you have to start from scratch, and even if you have to adopt it, you should go out and look at what the NIST cybersecurity framework is putting out there. They have great documentation that helps you start this process.

Russel:  I absolutely agree. I know that the API has currently got a committee working to update API 1164. That’s a recommended practice, if you will. One of the challenges here is there’s lots of frameworks. There’s NIST. There’s NERC CIP. DHS has some stuff. It’s really a bit challenging.

I guess, what I hear you saying is if I didn’t have anything as I’m starting from scratch, I’d probably start with NIST.

Pascal:  I’m saying that from experience because the NIST is not just a good standard to follow because it covers a lot of stuff but it has a really good structure of documentation that will help you get to where you need to be. They’re not just saying you need to have a two-factor authentication in place, for example.

They also have documentation that says how you should get there and how you control that and how you check on that. That’s why, in my opinion, NIST is for a specified CS and needed for pipeline organizations. That’s probably the best one to follow.

Apart from that, NIST also comes out with a profile that’s dedicated to food and beverage, for example. I don’t know if they have pipeline per se yet but they have other industries where they basically say, we have the NIST framework but now, we put a little spin to it if we add this set of documentations to it.

Russel:  Absolutely. If I were ACME Pipeline Company and I’m starting up a new pipeline operation and I’ve got to build a network from scratch, what advice would you give me?

Pascal:  The first thing would be design. Properly design your architecture with security in mind. With that, I mean, right off the bat, make sure you have all of your systems that need to be talking to each other in a zone. A zone is, like, a subnet on a network, for example.

Keep stuff that needs to be communicating together and make multiples of those zones. If there is a need between those zones to talk or to talk up, make secure conduit, make secure paths to do that.

Basically, what I’m saying is, design your architecture with security in mind. The benefit of doing zones like that is that you’re creating choke points for your traffic. If, in the long run, you want to put tools on there that help you do inventory, that helps you look at packet traffic, you have these choking points where you put a packet capturing device.

It’s easy to implement and it’s easy to capture everything that you need to get at the next level of security.

Russel:  I’m going to try and put this in my own language because I’m not a network engineer. It’s one of those things where, at this stage in my career, I’m trying to learn just enough.

[laughter]

Pascal:  Normally, what I refer to, then, is if you want to get onto a toll road, in order to get on the toll road, and nowadays, everybody’s got these passes or they take a picture of your license plate. You have to go to a choking point to get on the highway where everybody can be photographed or everybody can do their pass. That’s how you should design your network as well.

Russel:  This is even old school. It’s kind of how they do security in the surveillance and statecraft area. They departmentalize it. That’s what they call it. The people who need to talk together go into a room and they can all talk together. They all have the same clearance and they talk about the same things but getting out of that room and into a different room, that’s a whole different conversation.

It’s kind of the same thing. I want the things that need to talk together, put them in a zone and make it easy for them to talk together and limit the points where I go to another zone.

Pascal:  Correct. Which has the added benefit of, if everything in that zone can freely talk to each other and that’s one part of your business, let’s say there is something malicious going on in another zone. You cut the access between those two zones and, at least, it’s not going to cross populate. While you’re containing your business.

Russel:  Exactly. What other advice? You mentioned choke points. What’s important about choke points?

Pascal:  The choke point is where we can collect all of the traffic that needs to go out of the zone or up to the office network, for example. By having a choke point, it’s really easy to implement one of the new tools. You might have heard of Claroty or Indegy or CyberX. They have appliances that can sit there and sniff your traffic. They will tell you exactly what’s on the network.

They can start inventorying. They can start telling you, your controller over there has an old firmware. You might want to update it or it says, somebody on the network is using Nmap to scan all of your devices.

That’s not good. Having those choke points is a really easy way to add these bells and whistles, which is what I call security monitoring. In my opinion, it’s the second thing you should do when you design ICS security.

Russel:  The other thing about a choke point is, if I have a problem, I have the ability to shut that door and lock it. Now, I may have consequences about the ability to share data but I protect the network that’s behind the door.

Pascal:  Again, that’s where proper architecture comes in place. If you make sure that in that zone, there’s all of the devices you need to run that part of your production or your process or your organization. Then, you can safely shut that down.

Russel:  Exactly. Then, of course, the last part is monitoring. You mentioned a whole bunch of tools. That’s one of the areas where things are evolving very rapidly in cybersecurity, is the tools that are available and the capability of those tools for doing monitoring.

Pascal:  We have phenomenal tools right now. Like I mentioned, Claroty and Indegy and CyberX. These tools can give you an overview and in, like, two weeks’ time, they can start mapping out your entire network. That’s good and that’s bad because a lot of people will install these tools and say, “Okay, I’m secure.”

No, because you need to learn from these processes. They need to learn your traffic but you need to learn from them because once they start pumping out alerts, most people are going to get overwhelmed pretty quickly. They’re going to say this is not right and that is not right.

You need to have the processes and the training and the evolvement in place where you go and look at these alarms and you say, “This is relevant. We’re going to look at it,” and “This is not relevant, so we’re going to tune the tool to be quiet on that part.”

Even though you now have the tools installed, that doesn’t mean that you stop learning and you stop evolving. It is a continuous process that will go on forever.

Russel:  When people say monitoring, it’s not really monitoring. What it really is, is monitor, analyze, respond.

Pascal:  Correct.

Russel:  If I’m just doing monitoring, there’s no value in that. I have data. So what? You need to analyze the data and then, you need to be taking continual action to respond to the data.

Pascal:  Preferably by somebody who knows your system because if you’re a Rockwell shop or you’re a Siemens shop…Let’s say you’re a Rockwell shop and you get an alarm from that system that says, “Your Siemens PLC is vulnerable.” Somebody who doesn’t know what you’re running will start yelling and screaming and shutting stuff down.

If you don’t have a Siemens PLC in your building, then you can safely discard that. That’s an oversimplified example but it is important.

Russel:  You’ve got to be able to understand what the data that you’re collecting through monitoring, you’ve got to understand what it means to you and to your unique network configuration and your unique process.

Pascal:  To tie this quickly back to the pipelining business, I think monitoring right there with architecture is probably the most important thing you can do for your security because you’re not going to be able to protect all of your sites and all of your devices 24/7, all the time.

You can have a monitoring and alerting system in place that tells you if something is wrong and, at least, you can respond to it within a reasonable time.

Russel:  It’s a similar thing in physical security. Just because I have locks on all the doors and I have cameras on all the doors doesn’t mean I’m not going to have somebody come through the door. If I have locks on all the doors and I have cameras on all the doors, I don’t have any way to know when somebody comes through the door when it occurs.

If I don’t have resources available to respond to that when they come through the door, they’re just going to come through the door and I’m going to have information that helps me find them afterward.

[laughter]

Russel:  That may not be what I’m trying to accomplish.

Pascal:  A little spin on that, though. If you do see somebody in your camera system come to the door and you know that he has a key, now you know that you need to replace your locks because somebody, somehow, got a hold of your key.

The same with security monitoring. You notice something goes wrong and you detect that it’s because of your controller is not completely covering everything. Now, you have the ability to go in and adjust that.

Russel:  Just like putting locks on doors, the way I lock up my car and what I have in my car, the way I lock up my house and what I have in my house, and the way I lock up my office and what I have in my office, those things are all different. If I’m a jeweler and I deal in precious metals and gold, what I’m going to put in place for security is going to be different than if I’m a plumber.

Pascal:  Correct.

Russel:  Just because the interest that a nefarious character would have in getting my stuff is different. That’s the other thing to keep in mind in all of this is that as you’re doing this and you’re trying to figure out how to do it, you probably want to approach those things that are most valuable first.

Pascal:  Yes, or most vulnerable.

Russel:  That’s the calculus, right? How valuable, how vulnerable, and then, respond.

Pascal:  That’s where stuff like risk assessments come into place. You go out and you check your systems and you see which ones are the most critical. You check out which ones are the most vulnerable. Then, you make an educated decision on where you’re going to put your security budget.

Russel:  I want to try and wrap this up. As I do many times, I’m going to try and put together several key takeaways. You can give me a score after we’re done and see if I got it.

The first key takeaway is that ICS has got some different challenges and limitations, ICS being industrial control, than just my normal business systems, and pipelining has some different challenges than just ICS and specifically the fact that I have so many remote sites creating so many potential points of entry into my network.

The second is that I need to have an architecture. That architecture needs to be documented and understood and followed and controlled. The third thing is, in that architecture, I want to be very clear about where my choke points are, basically controlling where traffic moves between zones.

Then lastly, I want to monitor to make sure that the traffic’s going through the choke points and to understand what traffic’s going through those choke points and then take proactive action out of that.

I just summarized everything we talked about for thirty minutes. How did I do?

Pascal:  Just listen to the last part and it’ll be done.

Russel:  That’s why we put it at the end.

Pascal:  One little correction is that your architecture needs to be properly designed before you implement it.

Russel:  Yes.

Pascal:  Sit down, make a proper drawing, go to the experts, talk to people and make it to your specific needs with security in mind, so yes.

Russel:  Well, that sounds perfect. Hey, Pascal, so if somebody wanted to reach out to you and have more conversation about cyber security and ICS and pipelining, how would they get in touch with you?

Pascal:  I’m pascal@threatgen.com, so that’s how they could get a hold of me. I’m on LinkedIn if you want to find me there.

Russel:  Okay. We’ll of course link all that up in the show notes and there’ll be, if you want to go look at the guest page, you’ll find Pascal on the guest page.

Pascal:  Perfect.

Russel:  Pascal, thank you so much for joining us.

Pascal:  Thank you for having me. It was fun, thanks.

Russel:  I hope you enjoyed this week’s episode of the Pipeliner’s Podcast and our conversation with Pascal Ackerman.

Simply visit pipelinepodcastnetwork.com/win to enter yourself for the drawing.

If you would like to support this podcast, please leave a review on Apple Podcast, Google Play, or your smart device podcast app. You can find instructions at pipelinepodcastnetwork.com.

[background music]

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