Railroad Control System Security

There is an interesting article on the BostonReview.net site about control system security in US railroads. Unfortunately, the author (Bryce Emley) was not able to document a lot of the suspected control system attacks described in the article. This was not because of any lack of research on his part, but probably has more to do with the same sort of reluctance to discuss cyber incidents that we see throughout industry.

Cybersecurity Rules Non-existent

The article includes a rather lengthy discussion about the positive train control (PTC) technology that is still being implemented by the railroad industry. Now I did do a blog post on the security rules in the NPRM for the PTC rule back in 2009 and it is interesting to see how much our ideas about control system security have changed since that time.

As I described in 2009 the current PTC security rules (49 CFR 236.1033) are actually communications security rules and have nothing to do with the cybersecurity other than how secure encryption will be used to communicate between devices.

For other railroad safety systems (and older systems still in place until fully replaced by PTC by 2021) the closest you get to cybersecurity rules can be found in §236 Subpart H; Standards for Processor-Based Signal and Train Control Systems. But the scoping statement for that subpart never mentions security, just safety. The closest you get is found in §236.901:

“This subpart prescribes minimum, performance-based safety standards for safety critical products, including requirements to ensure that the development, installation, implementation, inspection, testing, operation, maintenance, repair, and modification of those products will achieve and maintain [emphasis added] an acceptable level of safety.”

What is Missing

What should have been included (to be fair, no one was really talking about this type stuff for control systems back in 2009, or year 1BS – Before Stuxnet) in the original PTC rulemaking? First, since the railroad industry was being tasked to design, essentially from scratch, a new industrial control system network, this would have been an ideal time to require that secure design tools and processes would be used in developing and manufacturing all components that would be included in PTC installations.

Next the railroads should have been required to develop and maintain network diagrams for all fixed components of their PTC systems and a similar network diagram for each mobile platform traversing those systems. Those diagrams would have to include all devices connected to the systems and all communications modes available to connect with each of those devices.

The rules should have also included requirements for railroads to conduct intrusion detection monitoring of those networks. Because public safety (both passenger and right-of-way neighbors) is involved there should have been requirements to establish internal reporting and incident response plans with requirements for reporting certain types of breaches to the TSA.

Finally, there should have been provisions made for reporting and coordinating component vulnerability disclosure and mitigation. Those provisions should have included specific DMCA exemptions for security researchers looking at PTC components or systems.

Conflicting Responsibilities

Sharp eyed readers will note that I listed TSA as the breach reporting agency. This is because TSA has been given responsibility for surface transportation security, not because they have expertise in cybersecurity matters. They do have a security incident reporting infrastructure in place, but they would probably have to pull in experts from ICS-CERT and/or the FRA for analysis and mitigation measures.

The FRA certainly has a certain amount of internal expertise on matters dealing with PTC systems. I am almost certain, however, that they have little or no cybersecurity expertise as it pertains to those systems. To be fair, nor does anyone else. The closest thing to having an agency with that sort of expertise is the ICS-CERT. A large measure of their control system security expertise would be directly translatable and the probable system specific blank spots would not be difficult to overcome; certainly more so for ICS-CERT than either FRA or TSA.

And there is yet a fourth agency that has a horse in this race, the Federal Communications Commission. Since the PTC systems use broadcast communications both between fixed components and mobile units and intra-fixed network communications over long distances. In fact, the FCC’s permitting process was responsible for some of the delays that the railroads experienced in setting up their PTC systems.

What Needs to Be Done

At this point adding any new PTC regulations for cybersecurity is going to be difficult. No agency has specific authority to issue such regulations and after recently extending the PTC implementation deadline, Congress is unlikely to provide specific regulatory authority. Unless, of course, we have a railroad hacking event of sufficient magnitude that the public and political outcry forces Congress to over-react.

It is probably too late at this point to include secure design requirements in any cybersecurity legislation. New equipment and system modifications could be addressed at this point, but most of the system design and much of the hardware acquisition has already taken place, so the secure design benefits would be somewhat lessened.

All of the other security measures discussed above, however, could be added onto the PTC systems already in place. They would go a long way to preventing the sorts of problems we have seen to date with security reporting. They would also provide for early detection of hacking attempts that could certainly prevent both intended and unintended railroad accidents resulting from such hacking attempts. That early detection and accident prevention fits well into the whole concept of positive train control.