The new TSA Rail Cyber Security Directive 1580/82-2022-01 increases the scope of passenger and freight rail system cyber security protections over the directives issued in 2021. The new rules reflect complexities intrinsic to many rail operators. Parts of the new rules are not so clear, while other parts might have been made even a bit stronger without a material increase in compliance paperwork. It seems likely that the directives are only the first steps in the U.S. government’s efforts to secure the nation’s critical rail infrastructure.
At the highest levels, the new rules expand the scope of earlier directives. The 2021 directives were focused on incident reporting and incident response capabilities. The new directive expands the scope of required cyber security programs to encompass all five pillars of the NIST Framework. In doing so, the new rules reflect the complexity of trying to require strong security in an industry where many owners and operators have complex interdependencies between their IT and OT systems.
Critical Cyber Systems
The new rules define “Critical Cyber System” as any IT or OT system or data whose compromise could result in operational disruption. While some safety critical systems such as signaling would qualify as an OT System, the definitions of IT and OT systems is more nebulous in other cases:
- In passenger rail systems, the ticketing systems might be considered critical to continuous operations and ticketing systems are most often hosted on IT networks,
- In freight systems, container tracking is often critical to on-loading and off-loading and these tracking systems are most often hosted on IT networks, and
- Cyber security programs at most operators are comparatively immature, and so there tends to be a host of lesser interdependencies between IT and OT networks.
Unlike the North American electric power sector where there is a strong emphasis on separating control-critical from non-critical networks, making such a separation in most rail networks is going to be very difficult, no matter how desirable such separation might be in the long run.
Confusing Rail Cyber Security Elements in the New Directive
Given these interdependencies, it may seem strange that rule III.B in the new directive requires network segmentation “designed to prevent operational disruption to the OT system if the IT system is compromised or vice-versa.” If most physical operations require both IT and OT systems running, what good is independent operation? The answer may be aspirational. If there are no OT dependencies on IT services, strong segmentation, such as with a Unidirectional Gateway, means that physical operations can continue if the Internet-exposed IT network is compromised. Ultimately, if operators can move away from these dependencies, then the reliability and resiliency of the entire system is improved through stronger rail cyber security.
Similarly confusing are III.D rules on spam and phishing emails, restrictions against known C2 Internet addresses, and restrictions against known malicious websites. Common OT security practices already forbid connections from anything on an OT network out to an email server, and similarly forbid connections to anything but known-good IP addresses and web domains – or completely forbid all connections out to the Internet for that matter. The reason here, again, appears to be that these rules apply to “critical systems” and those systems can be found on both IT and OT networks. Worse, critical systems such as passenger ticketing and freight tracking may themselves be exposed to customers through web services, and so may be intrinsically Internet-exposed.
Problematic Elements
The obvious problem with the directives is that they are regulations, and auditable regulations produce a lot of costly paperwork. It is not enough to implement robust security programs to comply with the rules. Given the potential for external audits, robust security programs must now be demonstrably compliant, which means a lot of paperwork and tracking.
A deeper problem stems from requirements in III.C that talk about eliminating shared passwords, MFA, password refreshes and least privilege. The only practical way to implement these policies reliably in an OT network, with thousands or tens of thousands of cooperating systems, is a central password and permission manager, with Active Directory (AD) servers being the elephant in the room. The problem with these systems is that they introduce new single points of compromise and are favorite targets of ransomware criminal groups. By way of contrast, the NERC CIP regulations effectively forbid OT systems from depending on IT AD servers, by flagging AD servers as “electronic access control devices,” which are subject to almost as many CIP rules as are critical cyber systems. Such rules are seen as onerous for IT AD systems, and so in practice, no CIP-compliant enterprise has their OT systems depend on or even trust the IT AD servers.
Another problem reflects the IT/OT spam and Internet-blocking confusion that we looked at a couple paragraphs ago. The directive really should require or encourage owners and operators to set up strong segmentation for all critical rail cyber systems, whether on IT networks or on OT networks, and either forbid outright any connections to the Internet from those critical networks or permit only connections to known-good destinations. Trying to track known-bad IP addresses and domains is a never-ending game of cat and mouse with our adversaries; one eventually doomed to failure if it persists long enough.
Residual Cyber Security Risk
One obvious residual risk here is pivoting paths. Pivoting is when our attackers take control of one machine in one of our networks and then use that machine to attack other machines in other networks. Targeted ransomware actors, hacktivists, and nation-states all use pivoting routinely. All three demonstrate routinely that they can push their attacks through firewalls. There were thousands of ransomware incidents last year, and all of them managed to plant their malware on IT networks through the Internet firewall, didn’t they? Any time there is only firewalled segmentation in place, there are pivoting paths from the Internet, through IT networks, into critical IT systems and OT networks.
Perhaps because of the deep distribution of critical rail systems throughout both IT and OT networks at most operators, the fundamental problem remains that only IT-grade cyber security solutions protect physical operations. The new rules require us to try to detect spam attacks and try to keep up with known-bad Internet destinations. We do this in the “hope” that we can discover and respond to attacks before truly unacceptable consequences are brought about on rail switching systems, the most consequential of our critical systems. The problem here is that “hope” can never pass as an acceptable engineering design practice.
Proper Engineering-Grade Rail Cyber Security
The engineering profession is charged with protecting public safety. Engineering-grade designs do not “hope” that a bridge will carry a specified load for a specified number of decades. Neither should engineering-grade rail cyber security designs “hope” that adversaries can be prevented from switching tracks maliciously and causing trains to collide. Engineering-grade protections are deterministic in that they always provide the same degree of protection, no matter what kind of cyber attack is thrown at them.
The new TSA directive is a step in the right direction security-wise, but rail system operators can both do better than meet the minimum security requirements. A simultaneously simpler and cheaper design is available that meets the new TSA requirements. For a look at Waterfall’s current recommendation at how to provide simple, predictable, and unbreachable protection for network segmentation, please have a look at our guide: Cyber security Imperatives for Vital Rail Networks at Operational Control Centers.
