This week’s Pipeliners Podcast episode features Suzanne Lemieux discussing the third revision of API, how TSA and API standards cohesively work together, and what we can expect to see in the future. 

In this episode, you will learn about how API 1164 continued to reference past frameworks but included new standards, why it is considered performance based, and why a proper cybersecurity profile is crucial.

3rd Edition of API 1164 Show Notes, Links, and Insider Terms:

• Suzanne Lemieux is the Director of Operations Security and Emergency Response Policy at API. Connect with Suzanne on LinkedIn.
  • API (American Petroleum Institute) represents all segments of America’s natural gas and oil industry. API has developed more than 700 standards to enhance operational and environmental safety, efficiency, and sustainability.
• API 1164 (Pipeline Control Systems Cybersecurity) 3rd Edition was released in April 2021. The new version of the RP provides a comprehensive approach to cyber defense for critical infrastructure.
• Cybersecurity is the state of being protected against the criminal or unauthorized use of electronic data, or the measures taken to achieve this.
• SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote locations.
• Colonial Pipeline Cybersecurity Incident: In May 2021, a cyber attack was launched against Colonial Pipeline that eventually resulted in the payment of $4.4 million to resolve the attack. The attackers gained access to Colonial’s systems and data through an unmonitored VPN by stealing a single password.
• 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.
• IEC 62443 was developed to secure industrial automation and control systems (IACS) throughout their lifecycle.
• Operational Technology (OT) cybersecurity references the software, hardware, practices, personnel, and services deployed to protect operational technology infrastructure, people, and data.
• PLCs (Programmable Logic Controllers) are programmable devices placed in the field that take action when certain conditions are met in a pipeline program.
• Performance based standard.
• 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.

• Crosswalking is the mapping of equivalent, identical, or similar information across two or more distinct data sets.
• 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.
• 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.
• CSF (cyber security framework) is a risk-based approach to reducing cybersecurity risk composed of three parts: the Framework Core, the Framework Profile, and the Framework Implementation Tiers.
• The PDCA (Plan-Do-Check-Act) Cycle is embedded in Pipeline SMS (API RP 1173) as a continuous quality improvement model consisting of a logical sequence of four repetitive steps for continuous improvement and learning.

3rd Edition of API 1164 Full Episode Transcript:

Russel Treat: Welcome to “The Pipeliners Podcast,” sponsored by the American Petroleum Institute, driving safety, environmental protection, and sustainability across the natural gas and oil industry through world class standards and safety programs.

Since its formation as a standard setting organization in 1919, API has developed more than 800 standards to enhance industry operations worldwide. Find out more about API at API.org. 

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 the appreciation, we give away a customized YETI tumbler to one listener every episode. This week, our winner is Chastity Cannon with the Knoxville Utilities Board. Congratulations. Your YETI is on its way. To learn how you can win this signature prize, stick around till the end of the episode.

This week, we will speak to Suzanne Lemieux with API about the third edition of API 1164, “Pipeline Cybersecurity.” Suzanne, welcome to the Pipeliners Podcast.

Suzanne Lemieux: Good afternoon. Thanks for having.

Russel: I am so glad you’re here because I’m looking forward to talk about cybersecurity. I’m weird. I enjoy these conversations.

Suzanne: It is a very important topic in today’s world and particularly in the pipeline sector.

Russel: No doubt. If you would, tell us a little bit about your background, how you came to be in your role at API, and what you do at API.

Suzanne: Thank you again for having me. My name’s Suzanne Lemieux. I’m the Director of Operation Security and Emergency Response Policy at the American Petroleum Institute. I just celebrated my 10 year anniversary here at API, working on things from physical security, cybersecurity, to midstream operations, to now into the corporate policy division.

I came from the Department of Energy, where I worked on similar issues across the energy sector. Before that, I had a different career in telecom, but certainly, one that relates to cybersecurity, how the Internet was built, how we’ve come along in the last 20 plus years. It’s been an interesting journey, but I’m really enjoying it.

Russel: I take it you were quite involved in the recent update to API 1164.

Suzanne: Yes. I was. It was a combination of our Cybernetics Work Group, which is really pipeline SCADA systems focused, that control room focus for pipelines, and then our cybersecurity subcommittee, which is the broader look across the industry at how we do best practices and frameworks within our cybersecurity world.

Russel: That was the third revision, right, the one that was recently published?

Suzanne: Correct.

Russel: What’s new or different in the third revision from previous versions?

Suzanne: Revision three is a pretty intensive rewrite of the second version. When we thought about what we needed to do in version three, we realized that we needed a more comprehensive approach to how cybersecurity is done in the pipeline sector and in the control system as part of the operations of pipelines.

Version two was focused on SCADA systems and that particular view into operational control over that part of the control room. When we looked at version three and just the operating environment we saw and the regulatory environment that we were facing, we knew that we needed to make it more expansive.

In version three, we aligned it with the NIST cybersecurity framework. We made sure it was aligned with IEC 62443, which is a framework or body of standards that address control system cybersecurity, so that we could have a broader view of not just SCADA, but the entire operating perspective of a pipeline system.

1164 provides a framework for maturity and growth within pipeline operators, cybersecurity on the OT side, and we think it’s a comprehensive approach that companies can mature into, which is more comprehensive than what we had in version two.

Russel: I was tangentially involved in the 1164 rewrite. I participated in some of the conference calls and such. After the colonial cyber incident, when everything radically accelerated, I got left in the dust.

I would say that what I found interesting in the conversation is all the pipeline operators already were following some standards, but there was a lot of diversity in what they were doing.

One of the real challenges of writing a standard, like 1164, is trying to arbitrate all these other standards. Then do that in a way you don’t specify what a particular operator has to do. That’s a tricky line to walk.

Suzanne: Absolutely. We are very sensitive to that in the standard and in the work that we’ve done since the standard, acknowledging that we need a performance based approach to how operators build their cybersecurity profile.

Each company’s at a different level of maturity based on how long they’ve been operating, how big their system is, the resources they have, the criticality of their systems, and so we want to acknowledge all that. There are voluntary standards, and API standards are all voluntary.

We want to make sure there’s that flexibility in the lack of prescription, but it was a priority within the development of 1164 to make sure we referenced the other standards that are out there.

If you’re already down the path of implementing a certain framework, it’s not going to disrupt that effort or say, “What you were doing isn’t really these specific things, so you need to discard some of those investments and start over in this other path.” We wanted to make sure it was inclusive, a lot of those other frameworks that are in use.

Russel: I know a little bit about what’s in some of these other frameworks. I know a little bit about the conversation that was occurring.

One of the things that committee did a great job of is referring to the other frameworks, but in 1164 saying, “Yes, but this is what pipeliners should be doing.” I don’t know how much of that there is, but there’s certainly some of it.

Suzanne: It’s definitely in there. That’s the value and the consensus based approach that we take to our standards, which is required under the American National Standards Institute, which we’re accredited under, is that consensus based approach.

We had operators, government, practitioners, vendors and academia all coming together to say, “There are these different frameworks and options out there, but we’re reaching consensus to say those things, these are some of the things that we think are most important pieces of those, and we’re going to reference back to them. Collectively, here are the steps that we should think you should take in your maturity process.”

It takes the best of a lot of those things to point out that in the pipeline, OT space, yes, there is a very whole past to get there. If you take these pieces and consider them in this framework recreated, you can use them and still build within 1164 to a certain level of maturity that we think is appropriate.

Russel: One of the things that’s unique about pipelining versus other kinds of operations is the remoteness of some of the sites and the cost benefit of doing things at a site because of the remoteness.

Suzanne: Absolutely. Some of these pump stations or PLCs that are out in the field are hundreds of miles from a town. They’re in geographically remote areas. Population is very sparse. What is the criticality, and part of the development of your program is identifying critical assets and tearing them into what is the…

Just generally from the approach to cybersecurity, you always want to identify your crown jewels and tear down from there so that you’re spending your resources on what is most important. In some configuration, the remote site could be important, but that’s part of your risk assessment and your asset management process.

Russel: That goes to the performance basis of the standard. Could you talk a little bit to that? What does that mean that 1164 is a performance based standard?

Suzanne: Yeah. We think that’s really important, generally, with all of our standards, and even with regulation is the ability for operators who know their own systems best. They know what equipment they have. They know what software they have. They know how it’s configured. Every system is a little bit different.

That performance base where you say, “This is the outcome you want to achieve. Here are the various ways to achieve that outcome,” without being prescriptive to say, “No, you can only achieve it in this one way.”

When every system is different and every operator’s experience with their systems is different. It’s important that it is performance based because you could be wasting time and resources to align with one practice that may not achieve the goal that you’re looking for.

We saw that in the initial version of a TSA’s security directive to A that there were things in that directive that weren’t necessarily even technically feasible in some cases, based on the equipment you were using.

If you have a PLC that’s not capable of multi factor authentication, that requirement was not…You could achieve isolation through other ways, so that if the end goal and I think SD02C reached that, that if you can’t do MFA, then just demonstrate you can isolate. That’s the performance based versus the prescriptive that we think of.

Russel: That’s one really good example. That’s also one of those areas where pipelining is somewhat different from other kinds of automation.

You brought up the TSA. I actually want to dig into that a little bit. The whole conversation about 1164 has kind of gotten quiet, because the conversation’s been all about TSA and SD01, SD02, and now I guess SD03 is here.

Suzanne: SD02C, yeah.

Russel: Yeah. Can you talk a little bit about how are the TSA directives the same or distinct from what’s in 1164? How do those two things work together?

Suzanne: That’s an interesting question. It’s one that we’re still trying to solve. Initially, there’s SD02-1, which was identify your cyber coordinator, develop an incident response plan, some kind of easily done things by the companies that were identified as critical by TSA.

In SD02-A, which is the first version, that was a very prescriptive set of instructions for operators. We did do a crosswalk between 1164 and SD02-A to understand how implementing 1164 could achieve some of the outcomes in SD02A, but because of the prescriptive nature and TSA learning as they were going along from some of the concerns that operators had, they ended up revising it.

They had SD02B, which was some changes, but then they still were having some of the same challenges around what was actually implementable.

Now they’re SD02C, which is much more performance based. We are planning on doing a crosswalk between SD02C and 1164. I think it aligns probably much more closely because they are much more performance based outcomes, and they do identify several of the technical challenges that are in 1164.

When you talk about asset management, profile control, multi factor authentication, whitelisting, allow listing those types of things that are in the next framework that is referenced within or built around…1160 was built around, I think there’s going to be a lot more alignment there.

Russel: You use the term cross walking. For people that don’t know what that is, what does that mean?

Suzanne: That is taking the requirements within SD02C along with some measures and controls in 1164 to align where those things match up, where you’re getting the same outcomes from those same types of what we call controls in 1164 to the requirements in SD02C.

Russel: When you do a crosswalk like that, is that something that API does independently, or is that something you’re collaborating with operators? How does that work?

Suzanne: When we did it the previous time, we used the previous co-chair of 1164, who wrote a lot of it, to do that comparison. We’re hopefully going to be able to work with him to do that again. We took a subject matter expert from industry to do that, and then shared it back with the members so that they could see what that was and provide comments if necessary on that.

Russel: When you share something like that back, who are you sharing it back with? Is there any kind of confidentiality controls around that type of thing? One of the big things that certainly I’m seeing in the whole cybersecurity space is the need to keep things confidential.

You don’t just want the whole world to have access to this information, but on the other hand, you need to collaborate with your peers. How are you dealing with that?

Suzanne: For the initial version, because SD02A was marked SSI by TSA, we did not share it. We wanted to have it. We did share it with TSA as they were looking at what was possible as far as next steps for what they were doing.

Because SD02C is no longer SSI, we would have less restrictions on it, but to your point, I think we would probably share it with the 1164 task group to have them be the validators and review what was in it. Then I think we would be able to share it likely with those entities within our membership that we know are covered.

We may work with our other partner trade associations where they would share with their covered companies and have some protections around it. Then we would have to work longer term with our global industry services who have the standard in their catalog.

If you purchase the standard, could you then get access to the crosswalk? I think that’s probably a longer term conversation, but it’s something we would certainly consider. That would be a value to the industry.

Russel: Yeah. One of the challenging things about working in this domain is how broadly can you throw the net?

Suzanne: Yes. One other thing to be pointed out that TSA has agreed with us is that it is helpful in a way that companies are taking different approaches, because if everyone was doing the same thing, then everyone would potentially have the same vulnerabilities.

The fact that people are taking their own routes to get to the goals of performance of cybersecurity is actually valuable in its own way, because homogeneity is not security.

Russel: Yeah. If all the locks get opened with the same key, the locks are really not of value, right?

Suzanne: Exactly.

Russel: Yeah, very true. Very true. What do you think is coming next in this domain? Is there another directive coming out of TSA? Is there going to be a near term need to rework 1164, or is that becoming somewhat more stable than it’s been in the last 24 months?

Suzanne: There’s two answers to that question. On the TSA side, we have just responded to comments produced February 1st to the Advanced Notice of Proposed Rulemaking that TSA put out for cybersecurity and resilience. They addressed questions in the pipeline sector and the railroad sector.

Their plan is to come out with a Notice of Proposed Rulemaking in the next few years. That rulemaking will replace the security directives, because now the railroads, as part of the surface transportation landscape, also have their own security directives, which is why they were both included in that NPRM.

TSA has stated, and I was on a call with the TSA leadership, and they reiterated that until that rule is published, they will recertify the SDs every year because that’s what they have to do to keep them alive. We see the SDs in their current state, SD01, and SD02C staying as they are. We don’t see further revisions at this point to those.

Then, for 1164, when we published that because it was an accelerated timeline because of the corneal ransomware incident and the pressure to finish that, we committed to a continuous improvement process. That process will continue along year on year.

Under our regular requirements, we have a five year review process, but with the continuous improvement that we committed to, we have a workgroup that has stood out, that we’ll be looking at what can be improved in 1164.

It may be lessons learned from SD02C implementation, it could be just changing dynamics within the industry. We know amidst CSF, the cyber security framework is in the revision process right now for a 2.0. Are there changes that may need to be reflected from that?

There was some consideration of waiting till the rule is published, but we’ve been told it could be three to four years until a final rule. I don’t think it’s necessary to wait. We’re going to learn in between now and then, the landscape is going to change, and we’ll want to be reflective of that within 1164 in what we have included.

Russel: That’s a nice segue to the next thing I want to talk about. In this conversation, around cybersecurity, the landscape changes very much faster than the regulatory framework. There’s what we need to do just to operate our systems with appropriate diligence versus what the regulatory framework is doing.

What my takeaway is, and I’d like to hear your comment on this, is that if you’re implementing 1164, and you’re following two TSA directives, you’re probably in pretty good stead.

You need to take and apply the pipeline safety management technique, the plan, do, check, adjust cycle to what you’re doing, and you need to be doing that regardless of what’s in the regulatory framework. What are your comments about that, Suzanne?

Suzanne: I think that’s absolutely appropriate to do the plan, do, check, adjust, implement, process that’s in the pipeline SMS. There are some requirements in SD02C for periodic assessments, whether it’s pen testing, which is very controversial on the OT side, so that’s TBD with TSA as they move forward.

Some other risk assessments have a requirement for something like what was the validated Architecture Design Review, which they were doing previously in 2018, 2017 through probably 2020. Very encouraging companies who do that continuous assessment.

1164 has some of those requirements. I believe that is one of the things in NIST CSF 2.0 that they’re trying to build out more is that assessment piece and how do you change management within the CSF and where’s the governance structure for all of that?

Those things are important, change management in particular, and that is change management based on your risk assessment and different factors within your operating environment. We definitely encourage all of those things. We’ll see those continue to be promoted not just by the industry, but also by the government as they move forward.

Russel: You might even see a whole new standard that is performance management around 1164. I could see something like that occurring because, in the cyber world, the performance management’s probably more important than the actual implementation. Because it is so dynamic, it does change so quickly.

Suzanne: Yeah. Which is, again, why we encouraged TSA to move to that more performance based. Like I said, in the first iteration, they had some requirements in there, I believe, around allowlisting other related topics that were actually at the forefront of best practice today from a technology perspective that there are other types of software and practices that are more current and do get a better result than what they had prescribed.

They were actually using what our comments said were a bit outdated. Again, if you do a performance goal, you can adapt and change. You’re meeting the goal of, yes, knowing who’s on your network and what their privileges may be, but it may not be the old way you did it before. Having that adaptation ability is important.

Russel: Absolutely concur. What would be your advice to pipeliners? What should pipeliners be doing right now? What should be their kind of minimum maturity level and what should they be focused on?

Suzanne: I think that even if a pipeline…Because, again, the SDs only cover the top 100 systems in the US, and that was a bit of a black box for how TSA identified those.

I will comment that in their process moving forward with a potential role, they do want to actually open that up, not open up what they did previously but have a transparent process for how they’re identifying what are the most critical systems or who they should be covering.

Generally, as a pipeline operator, you should look at what’s in the security directives and see how close you are to meeting those requirements because they could easily expand beyond those 100 systems.

Also, looking at 1164 and saying, “Where am I within this? Where is it aligned with what I’m doing? How can I adapt within my environment, and what am I already doing to meet some of what is aligned with how I want to move forward with my cybersecurity profile?”

There’s a lot of good work that’s being done out there, not just by TSA and not just by API necessarily, but using the resources that are available. Obviously, larger companies are going to have more. Third party services are very valuable, particularly for incidents.

I just watched a webinar on incident response in the OT environment. That was free. We know that the SD requires incident response plans. Not everyone has one for cybersecurity. That’s a critical step. Even if you have one, does it align with your business continuity plan, we know that that’s the place where more work is needed?

That if you haven’t had the experience or events and you have a practice to plan, if you don’t have them brought your lawyers in because if you look at data retention, data protection, and cyber events, it’s different than if you have an oil spill, let’s say. Bringing the lawyers in bringing the people in your IT department into those exercises is something that we think is important.

Russel: I’ll share with you recently in a conversation, and this was with an executive with a pipeline. I’ve heard this in multiple places, but the largest concern that they have, or one or two on their list, is cyber.

That is a material change to where we were a relatively short period of time ago because I think what you would have heard just three to five years ago is probably their concern would be around environmental damage due to rupture or loss of pipeline integrity.

That’s been supplanted by other concerns. That’s a credit to where we’ve gotten to an industry in these other domains, but it’s also just the nature of the risk.

My guidance would be that every operator needs to have a cybersecurity capability. They need to have a posture. They need to know what that posture is currently and what it needs to be next year and three years from now. That’s at the bottom line. I’d say that’s where you got to start.

Suzanne: Yeah, absolutely. I think we’ve seen over the last couple of years that anyone can be a victim. For those people who think they haven’t been breached, it’s just because they don’t know they’ve been breached. You’ll see most cybersecurity practitioners say that, especially some of the experts from think of the large cybersecurity vendors out there.

They put out reports every year. You can read about it, it’s every sector, but certainly, in the last couple years, we’ve seen the energy sector really rise to the top of that group of most valuable targets. Financial sector is always at the top, but energy certainly rose to a close second.

The war in Ukraine, when we in the lead up to that we really thought there’d be a more aggressive effort and we’re happy to know that that didn’t pan out, as they initially predicted, but it’s still always a possibility.

If you look at the global commodity markets and then broadly the US place, that’s naturally just going to create a target for US producers and products moving to and from the US to other countries.

Russel: You wouldn’t have to do a whole lot of upset in the US for very long to have that cascade out to other places and have big international impacts.

When I say this is like locking your house, how you lock your house and what you put in place for locks for your houses depending on who’s living in your house, which you keep it in your house, the neighborhood you’re living in, how well you know your neighbors, and a bunch of other factors.

That’s also true with these systems from a cyber security system. The other thing I would say is things happen. There are people out there actively looking for opportunities to make them happen. They’re looking for easy targets, soft targets. So, be hard.

Suzanne: It’s also a question of resilience. If you know something could happen, do you have a plan in place to recover? How quickly can you recover? Do you have the resource in place?

Whether it’s from a third party service provider who’s going to help you recover from physical recovery if it’s a cyber attack that leads to a kinetic event. We know people are going to be breached. Things are going to happen.

What’s your resilience, and what’s your plan for that resilience because of the critical nature these products play in our economy today?

Russel: Absolutely. Listen, I’ll just ask one final question. Is there anything else? Any way you’d like to wrap this up or a final comment?

Suzanne: I would just wrap it up to say that we and our industry are working very hard in this space. It’s certainly something that even before the Colonial Pipeline ransomware attack we were focused on.

The industry argued or advocated to TSA years ago to include cyber security in the TSA guidelines. Eventually, through a lot of change in the organization at TSA those were included.

This is not necessarily a new subject for us. We didn’t start thinking about this in 2022 or 2021 time. It’s not new to the industry. We’re, as a shameless plug, about to start planning for our 18th annual cyber security conference.

Again, not a new topic for the industry and not a new topic for pipeline operators, but certainly one that’s gotten a lot of attention in the last couple of years. We’re working really hard. We’re always looking for those best practices and lessons learned that we can share.

Russel: I want to say, Suzanne, I really appreciate you coming on and joining this conversation. I’ve been trying to get somebody to come talk about 1164, cybersecurity, the TSA, and all that, from API for some time.

I really appreciate you taking the time to do this. I always learn something. I’ve certainly learned something in this conversation. Thank you very much.

Suzanne: Thank you so much for having me.

Russel: I hope you enjoyed this week’s episode of the Pipeliners Podcast, our conversation with Suzanne. 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 have ideas, questions, or topics you’d be interested in hearing about, please let me know either on the Contact Us page of PipelinePodcastNetwork.com or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.

Transcription by CastingWords