An updated pipeline security directive is underway, reflecting TSA struggles

In the immediate aftermath of the devastating ransomware attack on Colonial Pipeline, the U.S. Transportation Safety Administration (TSA) issued in May 2021 a hastily prepared security directive that required oil and gas pipeline companies to report every security incident to the Cybersecurity and Infrastructure Security Agency (CISA) no later than 12 hours after they identify it. Companies that fail to meet this and other security requirements in the directive are reported to be subject to fines starting at $7,000 per day.

Although most experts considered the move a step in the right direction, pipeline companies and their lobbying arms, including the American Petroleum Institute, cried foul, saying that the federal government did not collaborate well enough with the private sector in crafting regulations for this complex segment of the industrial control community. A more detailed follow-up to the initial directive was announced on July 21, 2021, but was not released publicly.

This second directive reportedly contained mandates regarding password updates, disabling Microsoft macros, and additional security measures including multi-factor authentication (MFA) and password changes on programmable logic controllers (PLCs). Moreover, it offered pipeline owners and operators the option to suggest alternatives to these measures.

Now TSA, an arm of the Department of Homeland Security (DHS), is reportedly prepared to adjust some of the requirements in the second directive, in particular loosening the incident reporting requirement, which was apparently expanded from 12 to 24 hours on May 29. In addition, an update to the second directive is reportedly scheduled for no later than July 26.

A TSA spokesperson said that the new directive is a movement toward a “performance-based model that will enhance security and provide the flexibility needed to ensure cybersecurity advances with improvements in technology.” One of the criticisms of the directives is that TSA would not have enough industrial security experts to oversee its emerging pipeline regulations. TSA claims it has hired more than 20 specialists dedicated to pipeline security.

TSA security regulations are “a mess”

It’s unclear what will be in the second directive, but TSA appears to be struggling with its effort to craft security regulations for the pipeline sector. “TSA is totally overwhelmed,” Padraic O’Reilly, chief product officer and co-founder of CyberSaint, tells CSO. “It’s a bit of a mess, and I don’t think that was intentional at all. I think the trip-up thing has been around the standard stuff, like reporting.”

Patrick Miller, owner and CEO of Ampere Industrial Security, tells CSO, “It sounds like the TSA has finally had an epiphany, and I’m not sure what it took. There’s been a lot of stuff going on behind closed doors, whether it’s to the lobbying agencies or through direct communication with gas, utility executives, and other things. But I can tell you the pressure on the TSA has been enormous.”

Ron Fabela, CTO and co-founder of SynSaber, thinks the initial directive was reactionary and not well-thought-out. “They were just kind of throwing willy-nilly some hype terms, like go implement MFA and go implement zero trust and get back to us in some amount of time, and everyone’s going to be great,” he tells CSO. “What they’re doing now is bringing in the American Petroleum Institute and others, essentially those that shall be regulated, for their comment and feedback. They’re going to go through some iterations on it now, which is probably what they should have done the first time.”

IT security concepts were wrongly applied to OT environments

When it comes to identifying precisely what is amiss with the TSA’s directives, the answers are unclear because the details are not public. Moreover, those inside the industry who have seen them are not allowed to divulge them. “Like if we don’t tell the bad guys what the security control requirements are, they won’t know how to attack us. That to me is still just like a weird mindset to be in at this stage of the game,” Fabela says.

Nevertheless, it’s clear what some of the general sticking points are. O’Reilly points to some of the patching requirements, which may inappropriately apply some IT patching principles to OT environments. “Everyone tends to look at it through an IT lens, but patching in OT is totally different. You have to take systems offline. The patching cycles are longer and less well-understood. There is a danger that you might affect production.”

Miller underscores how IT security concepts don’t apply in OT environments even more strongly. “Some of that stuff, I’m sorry, was just absolutely stupid to try to apply to a control system,” he says. “Nobody in their right mind would ask some of these things to happen on a control system. Anybody with any experience in control systems would not ask for some of these things. It seemed almost like they took a bunch of IT security controls, shook them up in a bag, pulled them out, and said, ‘Do these things.’”

Specifically, requirements in the directive around two-factor authentication and changing passwords on PLCs were not feasible or potentially damaging to cybersecurity. “If I’ve got a line, some sort of gas transmission line, and it’s got, we’ll just arbitrarily say 40 or 50 PLCs along the way from end to end, I have to roll a truck to 40 or 50 individual locations to make a password change,” Miller says. “And can I change the password to something weak? It didn’t even say strong passwords. It was just: Change all passwords. So, can I change the password to no password? It was so poorly written and so poorly thought out.”

TSA could follow better models

Regarding how TSA might more appropriately revise its approach, it could look at other prevailing regulatory models. The quasi-voluntary critical infrastructure protection (CIP) requirements established by the North American Electric Reliability Corporation (otherwise known as NERC-CIP) are one set of rules TSA might consider.

“In NERC, there are regional auditors,” Fabela says. “They have an audit schedule, and there’s a lot of process and rigor around it, which I think is just the sign of maturity. I don’t think the TSA cyber regulations are there yet.”

Miller favors American Petroleum Institute’s Standard 1164 establishing cybersecurity specifications for pipeline infrastructure. “If I had my recommendation and they asked me, I’d say you should design a performance-based regulatory structure around API 1164,” he says. “It’s like their version of NERC-CIP. They wrote it. It’s designed for them. Frankly, It’s a whole lot better than NERC-CIP in my opinion. It’s solid. It’s good stuff.”

TSA may lack the expertise

One criticism from the outset about putting TSA in charge of pipeline security is the absence of qualified personnel to administer the regulations. Even though TSA says it has hired 20 people to work on this task, industrial control security experts are skeptical.

“There are not 20 people out there with pipeline experience that have any regulatory sense,” Miller says. “Those people don’t grow on trees, and there certainly aren’t 20 of them available for the TSA pay grade. It’s just not realistic. I mean, going out and getting 20 people and then putting them through some industrial control systems security training and having them look at some regulatory history, those are things that can happen. But you’re not going to go out and find seasoned professionals, not 20 of them.”