1 00:00:48,950 --> 00:00:52,550 Welcome to cybersecurity, under pressure, real attacks, real 2 00:00:52,550 --> 00:00:56,040 lessons. Today is Wednesday, June 24th, 3 00:00:56,040 --> 00:00:58,840 2026. Wow, you can't make this up. 4 00:00:59,000 --> 00:01:00,760 Well, you could, but nobody would believe you. 5 00:01:01,600 --> 00:01:05,800 Today we're taking a deep dive into the absolute nightmare that 6 00:01:05,800 --> 00:01:10,120 is OT security remote access, specifically in the railway 7 00:01:10,120 --> 00:01:13,520 sector. Nightmare is well, it's one of 8 00:01:13,520 --> 00:01:15,640 the most technically generous term we could use today. 9 00:01:16,360 --> 00:01:17,880 Honestly, yeah. Oh, absolutely. 10 00:01:18,080 --> 00:01:20,280 Look, if people actually understood how close we are to 11 00:01:20,280 --> 00:01:22,800 the edge on a daily basis, well, they'd probably just start 12 00:01:22,800 --> 00:01:23,520 taking the. Bus right? 13 00:01:23,600 --> 00:01:25,480 Right. And look, if you're listening to 14 00:01:25,480 --> 00:01:27,160 this deep dive, you already know the basics. 15 00:01:27,160 --> 00:01:30,040 You know the threat landscape is evolving, You know what a flat 16 00:01:30,040 --> 00:01:33,640 network is, and you probably have at least a morbid curiosity 17 00:01:33,640 --> 00:01:36,600 about how fragile our critical infrastructure truly is. 18 00:01:36,720 --> 00:01:38,400 Morbid is definitely the right word. 19 00:01:38,760 --> 00:01:41,000 So our mission today, and I'm speaking directly to you, the 20 00:01:41,000 --> 00:01:45,720 listener, is to unpack a massive stack of incredibly dense 21 00:01:45,840 --> 00:01:47,840 engineering and cybersecurity standards. 22 00:01:48,040 --> 00:01:49,840 Dense is putting it mildly. Seriously. 23 00:01:49,960 --> 00:01:54,200 Specifically, we're tearing in the Synalek TS-5 or Seven O 1 24 00:01:54,200 --> 00:02:00,160 and IEC 62443, and we are going to translate these rigid, highly 25 00:02:00,160 --> 00:02:04,240 theoretical frameworks into the terrifying, fascinating reality 26 00:02:04,240 --> 00:02:07,360 of how trains are actually kept safe from adversaries. 27 00:02:07,680 --> 00:02:10,160 And I think we need to set the baseline reality right from the 28 00:02:10,160 --> 00:02:11,400 jump here. Go for it. 29 00:02:11,440 --> 00:02:13,640 When we talk about securing operational technology, 30 00:02:13,640 --> 00:02:16,440 especially rail, we are not talking about Hollywood 31 00:02:16,440 --> 00:02:19,040 scenarios. There is no guy in a dark room 32 00:02:19,040 --> 00:02:23,160 furiously typing on 6 monitors to, you know, bypass a glowing 33 00:02:23,160 --> 00:02:25,040 red firewall and derail a locomotive. 34 00:02:25,120 --> 00:02:26,960 Right, no matrix code raining down. 35 00:02:26,960 --> 00:02:29,480 Exactly. The reality is so much Dumber, 36 00:02:29,560 --> 00:02:32,320 and frankly, that makes it exponentially harder to defend 37 00:02:32,320 --> 00:02:33,920 against. Because you can't predict it. 38 00:02:33,920 --> 00:02:35,400 Right. We aren't just trying to stop an 39 00:02:35,400 --> 00:02:37,760 elite APT group from a hostile nation state. 40 00:02:37,800 --> 00:02:40,560 I mean, yes, we do that, but the everyday threat, we're trying to 41 00:02:40,560 --> 00:02:43,600 stop our own mid level maintenance worker from plugging 42 00:02:43,600 --> 00:02:47,520 a $50 commercial wireless dongle into a critical Control Board. 43 00:02:47,640 --> 00:02:49,840 Just because he didn't feel like walking out into the rain to 44 00:02:49,840 --> 00:02:52,000 check a diagnostic log. Precisely. 45 00:02:52,000 --> 00:02:54,320 It's human nature. So we are fighting human 46 00:02:54,320 --> 00:02:57,280 convenience just as much as we're fighting malicious code. 47 00:02:58,240 --> 00:03:01,120 Which actually brings us to the first major issue we pulled from 48 00:03:01,120 --> 00:03:03,160 the source material. The geography problem. 49 00:03:03,160 --> 00:03:06,760 Yes, the physical geography of railway infrastructure and how 50 00:03:06,760 --> 00:03:10,200 it completely obliterates any traditional concept of an IT 51 00:03:10,200 --> 00:03:14,000 perimeter because, well, in enterprise IT or even in a 52 00:03:14,000 --> 00:03:17,680 manufacturing OT environment, your perimeter is literal, 53 00:03:17,680 --> 00:03:19,160 right? It's a concrete box. 54 00:03:19,160 --> 00:03:21,160 Correct. You secure a car factory. 55 00:03:21,240 --> 00:03:24,280 You have 4 walls. Your robotics, your scatter 56 00:03:24,280 --> 00:03:26,960 systems, your PLCS. They are physically contained. 57 00:03:27,200 --> 00:03:30,520 You put guards at the doors, badge readers on the turnstiles, 58 00:03:30,800 --> 00:03:33,760 maybe a massive next Gen. firewall at your single Internet 59 00:03:33,760 --> 00:03:35,400 gateway. You build a castle. 60 00:03:35,400 --> 00:03:38,760 But a National Rail network? Your perimeter isn't a wall. 61 00:03:39,000 --> 00:03:42,680 Your perimeter is 5000 miles of exposed copper fiber and 62 00:03:42,680 --> 00:03:45,680 trackside boxes stretching across mountain ranges, deep 63 00:03:45,720 --> 00:03:48,480 urban subway tunnels, and desolate rural plains. 64 00:03:48,480 --> 00:03:52,120 You literally have zero physical control over the environment. 65 00:03:52,120 --> 00:03:54,680 Zero. And out in that vast sprawl you 66 00:03:54,680 --> 00:03:56,920 have these things called signaling houses. 67 00:03:57,240 --> 00:03:59,800 The source material focuses heavily on them as a primary 68 00:03:59,800 --> 00:04:01,360 vector. Yes, signaling houses. 69 00:04:01,560 --> 00:04:04,920 I mean, a signaling house is basically an unassuming concrete 70 00:04:04,920 --> 00:04:07,680 or metal shed sitting out in the middle of nowhere. 71 00:04:07,920 --> 00:04:10,680 Like next to a cornfield? Yeah, maybe next to a level 72 00:04:10,680 --> 00:04:15,400 crossing in a cornfield or bolted to the wall of a damp 73 00:04:15,480 --> 00:04:18,399 underground tunnel. Inside that shed is your 74 00:04:18,399 --> 00:04:20,959 critical safety equipment. Stuff like interlocking 75 00:04:20,959 --> 00:04:23,160 controller. Interlocking controllers, track 76 00:04:23,160 --> 00:04:25,520 circuit monitors, communication relays. 77 00:04:25,800 --> 00:04:29,320 It is both a physical access point and a highly sensitive 78 00:04:29,320 --> 00:04:33,000 digital entry point into the backbone of the railway network. 79 00:04:33,160 --> 00:04:36,560 But historically, the defense for these places was just the 80 00:04:36,560 --> 00:04:39,480 legendary air gap, right? Pure isolation. 81 00:04:39,480 --> 00:04:41,000 Right. The idea was that because these 82 00:04:41,000 --> 00:04:43,680 systems weren't hardwired to the Internet, they were untouchable. 83 00:04:43,880 --> 00:04:45,080 Makes sense? True in theory. 84 00:04:45,640 --> 00:04:47,520 Tack it. An attacker would physically 85 00:04:47,520 --> 00:04:50,760 have to break the padlock on the shed, walk inside and plug a 86 00:04:50,760 --> 00:04:53,440 laptop directly into the serial port of a 20 year old 87 00:04:53,440 --> 00:04:55,240 controller. Which honestly sounds pretty 88 00:04:55,240 --> 00:04:58,440 robust until you factor in the operational realities of 89 00:04:58,440 --> 00:05:00,280 maintaining a network that massive. 90 00:05:00,400 --> 00:05:02,920 Precisely. Enter the maintenance crews. 91 00:05:04,440 --> 00:05:06,680 These are the guys responsible for keeping the trains moving 92 00:05:07,280 --> 00:05:10,640 and they have punishing SL as service level agreements. 93 00:05:11,320 --> 00:05:15,160 So if a fault light goes off in a remote signaling house that is 94 00:05:15,160 --> 00:05:17,680 say A5 hour drive from the regional depot and there's a 95 00:05:17,680 --> 00:05:20,080 Blizzard outside. Oh man, I can see exactly where 96 00:05:20,080 --> 00:05:21,840 this is going. It's just human nature, a 97 00:05:21,840 --> 00:05:25,320 maintenance engineer who is probably brilliant at mechanical 98 00:05:25,320 --> 00:05:28,280 systems but completely unaware of modern cyber threat 99 00:05:28,280 --> 00:05:30,440 landscapes. He says to himself. 100 00:05:30,760 --> 00:05:35,240 I am not driving 500 miles round trip just to pull a plain text 101 00:05:35,240 --> 00:05:37,840 diagnostic log ever again. Yeah, you can't blame him. 102 00:05:37,960 --> 00:05:41,480 You really can't. So what does he do the next time 103 00:05:41,480 --> 00:05:44,480 he's out there? He brings a cheap commercial 4G 104 00:05:44,480 --> 00:05:48,480 or 5G cellular modem. He quietly wires it into the 105 00:05:48,480 --> 00:05:51,920 diagnostic port of the trackside Ethernet switch, sets up an 106 00:05:51,920 --> 00:05:54,760 unencrypted remote desktop connection, and goes home. 107 00:05:55,360 --> 00:05:57,040 And he doesn't tell anyone. Never. 108 00:05:57,040 --> 00:05:59,960 He definitely doesn't log a ticket with the CIO sitting in a 109 00:05:59,960 --> 00:06:03,240 glass tower back in the Capitol. So now we have what the industry 110 00:06:03,240 --> 00:06:06,720 calls shadow OT. Shadow OT just saying the phrase 111 00:06:06,720 --> 00:06:10,240 makes my blood pressure spike. I bet the moment that $50 112 00:06:10,240 --> 00:06:13,360 consumer modem boots up and connects to the public cellular 113 00:06:13,360 --> 00:06:17,000 network, the entire multi $1,000,000 air gap collapses. 114 00:06:17,280 --> 00:06:20,240 All your enterprise firewalls, your intrusion detection 115 00:06:20,240 --> 00:06:23,320 systems, your SoC completely bypassed. 116 00:06:23,320 --> 00:06:25,640 Wait, so we spend millions building a digital digital 117 00:06:25,640 --> 00:06:28,920 fortress and the drawbridge is essentially lowered by our own 118 00:06:28,920 --> 00:06:31,440 guy who just wanted to save gas money? 119 00:06:31,440 --> 00:06:34,640 That is exactly what happens. Physical convenience Trump's 120 00:06:34,640 --> 00:06:38,120 cybersecurity every single time. And because we all know the 121 00:06:38,120 --> 00:06:41,160 nightmare of legacy flat networks, the implications here 122 00:06:41,160 --> 00:06:43,680 are catastrophic. I mean, listeners know that 123 00:06:43,680 --> 00:06:47,080 without micro segmentation, East West traffic is essentially a 124 00:06:47,080 --> 00:06:50,120 free for all. If I'm an attacker and I pop a 125 00:06:50,120 --> 00:06:53,840 weak lobby Wi-Fi in a corporate network, modern zero trust 126 00:06:53,840 --> 00:06:56,520 architecture usually stops me from pivoting into the HR 127 00:06:56,520 --> 00:06:59,160 database. But in a rail OT environment. 128 00:06:59,280 --> 00:07:01,240 There is no internal segmentation. 129 00:07:01,520 --> 00:07:03,920 You have to remember the era these systems were designed in. 130 00:07:04,200 --> 00:07:07,240 Legacy OT systems were built on the fundamental assumption of 131 00:07:07,320 --> 00:07:10,720 absolute inherent trust. Meaning if you're in, you're 132 00:07:10,720 --> 00:07:11,880 trusted. Right. 133 00:07:12,520 --> 00:07:16,360 If a device is on the wire, it is assumed to be a trusted piece 134 00:07:16,360 --> 00:07:19,360 of safety equipment. There's no authentication header 135 00:07:19,360 --> 00:07:23,320 on a Modbus TCP packet, it just executes the command. 136 00:07:23,600 --> 00:07:28,200 So if that maintenance worker's cheap 4G modem gets scanned on 137 00:07:28,200 --> 00:07:33,320 Show Dan and compromised by an automated botnet, the attacker 138 00:07:33,320 --> 00:07:35,760 doesn't just get to see a diagnostic log. 139 00:07:35,760 --> 00:07:39,600 No, no, They are sitting on a flat, unsegmented network that 140 00:07:39,600 --> 00:07:41,640 connects directly to the interlocking systems. 141 00:07:42,120 --> 00:07:44,960 They are on the backbone from that compromised cellular 142 00:07:44,960 --> 00:07:47,360 router. They can theoretically and in 143 00:07:47,360 --> 00:07:49,800 many legacy architectures, practically jump straight to the 144 00:07:49,800 --> 00:07:52,080 radio block center. And since the radio block center 145 00:07:52,080 --> 00:07:55,320 communicates with the onboard train control and management 146 00:07:55,320 --> 00:07:57,640 system. The PCMS, yes, you have a 147 00:07:57,640 --> 00:08:00,800 potential unfiltered pathway right to the train's dynamic 148 00:08:00,800 --> 00:08:03,040 braking system. All because a guy didn't want to 149 00:08:03,040 --> 00:08:05,000 drive in the snow. You know, it's wild to think 150 00:08:05,000 --> 00:08:06,320 about. I'm just thinking about how 151 00:08:06,320 --> 00:08:10,280 often we bypass security in our own daily lives just for a tiny 152 00:08:10,280 --> 00:08:12,000 fraction of convenience. All the time. 153 00:08:12,200 --> 00:08:14,440 Reusing a password across three accounts. 154 00:08:14,480 --> 00:08:17,280 We're disabling MFA on a trusted device because we're tired of 155 00:08:17,280 --> 00:08:19,400 checking our phones. It's the exact same 156 00:08:19,400 --> 00:08:23,120 psychological impulse. It is, but the blast radius is 157 00:08:23,120 --> 00:08:24,360 slightly different. Fairpoint. 158 00:08:24,680 --> 00:08:27,200 If you reuse a password, maybe your credit card gets cloned. 159 00:08:27,800 --> 00:08:31,280 In the railway sector, bypassing security for convenience 160 00:08:31,280 --> 00:08:34,600 translates to kinetic physical disaster. 161 00:08:35,080 --> 00:08:37,919 You have thousands of tons of steel moving at 300 kilometers 162 00:08:37,919 --> 00:08:40,080 an hour, carrying hundreds of passengers. 163 00:08:40,799 --> 00:08:43,960 The gap between convenience and derailment is terrifyingly 164 00:08:43,960 --> 00:08:46,080 narrow. Which naturally leads to the 165 00:08:46,080 --> 00:08:49,360 most infuriating question for any IT security professional 166 00:08:49,360 --> 00:08:51,520 listening. If you know these rogue modems 167 00:08:51,520 --> 00:08:54,160 are out there, why not just scan the network, find the 168 00:08:54,160 --> 00:08:56,800 unauthorized MA addresses, and shut them down? 169 00:08:57,520 --> 00:09:00,120 But the source material specifically and repeatedly 170 00:09:00,120 --> 00:09:03,400 warns against active probing. It highlights this absolute 171 00:09:03,400 --> 00:09:07,000 philosophical war between traditional IT security and OT 172 00:09:07,000 --> 00:09:08,240 engineering. Oh, it's a war. 173 00:09:08,520 --> 00:09:11,600 It is a holy war and the two sides speak completely mutually 174 00:09:11,600 --> 00:09:14,240 unintelligible languages. Let's look at the foundational 175 00:09:14,240 --> 00:09:17,520 frameworks. In traditional IT security, the 176 00:09:17,520 --> 00:09:20,720 entire universe revolves around the CIA triad. 177 00:09:21,160 --> 00:09:24,280 Confidentiality, integrity, availability. 178 00:09:24,400 --> 00:09:26,040 In that exact order. Right. 179 00:09:26,440 --> 00:09:30,280 If there is a suspected breach, it's immediate reflexive 180 00:09:30,280 --> 00:09:33,320 response is to protect the confidentiality of the data. 181 00:09:33,600 --> 00:09:36,560 You sever the connection, you lock out the users, you take the 182 00:09:36,560 --> 00:09:39,120 server offline. Right, but if you take an OT 183 00:09:39,120 --> 00:09:42,240 system offline trains. Simple as that. 184 00:09:42,320 --> 00:09:44,920 Simple as that. OT engineers, the people 185 00:09:44,920 --> 00:09:48,360 actually managing the physical physics of the railway, will 186 00:09:48,360 --> 00:09:52,800 aggressively counter your CIA triad with Rams reliability, 187 00:09:52,800 --> 00:09:55,240 availability, maintainability and safety. 188 00:09:55,440 --> 00:09:57,640 Notice what's missing? Confidentiality doesn't even 189 00:09:57,640 --> 00:09:59,560 make the list. They literally don't care if 190 00:09:59,560 --> 00:10:01,320 someone reads the data. Not even a little bit. 191 00:10:01,560 --> 00:10:04,520 An OT engineer doesn't care if a hacker intercepts the telemetry 192 00:10:04,520 --> 00:10:07,040 data of a track switch. Because it's just telemetry. 193 00:10:07,200 --> 00:10:08,800 Right. They care that the switch 194 00:10:08,800 --> 00:10:12,360 physically moves when it is mathematically scheduled to move 195 00:10:12,960 --> 00:10:15,560 every single time without a millisecond of deviation. 196 00:10:16,120 --> 00:10:17,960 Safety and reliability are paramount. 197 00:10:18,240 --> 00:10:21,360 If an IT guy shuts down the network to quote UN quote 198 00:10:21,360 --> 00:10:24,680 protect IT, they've just violated the OT core requirement 199 00:10:25,360 --> 00:10:27,720 availability. So what actually happens when an 200 00:10:27,720 --> 00:10:31,320 overzealous IT security team decides they want to secure the 201 00:10:31,320 --> 00:10:34,040 railway network using their standard enterprise tools? 202 00:10:34,520 --> 00:10:36,640 Say a new CI. So comes in and says hey, we're 203 00:10:36,640 --> 00:10:39,680 going to run and map across the whole subnet to find these rogue 204 00:10:39,680 --> 00:10:42,160 modems. Absolute, unmitigated disaster. 205 00:10:42,160 --> 00:10:44,680 Tell me the source documents detail this beautifully. 206 00:10:44,680 --> 00:10:47,640 We call it active probing in an enterprise IT environment. 207 00:10:47,640 --> 00:10:50,360 You run a vulnerability scan, you ping an IP address, you 208 00:10:50,360 --> 00:10:53,280 check for open ports, and the server just replies here I am 209 00:10:53,280 --> 00:10:56,560 and goes about its business. The TCPI IP stack on a modern 210 00:10:56,560 --> 00:10:58,960 server can handle millions of concurrent connections. 211 00:10:59,080 --> 00:11:02,920 But the TCT IP stack on a legacy programmable logic controller. 212 00:11:02,920 --> 00:11:06,200 Is virtually non existent. We are talking about legacy 213 00:11:06,200 --> 00:11:09,480 serial to IP converters and communication protocols like 214 00:11:09,480 --> 00:11:13,640 Prophibus running on PLCS that have microprocessors from 1998. 215 00:11:13,880 --> 00:11:16,880 1998. Yeah, these devices are designed 216 00:11:16,880 --> 00:11:21,080 to do 1 highly specific mathematical control loop over 217 00:11:21,080 --> 00:11:22,680 and over again deterministically. 218 00:11:23,120 --> 00:11:25,240 They have incredibly tiny memory buffer. 219 00:11:25,760 --> 00:11:28,280 Right, so the networking stack on those old chips just isn't 220 00:11:28,280 --> 00:11:31,480 built to handle malformed packets or active probes or 221 00:11:31,480 --> 00:11:33,440 rapid connection requests. Exactly. 222 00:11:33,640 --> 00:11:37,200 When the IT vulnerability scanner hits that legacy PLC 223 00:11:37,320 --> 00:11:41,480 with a barrage of active SYN requests, the PLCS networking 224 00:11:41,480 --> 00:11:44,320 stack simply cannot process the unexpected traffic. 225 00:11:44,880 --> 00:11:49,400 The buffer instantly overflows, the processor spikes to 100% 226 00:11:49,400 --> 00:11:52,800 utilization, and the device goes into what we call a freeze in 227 00:11:52,800 --> 00:11:55,320 state failure. It essentially has a digital 228 00:11:55,320 --> 00:11:57,320 panic attack and completely locks up. 229 00:11:57,320 --> 00:11:59,840 It drops the control loop entirely, and in a safety 230 00:11:59,840 --> 00:12:02,320 critical system, a frozen controller means the system 231 00:12:02,320 --> 00:12:03,880 doesn't know where the train is anymore. 232 00:12:04,080 --> 00:12:07,440 The feel safe protocol kicks in and the system halts everything. 233 00:12:07,520 --> 00:12:09,240 It's like trying. To change the tires on a car 234 00:12:09,240 --> 00:12:11,840 while it's driving at 100 miles an hour on the highway, Pretty 235 00:12:11,840 --> 00:12:14,840 much you're trying to inject modern disruptive security 236 00:12:14,840 --> 00:12:17,560 controls into a kinetic process that physically, physically 237 00:12:17,560 --> 00:12:19,520 cannot pause for even a microsecond. 238 00:12:19,720 --> 00:12:21,920 That's a great way to look at it, and it's not just scanning 239 00:12:22,240 --> 00:12:24,320 the source material. Highlights another massive 240 00:12:24,320 --> 00:12:27,080 systemic issue, latency. Right latency. 241 00:12:27,320 --> 00:12:30,880 Let's say IT decides, OK, no scanning, but we are going to 242 00:12:30,880 --> 00:12:34,760 put a standard next Gen. firewall in line between the 243 00:12:34,760 --> 00:12:37,600 trackside equipment and the central control room to block 244 00:12:37,600 --> 00:12:40,240 unauthorized remote access. Makes sense on paper. 245 00:12:40,240 --> 00:12:44,400 On paper, in the IT world, if a firewall introduces A200 246 00:12:44,400 --> 00:12:47,400 millisecond latency spike while it performs deep packet 247 00:12:47,400 --> 00:12:52,280 inspection on a payload, nobody cares. 200 milliseconds is a 248 00:12:52,320 --> 00:12:56,240 minor, completely unnoticeable lag on a zoom call or, you know, 249 00:12:56,400 --> 00:12:58,920 loading a cloud application. But in the European train 250 00:12:58,920 --> 00:13:02,240 control system. In ETCS, timing is literally 251 00:13:02,280 --> 00:13:05,040 life or death. The system relies on continuous 252 00:13:05,040 --> 00:13:08,000 real time communication between the train and the radio block 253 00:13:08,000 --> 00:13:10,360 center. If that new inline firewall 254 00:13:10,360 --> 00:13:13,920 delays an ETCS packet by 200 milliseconds, the train's 255 00:13:13,920 --> 00:13:17,080 onboard computer registers a loss of continuous communication 256 00:13:17,200 --> 00:13:19,000 the track. And let me guess, the train 257 00:13:19,000 --> 00:13:21,640 doesn't just buffer and wait for the connection to re establish? 258 00:13:21,920 --> 00:13:25,360 No, it enters a fail safe mode. It triggers the emergency 259 00:13:25,360 --> 00:13:28,320 brakes, pneumatic air valves open, pressure drops, and the 260 00:13:28,320 --> 00:13:32,120 train clamps down over a 200 millisecond packet delay. 261 00:13:32,360 --> 00:13:35,160 Unbelievable. So traditional IT security is 262 00:13:35,160 --> 00:13:39,160 like a doctor trying to cure a patient's mild cough with a 263 00:13:39,160 --> 00:13:41,440 medicine that accidentally stops their heart. 264 00:13:41,480 --> 00:13:43,720 Exactly. Your IT security control 265 00:13:43,720 --> 00:13:46,480 designed to keep the train safe just caused a fully loaded 266 00:13:46,480 --> 00:13:50,160 passenger train to dump its air brakes and violently skid to a 267 00:13:50,160 --> 00:13:51,440 halt in the middle of the main line. 268 00:13:51,880 --> 00:13:54,680 You've stranded passengers, disrupted the entire regional 269 00:13:54,680 --> 00:13:58,880 timetable and created a massive physical hazard, all in the name 270 00:13:58,880 --> 00:14:01,080 of cybersecurity. It's unbelievable and it's 271 00:14:01,080 --> 00:14:03,640 compounded by what the documents referred to as the 30 year 272 00:14:03,640 --> 00:14:06,440 problem, the patching paradox. The bane of my existence. 273 00:14:06,640 --> 00:14:10,000 Oh yeah, an IT server has a life cycle of maybe three to five 274 00:14:10,000 --> 00:14:13,280 years before it's decommissioned and replaced a railway 275 00:14:13,280 --> 00:14:16,560 interlocking system. The complex logic that ensures 2 276 00:14:16,560 --> 00:14:19,880 trains can literally never be routed onto the same track 277 00:14:19,880 --> 00:14:23,080 segment at the same time has a life cycle of 30 to 40 years. 278 00:14:23,320 --> 00:14:27,120 It is rigorously mathematically tested, certified by an 279 00:14:27,120 --> 00:14:30,440 independent safety assessment board, and then permanently 280 00:14:30,440 --> 00:14:32,560 locked down. I want to read a specific quote 281 00:14:32,560 --> 00:14:34,840 from our research on this because it really crystallizes 282 00:14:34,840 --> 00:14:36,840 the insanity of the situation. Quote. 283 00:14:38,280 --> 00:14:41,040 Install a security update on a critical interlocking system 284 00:14:41,040 --> 00:14:43,560 without CAB approval and you don't just avoid a 285 00:14:43,560 --> 00:14:47,160 certification, you risk triggering a mechanical response 286 00:14:47,160 --> 00:14:50,440 on live tracks that the safety case never anticipated. 287 00:14:50,920 --> 00:14:54,280 The patch closes ACVE it opens a hazard. 288 00:14:54,560 --> 00:14:57,000 End Quote. That is the crux of the entire 289 00:14:57,000 --> 00:15:00,400 ITOT conflict right there. A CVE is a common 290 00:15:00,400 --> 00:15:03,280 vulnerabilities and exposures logging a known software bug. 291 00:15:03,800 --> 00:15:05,520 IT demands you patch it immediately. 292 00:15:05,880 --> 00:15:09,640 CISA might even legally mandate that you catch it within 14 days 293 00:15:09,640 --> 00:15:11,640 if it's a known exploited vulnerability. 294 00:15:11,720 --> 00:15:15,000 Right, but legally from the OT side, how do they square that? 295 00:15:15,000 --> 00:15:17,160 If you change the code, you invalidate the safety 296 00:15:17,160 --> 00:15:20,000 certification you do. You no longer mathematically 297 00:15:20,000 --> 00:15:23,240 know for a fact how that system will behave under stress. 298 00:15:23,800 --> 00:15:25,680 The Safety Board signed off on version one, point O. 299 00:15:26,360 --> 00:15:30,320 If you push version 1.1 over the air to fix a remote execution 300 00:15:30,320 --> 00:15:33,680 bug, you are operating an uncertified, technically illegal 301 00:15:33,680 --> 00:15:36,560 safety system. That is a massive catch 22. 302 00:15:36,680 --> 00:15:38,960 It is OT. Engineers will fight tooth and 303 00:15:38,960 --> 00:15:41,360 nail against IT patching mandates because an unpatched 304 00:15:41,360 --> 00:15:43,000 system is vulnerable to a hacker. 305 00:15:43,520 --> 00:15:46,040 But a patch system is essentially uncertified, 306 00:15:46,440 --> 00:15:48,760 unpredictable, and potentially lethal. 307 00:15:48,880 --> 00:15:52,120 So we have geographic sprawl, rogue shadow modems, flat 308 00:15:52,120 --> 00:15:55,200 networks, devices that crash if you scan them, firewalls that 309 00:15:55,200 --> 00:15:57,960 trigger emergency brakes, and systems that you are legally 310 00:15:57,960 --> 00:15:59,840 forbidden to patch. Sounds fine, right? 311 00:15:59,840 --> 00:16:03,280 Which begs the question, is this just a theoretical academic 312 00:16:03,280 --> 00:16:05,520 exercise? Are adversaries actually 313 00:16:05,520 --> 00:16:07,760 exploiting the specific friction? 314 00:16:07,880 --> 00:16:09,600 I wish it were just an academic debate. 315 00:16:09,640 --> 00:16:12,080 It is not. The threat landscape we're 316 00:16:12,080 --> 00:16:14,160 reviewing here proves this is happening right now. 317 00:16:14,360 --> 00:16:17,160 You've pulled 3 case studies from the sources that highlight 318 00:16:17,160 --> 00:16:20,320 completely different vectors of this exact vulnerability. 319 00:16:20,600 --> 00:16:22,600 Let's start with Denmark late 2022. 320 00:16:22,760 --> 00:16:26,480 Right late 2022, trains across the entire country of Denmark 321 00:16:26,480 --> 00:16:30,320 were suddenly halted for hours. Complete nationwide systemic 322 00:16:30,320 --> 00:16:32,880 disruption. But the terrifying part is how 323 00:16:32,880 --> 00:16:35,280 it happened. It wasn't a direct attack on the 324 00:16:35,280 --> 00:16:38,400 trains, tracks, the signaling houses or the physical OT 325 00:16:38,400 --> 00:16:40,080 network. Then what forced the stop? 326 00:16:40,520 --> 00:16:43,640 They attacked an IT subcontractor, specifically a 327 00:16:43,640 --> 00:16:46,760 software vendor named Suvani that provided a testing 328 00:16:46,760 --> 00:16:49,280 environment for a train dispatching application. 329 00:16:50,120 --> 00:16:53,040 The subcontractor suffered a cyber attack and to contain the 330 00:16:53,040 --> 00:16:56,120 blast radius, they isolated and shut down their servers. 331 00:16:56,400 --> 00:16:59,320 But wait, why did the physical trains stop if the tracks 332 00:16:59,320 --> 00:17:01,520 weren't hacked? If it's just a dispatching app 333 00:17:01,520 --> 00:17:04,480 in a third party cloud. Because of the deep operational 334 00:17:04,480 --> 00:17:07,400 dependencies of modern rail architecture under systems like 335 00:17:07,400 --> 00:17:10,440 ETMS Level 2, dispatching schedules and safety protocols 336 00:17:10,440 --> 00:17:13,520 are completely interlocked. The train drivers rely on 337 00:17:13,520 --> 00:17:16,920 cryptographic token validation and real time updates pushed to 338 00:17:16,920 --> 00:17:18,680 their tablets from those servers. 339 00:17:19,520 --> 00:17:22,440 When the Suvani subcontractor went down, it wasn't just 340 00:17:22,560 --> 00:17:26,000 servers off, it meant the dispatchers lost visibility and 341 00:17:26,000 --> 00:17:28,920 control of mathematical safety margins between trains. 342 00:17:29,480 --> 00:17:32,400 If you can't guarantee the safety margin, the rule is you 343 00:17:32,400 --> 00:17:35,000 halt the train. So this perfectly illustrates 344 00:17:35,000 --> 00:17:38,120 the massive vulnerability of third party remote access and 345 00:17:38,120 --> 00:17:42,480 supply chain concentration risk. You can spend a billion dollars 346 00:17:42,480 --> 00:17:45,160 securing your physical rail network with data diodes and 347 00:17:45,160 --> 00:17:48,480 armed guards, but if the cloud vendor who supplies your 348 00:17:48,480 --> 00:17:51,800 operational diagnostic software gets hit with ransomware, you 349 00:17:51,800 --> 00:17:53,360 are still completely dead in the water. 350 00:17:53,360 --> 00:17:55,440 Exactly. You are outsourcing your 351 00:17:55,440 --> 00:17:58,680 availability risk to a vendor who might be prioritizing their 352 00:17:58,680 --> 00:18:01,840 own data confidentiality over your physical uptime. 353 00:18:02,160 --> 00:18:04,040 OK, let's look at a completely different director. 354 00:18:04,040 --> 00:18:06,240 Poland 2023. This is the one that actually 355 00:18:06,240 --> 00:18:09,040 gave me chills when I read the report because it bypasses the 356 00:18:09,040 --> 00:18:11,720 IP network entirely. We are worried about elite cyber 357 00:18:11,720 --> 00:18:14,360 syndicates and a couple of guys with off the shelf walkie 358 00:18:14,360 --> 00:18:17,400 talkies brought 20 trains to a screeching halt. 359 00:18:17,640 --> 00:18:20,200 This is the one that keeps OT engineers awake at night. 360 00:18:21,800 --> 00:18:24,640 Saboteurs didn't use sophisticated IP hacking. 361 00:18:24,840 --> 00:18:27,960 They didn't breach a firewall. They didn't fish a password. 362 00:18:28,120 --> 00:18:31,480 They used cheap analog radios. That is just nuts. 363 00:18:31,480 --> 00:18:35,160 They tuned into the unencrypted VHF radio frequencies used by 364 00:18:35,160 --> 00:18:38,640 the Polish railway network and broadcast unauthorized radio 365 00:18:38,640 --> 00:18:40,880 stop signals. Detail the mechanics of that. 366 00:18:41,040 --> 00:18:44,680 A radio stop signal is just an emergency command sent over open 367 00:18:44,680 --> 00:18:47,520 airwaves. Yes, it's a legacy analog safety 368 00:18:47,520 --> 00:18:50,000 feature. In an emergency, if there's an 369 00:18:50,000 --> 00:18:53,480 obstruction on the track, a train driver or a dispatcher can 370 00:18:53,480 --> 00:18:57,560 broadcast a specific sequence of three audio tones over the VHF 371 00:18:57,560 --> 00:18:58,800 radio. Just three tones. 372 00:18:58,840 --> 00:19:01,320 Just three tones. Any train receiver in a 10 373 00:19:01,320 --> 00:19:04,760 kilometer radius that hears those 3 tones will automatically 374 00:19:04,760 --> 00:19:06,560 instantly trigger its emergency brakes. 375 00:19:06,640 --> 00:19:08,240 And it's unauthenticated by design, right? 376 00:19:08,240 --> 00:19:10,640 Because in an emergency, you don't have time for a digital 377 00:19:10,640 --> 00:19:12,280 handshake. Exactly. 378 00:19:12,320 --> 00:19:14,680 You can't wait for a cryptographic key exchange when 379 00:19:14,680 --> 00:19:16,560 you're about to hit a derailed freight car. 380 00:19:17,560 --> 00:19:19,800 The attackers exploited the safety first design. 381 00:19:20,040 --> 00:19:22,600 They recorded those 3 tones and just played them back over the 382 00:19:22,600 --> 00:19:25,080 airwaves using off the shelf walkie talkies. 383 00:19:25,360 --> 00:19:28,520 Imagine you're the driver. You're doing 120 kilometers an 384 00:19:28,520 --> 00:19:30,960 hour at night. The cab is quiet. 385 00:19:31,600 --> 00:19:34,640 Suddenly 3 analog tones blast over the radio. 386 00:19:34,640 --> 00:19:36,960 Boop, beep, boop. And before you can even touch 387 00:19:36,960 --> 00:19:39,840 the console, the main brake pipe vents to the atmosphere. 388 00:19:40,440 --> 00:19:42,480 The entire train violently shutters. 389 00:19:42,600 --> 00:19:45,200 Sparks fly off the wheels and you're skidding in the dark. 390 00:19:45,440 --> 00:19:47,480 And you look at the dispatch board and there's no 391 00:19:47,560 --> 00:19:49,720 construction, just ghost signals. 392 00:19:50,080 --> 00:19:54,720 Over 20 trains halted massive cascading disruption and it 393 00:19:54,720 --> 00:19:58,040 bypassed all the multi $1,000,000 IT network defenses 394 00:19:58,040 --> 00:20:00,080 entirely. It didn't matter how good your 395 00:20:00,080 --> 00:20:03,120 next Gen. firewalls were or if you had zero trust implemented 396 00:20:03,120 --> 00:20:05,720 on your corporate laptops because the attack came to the 397 00:20:05,720 --> 00:20:08,720 airwaves on an analog frequency from the 1970s. 398 00:20:09,720 --> 00:20:12,880 It perfectly highlights how mixing old, unencrypted kinetic 399 00:20:12,880 --> 00:20:15,320 technology with modern infrastructure creates a 400 00:20:15,320 --> 00:20:18,960 massive, glaring blind spot. Secure the digital front door 401 00:20:18,960 --> 00:20:21,960 with biometric retina standards and they just walk right through 402 00:20:21,960 --> 00:20:23,560 the analog screen door in the back. 403 00:20:23,680 --> 00:20:26,520 Exactly. And for our third example, let's 404 00:20:26,520 --> 00:20:30,240 look at the SFMTA attack in San Francisco in 2016. 405 00:20:30,920 --> 00:20:35,560 This is a classic IT incident, laterally cascading into an OT 406 00:20:35,560 --> 00:20:38,920 operational nightmare. Ransomware infected the 407 00:20:38,920 --> 00:20:41,480 Municipal Transport Agency's IT network. 408 00:20:41,480 --> 00:20:42,840 I remember reading about this one. 409 00:20:43,040 --> 00:20:46,040 Right now it didn't breach the OT systems controlling the 410 00:20:46,040 --> 00:20:47,680 trains. The trains could still safely 411 00:20:47,680 --> 00:20:51,280 drive, but it laterally moved into and disabled the ticketing 412 00:20:51,280 --> 00:20:53,720 and fare collection servers. The screens on the ticket 413 00:20:53,720 --> 00:20:55,960 machines just showed a ransom note, right? 414 00:20:56,040 --> 00:20:58,360 And they had to leave the physical fare gates open for 415 00:20:58,360 --> 00:20:59,400 days. Right. 416 00:20:59,640 --> 00:21:01,680 And they didn't leave them open just out of generosity. 417 00:21:02,200 --> 00:21:05,320 If the Farrah capes are locked and thousands of commuters are 418 00:21:05,320 --> 00:21:08,320 pouring into a subterranean station during rush hour, you 419 00:21:08,320 --> 00:21:10,360 create a massive physical crush hazard. 420 00:21:10,720 --> 00:21:13,400 People can't get to the platforms, the stairs back up 421 00:21:13,400 --> 00:21:14,760 and you have a life safety situation. 422 00:21:14,800 --> 00:21:16,920 That makes sense. To prevent that physical safety 423 00:21:16,920 --> 00:21:20,080 hazard, they had to force open the fare gates and let everyone 424 00:21:20,080 --> 00:21:22,960 ride for free. It's a perfect example of how a 425 00:21:22,960 --> 00:21:27,720 purely digital IT ransomware event rapidly translates into 426 00:21:27,720 --> 00:21:31,480 physical operational degradation and massive revenue loss. 427 00:21:31,480 --> 00:21:34,000 So just sit with this chilling thought for a moment. 428 00:21:34,200 --> 00:21:38,760 What are critical infrastructure relies on opaque global multi 429 00:21:38,760 --> 00:21:41,720 tier supply chains and mixed era technologies. 430 00:21:42,160 --> 00:21:45,280 How do you even know who has remote access to your systems? 431 00:21:45,400 --> 00:21:47,320 The software vendor in another country? 432 00:21:47,680 --> 00:21:50,000 The manufacturer of the legacy radio system? 433 00:21:50,240 --> 00:21:51,960 The guy who installed the ticketing server. 434 00:21:52,000 --> 00:21:54,240 The terrifying answer is usually you don't. 435 00:21:54,480 --> 00:21:56,400 You simply don't know all your dependencies. 436 00:21:56,800 --> 00:21:59,120 And that is exactly why the industry realized they couldn't 437 00:21:59,120 --> 00:22:01,800 just keep patching holes, They needed a radical new 438 00:22:01,800 --> 00:22:03,960 mathematical way of managing this risk. 439 00:22:04,040 --> 00:22:06,600 All right, let's pivot to the solution, because otherwise this 440 00:22:06,600 --> 00:22:08,680 is just a very depressing hour of horror stories. 441 00:22:08,840 --> 00:22:11,520 If patching is illegal because it voids safety certs and the 442 00:22:11,520 --> 00:22:14,520 perimeter is 5000 miles of open countryside, what is the 443 00:22:14,520 --> 00:22:17,920 industry actually doing? This is where the Cinelec TS5O O 444 00:22:17,920 --> 00:22:19,480 seven O 1 standard comes into play. 445 00:22:20,960 --> 00:22:24,480 DS5771. This technical specification is 446 00:22:24,480 --> 00:22:27,120 currently the absolute gold standard for railway 447 00:22:27,120 --> 00:22:30,160 cybersecurity. What makes it brilliant isn't 448 00:22:30,160 --> 00:22:32,600 that it invents some magical new security hardware. 449 00:22:32,600 --> 00:22:34,760 OK, then what is it? It's brilliant because it 450 00:22:34,760 --> 00:22:38,080 mathematically and procedurally forces cybersecurity directly 451 00:22:38,080 --> 00:22:41,160 into the existing functional safety life cycle, which is 452 00:22:41,160 --> 00:22:44,360 governed by an older standard called EN 50126. 453 00:22:44,640 --> 00:22:47,080 Unpack that for us. How does it actually work in 454 00:22:47,080 --> 00:22:49,480 practice? First, it completely stops 455 00:22:49,480 --> 00:22:52,440 treating the railway as one giant unmanageable monolith. 456 00:22:52,680 --> 00:22:54,000 You don't try to secure the railway. 457 00:22:54,920 --> 00:22:58,720 TS5O7 der one forces engineers to define very specific zones, 458 00:22:58,720 --> 00:23:00,720 called the CC or system under consideration. 459 00:23:00,880 --> 00:23:03,600 So you break the element down into manageable chunks. 460 00:23:03,600 --> 00:23:05,360 Exactly. You define the onboard zone, 461 00:23:05,360 --> 00:23:07,320 which is the physical train itself, the train control and 462 00:23:07,320 --> 00:23:09,160 management system, the passenger Wi-Fi. 463 00:23:09,520 --> 00:23:11,720 Then you define the trackside zone, the interlockings, the 464 00:23:11,720 --> 00:23:14,840 bells is on the track, the radio block centers, and finally the 465 00:23:14,840 --> 00:23:17,200 central zone, the scatter systems, the traffic management 466 00:23:17,200 --> 00:23:20,360 systems back at headquarters. OK, so once you've logically 467 00:23:20,360 --> 00:23:24,240 zoned it out, how do you fix the cultural and legal conflict 468 00:23:24,240 --> 00:23:27,680 between the 25 year old IT SoC analyst who wants to patch 469 00:23:27,680 --> 00:23:31,120 everything and the 60 year old railway safety engineer who 470 00:23:31,120 --> 00:23:33,960 refuses to let them touch it? You force them into a room 471 00:23:33,960 --> 00:23:36,360 together to do what's called safety, Security, Co 472 00:23:36,360 --> 00:23:39,400 engineering. This is the entire beating heart 473 00:23:39,440 --> 00:23:42,240 of TS-10 at 7:01. Sounds intense. 474 00:23:42,240 --> 00:23:44,080 Oh it is. Historically, the safety 475 00:23:44,080 --> 00:23:47,440 engineer would do a system hazard analysis for SHA to 476 00:23:47,440 --> 00:23:50,120 figure out what could mechanically cause the train to 477 00:23:50,120 --> 00:23:53,320 crash, like a brake pad wearing out or relay failing. 478 00:23:53,520 --> 00:23:55,440 They use things like fault tree analysis, right? 479 00:23:55,560 --> 00:23:58,640 Calculating the probability of a mechanical failure based on wear 480 00:23:58,640 --> 00:24:00,680 and tear physics. Exactly and completely 481 00:24:00,680 --> 00:24:03,280 separately in another building, the security guy would do a 482 00:24:03,280 --> 00:24:06,440 threat analysis and risk assessment or Tara to figure out 483 00:24:06,440 --> 00:24:09,240 what could be hacked, calculating likelihood times 484 00:24:09,240 --> 00:24:11,240 impact. And the mathematical models 485 00:24:11,240 --> 00:24:13,800 never overlapped. I mean, how do you integrate a 486 00:24:13,800 --> 00:24:17,200 cyber threat vector, which is a deterministic intelligent action 487 00:24:17,200 --> 00:24:20,040 by a hacker into a purely mechanical folk tree? 488 00:24:20,160 --> 00:24:23,800 It used to be impossible. Co engineering forces you to 489 00:24:23,800 --> 00:24:27,800 mathematically weave the SHA into the Terra using a unified 490 00:24:27,800 --> 00:24:31,040 matrix. The ultimate unbreakable rule 491 00:24:31,040 --> 00:24:33,840 that TS5O7O1 establishes is this. 492 00:24:34,600 --> 00:24:38,080 A security control must never violate a safety invariant. 493 00:24:38,320 --> 00:24:41,080 Give me a concrete example of a safety invariant interacting 494 00:24:41,080 --> 00:24:43,920 with the security control. OK, a safety invariant is a hard 495 00:24:43,920 --> 00:24:47,600 mathematical rule, like if trackside communication is lost 496 00:24:47,600 --> 00:24:50,240 for more than two seconds, the train must immediately apply the 497 00:24:50,240 --> 00:24:52,960 emergency brake. So if the IT security team 498 00:24:52,960 --> 00:24:55,120 proposes adding a heavy encryption layer to the 499 00:24:55,120 --> 00:24:58,120 trackside communication to stop spoofing, they have to 500 00:24:58,120 --> 00:25:00,920 mathematically prove in the Terra that the cryptographic 501 00:25:00,920 --> 00:25:04,520 processing time will never, under any CPU load, exceed that 502 00:25:04,600 --> 00:25:07,200 A2 second safety invariant. Because if the encryption takes 503 00:25:07,200 --> 00:25:10,760 2.1 seconds to process, the safety logic assumes the 504 00:25:10,760 --> 00:25:12,360 connection is dead and stops the train. 505 00:25:12,480 --> 00:25:13,760 Right. So if they can't prove it 506 00:25:13,760 --> 00:25:16,320 mathematically, the security control is outright rejected. 507 00:25:16,560 --> 00:25:19,120 Safety always, always wins. That makes total sense on a 508 00:25:19,120 --> 00:25:22,360 systemic level, but what about the remote access problem? 509 00:25:22,560 --> 00:25:25,520 What about the maintenance guy with the 4G modem? 510 00:25:25,760 --> 00:25:29,080 Or the cloud vendor who needs to pull diagnostic logs. 511 00:25:29,360 --> 00:25:33,040 TS5O7O1 lays down brutal guardrails for vendor remote 512 00:25:33,040 --> 00:25:35,800 access, specifically targeting predictive maintenance 513 00:25:35,800 --> 00:25:38,560 pipelines. The standard dictates that any 514 00:25:38,560 --> 00:25:41,720 vendor remote access can no longer be a persistent always 515 00:25:41,720 --> 00:25:45,280 open backdoor. It mandates 4 strict conditions. 516 00:25:45,760 --> 00:25:49,440 Access must be requested, logged, time limited and require 517 00:25:49,440 --> 00:25:52,080 multi factor authentication. So instead of letting vendors 518 00:25:52,080 --> 00:25:55,240 just leave an unmonitored backdoor open for 30 years, we 519 00:25:55,240 --> 00:25:58,040 are forcing them into a digital prenup where they have to 520 00:25:58,040 --> 00:26:00,960 explicitly ask permission every single time they want to look at 521 00:26:00,960 --> 00:26:02,760 the engine data. Digital prenup. 522 00:26:02,760 --> 00:26:05,040 I like that. Yes, the vendor has to call the 523 00:26:05,040 --> 00:26:08,160 central control room, request a maintenance window, authenticate 524 00:26:08,160 --> 00:26:11,520 with MFA, and after exactly, say, 60 minutes, the 525 00:26:11,520 --> 00:26:14,520 cryptographic session token expires and the connection is 526 00:26:14,520 --> 00:26:15,920 forcefully severed by the firewall. 527 00:26:16,120 --> 00:26:19,080 That is a massive improvement. And what about protecting the 528 00:26:19,080 --> 00:26:21,720 genuine air gap from the flat network issue? 529 00:26:22,280 --> 00:26:25,520 If a hacker does compromise the passenger Wi-Fi on the onboard 530 00:26:25,520 --> 00:26:29,240 zone, how do we physically stop them from traversing the network 531 00:26:29,240 --> 00:26:32,760 and reaching the brakes? Hardware solutions, specifically 532 00:26:32,960 --> 00:26:35,960 the standard, heavily leans on the use of unidirectional data 533 00:26:35,960 --> 00:26:38,120 diodes. I love the concept of data 534 00:26:38,120 --> 00:26:40,120 diodes. Explain how physical physics 535 00:26:40,120 --> 00:26:41,800 solves a software routing problem. 536 00:26:41,840 --> 00:26:43,880 It's beautiful in its absolute simplicity. 537 00:26:44,720 --> 00:26:47,920 A data diode is a physical piece of hardware placed between two 538 00:26:47,920 --> 00:26:52,320 network zones, say the highly secure OT braking network and 539 00:26:52,320 --> 00:26:54,720 the less secure passenger Wi-Fi network. 540 00:26:55,440 --> 00:26:59,480 Inside the diode, the connection isn't copper wire, it's a fiber 541 00:26:59,480 --> 00:27:02,000 optic cable. On the secure side there's only 542 00:27:02,000 --> 00:27:05,120 an optical transmitter, A gallium arsenide laser that 543 00:27:05,120 --> 00:27:08,280 sends light pulses. On the insecure side, there is 544 00:27:08,280 --> 00:27:10,920 only an optical receiver of photocell that receives light. 545 00:27:11,040 --> 00:27:14,800 So data can physically, fundamentally only travel in One 546 00:27:14,800 --> 00:27:16,160 Direction. Precisely. 547 00:27:16,800 --> 00:27:20,320 The secure network can broadcast diagnostic telemetry data out to 548 00:27:20,320 --> 00:27:23,800 the monitoring servers on the insecure side, but because there 549 00:27:23,800 --> 00:27:27,480 is literally physically no laser on the insecure side to send 550 00:27:27,480 --> 00:27:30,760 light back, it is mathematically impossible for a hacker on the 551 00:27:30,760 --> 00:27:33,360 passenger Wi-Fi to send a malicious command in. 552 00:27:33,520 --> 00:27:35,480 You can't hack the laws of physics. 553 00:27:35,480 --> 00:27:36,800 Exactly. You can't hack a light. 554 00:27:37,200 --> 00:27:40,000 It allows the OT network to export data for predictive 555 00:27:40,000 --> 00:27:43,400 maintenance while maintaining a true physical air gap. 556 00:27:43,440 --> 00:27:43,760 Wait. Hold. 557 00:27:43,760 --> 00:27:44,920 On I love the physical physics of it. 558 00:27:44,920 --> 00:27:47,800 You can't hack light, but operationally, let's think about 559 00:27:47,800 --> 00:27:50,280 this. If data only flows one way out 560 00:27:50,280 --> 00:27:53,360 of the secure zone, how the hell does the central control room 561 00:27:53,360 --> 00:27:56,680 send an emergency stop command in if they see a catastrophic 562 00:27:56,680 --> 00:27:59,760 failure on the telemetry? Doesn't a physical diode break 563 00:27:59,760 --> 00:28:03,360 bi directional safety controls? You need the TCP handshake just 564 00:28:03,360 --> 00:28:06,480 to confirm receipt of the data. That is exactly the multi 565 00:28:06,480 --> 00:28:09,080 $1,000,000 architectural headache that engineers fight 566 00:28:09,080 --> 00:28:12,200 over. You're right, TCP requires a bi 567 00:28:12,200 --> 00:28:15,240 directional handshake, so a diode breaks standard TCP 568 00:28:15,240 --> 00:28:17,680 traffic. To fix the network protocol 569 00:28:17,680 --> 00:28:20,720 issue you have to use UDP proxies on both sides of the 570 00:28:20,720 --> 00:28:24,480 diode to basically spoof the handshake and blind fire the 571 00:28:24,480 --> 00:28:27,320 packets across the light gap. And for the safety controls? 572 00:28:27,520 --> 00:28:30,280 For the safety controls you have to completely decouple 573 00:28:30,280 --> 00:28:33,800 monitoring from actuation. The diode is only used for 574 00:28:33,800 --> 00:28:37,240 exporting non critical telemetry and logs to the IT network. 575 00:28:37,640 --> 00:28:41,200 Actual bi directional control pathways, the signals that move 576 00:28:41,200 --> 00:28:45,360 switches and stop trains use strict dedicated hard lines with 577 00:28:45,360 --> 00:28:48,480 deterministic cryptographic key exchanges that are completely 578 00:28:48,480 --> 00:28:50,560 segregated from the IT or vendor networks. 579 00:28:51,000 --> 00:28:53,560 You never wrote safety commands to the same interface that 580 00:28:53,560 --> 00:28:55,200 handles predictive maintenance logs. 581 00:28:55,280 --> 00:28:57,880 OK, that clarifies it. It's a massive architectural 582 00:28:57,880 --> 00:29:00,200 separation. But this brings us to the 583 00:29:00,200 --> 00:29:02,720 elephant in the room. We hear a lot about rules on 584 00:29:02,720 --> 00:29:05,320 paper, but implementing them is a different story. 585 00:29:05,560 --> 00:29:08,800 If you go to any cybersecurity conference today, the only thing 586 00:29:08,800 --> 00:29:10,720 anyone is talking about is zero trust. 587 00:29:11,080 --> 00:29:14,360 Don't get me started. Assume breach, never trust, 588 00:29:14,520 --> 00:29:17,560 always verify. But from everything we've just 589 00:29:17,560 --> 00:29:21,480 discussed about legacy flat networks and PLCS from 1998, a 590 00:29:21,480 --> 00:29:25,000 playing zero trust architecture to a railway seems completely 591 00:29:25,000 --> 00:29:27,000 absurd. It borders on the delusional. 592 00:29:27,480 --> 00:29:30,640 Implementing True Zero Trust, which involves continuous 593 00:29:30,640 --> 00:29:33,600 cryptographic authentication of every single user and device, 594 00:29:33,920 --> 00:29:37,480 dynamic policy enforcement, and granular micro segmentation of 595 00:29:37,480 --> 00:29:40,800 the network is physically impossible in legacy OT 596 00:29:40,800 --> 00:29:43,080 environments. I mean, we know old protocols 597 00:29:43,080 --> 00:29:46,400 like Modbus, TCP or cleartext. There's no authentication 598 00:29:46,400 --> 00:29:48,400 header. You can't just slap a zero trust 599 00:29:48,400 --> 00:29:50,360 policy engine onto a legacy serial bus. 600 00:29:50,360 --> 00:29:51,960 Exactly. It's a hardware limitation. 601 00:29:52,240 --> 00:29:55,040 Remember those trackside PLCS? They literally do not have the 602 00:29:55,040 --> 00:29:58,360 compute power, the CPU cycles, or the memory to perform 603 00:29:58,360 --> 00:30:00,200 continuous cryptographic authentication. 604 00:30:00,520 --> 00:30:03,840 If you ask a 1998 track switch controller to perform a modern 605 00:30:03,840 --> 00:30:07,560 TLS 1.3 handshake and validate and buy five O 9 certificate 606 00:30:07,560 --> 00:30:09,880 every time you need to send a status packet, the CPU will 607 00:30:09,880 --> 00:30:12,080 meltdown. You cannot wrap zero trust 608 00:30:12,080 --> 00:30:13,880 around a silicon chip that doesn't understand what a 609 00:30:13,880 --> 00:30:16,440 password is. So how do you secure a legacy 610 00:30:16,440 --> 00:30:19,720 network that physically cannot be upgraded to modern security 611 00:30:19,720 --> 00:30:21,760 standards? Because that sounds like an 612 00:30:21,760 --> 00:30:24,880 unsolvable paradox. It requires a massive cultural 613 00:30:24,880 --> 00:30:27,000 shift. Historically, security 614 00:30:27,000 --> 00:30:30,440 boundaries in OT were physical, a padlock on a metal door. 615 00:30:31,000 --> 00:30:32,600 Now those boundaries have to be logical. 616 00:30:33,080 --> 00:30:36,160 But since you cannot install a modern endpoint detection agent 617 00:30:36,160 --> 00:30:39,480 like a crowd strike or a Sentinel and antivirus directly 618 00:30:39,480 --> 00:30:42,320 onto a fragile legacy train controller without freezing it, 619 00:30:42,760 --> 00:30:45,840 you have to rely on the only practical solution left, which 620 00:30:45,920 --> 00:30:48,680 is passive visibility. Passive visibility detail the 621 00:30:48,680 --> 00:30:51,160 mechanics of that. Because the critical systems are 622 00:30:51,160 --> 00:30:54,640 safety certified and incredibly fragile, you cannot use active 623 00:30:54,640 --> 00:30:57,560 host agents, you can't touch the system, and you can't scan it 624 00:30:57,560 --> 00:31:00,200 with nmap. So instead you just watch it use 625 00:31:00,200 --> 00:31:03,560 passive network monitoring via hardware taps or span ports on 626 00:31:03,560 --> 00:31:06,200 the core network switches. You quietly copy the data 627 00:31:06,200 --> 00:31:08,960 flowing across the network wire and send it to a separate 628 00:31:08,960 --> 00:31:12,040 physically isolated monitoring tool equipped with Rail Aware 629 00:31:12,040 --> 00:31:15,680 deep Packet Inspection, or DPI. OK, let's elevate an analogy 630 00:31:15,680 --> 00:31:17,920 here. It's like trying to teach a 631 00:31:17,920 --> 00:31:21,840 1980s VCR to use facial recognition to know who is 632 00:31:21,840 --> 00:31:23,440 pressing the play button. Okay, I'm tracking. 633 00:31:23,800 --> 00:31:27,200 The VCR physically doesn't have the circuitry for it since it 634 00:31:27,200 --> 00:31:29,000 can. You just put a very smart 635 00:31:29,000 --> 00:31:31,760 security camera pointed at the VCR to see who is pushing the 636 00:31:31,760 --> 00:31:34,160 buttons. You don't alter the VCR's 637 00:31:34,160 --> 00:31:37,200 internal circuitry at all, you just monitor the environment 638 00:31:37,200 --> 00:31:39,200 around it. That is surprisingly accurate, 639 00:31:39,200 --> 00:31:41,160 yes. You never touch the safety 640 00:31:41,160 --> 00:31:44,680 critical asset, you just watch the traffic flowing across what 641 00:31:44,680 --> 00:31:49,000 TS 50701 calls the conduits between the different zones. 642 00:31:49,640 --> 00:31:53,960 The DPI tool sitting on the SPAN port understands the specific 643 00:31:54,120 --> 00:31:57,600 esoteric railway protocols. It unpacked the Modbus or 644 00:31:57,600 --> 00:32:00,640 Profibus packets in real time. It does state machine tracking. 645 00:32:00,760 --> 00:32:02,200 So it knows what normal looks like. 646 00:32:02,200 --> 00:32:04,320 Exactly. It knows that this specific IP 647 00:32:04,320 --> 00:32:07,520 address belongs to a track switch, and mathematically that 648 00:32:07,520 --> 00:32:10,120 switch should only ever send a status update message to the 649 00:32:10,120 --> 00:32:12,640 central server. If the passive monitor suddenly 650 00:32:12,640 --> 00:32:16,480 sees that same switch trying to send a firmware rewrite message, 651 00:32:16,680 --> 00:32:19,560 or trying to communicate with an unauthorized external IP address 652 00:32:20,080 --> 00:32:23,320 like our maintenance workers 4G modem, it instantly triggers 653 00:32:23,320 --> 00:32:26,560 massive alarms in the SoC, the security operation center. 654 00:32:26,720 --> 00:32:30,400 And it does all of this without ever sending a single active 655 00:32:30,400 --> 00:32:33,960 probe or TCPSYM packet to the fragile OT device. 656 00:32:34,000 --> 00:32:36,760 It just listens. It just listens sustained 657 00:32:36,760 --> 00:32:38,800 visibility into the operational network. 658 00:32:38,800 --> 00:32:41,800 You turn opaque legacy control flows into measurable, 659 00:32:41,800 --> 00:32:44,280 actionable telemetry. And I really want to emphasize 660 00:32:44,280 --> 00:32:47,000 to the listener here, this methodology isn't just about 661 00:32:47,000 --> 00:32:48,960 trains. Right, the supplies everywhere, 662 00:32:48,960 --> 00:32:51,880 everywhere. The power grid, water treatment 663 00:32:51,880 --> 00:32:54,960 plants, chemical manufacturing facilities, oil pipelines. 664 00:32:55,200 --> 00:32:57,880 We live in a modern hyper connected world that is 665 00:32:57,920 --> 00:33:00,440 completely, fundamentally reliant on critical 666 00:33:00,440 --> 00:33:03,920 infrastructure running on 2030, even 40 year old technology. 667 00:33:04,360 --> 00:33:06,440 You cannot patch it all. You cannot replace it all 668 00:33:06,440 --> 00:33:07,520 overnight. You have to watch the 669 00:33:07,520 --> 00:33:09,640 interfaces, You have to monitor the conduits. 670 00:33:09,760 --> 00:33:12,640 Which brings us to the synthesis of this entire deep dive. 671 00:33:13,160 --> 00:33:15,680 We've gone from the sprawl of the signalling houses to the 672 00:33:15,680 --> 00:33:18,400 maintenance guys buying rogue modems, to the brutal 673 00:33:18,400 --> 00:33:21,040 mathematical war between CIA and Rams. 674 00:33:21,440 --> 00:33:24,080 We've seen hackers trigger emergency brakes with analog 675 00:33:24,080 --> 00:33:27,680 walkie talkies, explore the elegant physics of data diodes, 676 00:33:27,680 --> 00:33:30,480 and unpack the absolute necessity of passive DPI 677 00:33:30,480 --> 00:33:31,880 monitoring. It's a lot to take in. 678 00:33:32,120 --> 00:33:33,640 It is. I want to pull all of this 679 00:33:33,640 --> 00:33:38,400 together and leave you, the listener, with one final, deeply 680 00:33:38,400 --> 00:33:41,560 provocative thought that really crystallized for me while 681 00:33:41,560 --> 00:33:43,520 reading through the appendices of these sources. 682 00:33:44,320 --> 00:33:48,280 As an industry and as a society, we are moving rapidly toward 683 00:33:48,360 --> 00:33:50,840 fully autonomous driverless trains. 684 00:33:51,440 --> 00:33:55,280 The sources talk extensively about FRMCS, the future railway 685 00:33:55,280 --> 00:33:58,320 mobile communication system, which is essentially a dedicated 686 00:33:58,320 --> 00:34:02,000 5G network for trains, enabling massive real time data exchange, 687 00:34:02,320 --> 00:34:04,640 AI diagnostics and remote autonomous control. 688 00:34:05,280 --> 00:34:07,720 But if the 30 year old train wasn't built for the Internet, 689 00:34:08,080 --> 00:34:10,719 and the Internet certainly wasn't built for safety, who 690 00:34:10,719 --> 00:34:13,520 actually owns the risk? That's a huge issue. 691 00:34:13,639 --> 00:34:17,880 When a software vendor remotes in from across the globe over a 692 00:34:17,880 --> 00:34:21,400 5G network into a trackside interlocking system that was 693 00:34:21,400 --> 00:34:24,600 built when dial up Internet was cutting edge, and an AI 694 00:34:24,600 --> 00:34:27,400 algorithm is dynamically managing the braking distance 695 00:34:27,400 --> 00:34:30,679 based on passive telemetry exported through a UDP proxy, 696 00:34:31,080 --> 00:34:34,159 who is truly driving the train? Is it the local operator? 697 00:34:34,600 --> 00:34:37,199 The cloud software vendor? The telecom provider hosting the 698 00:34:37,199 --> 00:34:39,679 5G slice. That is the multi billion dollar 699 00:34:39,679 --> 00:34:42,320 question and it's going to be the absolute liability nightmare 700 00:34:42,320 --> 00:34:44,679 of the next next decade. That's all for this episode of 701 00:34:44,679 --> 00:34:47,719 Cybersecurity Under Pressure. Real attacks, real lessons. 702 00:34:47,719 --> 00:34:50,960 Check your PLCS, check your logs, and maybe, just maybe 703 00:34:50,960 --> 00:34:53,239 question whether that air gap is really an air gap. 704 00:34:53,320 --> 00:34:54,320 See you in the next chapter.