This week’s Pipeliners Podcast episode features Mark Grant discussing cybersecurity, where TSA cybersecurity is headed in the future with rulemaking, how cybersecurity has impacted the pipeline industry, and why it is necessary for developers to adapt to current threats.
In this episode, you will learn how malware has changed in recent years and ways to counteract them, the importance of isolating the incident while continuing to operate, and understanding what parts of the system are worth protecting.
Jump to:
TSA Cybersecurity Directives Show Notes
TSA Cybersecurity Full Episode Transcript
TSA Cybersecurity Directives and the Impact on Pipeline Contractors and Vendors Show Notes, Links, and Insider Terms:
- Mark Grant is the former CISO of CSX Corporation, with decades of experience protecting critical infrastructure, and now serves as a trusted advisor to help companies enhance their IT, security, and business strategies. Connect with Mark on LinkedIn.
- RiskSec is a Experienced Risk and Information Security company, specializing in regulatory compliance and overall security framework.
- TSA (Transportation Safety Administration) develops broad policies to protect the U.S. transportation system, including highways, railroads, buses, mass transit systems, ports, pipelines, and intermodal freight facilities.
- Cybersecurity is the state of being protected against the criminal or unauthorized use of electronic data, or the measures taken to achieve this.
- Advanced Notice of Proposed Rulemaking (ANPRM) tells the public that FAA is considering an area for rulemaking and requests written comments on the appropriate scope of the rulemaking or on specific topics.
- SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote locations.
- Ransomware is a type of malware from cryptovirology that threatens to publish the victim’s data or perpetually block access to it unless a ransom is paid.
- Malware is software that is specifically designed to disrupt, damage, or gain unauthorized access to a computer system.
- PLCs (Programmable Logic Controllers) are programmable devices placed in the field that take action when certain conditions are met in a pipeline program.
- Zero-day attack is an attack between the time a new software vulnerability is discovered and “released into the wild” and the time a software developer releases a patch to fix the problem.
- SSI (sensitive security information) is information that, if publicly released, would be detrimental to transportation security, as defined by Federal regulation 49 CFR part 1520.
- SOC Audit (System and Organization Controls) and is an audit of a company’s controls that are in place to help ensure the security, availability, processing integrity, confidentiality and privacy of their customers’ data.
- OWASP (The Open Web Application Security Project®) is a nonprofit foundation that works to improve the security of software.
- Executive Order 14028 pushes agencies to adopt zero trust cybersecurity principles and adjust their network architectures accordingly.
- Outcome–based testing model is an approach that prioritizes security outcomes, improvements where they count, and alignment with business resilience, instead of specifying output or 100% comprehensive coverage of potential vulnerabilities.
TSA Cybersecurity Directives and the Impact on Pipeline Contractors and Vendors Full Episode Transcript:
Russel Treat: Welcome to the “Pipeliners Podcast,” Episode 261, sponsored by Gas Certification Institute, providing standard operating procedures, training and software tools for custody transfer measurement and field operations professionals. Find out more about GCI at GasCertification.com.
[music]
Announcer: The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations.
[music]
Announcer: Now your host, Russel Treat.
[music]
Russel: Thanks for listening the Pipeliners Podcast. I appreciate you taking the time. To show that appreciation, we’re giving away a customized YETI tumbler to one listener every episode. This week our winner is Bob Price. Congratulations, Bob, 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, Dr. Mark Grant with RiskSec joins to talk about the recent TSA cybersecurity directives, and in particular, their impact on pipeline contractors and vendors. Mark, welcome to the Pipeliners Podcast.
Mark Grant: Well, thank you, Russel. It’s a pleasure to be here. I appreciate the chance to talk about timely and important topics.
Russel: I appreciate you taking the time. Just to shout out to Skip Elliot for introducing us. Appreciate the introduction. This is going to be very valuable. I asked you to come on so you could talk about all the stuff going on in cybersecurity, and more specifically, around TSA cybersecurity, and rulemaking, and what’s going on.
Maybe a good place to start is, what’s going on with the TSA and its rulemaking for cybersecurity?
Mark: Well, Russel, I would say in recent months and continues to be true, the TSA is very busy with rulemaking right now clearly focused on the pipeline industry and the railroad industry. I know last year the pipeline saw two security directives around cybersecurity.
At present, freight and passenger railroads are also covered by two security directives which were issued in December of 2021 and October 2022. For both the industries, the security directives, the latest one is requiring submission and approval of cybersecurity implementation plans.
The contents I would say, and the approach that the TSA has been taking and working with the covered companies has been very similar across the industry.
I was at a security event a couple of weeks ago and met Scott Gordon who is TSA’s executive director for surface policy. I have to say, I think he’s done a commendable job of trying to navigate the implementation of the security directives. They’ve talked about the industry, they’ve taken some feedback.
The comments at the event, he made it clear that we should expect to see some more regulation in this area across both sectors. I do believe that, since then, they’ve started actually notifying about what they call an advanced notice of proposed rulemaking which is going to apply both to the pipelines to rail transit agencies and to railroads.
I think that’s going to focus around cybersecurity risk management. I believe they’re looking for that advance notice to come out sometime this month. They’re moving pretty fast on this stuff, currently.
Russel: That’s certainly true. In this domain, it really doesn’t matter how fast you move as a regulator. There’s no way you’re going to move as fast as the threat is moving.
Mark: Yeah, I think that’s true.
Russel: The other thing I think…I’ll just say this. I was recently reading an article about this third TSA cybersecurity directive that’s being worked on. There was a lot of discussion about…The first directive was pretty light. Just register with us, so we know how to find you. We can have a conversation.
The second was very prescriptive. “You need to get these things done this way.” Certainly, most of our customers have been very involved with getting those things addressed. Then this third is more of…At least based on what I’m reading, it sounds like it’s going to be more of a typical kind of regulatory governance approach. Is my take on that correct?
Mark: Yeah, I believe that’s true from what I understand. Although I know that various people have asked the TSA, we haven’t yet seen any sort of draft on where they’re going with it. I don’t know that we will actually see a draft until we get the notice that says, “Hey, this is what we’re thinking about.”
I do believe that they’ll have some opportunity to get some feedback. I know they’re looking at a certain time period to get feedback from various covered entities for the regulation.
Then likely they’ll take some of that feedback, and it might make a difference. There is an opportunity as people are tracking this to get involved, if you’re a pipeline, if you’re a railroad, to get involved in the conversation and try to give good feedback because, once you get too deep into it, you’re going to get what you’re going to get in terms of regulation.
The problem with regulation is, once it’s out there, then…When the TSA’s busy making regulations, that means companies are busy trying to address those regulations. Whether it’s putting together the documentation that’s needed, or modifying their plans to be compliant. That’s distracting, and it’s also not flexible.
The regulation is what the regulation is. You have to do these things. What that means is you may not have time to do other things, which could actually provide a greater security benefit. That traditionally is what people talk about when they talk about the difficulty with dealing with cybersecurity regulations.
In a world where the threat evolves rapidly, regulation isn’t going to evolve at the same pace.
Russel: That’s true. That gets to a bigger conversation I recently had in another conversation about the difference between compliance and safety. You think of that as the difference between compliance and process quality is another way to frame that. Compliance is needed and necessary, but it’s only really one piece of the puzzle.
Particularly in this domain, because of the nature of the threat and how quickly it moves, compliance is really just a bare minimum capability.
Mark: Yeah. You hope that they get the right stuff in there in terms of, we see this as a baseline of compliance. I know that companies are focused on these things. They have very strong business incentives that drive them to have good security. They want their systems to be secure. They want them to work.
You hope that the baseline requirements match pretty closely with what companies are focused on already. You also hope that there is some flexibility so that they can, in addition, address those things that they know are necessary based on what they’re monitoring and the specific conditions they’re facing within their company.
Russel: What is the nature of the threat right now? For those of us that are running SCADA and distributed assets?
Mark: I would say, in the last couple of years, by far the largest threats that have been out there are probably really three things I would say. The three big threats are ransomware, ransomware, and ransomware. It’s been all about ransomware in the last several years. The big concern there was about business disruption.
Whether you’ve got SCADA operational technologies or you don’t, you’re worried about your business getting impacted and slowed down. It could be a direct result of malware infecting your operational technology, or getting on your SCADA systems. It could be a direct hit, or in a lot of cases, what you see is there is not a direct hit.
There is some other part of your company that’s impacted by this malicious software, but you’re shutting down those control systems, or disconnecting them from the rest of the environment in order to protect them. That still leads to a business impact. We’ve seen a lot of that across a variety of companies.
The other thing that we continue to see, which is similar, involves a ransom but it’s not that your systems are encrypted, it’s that, hey, we stole a bunch of your data. We’ve got it, and we’re going to look at all the stuff we have. We’re going to post it online if you don’t pay us.
Companies then try to do the risk management calculus to figure out, how damaging is this going to be and what’s going to be our response? So they start to formulate a response. That’s been, the last five plus years, has been a big threat, particularly for companies that rely on your technology so heavily to run.
Given what’s going on geopolitically – you don’t have to be the NSA to figure this out – particularly if you’re critical infrastructure, you have to be watching what the Russians are doing and other affiliated organizations or other nation states that have an interest that aligns with what the Russians might do.
You don’t forget about the ransomware, but this is a new thing that you’re tracking on top of that. Particularly, the challenge, when it comes to SCADA or control systems in particular and critical infrastructure, is the systems that are used, the underlying systems, are often very similar across the industry.
If you know, for example, how to attack a PLC in the energy sector or on a railroad, you’re going to have a pretty good idea how to attack that stuff in a pipeline. The tool set, the attack methods, it’s all pretty similar.
Russel: That’s a great tee-up, Mark. The thing that’s up for me in this whole conversation, I’ve done a number of podcasts on cyber. I’ve talked about how the issue is no longer a smart guy doing nefarious things. The issue now is more nation states trying to execute war plans, economic war plans, cyber war plans, against other nation states to influence things.
The tools are out there. They’re pretty well known. They’re pretty well understood. The ransomware and the various kinds of things you can do to do nefarious things with code are out there. They’re pretty well understood.
There’s always people coming up with something that’s a little bit new, but the big weakness is the vectors. What are all the places and means where that nefarious software can get placed and deployed?
Being a software company ourselves, one of the things that’s up for us is we’re seeing a huge level of risk management activity in our customers and in our contracts and in our agreements. They’re asking us all kinds of questions about, “What are you doing about your cybersecurity?”
One of the things I wanted to talk to you about in this conversation is, as a vendor, what’s our risk? Somebody who’s providing software or services. If you have any kind of automation that’s touching a customer system, including something as simple as you’re logging into their systems to do work, then you have very material risks that you may not understand or may not have had in the past.
Mark: Yes, absolutely. We’ve seen a number of attacks which have leveraged this supply chain nature of how things are connected in products, in particular products which are used across a variety of companies. It may be an important product for them, or it may not be, but it’s in their environment. There’s connectivity associated with that product.
What the attackers will do, will leverage those products. In some cases, particularly if it’s internet facing, they can easily determine who’s using the product. They may know about a vulnerability in the product that no one else knows about, so there’s not an opportunity for companies to address that vulnerability.
You may have heard the zero-day term, these zero-day vulnerabilities. They’ll have a list of a hundred, a thousand companies that are using this product. They’ll just go down the list and start compromising them. Eventually, people will figure out what’s going on, and they’ll focus on reducing that risk by addressing whatever vulnerability is being leveraged.
At that point, if you’re a provider of that product, you have the product and a lot of customers, which you are happy about. Suddenly, you’ve got all these issues related to all these companies that have been compromised with your product. There is liability. It becomes realized whenever those attacks scale across multiple companies.
That’s the problem with these things. They can be done remotely now. It used to be if you wanted to mess something up, you had to be there, be present. There was a manual process. You had to be physically present with a crowbar or something to cause a disruption. That was decades ago. Now all this stuff is automated. These things are connected, ultimately.
They’re isolated. People try to isolate them, but it’s difficult. Ultimately, there may be a path to them. It can scale across a company.
Russel: It only take one pinhole in the balloon for the balloon to deflate.
Mark: That’s right.
Russel: It doesn’t take much. These companies have been focused, historically, on their internal systems, policies, procedures. Now the focus is starting to be…We’ve gotten what we can get in terms of risk management there.
We need to start looking. What are all the external connections into our networks? Our vendors and our contractors and all of that, are they doing what we need them to do in order that our systems stay safe? Really, this is a reliability thing. It’s a business continuity thing.
Mark: Most companies can withstand a hit. They can take an outage as long as it’s not prolonged. Some of these things do have to be somewhat sophisticated. I think that the importance of understanding the business context of how you use your systems and how they support what’s important to your business ultimately is where companies need to focus.
You’re right. We’re having these conversations. I’m working with companies right now to work through the TSA cybersecurity regs and how they respond to them.
Almost immediately in the first conversation, what comes up is, “Well, what about all these suppliers we have? We don’t even manage this system. It’s managed by a third party. The TSA is asking us about these steps that we’re taking or these protocols we have. We’re just having to turn around and go to our suppliers and ask them.”
What we’ve been trying to do is get the suppliers to take a proactive approach. I think initially, for example, the TSA regs, the security directives were classified as SSI. They were trying to protect them and keep them secret. They’ve changed that approach now. They’re making them public. You can go to the tsa.gov website. You can look at them.
The suppliers can do that too. We’ve been talking with suppliers about, “Hey, why don’t you all take a proactive approach? Rather than responding to X number of customers who are reaching out to you, why don’t you look at the reg? Maybe you could produce a response for us that we could all leverage. Then if we have any questions, we’ll come talk to you.”
There are ways that process can be easier, both from a customer perspective and from a supplier perspective.
Russel: I absolutely agree. What I would say, at least in our experience, is we…I say recently. It’s been a while now. It’s recent enough that I remember it well, going through our first SOC audit.
What was interesting about that is probably 95 percent of the things that were required, we were already doing, but the level of effort to get really clear about the governance around those things and the policies and the procedures to ensure they’re occurring on some kind of recurring basis and we don’t drop the ball anyplace. It’s fairly significant, fairly significant.
Mark: That’s where the work comes in. That’s where the work is. Occasionally you get something that gets put in a directive or in a regulation that is really too prescriptive, and in some cases may be nearly impossible to implement for some of the customers and some of the suppliers.
That’s where, you’re right, it’s that last couple of percent to get compliance that produces all the work and all the change that’s required. When you’re changing stuff, that introduces risk as well. These changes in the environment, particularly when it comes to security, don’t come with zero risk to your company.
Russel: That’s absolutely right. Anytime you’re taking on a big undertaking, and it’s requiring leadership and senior people to focus their attention on that, it means their attention is coming off of other things. That always has risks.
I would say though, if you’re a vendor and you’re providing services, or software, or any automation to contractors or to the pipeline operators, so if you’re a contractor providing those things to pipeline operators, you need to have a mature cybersecurity posture, just like you have to have a secure safety posture.
Mark: That’s right. Absolutely.
Russel: If you don’t, you need to get after it. [laughs]
Mark: Yeah. Your customers are going to figure that out real fast. We talked a little bit about the business context, and particularly if you’re providing software that you know is important and critical to your customers’ process, and that their business is going to be impacted. Absolutely, you need to be on top of that stuff, and you need to really feel real comfortable about the security of your product.
There are ways to do that. There are standards and processes that people should be looking at and adopting if they haven’t already. You look at stuff like the OWASP, which is the open standard for web application development security. There’s a top 10 list that they produce that says, “Hey, these are the most important things that we think right now, given what we see going on in the world, and what we see being delivered to software, that you really need to address. These are vulnerabilities that we see.”
These are things that the attackers understand which vulnerabilities are prevalent in software, and security people understand which things are prevalent as well. What they’re trying to do with this OWASP thing, is to make sure that developers understand, so that they’re not continuing to provide software that’s susceptible to attack. If you’re providing that software, if you’re a supplier, it’s likely that your customer is going to test that stuff.
If they find a lot of vulnerabilities that should have been easily caught, they’re going to start asking even more questions about your development process. That stuff has to start at the beginning, in the design phase, while it’s being developed. As the software is being…new releases are being worked on, there should be testing that takes place in each step of the way. When the thing’s done it should be tested again because customers are increasingly starting to test that at some point.
Russel: I couldn’t agree more. That’s very on point. I would also say that older developers, and what I mean by that is people who have been doing software development for a long time and are top performers in software development, they know how to get code written, they’re current on all of the various development tools, and the processes, and the procedures and techniques for using those tools effectively, often, know little, if anything, about the cyber aspect of what they’re doing.
That’s a problem. It’s a big problem throughout the industry.
OWASP actually has some interesting tools that are free, that you can use and run them against your code, that will find a fairly substantial list of known vulnerabilities. Not only do they have a lot of guidance and policy and practice stuff, but they also actually have some tools that help with implementation of that. Those kinds of things are super important.
The other point I would make is this is not just for people writing software and delivering software or people building PLCs and delivering PLCs. It’s people building skids. It’s people selling engine packages or compression packages.
Anybody who’s working as a contractor where your employees are on the company’s, the customer’s, systems, this applies to all of you folks as well. It’s not just those of us that are writing code.
Mark: It’s the entire process as well. I saw a discussion recently from a guy from MITRE Institute. They produce an attack framework for helping people understand how their systems might be attacked and where they might need to protect it.
This was a control system. It was well designed. It had good controls, things like you can’t change the configuration unless you’re standing in front of the machine and you’re pressing this button, things like that, which are very helpful from a cybersecurity perspective.
Where they ended up in their analysis is that’s not how they’re going to attack. What they’re going to do is they’re going to attack the engineer’s laptop who uses his laptop to plug into that thing when he’s making that configuration change. That’s where the malicious code will have been introduced.
As you said, it’s the whole ecosystem around that system. The product itself may be secure, but the surrounding process around it, is there a gap there?
Russel: It could be something as simple as the guy is using a company laptop, but he has put some software on there that he uses to do some kind of commercial transaction or to watch videos or something like that. He’s got credentials that are on that software, that can be found and exploited. It doesn’t take much.
Mark: Or maybe he doesn’t work there anymore, but you didn’t get his laptop. You didn’t turn his account off. He’s not that happy with you.
There’s this whole baseline security measures that happen at the enterprise level, the nuts and bolts and blocking and tackling around the security 101 basics that help you out across the board and even in these controlled environments. You have to get all that stuff right. It’s a challenge.
Russel: Mark, one of the other things we talked about was you brought up this presidential directive on product certification. When you brought that up, that was the first time I had heard about that. Could you tell us a little bit about what that is and what does it involve?
Mark: This is an interesting one. It’s Executive Order 14028, which is about improving the software supply chain. It doesn’t necessarily address everything across all the different providers. What I think it indicates is the direction that these things may be going and the way that at least the government is thinking about the supply chain issue.
One of the most interesting things it does, it’s all about security requirements for software that is supplied to the government. Understanding that the government uses a lot of software that the rest of us use as well, I think this potentially could drive changes that will impact everybody.
One of the interesting things is there’s a pilot initiative which they call the “Energy Star labeling” of software, which means this stuff has been validated, tested to a certain level of security, so when you buy something, it’s not a complete unknown, what you’re going to get. From a security perspective, you know it’s had a basic stamp of approval.
This is something that suppliers should welcome and should embrace. It’s additional work, but it’s largely stuff they should be doing anyway. Cybersecurity insurance providers might be very interested in this sort of approach, and potentially should look at embracing it as well.
This is the kind of thing that customers probably should have been demanding for a while. Saying, hey, when I get a piece of software from you, I need some kind of information, or certification, [laughs] or description of what you’ve done from a security perspective.
It may be true that, yeah, if you’re working with a niche provider, and you’re working on a customized contract, and it’s a very specialized software, you’re likely going to be able to put that stuff in the contract and hold their feet to the fire from that perspective. If you’re buying something from Oracle or Microsoft, they’re not going to do that.
They’re not going to customize the contract. You’re going to buy the thing off the shelf. As long as they do it the right way, it’s potentially a step in the right direction, could be helpful.
Long term, if you think about the concepts, like say you’re a pipeline, and before you bring an important product into your environment, say it’s a new control system, if you could go to a facility, for example, that had a configuration like yours, a testing facility, and bring a red team in to test the software.
Maybe, at the same time, you even include some people from your own security team so that they can see how the testing goes, they can understand the techniques a little better, they can help see how well they can defend against those attacks.
Even better, say you bring in a supplier that you use for security, and then maybe they’re developing security products or solutions for you to implement, at the same time, they’re able to see how that testing goes and understand how they can better monitor and defend against those kinds of attacks.
You can see how this could evolve into something that could be much more collaborative, much more open in terms of how we think about securing software, and ultimately, could lead to a much more secure product being delivered on the back end.
Russel: Those vendors that have a mature cyber profile are going to become preferred over those that don’t.
Mark: I agree with that.
Russel: If you have existing relationships and you’re not maturing your cybersecurity profile, you’re at risk of losing those relationships.
Mark: I think that that’s true.
Russel: I think those are factual. I don’t know what the speed of that is, but that’s certainly the direction. When you start talking about testing and certifying or giving a customer an opportunity to hack your product, that’s a very interesting idea, but me being a software guy and thinking about that, it’s like, man, what is it going to cost me to build that and maintain that capability?
If I’ve got to build and maintain that capability, how do I pass that cost back to my customers? I can’t do that without passing it back, right?
Mark: Yeah. That’s what’s going to happen too. I mean, even with the security directives and the folks, some of the people I’ve been working with, as you talk to the suppliers, initially, they begin to realize, yeah, we can do whatever you want from a security perspective.
We can help you comply with this regulation clearly, but we need to sit down and talk about the relationship and the contract, and how we’re going to approach that. What that translates into is, yeah, we can do that, but it’s going to be additional money. That is the reality of some of these regulations. It’s going to force some companies to need to spend more.
Like I said earlier, companies focus on this stuff. I’m familiar with what companies do with the security programs across a lot of sectors, and they’re serious about it and they have people focused on it. A lot of suppliers are the same way, but it’s going to be an additional effort.
Russel: Well, that’s certainly true. One of the other things we talked about too as we were prepping for the podcast was this idea of outcome-based testing. Could you talk a little bit about that? What does it mean, and what does that look like?
Mark: This is something that I certainly learned a lot about this working with one of our national labs. This was in an industry which has a lot of control systems and was implementing a new product across the industry that was going to be critical to operations. It was one of these multibillion dollar efforts.
One of the things that this industry did was they brought in a national lab who focused on understanding at the early stages of how these types of implementations affect the risk of the company.
What that organization focused on, because they had done a lot of these things for the military and other industries, the people there talked about this outcome-based process which really amounted to understanding the business context of how the system would be implemented. Rather than chasing vulnerabilities…
I mean, you have to manage vulnerabilities, but there are always going to be vulnerabilities, and so you have to think of your system as vulnerable and you have to think about what are the important parts of your business you’re trying to protect. What does this system do, and how can it be leveraged?
It’s a threat modeling risk analysis, and where you end up is understanding what are the most important things to protect, and how could those things be manipulated. A cyber attack is not a normal sort of failure mode, so failure mode analysis isn’t applicable.
When people think about how things break, they’re like, OK, it’s going to break like this, it’s predictable, how do we address that? If someone is actively in there manipulating the system, it’s going to break in ways that it normally wouldn’t.
You have to consider those factors and focus all your efforts on preventing those outcomes that are going to be most damaging to your business. Like I said, if the reality is, if someone gets in, breaks your system, and you can fix it in half an hour, you can probably live with that.
It’s the sustained, long-term impact that you want to avoid. You don’t want the thing to be down for six weeks. You want it to be fixed.
Russel: That’s the same thing you do in any kind of critical infrastructure when you’re looking at, what do I need in the way of business continuity and how much downtime can I take? If I lose my primary, how do I get to my secondary and how quickly do I get to my secondaries? That kind of analysis is all the same, I think, or similar.
The point you’re making is the failure mode is going to be something completely unanticipated.
Mark: Oh, yeah. Like I said, the normal analysis, when you think about that, is completely different. You could end up in really weird places in terms of how the thing behaves. The basic steps are, “Look, yeah, you have to prevent the attack, you do everything you can to prevent it, but you realize that’s never going to be a 100 percent.” You need to focus on how you figure out you’ve got an issue…
Russel: How do you isolate it and continue to operate? To me, that’s more where the rubber meets the road. How do I isolate and continue to operate?
Mark: You’re going to see things. You just need to be a resilient environment, and you have to protect your backup environment too. It’s a complicated process. The incident response, and how often you exercise it, what testing you do, all these are important aspects of how you prepare it yourself. In most companies, it’s not like…people say it’s not if you’re going to get attacked, it’s when. We’ve seen that play out.
Russel: Just to wrap the conversation Mark, what do you think that pipeliners, particularly those that are the contractors and providers, what do you think they should take away from this conversation?
Mark: You’ve brought up the point, Russel. Look, customers are going to be asking you more and more, particularly with these regulations in place. They’re pretty prescriptive in terms of what needs to happen. Your customers are going to say, “Hey, I’m going to have to engage with my suppliers.” You’ll see them wanting to look at contracts when they’re renegotiated, and make sure they’ve gotten additional security language in there.
It’s pretty prevalent right now for normal IT systems, for those types of discussions to take place at contract time. It’s less prevalent for some of the control systems.
Certainly, if you buy equipment that has embedded technology, it may not be thought about at all. I think it will be more so in the future. If you’re producing equipment that’s got some automated component or an onboard computer, whatever, computer embedded, people are going to start catching that stuff too and say, “Hey, we know there’s IT in there.”
That stuff is not as mature, in some cases, in terms of the processes that have been used and the security that you can rely on there. That’s what you’re going to get. You’re going to get more outreach. If you’re a supplier like that, you should be thinking about how you test that stuff, when you test it, and what kind of materials you can produce that will make your customers feel comfortable.
The leading providers – you hit the nail on the head – they’re going to be out in front, talking about that stuff because they’re going to see that as a competitive advantage. They’re going to be looking to leverage that, the maturity and the money they’ve invested there.
Russel: That’s absolutely true. What I would say is if you’re working in critical infrastructure or supporting critical infrastructure and you don’t have a well understood cyber profile, you need to get there.
Mark: You need to get there.
Russel: That’s the takeaway. For people that hear that and go, “I don’t even know where to start,” the place to start is to find somebody who can help you get through a SOC audit. That’s the place to start. Once you’ve done that, the next thing is what standard, of all the standards that are out there, am I going to follow and get after it.
Mark: I agree with that. It’s got to be something you’re focused on. I totally agree.
Russel: Listen, I appreciate this. I think pipeliners will find this conversation helpful. This is one of those things that seems to be changing quicker than we can talk about it. From the time we started this podcast till the time we ended this podcast, the situation has changed.
Mark: Again, I appreciate the opportunity to get on. I always like talking about cybersecurity with folks working in the industry. It’s been a pleasure talking about it.
Russel: It’s been great to have you.
Mark: Thanks, Russel.
Russel: I hope you enjoyed this week’s episode of the Pipeliners Podcast, and our conversation with Mark. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit PipelinePodcastNetwork.com/Win and enter yourself in the drawing.
If you’d like to support the podcast, the best way to do that is to leave us a review, and you can leave us a review on Apple Podcasts, Google Play, or whatever app you happen to use to listen. 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.
[music]
Transcription by CastingWords
TSA Cybersecurity Related Episodes & Resources:
Pipeline Technology Podcast episode 25
Pipeline Technology Podcast episode 20
CYBERSECURITY DIRECTIVE FOR OIL & GAS PIPELINES TARGETS VULNERABILITIES WITH MARCO AYALA
Pipeliners Podcast Special Edition Episode
THE COLONIAL PIPELINE CYBERSECURITY INCIDENT WITH PASCAL ACKERMAN AND CLINT BODUNGEN