Latest / Cybersecurity Under Pressure. Real Attacks, Real Lessons / Railway Patch Management: When an Update Stops the Network

Transcript

Railway Patch Management: When an Update Stops the Network · Cybersecurity Under Pressure. Real Attacks, Real Lessons

• 0:48
  Welcome to cybersecurity, under pressure, real attacks, real
• 0:52
  lessons. Today is Wednesday, June 24th,
• 0:56
  2026. Wow, you can't make this up.
• 0:59
  Well, you could, but nobody would believe you.
• 1:01
  Today we're taking a deep dive into the absolute nightmare that
• 1:05
  is OT security remote access, specifically in the railway
• 1:10
  sector. Nightmare is well, it's one of
• 1:13
  the most technically generous term we could use today.
• 1:16
  Honestly, yeah. Oh, absolutely.
• 1:18
  Look, if people actually understood how close we are to
• 1:20
  the edge on a daily basis, well, they'd probably just start
• 1:22
  taking the. Bus right?
• 1:23
  Right. And look, if you're listening to
• 1:25
  this deep dive, you already know the basics.
• 1:27
  You know the threat landscape is evolving, You know what a flat
• 1:30
  network is, and you probably have at least a morbid curiosity
• 1:33
  about how fragile our critical infrastructure truly is.
• 1:36
  Morbid is definitely the right word.
• 1:38
  So our mission today, and I'm speaking directly to you, the
• 1:41
  listener, is to unpack a massive stack of incredibly dense
• 1:45
  engineering and cybersecurity standards.
• 1:48
  Dense is putting it mildly. Seriously.
• 1:49
  Specifically, we're tearing in the Synalek TS-5 or Seven O 1
• 1:54
  and IEC 62443, and we are going to translate these rigid, highly
• 2:00
  theoretical frameworks into the terrifying, fascinating reality
• 2:04
  of how trains are actually kept safe from adversaries.
• 2:07
  And I think we need to set the baseline reality right from the
• 2:10
  jump here. Go for it.
• 2:11
  When we talk about securing operational technology,
• 2:13
  especially rail, we are not talking about Hollywood
• 2:16
  scenarios. There is no guy in a dark room
• 2:19
  furiously typing on 6 monitors to, you know, bypass a glowing
• 2:23
  red firewall and derail a locomotive.
• 2:25
  Right, no matrix code raining down.
• 2:26
  Exactly. The reality is so much Dumber,
• 2:29
  and frankly, that makes it exponentially harder to defend
• 2:32
  against. Because you can't predict it.
• 2:33
  Right. We aren't just trying to stop an
• 2:35
  elite APT group from a hostile nation state.
• 2:37
  I mean, yes, we do that, but the everyday threat, we're trying to
• 2:40
  stop our own mid level maintenance worker from plugging
• 2:43
  a $50 commercial wireless dongle into a critical Control Board.
• 2:47
  Just because he didn't feel like walking out into the rain to
• 2:49
  check a diagnostic log. Precisely.
• 2:52
  It's human nature. So we are fighting human
• 2:54
  convenience just as much as we're fighting malicious code.
• 2:58
  Which actually brings us to the first major issue we pulled from
• 3:01
  the source material. The geography problem.
• 3:03
  Yes, the physical geography of railway infrastructure and how
• 3:06
  it completely obliterates any traditional concept of an IT
• 3:10
  perimeter because, well, in enterprise IT or even in a
• 3:14
  manufacturing OT environment, your perimeter is literal,
• 3:17
  right? It's a concrete box.
• 3:19
  Correct. You secure a car factory.
• 3:21
  You have 4 walls. Your robotics, your scatter
• 3:24
  systems, your PLCS. They are physically contained.
• 3:27
  You put guards at the doors, badge readers on the turnstiles,
• 3:30
  maybe a massive next Gen. firewall at your single Internet
• 3:33
  gateway. You build a castle.
• 3:35
  But a National Rail network? Your perimeter isn't a wall.
• 3:39
  Your perimeter is 5000 miles of exposed copper fiber and
• 3:42
  trackside boxes stretching across mountain ranges, deep
• 3:45
  urban subway tunnels, and desolate rural plains.
• 3:48
  You literally have zero physical control over the environment.
• 3:52
  Zero. And out in that vast sprawl you
• 3:54
  have these things called signaling houses.
• 3:57
  The source material focuses heavily on them as a primary
• 3:59
  vector. Yes, signaling houses.
• 4:01
  I mean, a signaling house is basically an unassuming concrete
• 4:04
  or metal shed sitting out in the middle of nowhere.
• 4:07
  Like next to a cornfield? Yeah, maybe next to a level
• 4:10
  crossing in a cornfield or bolted to the wall of a damp
• 4:15
  underground tunnel. Inside that shed is your
• 4:18
  critical safety equipment. Stuff like interlocking
• 4:20
  controller. Interlocking controllers, track
• 4:23
  circuit monitors, communication relays.
• 4:25
  It is both a physical access point and a highly sensitive
• 4:29
  digital entry point into the backbone of the railway network.
• 4:33
  But historically, the defense for these places was just the
• 4:36
  legendary air gap, right? Pure isolation.
• 4:39
  Right. The idea was that because these
• 4:41
  systems weren't hardwired to the Internet, they were untouchable.
• 4:43
  Makes sense? True in theory.
• 4:45
  Tack it. An attacker would physically
• 4:47
  have to break the padlock on the shed, walk inside and plug a
• 4:50
  laptop directly into the serial port of a 20 year old
• 4:53
  controller. Which honestly sounds pretty
• 4:55
  robust until you factor in the operational realities of
• 4:58
  maintaining a network that massive.
• 5:00
  Precisely. Enter the maintenance crews.
• 5:04
  These are the guys responsible for keeping the trains moving
• 5:07
  and they have punishing SL as service level agreements.
• 5:11
  So if a fault light goes off in a remote signaling house that is
• 5:15
  say A5 hour drive from the regional depot and there's a
• 5:17
  Blizzard outside. Oh man, I can see exactly where
• 5:20
  this is going. It's just human nature, a
• 5:21
  maintenance engineer who is probably brilliant at mechanical
• 5:25
  systems but completely unaware of modern cyber threat
• 5:28
  landscapes. He says to himself.
• 5:30
  I am not driving 500 miles round trip just to pull a plain text
• 5:35
  diagnostic log ever again. Yeah, you can't blame him.
• 5:37
  You really can't. So what does he do the next time
• 5:41
  he's out there? He brings a cheap commercial 4G
• 5:44
  or 5G cellular modem. He quietly wires it into the
• 5:48
  diagnostic port of the trackside Ethernet switch, sets up an
• 5:51
  unencrypted remote desktop connection, and goes home.
• 5:55
  And he doesn't tell anyone. Never.
• 5:57
  He definitely doesn't log a ticket with the CIO sitting in a
• 5:59
  glass tower back in the Capitol. So now we have what the industry
• 6:03
  calls shadow OT. Shadow OT just saying the phrase
• 6:06
  makes my blood pressure spike. I bet the moment that $50
• 6:10
  consumer modem boots up and connects to the public cellular
• 6:13
  network, the entire multi $1,000,000 air gap collapses.
• 6:17
  All your enterprise firewalls, your intrusion detection
• 6:20
  systems, your SoC completely bypassed.
• 6:23
  Wait, so we spend millions building a digital digital
• 6:25
  fortress and the drawbridge is essentially lowered by our own
• 6:28
  guy who just wanted to save gas money?
• 6:31
  That is exactly what happens. Physical convenience Trump's
• 6:34
  cybersecurity every single time. And because we all know the
• 6:38
  nightmare of legacy flat networks, the implications here
• 6:41
  are catastrophic. I mean, listeners know that
• 6:43
  without micro segmentation, East West traffic is essentially a
• 6:47
  free for all. If I'm an attacker and I pop a
• 6:50
  weak lobby Wi-Fi in a corporate network, modern zero trust
• 6:53
  architecture usually stops me from pivoting into the HR
• 6:56
  database. But in a rail OT environment.
• 6:59
  There is no internal segmentation.
• 7:01
  You have to remember the era these systems were designed in.
• 7:04
  Legacy OT systems were built on the fundamental assumption of
• 7:07
  absolute inherent trust. Meaning if you're in, you're
• 7:10
  trusted. Right.
• 7:12
  If a device is on the wire, it is assumed to be a trusted piece
• 7:16
  of safety equipment. There's no authentication header
• 7:19
  on a Modbus TCP packet, it just executes the command.
• 7:23
  So if that maintenance worker's cheap 4G modem gets scanned on
• 7:28
  Show Dan and compromised by an automated botnet, the attacker
• 7:33
  doesn't just get to see a diagnostic log.
• 7:35
  No, no, They are sitting on a flat, unsegmented network that
• 7:39
  connects directly to the interlocking systems.
• 7:42
  They are on the backbone from that compromised cellular
• 7:44
  router. They can theoretically and in
• 7:47
  many legacy architectures, practically jump straight to the
• 7:49
  radio block center. And since the radio block center
• 7:52
  communicates with the onboard train control and management
• 7:55
  system. The PCMS, yes, you have a
• 7:57
  potential unfiltered pathway right to the train's dynamic
• 8:00
  braking system. All because a guy didn't want to
• 8:03
  drive in the snow. You know, it's wild to think
• 8:05
  about. I'm just thinking about how
• 8:06
  often we bypass security in our own daily lives just for a tiny
• 8:10
  fraction of convenience. All the time.
• 8:12
  Reusing a password across three accounts.
• 8:14
  We're disabling MFA on a trusted device because we're tired of
• 8:17
  checking our phones. It's the exact same
• 8:19
  psychological impulse. It is, but the blast radius is
• 8:23
  slightly different. Fairpoint.
• 8:24
  If you reuse a password, maybe your credit card gets cloned.
• 8:27
  In the railway sector, bypassing security for convenience
• 8:31
  translates to kinetic physical disaster.
• 8:35
  You have thousands of tons of steel moving at 300 kilometers
• 8:37
  an hour, carrying hundreds of passengers.
• 8:40
  The gap between convenience and derailment is terrifyingly
• 8:43
  narrow. Which naturally leads to the
• 8:46
  most infuriating question for any IT security professional
• 8:49
  listening. If you know these rogue modems
• 8:51
  are out there, why not just scan the network, find the
• 8:54
  unauthorized MA addresses, and shut them down?
• 8:57
  But the source material specifically and repeatedly
• 9:00
  warns against active probing. It highlights this absolute
• 9:03
  philosophical war between traditional IT security and OT
• 9:07
  engineering. Oh, it's a war.
• 9:08
  It is a holy war and the two sides speak completely mutually
• 9:11
  unintelligible languages. Let's look at the foundational
• 9:14
  frameworks. In traditional IT security, the
• 9:17
  entire universe revolves around the CIA triad.
• 9:21
  Confidentiality, integrity, availability.
• 9:24
  In that exact order. Right.
• 9:26
  If there is a suspected breach, it's immediate reflexive
• 9:30
  response is to protect the confidentiality of the data.
• 9:33
  You sever the connection, you lock out the users, you take the
• 9:36
  server offline. Right, but if you take an OT
• 9:39
  system offline trains. Simple as that.
• 9:42
  Simple as that. OT engineers, the people
• 9:44
  actually managing the physical physics of the railway, will
• 9:48
  aggressively counter your CIA triad with Rams reliability,
• 9:52
  availability, maintainability and safety.
• 9:55
  Notice what's missing? Confidentiality doesn't even
• 9:57
  make the list. They literally don't care if
• 9:59
  someone reads the data. Not even a little bit.
• 10:01
  An OT engineer doesn't care if a hacker intercepts the telemetry
• 10:04
  data of a track switch. Because it's just telemetry.
• 10:07
  Right. They care that the switch
• 10:08
  physically moves when it is mathematically scheduled to move
• 10:12
  every single time without a millisecond of deviation.
• 10:16
  Safety and reliability are paramount.
• 10:18
  If an IT guy shuts down the network to quote UN quote
• 10:21
  protect IT, they've just violated the OT core requirement
• 10:25
  availability. So what actually happens when an
• 10:27
  overzealous IT security team decides they want to secure the
• 10:31
  railway network using their standard enterprise tools?
• 10:34
  Say a new CI. So comes in and says hey, we're
• 10:36
  going to run and map across the whole subnet to find these rogue
• 10:39
  modems. Absolute, unmitigated disaster.
• 10:42
  Tell me the source documents detail this beautifully.
• 10:44
  We call it active probing in an enterprise IT environment.
• 10:47
  You run a vulnerability scan, you ping an IP address, you
• 10:50
  check for open ports, and the server just replies here I am
• 10:53
  and goes about its business. The TCPI IP stack on a modern
• 10:56
  server can handle millions of concurrent connections.
• 10:59
  But the TCT IP stack on a legacy programmable logic controller.
• 11:02
  Is virtually non existent. We are talking about legacy
• 11:06
  serial to IP converters and communication protocols like
• 11:09
  Prophibus running on PLCS that have microprocessors from 1998.
• 11:13
  1998. Yeah, these devices are designed
• 11:16
  to do 1 highly specific mathematical control loop over
• 11:21
  and over again deterministically.
• 11:23
  They have incredibly tiny memory buffer.
• 11:25
  Right, so the networking stack on those old chips just isn't
• 11:28
  built to handle malformed packets or active probes or
• 11:31
  rapid connection requests. Exactly.
• 11:33
  When the IT vulnerability scanner hits that legacy PLC
• 11:37
  with a barrage of active SYN requests, the PLCS networking
• 11:41
  stack simply cannot process the unexpected traffic.
• 11:44
  The buffer instantly overflows, the processor spikes to 100%
• 11:49
  utilization, and the device goes into what we call a freeze in
• 11:52
  state failure. It essentially has a digital
• 11:55
  panic attack and completely locks up.
• 11:57
  It drops the control loop entirely, and in a safety
• 11:59
  critical system, a frozen controller means the system
• 12:02
  doesn't know where the train is anymore.
• 12:04
  The feel safe protocol kicks in and the system halts everything.
• 12:07
  It's like trying. To change the tires on a car
• 12:09
  while it's driving at 100 miles an hour on the highway, Pretty
• 12:11
  much you're trying to inject modern disruptive security
• 12:14
  controls into a kinetic process that physically, physically
• 12:17
  cannot pause for even a microsecond.
• 12:19
  That's a great way to look at it, and it's not just scanning
• 12:22
  the source material. Highlights another massive
• 12:24
  systemic issue, latency. Right latency.
• 12:27
  Let's say IT decides, OK, no scanning, but we are going to
• 12:30
  put a standard next Gen. firewall in line between the
• 12:34
  trackside equipment and the central control room to block
• 12:37
  unauthorized remote access. Makes sense on paper.
• 12:40
  On paper, in the IT world, if a firewall introduces A200
• 12:44
  millisecond latency spike while it performs deep packet
• 12:47
  inspection on a payload, nobody cares. 200 milliseconds is a
• 12:52
  minor, completely unnoticeable lag on a zoom call or, you know,
• 12:56
  loading a cloud application. But in the European train
• 12:58
  control system. In ETCS, timing is literally
• 13:02
  life or death. The system relies on continuous
• 13:05
  real time communication between the train and the radio block
• 13:08
  center. If that new inline firewall
• 13:10
  delays an ETCS packet by 200 milliseconds, the train's
• 13:13
  onboard computer registers a loss of continuous communication
• 13:17
  the track. And let me guess, the train
• 13:19
  doesn't just buffer and wait for the connection to re establish?
• 13:21
  No, it enters a fail safe mode. It triggers the emergency
• 13:25
  brakes, pneumatic air valves open, pressure drops, and the
• 13:28
  train clamps down over a 200 millisecond packet delay.
• 13:32
  Unbelievable. So traditional IT security is
• 13:35
  like a doctor trying to cure a patient's mild cough with a
• 13:39
  medicine that accidentally stops their heart.
• 13:41
  Exactly. Your IT security control
• 13:43
  designed to keep the train safe just caused a fully loaded
• 13:46
  passenger train to dump its air brakes and violently skid to a
• 13:50
  halt in the middle of the main line.
• 13:51
  You've stranded passengers, disrupted the entire regional
• 13:54
  timetable and created a massive physical hazard, all in the name
• 13:58
  of cybersecurity. It's unbelievable and it's
• 14:01
  compounded by what the documents referred to as the 30 year
• 14:03
  problem, the patching paradox. The bane of my existence.
• 14:06
  Oh yeah, an IT server has a life cycle of maybe three to five
• 14:10
  years before it's decommissioned and replaced a railway
• 14:13
  interlocking system. The complex logic that ensures 2
• 14:16
  trains can literally never be routed onto the same track
• 14:19
  segment at the same time has a life cycle of 30 to 40 years.
• 14:23
  It is rigorously mathematically tested, certified by an
• 14:27
  independent safety assessment board, and then permanently
• 14:30
  locked down. I want to read a specific quote
• 14:32
  from our research on this because it really crystallizes
• 14:34
  the insanity of the situation. Quote.
• 14:38
  Install a security update on a critical interlocking system
• 14:41
  without CAB approval and you don't just avoid a
• 14:43
  certification, you risk triggering a mechanical response
• 14:47
  on live tracks that the safety case never anticipated.
• 14:50
  The patch closes ACVE it opens a hazard.
• 14:54
  End Quote. That is the crux of the entire
• 14:57
  ITOT conflict right there. A CVE is a common
• 15:00
  vulnerabilities and exposures logging a known software bug.
• 15:03
  IT demands you patch it immediately.
• 15:05
  CISA might even legally mandate that you catch it within 14 days
• 15:09
  if it's a known exploited vulnerability.
• 15:11
  Right, but legally from the OT side, how do they square that?
• 15:15
  If you change the code, you invalidate the safety
• 15:17
  certification you do. You no longer mathematically
• 15:20
  know for a fact how that system will behave under stress.
• 15:23
  The Safety Board signed off on version one, point O.
• 15:26
  If you push version 1.1 over the air to fix a remote execution
• 15:30
  bug, you are operating an uncertified, technically illegal
• 15:33
  safety system. That is a massive catch 22.
• 15:36
  It is OT. Engineers will fight tooth and
• 15:38
  nail against IT patching mandates because an unpatched
• 15:41
  system is vulnerable to a hacker.
• 15:43
  But a patch system is essentially uncertified,
• 15:46
  unpredictable, and potentially lethal.
• 15:48
  So we have geographic sprawl, rogue shadow modems, flat
• 15:52
  networks, devices that crash if you scan them, firewalls that
• 15:55
  trigger emergency brakes, and systems that you are legally
• 15:57
  forbidden to patch. Sounds fine, right?
• 15:59
  Which begs the question, is this just a theoretical academic
• 16:03
  exercise? Are adversaries actually
• 16:05
  exploiting the specific friction?
• 16:07
  I wish it were just an academic debate.
• 16:09
  It is not. The threat landscape we're
• 16:12
  reviewing here proves this is happening right now.
• 16:14
  You've pulled 3 case studies from the sources that highlight
• 16:17
  completely different vectors of this exact vulnerability.
• 16:20
  Let's start with Denmark late 2022.
• 16:22
  Right late 2022, trains across the entire country of Denmark
• 16:26
  were suddenly halted for hours. Complete nationwide systemic
• 16:30
  disruption. But the terrifying part is how
• 16:32
  it happened. It wasn't a direct attack on the
• 16:35
  trains, tracks, the signaling houses or the physical OT
• 16:38
  network. Then what forced the stop?
• 16:40
  They attacked an IT subcontractor, specifically a
• 16:43
  software vendor named Suvani that provided a testing
• 16:46
  environment for a train dispatching application.
• 16:50
  The subcontractor suffered a cyber attack and to contain the
• 16:53
  blast radius, they isolated and shut down their servers.
• 16:56
  But wait, why did the physical trains stop if the tracks
• 16:59
  weren't hacked? If it's just a dispatching app
• 17:01
  in a third party cloud. Because of the deep operational
• 17:04
  dependencies of modern rail architecture under systems like
• 17:07
  ETMS Level 2, dispatching schedules and safety protocols
• 17:10
  are completely interlocked. The train drivers rely on
• 17:13
  cryptographic token validation and real time updates pushed to
• 17:16
  their tablets from those servers.
• 17:19
  When the Suvani subcontractor went down, it wasn't just
• 17:22
  servers off, it meant the dispatchers lost visibility and
• 17:26
  control of mathematical safety margins between trains.
• 17:29
  If you can't guarantee the safety margin, the rule is you
• 17:32
  halt the train. So this perfectly illustrates
• 17:35
  the massive vulnerability of third party remote access and
• 17:38
  supply chain concentration risk. You can spend a billion dollars
• 17:42
  securing your physical rail network with data diodes and
• 17:45
  armed guards, but if the cloud vendor who supplies your
• 17:48
  operational diagnostic software gets hit with ransomware, you
• 17:51
  are still completely dead in the water.
• 17:53
  Exactly. You are outsourcing your
• 17:55
  availability risk to a vendor who might be prioritizing their
• 17:58
  own data confidentiality over your physical uptime.
• 18:02
  OK, let's look at a completely different director.
• 18:04
  Poland 2023. This is the one that actually
• 18:06
  gave me chills when I read the report because it bypasses the
• 18:09
  IP network entirely. We are worried about elite cyber
• 18:11
  syndicates and a couple of guys with off the shelf walkie
• 18:14
  talkies brought 20 trains to a screeching halt.
• 18:17
  This is the one that keeps OT engineers awake at night.
• 18:21
  Saboteurs didn't use sophisticated IP hacking.
• 18:24
  They didn't breach a firewall. They didn't fish a password.
• 18:28
  They used cheap analog radios. That is just nuts.
• 18:31
  They tuned into the unencrypted VHF radio frequencies used by
• 18:35
  the Polish railway network and broadcast unauthorized radio
• 18:38
  stop signals. Detail the mechanics of that.
• 18:41
  A radio stop signal is just an emergency command sent over open
• 18:44
  airwaves. Yes, it's a legacy analog safety
• 18:47
  feature. In an emergency, if there's an
• 18:50
  obstruction on the track, a train driver or a dispatcher can
• 18:53
  broadcast a specific sequence of three audio tones over the VHF
• 18:57
  radio. Just three tones.
• 18:58
  Just three tones. Any train receiver in a 10
• 19:01
  kilometer radius that hears those 3 tones will automatically
• 19:04
  instantly trigger its emergency brakes.
• 19:06
  And it's unauthenticated by design, right?
• 19:08
  Because in an emergency, you don't have time for a digital
• 19:10
  handshake. Exactly.
• 19:12
  You can't wait for a cryptographic key exchange when
• 19:14
  you're about to hit a derailed freight car.
• 19:17
  The attackers exploited the safety first design.
• 19:20
  They recorded those 3 tones and just played them back over the
• 19:22
  airwaves using off the shelf walkie talkies.
• 19:25
  Imagine you're the driver. You're doing 120 kilometers an
• 19:28
  hour at night. The cab is quiet.
• 19:31
  Suddenly 3 analog tones blast over the radio.
• 19:34
  Boop, beep, boop. And before you can even touch
• 19:36
  the console, the main brake pipe vents to the atmosphere.
• 19:40
  The entire train violently shutters.
• 19:42
  Sparks fly off the wheels and you're skidding in the dark.
• 19:45
  And you look at the dispatch board and there's no
• 19:47
  construction, just ghost signals.
• 19:50
  Over 20 trains halted massive cascading disruption and it
• 19:54
  bypassed all the multi $1,000,000 IT network defenses
• 19:58
  entirely. It didn't matter how good your
• 20:00
  next Gen. firewalls were or if you had zero trust implemented
• 20:03
  on your corporate laptops because the attack came to the
• 20:05
  airwaves on an analog frequency from the 1970s.
• 20:09
  It perfectly highlights how mixing old, unencrypted kinetic
• 20:12
  technology with modern infrastructure creates a
• 20:15
  massive, glaring blind spot. Secure the digital front door
• 20:18
  with biometric retina standards and they just walk right through
• 20:21
  the analog screen door in the back.
• 20:23
  Exactly. And for our third example, let's
• 20:26
  look at the SFMTA attack in San Francisco in 2016.
• 20:30
  This is a classic IT incident, laterally cascading into an OT
• 20:35
  operational nightmare. Ransomware infected the
• 20:38
  Municipal Transport Agency's IT network.
• 20:41
  I remember reading about this one.
• 20:43
  Right now it didn't breach the OT systems controlling the
• 20:46
  trains. The trains could still safely
• 20:47
  drive, but it laterally moved into and disabled the ticketing
• 20:51
  and fare collection servers. The screens on the ticket
• 20:53
  machines just showed a ransom note, right?
• 20:56
  And they had to leave the physical fare gates open for
• 20:58
  days. Right.
• 20:59
  And they didn't leave them open just out of generosity.
• 21:02
  If the Farrah capes are locked and thousands of commuters are
• 21:05
  pouring into a subterranean station during rush hour, you
• 21:08
  create a massive physical crush hazard.
• 21:10
  People can't get to the platforms, the stairs back up
• 21:13
  and you have a life safety situation.
• 21:14
  That makes sense. To prevent that physical safety
• 21:16
  hazard, they had to force open the fare gates and let everyone
• 21:20
  ride for free. It's a perfect example of how a
• 21:22
  purely digital IT ransomware event rapidly translates into
• 21:27
  physical operational degradation and massive revenue loss.
• 21:31
  So just sit with this chilling thought for a moment.
• 21:34
  What are critical infrastructure relies on opaque global multi
• 21:38
  tier supply chains and mixed era technologies.
• 21:42
  How do you even know who has remote access to your systems?
• 21:45
  The software vendor in another country?
• 21:47
  The manufacturer of the legacy radio system?
• 21:50
  The guy who installed the ticketing server.
• 21:52
  The terrifying answer is usually you don't.
• 21:54
  You simply don't know all your dependencies.
• 21:56
  And that is exactly why the industry realized they couldn't
• 21:59
  just keep patching holes, They needed a radical new
• 22:01
  mathematical way of managing this risk.
• 22:04
  All right, let's pivot to the solution, because otherwise this
• 22:06
  is just a very depressing hour of horror stories.
• 22:08
  If patching is illegal because it voids safety certs and the
• 22:11
  perimeter is 5000 miles of open countryside, what is the
• 22:14
  industry actually doing? This is where the Cinelec TS5O O
• 22:17
  seven O 1 standard comes into play.
• 22:20
  DS5771. This technical specification is
• 22:24
  currently the absolute gold standard for railway
• 22:27
  cybersecurity. What makes it brilliant isn't
• 22:30
  that it invents some magical new security hardware.
• 22:32
  OK, then what is it? It's brilliant because it
• 22:34
  mathematically and procedurally forces cybersecurity directly
• 22:38
  into the existing functional safety life cycle, which is
• 22:41
  governed by an older standard called EN 50126.
• 22:44
  Unpack that for us. How does it actually work in
• 22:47
  practice? First, it completely stops
• 22:49
  treating the railway as one giant unmanageable monolith.
• 22:52
  You don't try to secure the railway.
• 22:54
  TS5O7 der one forces engineers to define very specific zones,
• 22:58
  called the CC or system under consideration.
• 23:00
  So you break the element down into manageable chunks.
• 23:03
  Exactly. You define the onboard zone,
• 23:05
  which is the physical train itself, the train control and
• 23:07
  management system, the passenger Wi-Fi.
• 23:09
  Then you define the trackside zone, the interlockings, the
• 23:11
  bells is on the track, the radio block centers, and finally the
• 23:14
  central zone, the scatter systems, the traffic management
• 23:17
  systems back at headquarters. OK, so once you've logically
• 23:20
  zoned it out, how do you fix the cultural and legal conflict
• 23:24
  between the 25 year old IT SoC analyst who wants to patch
• 23:27
  everything and the 60 year old railway safety engineer who
• 23:31
  refuses to let them touch it? You force them into a room
• 23:33
  together to do what's called safety, Security, Co
• 23:36
  engineering. This is the entire beating heart
• 23:39
  of TS-10 at 7:01. Sounds intense.
• 23:42
  Oh it is. Historically, the safety
• 23:44
  engineer would do a system hazard analysis for SHA to
• 23:47
  figure out what could mechanically cause the train to
• 23:50
  crash, like a brake pad wearing out or relay failing.
• 23:53
  They use things like fault tree analysis, right?
• 23:55
  Calculating the probability of a mechanical failure based on wear
• 23:58
  and tear physics. Exactly and completely
• 24:00
  separately in another building, the security guy would do a
• 24:03
  threat analysis and risk assessment or Tara to figure out
• 24:06
  what could be hacked, calculating likelihood times
• 24:09
  impact. And the mathematical models
• 24:11
  never overlapped. I mean, how do you integrate a
• 24:13
  cyber threat vector, which is a deterministic intelligent action
• 24:17
  by a hacker into a purely mechanical folk tree?
• 24:20
  It used to be impossible. Co engineering forces you to
• 24:23
  mathematically weave the SHA into the Terra using a unified
• 24:27
  matrix. The ultimate unbreakable rule
• 24:31
  that TS5O7O1 establishes is this.
• 24:34
  A security control must never violate a safety invariant.
• 24:38
  Give me a concrete example of a safety invariant interacting
• 24:41
  with the security control. OK, a safety invariant is a hard
• 24:43
  mathematical rule, like if trackside communication is lost
• 24:47
  for more than two seconds, the train must immediately apply the
• 24:50
  emergency brake. So if the IT security team
• 24:52
  proposes adding a heavy encryption layer to the
• 24:55
  trackside communication to stop spoofing, they have to
• 24:58
  mathematically prove in the Terra that the cryptographic
• 25:00
  processing time will never, under any CPU load, exceed that
• 25:04
  A2 second safety invariant. Because if the encryption takes
• 25:07
  2.1 seconds to process, the safety logic assumes the
• 25:10
  connection is dead and stops the train.
• 25:12
  Right. So if they can't prove it
• 25:13
  mathematically, the security control is outright rejected.
• 25:16
  Safety always, always wins. That makes total sense on a
• 25:19
  systemic level, but what about the remote access problem?
• 25:22
  What about the maintenance guy with the 4G modem?
• 25:25
  Or the cloud vendor who needs to pull diagnostic logs.
• 25:29
  TS5O7O1 lays down brutal guardrails for vendor remote
• 25:33
  access, specifically targeting predictive maintenance
• 25:35
  pipelines. The standard dictates that any
• 25:38
  vendor remote access can no longer be a persistent always
• 25:41
  open backdoor. It mandates 4 strict conditions.
• 25:45
  Access must be requested, logged, time limited and require
• 25:49
  multi factor authentication. So instead of letting vendors
• 25:52
  just leave an unmonitored backdoor open for 30 years, we
• 25:55
  are forcing them into a digital prenup where they have to
• 25:58
  explicitly ask permission every single time they want to look at
• 26:00
  the engine data. Digital prenup.
• 26:02
  I like that. Yes, the vendor has to call the
• 26:05
  central control room, request a maintenance window, authenticate
• 26:08
  with MFA, and after exactly, say, 60 minutes, the
• 26:11
  cryptographic session token expires and the connection is
• 26:14
  forcefully severed by the firewall.
• 26:16
  That is a massive improvement. And what about protecting the
• 26:19
  genuine air gap from the flat network issue?
• 26:22
  If a hacker does compromise the passenger Wi-Fi on the onboard
• 26:25
  zone, how do we physically stop them from traversing the network
• 26:29
  and reaching the brakes? Hardware solutions, specifically
• 26:32
  the standard, heavily leans on the use of unidirectional data
• 26:35
  diodes. I love the concept of data
• 26:38
  diodes. Explain how physical physics
• 26:40
  solves a software routing problem.
• 26:41
  It's beautiful in its absolute simplicity.
• 26:44
  A data diode is a physical piece of hardware placed between two
• 26:47
  network zones, say the highly secure OT braking network and
• 26:52
  the less secure passenger Wi-Fi network.
• 26:55
  Inside the diode, the connection isn't copper wire, it's a fiber
• 26:59
  optic cable. On the secure side there's only
• 27:02
  an optical transmitter, A gallium arsenide laser that
• 27:05
  sends light pulses. On the insecure side, there is
• 27:08
  only an optical receiver of photocell that receives light.
• 27:11
  So data can physically, fundamentally only travel in One
• 27:14
  Direction. Precisely.
• 27:16
  The secure network can broadcast diagnostic telemetry data out to
• 27:20
  the monitoring servers on the insecure side, but because there
• 27:23
  is literally physically no laser on the insecure side to send
• 27:27
  light back, it is mathematically impossible for a hacker on the
• 27:30
  passenger Wi-Fi to send a malicious command in.
• 27:33
  You can't hack the laws of physics.
• 27:35
  Exactly. You can't hack a light.
• 27:37
  It allows the OT network to export data for predictive
• 27:40
  maintenance while maintaining a true physical air gap.
• 27:43
  Wait. Hold.
• 27:43
  On I love the physical physics of it.
• 27:44
  You can't hack light, but operationally, let's think about
• 27:47
  this. If data only flows one way out
• 27:50
  of the secure zone, how the hell does the central control room
• 27:53
  send an emergency stop command in if they see a catastrophic
• 27:56
  failure on the telemetry? Doesn't a physical diode break
• 27:59
  bi directional safety controls? You need the TCP handshake just
• 28:03
  to confirm receipt of the data. That is exactly the multi
• 28:06
  $1,000,000 architectural headache that engineers fight
• 28:09
  over. You're right, TCP requires a bi
• 28:12
  directional handshake, so a diode breaks standard TCP
• 28:15
  traffic. To fix the network protocol
• 28:17
  issue you have to use UDP proxies on both sides of the
• 28:20
  diode to basically spoof the handshake and blind fire the
• 28:24
  packets across the light gap. And for the safety controls?
• 28:27
  For the safety controls you have to completely decouple
• 28:30
  monitoring from actuation. The diode is only used for
• 28:33
  exporting non critical telemetry and logs to the IT network.
• 28:37
  Actual bi directional control pathways, the signals that move
• 28:41
  switches and stop trains use strict dedicated hard lines with
• 28:45
  deterministic cryptographic key exchanges that are completely
• 28:48
  segregated from the IT or vendor networks.
• 28:51
  You never wrote safety commands to the same interface that
• 28:53
  handles predictive maintenance logs.
• 28:55
  OK, that clarifies it. It's a massive architectural
• 28:57
  separation. But this brings us to the
• 29:00
  elephant in the room. We hear a lot about rules on
• 29:02
  paper, but implementing them is a different story.
• 29:05
  If you go to any cybersecurity conference today, the only thing
• 29:08
  anyone is talking about is zero trust.
• 29:11
  Don't get me started. Assume breach, never trust,
• 29:14
  always verify. But from everything we've just
• 29:17
  discussed about legacy flat networks and PLCS from 1998, a
• 29:21
  playing zero trust architecture to a railway seems completely
• 29:25
  absurd. It borders on the delusional.
• 29:27
  Implementing True Zero Trust, which involves continuous
• 29:30
  cryptographic authentication of every single user and device,
• 29:33
  dynamic policy enforcement, and granular micro segmentation of
• 29:37
  the network is physically impossible in legacy OT
• 29:40
  environments. I mean, we know old protocols
• 29:43
  like Modbus, TCP or cleartext. There's no authentication
• 29:46
  header. You can't just slap a zero trust
• 29:48
  policy engine onto a legacy serial bus.
• 29:50
  Exactly. It's a hardware limitation.
• 29:52
  Remember those trackside PLCS? They literally do not have the
• 29:55
  compute power, the CPU cycles, or the memory to perform
• 29:58
  continuous cryptographic authentication.
• 30:00
  If you ask a 1998 track switch controller to perform a modern
• 30:03
  TLS 1.3 handshake and validate and buy five O 9 certificate
• 30:07
  every time you need to send a status packet, the CPU will
• 30:09
  meltdown. You cannot wrap zero trust
• 30:12
  around a silicon chip that doesn't understand what a
• 30:13
  password is. So how do you secure a legacy
• 30:16
  network that physically cannot be upgraded to modern security
• 30:19
  standards? Because that sounds like an
• 30:21
  unsolvable paradox. It requires a massive cultural
• 30:24
  shift. Historically, security
• 30:27
  boundaries in OT were physical, a padlock on a metal door.
• 30:31
  Now those boundaries have to be logical.
• 30:33
  But since you cannot install a modern endpoint detection agent
• 30:36
  like a crowd strike or a Sentinel and antivirus directly
• 30:39
  onto a fragile legacy train controller without freezing it,
• 30:42
  you have to rely on the only practical solution left, which
• 30:45
  is passive visibility. Passive visibility detail the
• 30:48
  mechanics of that. Because the critical systems are
• 30:51
  safety certified and incredibly fragile, you cannot use active
• 30:54
  host agents, you can't touch the system, and you can't scan it
• 30:57
  with nmap. So instead you just watch it use
• 31:00
  passive network monitoring via hardware taps or span ports on
• 31:03
  the core network switches. You quietly copy the data
• 31:06
  flowing across the network wire and send it to a separate
• 31:08
  physically isolated monitoring tool equipped with Rail Aware
• 31:12
  deep Packet Inspection, or DPI. OK, let's elevate an analogy
• 31:15
  here. It's like trying to teach a
• 31:17
  1980s VCR to use facial recognition to know who is
• 31:21
  pressing the play button. Okay, I'm tracking.
• 31:23
  The VCR physically doesn't have the circuitry for it since it
• 31:27
  can. You just put a very smart
• 31:29
  security camera pointed at the VCR to see who is pushing the
• 31:31
  buttons. You don't alter the VCR's
• 31:34
  internal circuitry at all, you just monitor the environment
• 31:37
  around it. That is surprisingly accurate,
• 31:39
  yes. You never touch the safety
• 31:41
  critical asset, you just watch the traffic flowing across what
• 31:44
  TS 50701 calls the conduits between the different zones.
• 31:49
  The DPI tool sitting on the SPAN port understands the specific
• 31:54
  esoteric railway protocols. It unpacked the Modbus or
• 31:57
  Profibus packets in real time. It does state machine tracking.
• 32:00
  So it knows what normal looks like.
• 32:02
  Exactly. It knows that this specific IP
• 32:04
  address belongs to a track switch, and mathematically that
• 32:07
  switch should only ever send a status update message to the
• 32:10
  central server. If the passive monitor suddenly
• 32:12
  sees that same switch trying to send a firmware rewrite message,
• 32:16
  or trying to communicate with an unauthorized external IP address
• 32:20
  like our maintenance workers 4G modem, it instantly triggers
• 32:23
  massive alarms in the SoC, the security operation center.
• 32:26
  And it does all of this without ever sending a single active
• 32:30
  probe or TCPSYM packet to the fragile OT device.
• 32:34
  It just listens. It just listens sustained
• 32:36
  visibility into the operational network.
• 32:38
  You turn opaque legacy control flows into measurable,
• 32:41
  actionable telemetry. And I really want to emphasize
• 32:44
  to the listener here, this methodology isn't just about
• 32:47
  trains. Right, the supplies everywhere,
• 32:48
  everywhere. The power grid, water treatment
• 32:51
  plants, chemical manufacturing facilities, oil pipelines.
• 32:55
  We live in a modern hyper connected world that is
• 32:57
  completely, fundamentally reliant on critical
• 33:00
  infrastructure running on 2030, even 40 year old technology.
• 33:04
  You cannot patch it all. You cannot replace it all
• 33:06
  overnight. You have to watch the
• 33:07
  interfaces, You have to monitor the conduits.
• 33:09
  Which brings us to the synthesis of this entire deep dive.
• 33:13
  We've gone from the sprawl of the signalling houses to the
• 33:15
  maintenance guys buying rogue modems, to the brutal
• 33:18
  mathematical war between CIA and Rams.
• 33:21
  We've seen hackers trigger emergency brakes with analog
• 33:24
  walkie talkies, explore the elegant physics of data diodes,
• 33:27
  and unpack the absolute necessity of passive DPI
• 33:30
  monitoring. It's a lot to take in.
• 33:32
  It is. I want to pull all of this
• 33:33
  together and leave you, the listener, with one final, deeply
• 33:38
  provocative thought that really crystallized for me while
• 33:41
  reading through the appendices of these sources.
• 33:44
  As an industry and as a society, we are moving rapidly toward
• 33:48
  fully autonomous driverless trains.
• 33:51
  The sources talk extensively about FRMCS, the future railway
• 33:55
  mobile communication system, which is essentially a dedicated
• 33:58
  5G network for trains, enabling massive real time data exchange,
• 34:02
  AI diagnostics and remote autonomous control.
• 34:05
  But if the 30 year old train wasn't built for the Internet,
• 34:08
  and the Internet certainly wasn't built for safety, who
• 34:10
  actually owns the risk? That's a huge issue.
• 34:13
  When a software vendor remotes in from across the globe over a
• 34:17
  5G network into a trackside interlocking system that was
• 34:21
  built when dial up Internet was cutting edge, and an AI
• 34:24
  algorithm is dynamically managing the braking distance
• 34:27
  based on passive telemetry exported through a UDP proxy,
• 34:31
  who is truly driving the train? Is it the local operator?
• 34:34
  The cloud software vendor? The telecom provider hosting the
• 34:37
  5G slice. That is the multi billion dollar
• 34:39
  question and it's going to be the absolute liability nightmare
• 34:42
  of the next next decade. That's all for this episode of
• 34:44
  Cybersecurity Under Pressure. Real attacks, real lessons.
• 34:47
  Check your PLCS, check your logs, and maybe, just maybe
• 34:50
  question whether that air gap is really an air gap.
• 34:53
  See you in the next chapter.