Latest / Cybersecurity Under Pressure. Real Attacks, Real Lessons / Industrial Network Security: Designing for Operational Resilience

Transcript

Industrial Network Security: Designing for Operational Resilience · Cybersecurity Under Pressure. Real Attacks, Real Lessons

0:47
Imagine that your fraud detection system has been
0:50
disabled for three years and nobody knew it.
0:53
Oh man. I know take a second with that
0:57
one because I mean, while that sounds like an absolute
0:59
nightmare scenario if you're, you know, managing the risk
1:02
portfolio for a major bank. It's a career ending scenario
1:05
honestly. Right.
1:06
But we are not talking about banking today.
1:08
We're venturing deep into the world of operational technology
1:12
OT. Yep, the physical world.
1:14
Exactly. We're talking about
1:15
manufacturing plants, regional power grids, municipal water
1:19
treatment facilities. In that specific world, a blind
1:23
spot doesn't just mean a on a spreadsheet or a financial write
1:28
off. A blind spot literally stops
1:30
physical reality in its tracks. It stops the assembly line dead
1:34
or, you know, it forces a Regional Water supply to shut
1:37
off its pumps to prevent contamination.
1:39
It turns off the lights for a million people.
1:41
The stakes are entirely physical.
1:43
And I think that's why treating this domain like a standard IT
1:46
security problem is, well, it's getting us into so much profound
1:49
trouble right now. We're trying to apply digital
1:51
band aids to massive kinetic machines.
1:55
It's a disaster. And you know, today's a Monday,
1:57
July 6th, 2020 Sixth. And looking at the sheer volume
2:01
of alerts hitting the wire this morning, the landscape is
2:04
frankly wild. What happens when technical
2:07
details collide with the reality of the boardroom?
2:09
This story answers that. It really does.
2:11
It's a collision that most organizations, even the highly
2:14
resourced ones, are just entirely unprepared for.
2:16
The technical debt is finally meeting the legal liability.
2:19
Absolutely. And we have a massive stack of
2:21
sources to unpack for you today on this deep dive.
2:24
We're pulling from the latest SISA advisories, so the
2:27
Cybersecurity and Infrastructure Security Agency, some very fresh
2:31
and frankly very alarming Siemens vulnerability, reports
2:34
the European Union's NIS 2 directive.
2:36
Which is actively reshaping global compliance right now.
2:39
Big time. And we've also got some cutting
2:42
edge OT architecture guides from specialized firms like Zona,
2:45
Signia and OT Nexus. It's a lot of ground to cover.
2:48
It is our mission for this deep dive is to explain exactly how
2:52
industrial control systems are currently under absolute siege.
2:56
Why the traditional IT defenses you've trusted for a decade?
3:04
How to survive the fallout when the screens go dark?
3:07
Yeah, because they will go dark. They will, yeah.
3:09
So to do this justice, we have to start at the absolute
3:13
boundary of the network, because before we can even begin to talk
3:17
about monitoring traffic or, you know, looking for anomalies
3:19
inside a manufacturing plant, we need to look at how humans are
3:23
getting into that network in the first place.
3:25
Right, the front door. Yeah, and why the traditional
3:28
so-called secure methods are actually just loaded traps
3:31
waiting to be sprung. You're talking about the
3:33
corporate VPN. Talking about the VPN, the
3:35
Virtual Private Network, the ubiquitous tool we all use like
3:39
every single day to check our e-mail from a coffee shop or
3:42
access the corporate intranet from home.
3:44
We all love it. Right, But according to the Zona
3:47
Protocol Isolation guide we spent the weekend reviewing,
3:50
traditional VPNs fundamentally architecturally fail when you
3:55
try to apply them to an OT environment.
3:56
They absolutely fail. And the reason comes down to the
3:59
mechanics of how they actually establish a connection.
4:02
AVPN creates what's called a Persistent Network Layer tunnel.
4:06
Once that tunnel is authenticated and established,
4:10
any network protocol, any port that is within the scope of that
4:13
routing table is completely reachable.
4:15
Which is the fatal flaw when you bring it into an industrial
4:18
space. I mean, think about a normal
4:20
corporate IT environment. You might mitigate the risk of
4:22
that wide open tunnel with a ton of heavy endpoint controls.
4:26
Like what? Well, you have constant
4:28
antivirus patching, dynamic network segmentation, agent
4:32
based behavioral monitoring running on every single laptop.
4:35
But the laptop itself is heavily guarded.
4:37
Exactly. But in operational technology
4:40
you cannot do any of that. You're dealing with strict
4:43
deterministic communication requirements, legacy operating
4:46
systems from 20 years ago, and incredibly rigid safety
4:50
certifications. You cannot just slap a heavy IT
4:53
security agent on a 15 year old controller running a gas
4:56
turbine. It would just crash the turbine.
4:58
Right. So when that VPN tunnel is
5:01
created for a or remote engineer to login, native management
5:05
protocols suddenly become natively reachable across zones.
5:08
The tunnel bridges the gap. Suddenly, credentials can be
5:11
harvested out of memory or replayed.
5:14
A worm or some ransomware strain sitting quietly on that
5:19
engineer's laptop can just casually stroll across the
5:22
connection and find itself sitting right next to a critical
5:24
safety system. OK wait let me stop you there
5:26
because I was struggling with this when reading the zone a
5:28
brief. If I have multi factor
5:30
authentication MFA turned on, isn't that enough?
5:33
I mean it works perfectly fine for my e-mail.
5:34
I hear that all the time. Right.
5:36
Like if I have a hard token or I have to biometrically approve a
5:39
push notification on my phone to establish the VPN tunnel, I've
5:43
proven I am who I say I am. How is the malware bypassing
5:47
that? So that is the most common
5:49
misunderstanding in remote access architecture.
5:52
You are confusing identity with access.
5:54
OK, let's try to visualize it. MFA verifies who you are.
5:58
It proves cryptographically that the person holding the phone is
6:01
the authorized user. But AVPN dictates how you enter
6:05
the network and more importantly, what you bring with
6:07
you. Oh, I see.
6:08
OK, so it's less about my identity and more about the
6:11
vehicle I'm driving into the plant.
6:12
Yes. Like, let's say I give some of
6:14
the keys to my house the MFA. They proves they are the
6:17
specific person I intended to give the keys to.
6:20
But once they unlock the front door, they're inside.
6:23
They can walk into the kitchen, they can go into the basement,
6:25
they can rifle through my desk. The VPN gives their entire
6:28
computer, including any hidden malware riding along in the
6:31
background, the keys to the front door and lets the device
6:34
itself roam the house. That is a perfect way to put it.
6:37
And in a chemical processing plant or you know, a regional
6:40
power substation, we absolutely do not want anyone roaming the
6:44
house. We want them looking through a
6:46
heavily reinforced blip roof window at one specific object, a
6:50
single machine, and they cannot touch or see anything else.
6:54
That is the fundamental premise of protocol isolation.
6:56
OK, so how does that actually work mechanically?
6:59
If there is no tunnel, how am I controlling the machine?
7:01
It operates as a session level mediation, so when a user
7:04
initiates remote access using a platform designed for OT like
7:08
Zona, the inbound connection from their laptop is terminated
7:11
completely at a gateway and. This gateway is sitting where?
7:14
Sitting in the DMZ, the Demilitarized Zone, it usually
7:18
terminates using standard HTTPS or TLS.
7:21
Transport your security and it stops right there.
7:24
It completely removes the routable network path.
7:26
There is no IP to IP connection between the user's laptop and
7:29
the industrial machine. The tunnel just doesn't exist.
7:31
It physically and logically does not exist.
7:34
The user device never actually communicates directly with the
7:37
OT asset. It never participates in the
7:39
protocol negotiation at all. The isolation gateway terminates
7:44
your web session, validates who you are, and then the gateway
7:47
itself establishes a separate, entirely localized session to
7:50
the target asset inside the plant.
7:52
It basically translates your mouse clicks and keystrokes into
7:55
whatever native protocol is required by that legacy machine.
7:58
Like a remote desktop protocol RDP?
8:01
Yeah, RDP or virtual network computing, VNC.
8:04
Which means, if I'm understanding the architecture
8:07
correctly, even if my remote laptop is completely infected
8:11
with a self propagating ransomware worm, because there's
8:14
no network layer tunnel, the malware literally has no
8:18
physical or logical path to traverse into the plant.
8:22
It hits the gateway and dies because the gateway is only
8:25
passing pixels and keystrokes. Precisely.
8:27
The protocol execution is entirely isolated.
8:29
The malware cannot route itself because there is no route.
8:32
And you know, this architectural shift ties directly into how we
8:34
have to handle credentials in these environments, which is its
8:37
own total nightmare. Oh, I bet.
8:39
In OT, credentials are notoriously messy.
8:43
Because of the nature of shift work, accounts are often shared
8:46
among five different operators, or worse, administrative
8:50
passwords are just hard coded and embedded into automated
8:53
engineering workflows. That's terrifying.
8:55
It is if you rely on a VPNA compromised technician's laptop
9:00
that has a shared factory password saved in a text file on
9:04
the desktop is a disaster waiting to happen.
9:07
Yeah, I was reading the section on credential injection and it
9:10
honestly feels like magic compared to how IT usually
9:13
handles this. With protocol isolation.
9:16
The user never actually sees, types or handles the passwords
9:19
for the end devices. Never, because they shouldn't.
9:22
The user authenticates to the external gateway via their
9:25
identity provider using your beloved MFA, and once their
9:28
identity is proven, the gateway retrieves the required
9:31
credentials for the specific OT asset from a highly secure
9:34
encrypted vault. The gateway then injects those
9:36
credentials directly into the isolated session it creates on
9:39
the back end. So the password never traverses
9:41
the Internet, it never touches the user's laptop, it cannot be
9:45
stolen by a phishing attack targeting the user, it can't be
9:48
reused outside that specific mediated session, and a stolen
9:52
password alone is completely useless without the identity and
9:55
session context to trigger the injection.
9:58
It aligns perfectly with true zero trust principles.
10:03
I mean, zero trust is a massive buzzword right now, but its core
10:07
definition demands that we assume a breach has already
10:09
occurred on the endpoint. You must assume every laptop
10:12
connecting to your network is hostile.
10:14
Which is a grim way to look at it, but necessary.
10:16
Very necessary. If we assume the engineer's
10:19
laptop is compromised, granting it AVPN tunnel is a death
10:23
sentence for the facility. Protocol isolation contains the
10:26
blast radius. By simply eliminating the path,
10:29
you don't have to worry about detecting the malware crossing
10:31
the tunnel if you don't build the tunnel in the first place.
10:33
Which naturally brings us to the internal network, because even
10:37
if we isolate our remote access perfectly, we know the perimeter
10:40
is essentially porous. We were looking at the Fortnet
10:43
2025 report earlier this week and the data show that 75% of
10:48
all OT attacks actually start as a breach on the corporate IT
10:52
side. Yep. 3/4.
10:53
Someone in human resources clicks a bad link, the corporate
10:56
network is compromised and the attackers pivot laterally into
10:59
the manufacturing side. We have to operate under the
11:02
assumption that the attackers are already inside the house.
11:05
You have to. The idea of a hard outer shell
11:07
and a soft trusted internal network is an illusion.
11:10
It has been for a long time. So we must monitor the inside of
11:13
the plant. We have to look for lateral
11:15
movement, command and control beacons, unauthorized
11:17
configuration changes. But the literature from OT,
11:20
Nexus and Scatterhawk makes it abundantly clear that monitoring
11:24
an operational technology network is fundamentally
11:26
different from monitoring an office network.
11:28
It all stems from what you called earlier the sacred rule
11:31
of OT. Do no harm.
11:33
Determinism. If you walk into any industrial
11:36
facility and talk to a process control engineer, determinism is
11:40
the concept they will defend with their lives.
11:42
How did that differ from IT? In an IT network, if you try to
11:45
load a web page and the network is congested, the packets might
11:48
get delayed or dropped. The web page takes three extra
11:51
seconds to load. You get annoyed, but life goes
11:54
on. That is non deterministic.
11:57
In OT. Determinism means that a
11:59
specific digital signal must reach its destination within a
12:02
guaranteed exact mathematical time frame, not as fast as
12:06
possible, but at an exact microsecond.
12:10
Because if a massive chemical mixing VAT is approaching a
12:12
critical pressure limit and the safety controller sends a
12:15
command to open a release valve, and that command is delayed by
12:18
two seconds because the network was congested with IT traffic.
12:21
The valve doesn't open in. Time and the VAT explodes.
12:24
Literally. The physical process fails
12:27
catastrophically. The tolerances are incredibly
12:30
tight. And this is exactly why
12:33
traditional IT monitoring tools are so profoundly dangerous when
12:37
deployed blindly in OT environments.
12:40
IT tools are loud. They love active scanning.
12:42
Think about how a vulnerability scanner works on a corporate
12:45
network. OK, IT aggressively sends out
12:48
thousands of packets, pinging devices, probing ports, asking
12:51
who are you? What operating system are you
12:53
running? Are you alive?
12:54
Send me your version number. Right.
12:56
And on a corporate network, Windows and Mac laptops are
12:59
built to handle that noise. They just reply, hey, I'm a
13:01
Windows 11 machine and move on. Right?
13:04
Here's where it gets really interesting.
13:05
In an IT network it's fine, but in OT doing that active scanning
13:09
is like, well it's like taking inventory in a warehouse by
13:12
walking in with a megaphone and screaming at every single worker
13:15
to drop what they're doing, yell their name back to you, and list
13:19
everything they are carrying. That is exactly what it's like,
13:23
and in a human warehouse, productivity grinds to a halt
13:25
and people hate you. But in an OT environment, the
13:28
outcome is much worse. We're dealing with legacy
13:31
programmable logic controllers, PLCS.
13:35
These are essentially small, ruggedized computers designed to
13:38
interface directly with physical sensors and motors.
13:41
They have incredibly fragile, minimal network stacks.
13:45
They're built to do 1 physical task perfectly millions of times
13:48
in a row for 20 years. They are not built to handle
13:51
unexpected malformed packets or aggressive TCPSL Axicus
13:55
handshakes from a modern IT vulnerability scanner.
13:58
So what happens when you hit them with one?
14:00
If you shout at a legacy PLC with an active scan, it doesn't
14:03
know how to drop the packet. It's memory buffer overflows, it
14:06
doesn't answer you, it just crashes.
14:08
It goes into a fault state and the assembly line halts
14:10
immediately. Wow, I remember reading an
14:13
incident report where a security team accidentally shut down an
14:16
entire automotive manufacturing line because they ran an IT ping
14:20
sweep across the factory subnet. It cost them millions in
14:23
downtime. Happens more often than you'd
14:24
think. Which is why the architectural
14:26
guides emphasize the absolute, non negotiable necessity of
14:31
passive monitoring. You have to observe the network
14:34
traffic without generating a single packet of your own.
14:37
Going back to the warehouse analogy, it's like installing
14:39
silent cameras in the rafters. You watch the natural flow of
14:43
work, you see who was talking to whom, but you never interrupt
14:46
the process. You listen to the existing
14:48
communication between devices. Usually this is done by
14:51
configuring a span port on a network switch, which takes a
14:54
copy of all the traffic passing through and mirrors it silently
14:57
to your monitoring sensor. You build your asset inventory,
15:00
your topology maps, and your understanding of the environment
15:03
entirely from what you see passively on the wire.
15:05
You never ask a device a direct question.
15:08
But to do that effectively, your monitoring platform has to
15:10
actually speak the native languages of the plant floor.
15:14
Right, exactly. It can't just parse standard TCP
15:17
IP web traffic. It has to have deep native OT
15:20
protocol support the guides mentioned it needs to understand
15:24
Modbus TCP, Profinet DNP 3, OPCUA.
15:28
I got to be honest, these are protocols I had never even heard
15:30
of before looking at this stack of research.
15:32
And that is the exact problem many IT security teams face.
15:37
If your monitoring tool only understands standard IT
15:40
protocols, it is blind to 90% of what is actually happening in a
15:44
manufactory facility. Modbus TCP, for example, is one
15:48
of the most common industrial protocols in the world.
15:50
It's ancient, it's unencrypted, and it operates entirely in
15:54
clear text. Really just clear text.
15:56
Just clear text. It is basically just a protocol
15:59
for reading and writing memory registers on APLC.
16:02
If your monitoring tool doesn't know how to decode a Modbus
16:05
packet, it might see that an engineering workstation is
16:08
talking to APLC, but it has no idea what they're saying.
16:11
Are they exchanging a routine temperature status update, or is
16:14
the workstation sending a command to shut down the primary
16:17
safety cooling pump? Without deep packet inspection
16:19
tailored for OT protocols, you're just looking at static
16:22
and the. Threat landscape taking
16:24
advantage of that static is staggering.
16:26
Want to bring in the Dragos 2026 report data we reviewed, they
16:29
actively tracked 119 different ransomware groups that are now
16:33
specifically purposely targeting industrial organizations that
16:36
impacted over 3 to 300 organizations globally last year
16:39
alone. It's massive.
16:41
At the Trellix report from late 2025 to that context,
16:45
manufacturing is now definitively the number one
16:48
targeted sector globally. 42% of all OT cyberattacks hit the
16:52
manufacturing sector. That is more than the energy
16:55
sector, more than transportation, more than water.
16:58
Why manufacturing factoring. You think power grids would be
17:00
the prime target for nation states?
17:02
Nation states. Yes, they want the grid.
17:05
But cyber criminals operate on economics.
17:07
Attackers know that downtime in manufacturing costs millions of
17:11
dollars per day, sometimes per hour.
17:14
It's the ultimate leverage for extortion.
17:16
A hospital might pay a ransom to save lives, but a manufacturer
17:19
will pay a ransom in hours just to stop bleeding cash.
17:22
That makes total sense. And these attackers aren't just
17:24
doing smash and grab operations anymore.
17:26
They are pre positioning silently inside these networks.
17:29
Sometimes they sit there for weeks or months learning the
17:32
process, finding the most critical PLCS.
17:35
If you don't have passive monitoring establishing a
17:38
behavioral baseline, they are completely invisible until the
17:41
ransom note prints out on the factory floor.
17:43
So let's talk about how we actually detect them when we are
17:46
monitoring passively. The IC3 guide draws a really
17:49
critical distinction regarding detection methodologies.
17:52
First, they talk about baseline based detection.
17:55
This uses machine learning and statistical models to identify
17:58
deviations from normal behavior, right?
18:00
If APLC usually sends 50 packets a minute to a human machine
18:04
interface, the HMI screen, the operator watches and suddenly
18:08
that PLC starts sending 5000 packets a minute, the baseline
18:12
model flags it as an anomaly and triggers an alert.
18:15
Yes, baseline detection is highly effective for spotting
18:18
novel, unknown threats, like a new ransomware strain trying to
18:22
spread, but it has a significant flaw.
18:24
What's that? It requires a perfectly clean
18:27
learning window. If the attacker is already
18:29
inside your network when you turn on the monitoring tool, the
18:32
tool learns the attacker's behavior as normal.
18:34
Oh wow. Yeah.
18:35
Furthermore, statistical models might miss very quiet, highly
18:38
targeted edge cases. A sophisticated attacker might
18:41
only send one single malicious command packet.
18:44
A baseline model looking for volume anomalies will just
18:46
completely miss it. Which is why the guide heavily
18:49
stresses specification based detection as the necessary
18:52
counterpart. Exactly.
18:54
Specification based detection doesn't care about what is
18:57
normal based on observation. It defines the absolute
19:01
mathematical range of valid behaviors.
19:03
Almost like a digital safety system.
19:06
You sit down with the process engineers and you define the
19:08
operational state machine. You hard code code rules based
19:11
on engineering reality. I can see the IT side struggling
19:14
with this. I mean, how do you even build a
19:16
specification for a 20 year old plant where the original
19:19
engineers have all retired? It is incredibly difficult,
19:22
which is why it usually focuses on the most critical safety
19:25
checkpoints. For example, you build a rule
19:27
that says this specific engineering workstation on this
19:30
specific IP address during these specific maintenance hours is
19:34
the only device allowed to send a firmware update command to
19:38
this critical turbine PLC. Anything else?
19:40
Try if any other device tries it at any other time.
19:43
It's not just flagged as an anomaly, it's recognized as a
19:45
direct violation of the engineering specification.
19:48
It triggers a massive alarm. So if we step back, we have our
19:52
remote protocols perfectly isolated.
19:54
We are passively monitoring everything with deep protocol
19:57
visibility. We're using both baseline and
19:59
specification detection. We're doing everything by the
20:02
book. Perfect setup.
20:03
But all of this relies on the physical network infrastructure
20:06
actually enforcing these rules. What happens when the physical
20:10
devices enforcing our network zones, the managed industrial
20:13
switches, are fundamentally cryptographically flawed?
20:17
Then the entire architecture collapses like a House of Cards.
20:20
The logical zones you've drawn on a whiteboard just cease to
20:22
exist in reality. We need to talk about one of the
20:24
most terrifying vulnerabilities I've read about in a long time.
20:27
Let's dig into the Radius protocol and the industrial
20:30
switch. We have the Siemens Security
20:33
Advisory SSA 723487 and a very closely related deeply urgent
20:39
SISA advisory regarding Schneider Electric Modicon
20:42
industrial switches. We are talking about the
20:44
vulnerability designated as CVE 20243596.
20:48
It has been dubbed Blast Radius by the security community.
20:51
It carries ACVSS severity score of 9.1 out of 10.
20:54
Which is astronomical. It is, and it doesn't attack an
20:58
endpoint or a PLC. It attacks the absolute core of
21:01
how network devices authenticate the administrators trying to
21:05
manage them. OK, let's break this down for
21:07
anyone who hasn't stared at a network packet capture recently.
21:10
Radiuses remote authentication dial in user service.
21:14
It's a protocol used for centralized authentication,
21:17
right? If I am an administrator and I
21:19
want to log into an industrial managed switch to change a
21:22
configuration or update a firewall rule, I type in my
21:24
password. The switch acting as the client
21:27
takes my request, wraps it up and asks the central radio
21:30
server over the network. Hey this guy is trying to log in
21:33
with his password, is he legit? That is exactly how it works.
21:36
It allows you to manage passwords in one central
21:38
database instead of updating them manually on 500 different
21:41
switches. But Blastradius exploits a
21:44
fundamental mathematical flaw in how the RADIUS protocol,
21:47
specifically when using UDP as its transport layer, validates
21:51
the response coming back from that central circuit.
21:53
How does it validate it? RADIUS relies on the MD5 hashing
21:57
algorithm to create a digital signature for the packet,
22:00
ensuring it hasn't been tampered with in transit, and we have
22:03
known for over a decade that MD5IS cryptographically weak.
22:07
I remember learning about MD5 collisions years ago.
22:10
A hash is just like a mathematical fingerprint of a
22:13
file or a packet. If you change even one letter in
22:16
the packet, the resulting hash fingerprint should be completely
22:19
wildly different. But MD5IS broken, meaning you
22:23
can theoretically find 2 completely different files that
22:27
accidentally produce the exact same fingerprint.
22:29
But this attack blast radius is a chosen prefix collision
22:33
attack. Reading how this actually works
22:36
physically hurt my brain. It is brilliant and it is
22:39
devastating. Let's map it out.
22:40
To execute this you need an on path attacker.
22:44
This means an attacker who has already gained a minor foothold
22:46
on the network. Maybe they compromised a low
22:48
level device and they're sitting logically between the target
22:51
switch and the RADIUS server. So they can see the traffic
22:54
passing by. Yes, the attacker attempts to
22:56
log into the manage switch using a completely fake password.
22:59
So the switch says hold on, let me check and sends the
23:02
authentication request to the RADIUS server.
23:04
The RADIUS server looks at the fake password, laughs, and
23:08
generates an access reject message to send back to the
23:10
switch. Precisely.
23:12
But before that access reject message can reach the switch,
23:15
our on path attacker intercepts it in transit, they capture the
23:18
packet. Now, because of the specific
23:20
chosen prefix MD5 vulnerability, the attacker can mathematically
23:24
forge the hash and alter the payload of the packet on the
23:28
fly. Wait, they don't just change the
23:30
message, they have to make the math line up perfectly so the
23:32
switch doesn't realize it's been tampered with.
23:34
Right, they flip the ACCESS REJECT command into an ACCESS
23:38
ACCEPT command. Then they append carefully
23:40
calculated junk data the collision block into the packet
23:43
so that when the switch calculates the MD 5 hash upon
23:46
receiving it, the fingerprint miraculously matches the
23:49
original legitimate signature of the server.
23:52
That is insane. The attacker forwards this
23:54
mathematically perfect forged packet to the switch.
23:58
The switch receives it, checks the hash, assumes the central
24:01
authentication server just approved the login, and grants
24:04
the attacker full, unhindered administrative access to the
24:07
network switch. Full access.
24:08
No valid credentials needed, no noisy brute forcing of passwords
24:12
required. They just mathematically lie to
24:14
the door. And they are in.
24:16
Wait, no, that's not right. If the switch is compromised,
24:20
doesn't the whole concept of network segmentation just
24:22
vanish? Yes, it entirely vanishes and
24:25
that is the dark uncomfortable reality of OP security that many
24:30
executives refuse to acknowledge.
24:32
An industrial managed switch is not just a piece of dumb IT
24:36
plumbing routing packets, it is the device where the plants
24:39
entire trust model becomes a physical reality.
24:42
In all the architecture guides like IEC 62443, they talk
24:45
constantly about zones and conduits.
24:48
You isolate the highly volatile chemical mixing zone from the
24:51
mundane packaging zone. You create strict rules about
24:53
what data can flow between them. But those zones are just logical
24:56
concepts, just drawings on a PowerPoint slide until a managed
25:00
switch physically enforces them using virtual local area
25:03
networks, Vlans, and access control lists.
25:06
If the device managing those Vlans is hijacked, your zones
25:09
are gone. Or consider RSTP, the Rapid
25:13
Spanning Tree Protocol switches use this to prevent network
25:16
loops, ensuring traffic flows smoothly.
25:18
An attacker with control of the switch can manipulate RSTP to
25:22
create a loop, causing a broadcast storm that overwhelms
25:25
every device on the network. Wow.
25:27
Effectively shutting down the entire plant floor without ever
25:30
touching Aplc. Exactly.
25:31
They can reroute traffic to bypass firewalls, open hidden
25:34
ports, and crucially, they can disable the SPAN ports you're
25:38
using for your passive monitoring.
25:40
They can blind your security team entirely while they move
25:43
laterally across the facility. How on earth do we mitigate a
25:46
9.1 CBSS vulnerability in a core protocol?
25:49
I mean, the Siemens advisory outlines a few specific
25:51
countermeasures, but they sound incredibly difficult to
25:54
implement in an active plant. The primary recommendation is
25:57
requiring the Message Authenticator attribute in all
25:59
RADIUS packets. This attribute essentially
26:02
forces the protocol to use a stronger cryptographic check by
26:06
passing the vulnerable MD5 collision point.
26:09
But it's not a simple switch you flip.
26:11
It requires that both the switch firmware and the RADIUS server
26:14
software are updated to support and strictly mandate this
26:17
attribute. Which sounds easy in IT, but.
26:20
In OT, it's a nightmare if you mandate it on the server but a
26:23
legacy switch doesn't support it.
26:25
That switch can no longer authenticate administrators.
26:28
You lock yourself out, and patching the firmware on a core
26:31
network switch requires taking the network down.
26:34
You need a scheduled maintenance window, which for a power plant
26:37
could take six months to a year to approve and schedule.
26:40
Which makes the secondary mitigation strategy outlined by
26:42
CISA absolutely critical right now.
26:45
If you can't patch, you most strictly isolate the management
26:48
plane. You cannot allow RADIUS
26:50
authentication traffic to mix with general plant floor
26:53
communication. You have to restrict access to
26:56
the specific network segments where these management messages
26:59
are exchanged. Typically you do this by putting
27:01
all switch management interfaces on a highly restricted dedicated
27:05
management VLAN and wrapping it in strict firewall rules.
27:09
Because the attack requires the attacker to be on path, if they
27:12
cannot physically or logically get on to the management VLAN to
27:16
intercept the radius traffic in the 1st place, they cannot
27:19
execute the collision attack, even if the protocol remains
27:22
vulnerable. Precisely, you contain the risk.
27:25
It is just a stark reminder that the very tools we use to build
27:28
the defensive walls, the switches, the centralized
27:31
authentication servers, can become the easiest doors for the
27:34
attackers to walk through. And because these deeply
27:37
technical details like an MD5 hash collision can literally
27:40
cause a municipal water supply to halt operations, governments
27:44
are completely loose using their patients.
27:46
We're witnessing a massive historic collision between the
27:48
technical reality we just described and the legal reality
27:51
of the boardroom. The era of executive standing in
27:54
front of a regulatory committee and saying we didn't understand
27:57
the cyber risks, it was an IT problem is over.
28:00
The legal liability has fundamentally shifted and it is
28:04
catching a lot of corporate boards completely off guard.
28:07
Enter the NIS 2 directive in the European Union.
28:11
This piece of legislation went into effect in October 2024,
28:14
with major, highly targeted amendments finalized just a few
28:18
months ago in January 2026. It is sweeping.
28:22
It covers 18 critical sectors, energy, transport, banking and
28:26
water, sure, But it also aggressively expands into waste
28:29
management, public electronic communications, postal services
28:32
and the manufacturing of critical products like
28:34
pharmaceuticals and medical devices.
28:36
And the most vital structural shift in NIS 2 is not the
28:39
technical requirements, it is the introduction of direct
28:42
personal accountability for top management.
28:45
See more about that. The directive explicitly states
28:47
that the management bodies of these essential entities must
28:49
approve the cybersecurity risk management measures, oversee
28:52
their implementation, and critically, they can be held
28:55
personally legally liable for non compliance if a major
28:58
incident occurs. It is dragging cybersecurity
29:01
directly into the boardroom by the lapels.
29:04
The board can no longer just outsource this complex risk to
29:07
the Chief Information Security officer.
29:09
Look at a dashboard showing green check marks once 1/4 and
29:12
consider their fiduciary duty fulfilled.
29:14
The regulators recognize that without executive skin in the
29:17
game, security budgets are always the first to be cut and
29:21
to manage this massive new regulatory framework at a macro
29:24
level, NIS to legally establish A coordinated network of
29:28
computer security incident response teams or CSI, youths
29:31
across Member States. Right.
29:33
And it also established the EU Cyclone network.
29:36
This stands for the Cyber Crisis Liaison Organization network,
29:39
designed specifically for coordinating responses to large
29:42
scale cross-border cyber crises. If a ransomware group hits a
29:45
major logistics provider operating across France, Germany
29:49
and Italy, Cyclone ensures A unified government level
29:52
response. But all of this macro level
29:54
regulation demands very specific granular technical
29:57
implementation at the factory level.
29:59
Exactly. The law tells you what you must
30:01
achieve, but it doesn't tell you how to wire your network.
30:05
Which brings us to IEC 62443. If NIS 2 is the law telling you
30:11
that you must be secure or face ruinous fines and liability, IEC
30:15
62443 is the globally recognized technical blueprint showing you
30:20
exactly how to build that security.
30:22
It is the definitive global standard for industrial
30:24
automation and control system security, and it is structured
30:27
in a very deliberate, layered way across 4 distinct areas.
30:31
You have Part 1, the policies and procedures which defines the
30:34
management system and risk assessment processes.
30:36
OK. Part 2 is the system
30:38
requirements which covers the architectural design at a macro
30:40
level. Part 3 is the component
30:42
requirements which actually dictates how vendors like
30:45
Siemens or Rockwell must build secure features into their pre
30:47
LCS and switches. And Part 4 contains profiles for
30:50
specific industries adapting the rules for a pipeline versus,
30:53
say, a pharmaceutical lab. In a core tenet running through
30:57
all of IEC 62443 is that concept of zones and conduits we keep
31:02
coming back to. You logically group physical
31:05
assets with similar security requirements and risk levels
31:08
into zones. Think of them like watertight
31:10
bulkheads on a submarine. And then you strictly,
31:13
rigorously control the conduits, the network paths between them.
31:17
But here is the massive friction point when the technical
31:20
blueprint of 62443 meets the legal hammer of NIS 2.
31:25
Compliance demands evidence. You cannot just present an
31:28
auditor with a beautifully drawn Vizio diagram showing your zones
31:31
and conduits. You have to mathematically,
31:34
technically prove that those zones are actively enforced
31:37
every single second of the day. So what does this all mean?
31:39
It sounds like the difference between telling a judge you're a
31:41
good driver versus handing over your dash Cam footage.
31:44
That is the perfect analogy. In an OT environment facing
31:47
regulatory scrutiny, your dash Cam is your unalterable
31:51
continuous audit trail. This is where the monitoring
31:53
platforms we discussed, like OT Access and Scatterhawk,
31:56
transformed from being just security tools into vital
31:59
compliance engines. If a national regulator walks
32:02
into your facility following an incident and asks to see your
32:05
network segmentation enforcement, they want proof.
32:08
You have to pull the date stamped cryptographically signed
32:11
log showing that when an unauthorized connection from the
32:14
IT network attempted to cross the conduit into the OT zone,
32:18
the system detected it, alerted on it, the firewall blocked it,
32:21
and the security operation center formally responded.
32:25
An audit is just a failure waiting to happen.
32:28
You need deep event logging. You need granular change
32:31
management tracking. If a maintenance engineer plugs
32:33
in a laptop and updates the logic code on APLC governing a
32:37
chemical mixing ratio, the system must record who did it,
32:40
at what exact time, and what specific lines of code changed.
32:43
Because under NIS 2, if that PLC code change causes a toxic spill
32:48
or a safety incident and you do not have an audit trail proving
32:51
you followed security procedures, the executives are
32:54
personally legally exposed to negligence claims.
32:57
Compliance theater is dead. We are firmly in the era of
33:00
evidence based governance. You must prove your security
33:03
posture every day. But here is the sobering reality
33:07
we have to address. Even with the best governance,
33:10
the most rigorous executive oversight, the best protocol
33:13
isolation at the perimeter, the most comprehensive passive
33:16
monitoring, and a fully patched RADIUS authentication server,
33:21
the core tenet of zero trust dictates that we must assume a
33:24
breach will eventually happen. We have to assume a highly
33:27
resourced attacker will find a zero day vulnerability and
33:30
bypass all of it. Which leads us to the final, and
33:33
frankly, the most terrifying chapter of this deep dive.
33:36
When the mitigations fail, when the screens on the factory floor
33:39
suddenly go dark, when the ransomware extortion note pops
33:42
up on the HMI terminal and the physical plant grinds to a
33:44
chaotic halt, how do you get physical reality running again?
33:47
You turn to your last ultimate line of defense, your OT backup
33:51
and recovery strategy. And I need to be brutally clear
33:53
here. If a manufacturing plant thinks
33:55
they can just rely on their standard enterprise IT backup
33:58
system to restore their industrial controllers, they are
34:00
in for a very, very bad day. We spent hours reading through
34:04
the Signia guide to OT backup strategies, and it outlines
34:07
exactly why traditional IT backups fail so spectacularly in
34:11
industrial environments. IT backups, like a central agent
34:16
running on a Windows Server backing up to a cloud
34:18
repository, are built for dynamic data, centralized
34:21
management, and unified policies.
34:23
Right. OT environments are an entirely
34:25
different beast. They are incredibly static in
34:27
the configurations, but they are supported by a wildly, almost
34:32
comically fragmented vendor ecosystem.
34:34
It is chaos. In a single manufacturing plant.
34:37
You might have Siemens PLCS controlling the main line,
34:40
Rockwell Automation controllers managing the packaging, legacy
34:43
Schneider Electric HM is on the walls, all running different
34:47
heavily proprietary closed source operating systems.
34:50
Some of these devices this is haven't had a firmware update in
34:52
a decade because they are certified for safety and cannot
34:55
be touched. A centralized IT backup agent
34:58
literally cannot be installed on a proprietary embedded
35:01
controller from 2005. I kept asking myself while
35:03
reading this, why can't we just throw all this PLC logic, all
35:07
these kind of configuration files into the cloud like I do
35:10
with my smartphone photos? We have immense bandwidth now.
35:13
I backup gigabytes of photos from my phone to a cloud server
35:17
every night. Why can't a power plant just
35:20
push its configs to an AWS bucket?
35:22
Because you have to account for the physical, chaotic reality of
35:25
a major ransomware attack. When a sophisticated threat
35:29
actor group hits a manufacturing plant, they spread as fast as
35:32
possible. The very first action the
35:34
incident Response team takes when they realize what is
35:36
happening is to sever the network connections.
35:40
They physically pull the cables or shut down the core riders.
35:43
They cut the plant off from the Internet entirely, and they
35:45
often sever the connection to the corporate IT network to stop
35:49
the lateral movement of the malware.
35:51
If the plant network is intentionally severed to stop
35:53
the bleeding, a cloud backup repository is completely,
35:57
totally inaccessible. It might as well be stored on
36:00
the moon. Exactly when the plant is dark
36:03
and the network is down, you need offline physical backup
36:06
sitting in a fireproof safe right next to the machine on the
36:09
factory floor. The Signia guide highlights the
36:12
absolute necessity of maintaining specialized recovery
36:15
devices like a ruggedized Siemens Field PG.
36:18
What's that? For those unfamiliar, a Field PG
36:21
is essentially A heavily armored, incredibly thick
36:24
industrial laptop. It comes with all the necessary
36:27
legacy serial ports and most importantly, it has all the
36:30
proprietary, heavily licensed vendor software pre installed
36:33
and authenticated. You keep the critical PLC
36:36
configuration files and the compiled project logic stored
36:39
secure securely offline on the encrypted hard drive of that
36:42
specific device. So if.
36:44
APLC on the floor is bricked or encrypted by an attacker.
36:47
An engineer can walk up to it in the dark, plug the rugged Field
36:50
PG directly into the controller with the physical serial cable,
36:54
and manually push the clean logic back onto the device
36:57
without needing a network connection.
36:58
Yes, but the logic is only half the battle.
37:01
What if the ransomware payload intentionally corrupted the
37:04
firmware? Or what if the hardware itself
37:06
fails during the chaotic shutdown?
37:08
You must maintain what the industry calls deployment ready
37:12
spare hardware hot swaps. So just physical backups of the
37:16
machines themselves, yeah. You need a physical identical
37:19
spare PLC sitting in a locked cabinet on the factory floor,
37:23
preconfigured with the baseline firmware ready to be physically
37:26
slotted into the rack and loaded from that offline backup.
37:30
The logistics of that are mind boggling.
37:32
You essentially need a shadow inventory of your most critical
37:35
infrastructure. Yeah, but the guide points out
37:37
it's not just the PLCS, it's the HM is the human machine
37:41
interfaces and the massive engineering workstations that
37:44
manage them. For those full scale servers,
37:46
the Sydney A Guide aggressively stresses the need for bare metal
37:49
recovery. Bare Metal Recovery, or BMR
37:51
means your backup solution must support restoring the full
37:54
system state, the underlying operating system, the registry,
37:57
the applications, the exact configurations, all at once as a
38:00
single image directly onto brand new blank hardware.
38:04
It bypasses the need to manually reinstall Windows or Linux, then
38:09
reinstall the drivers, then reinstall the software.
38:12
In a crisis, when you are losing millions of dollars an hour, you
38:15
do not have the time to rebuild complex engineering servers from
38:18
scratch. And reading to the guide, the
38:21
biggest hurdle to bare metal recovery isn't the data size,
38:24
it's the nightmare of hardware bound licenses, or HBLSI hadn't
38:28
even considered this layer of complexity.
38:30
Some incredibly expensive industrial software licenses are
38:33
mathematically tied to the specific MXE address of the
38:36
network card or the physical serial number of the motherboard
38:40
of the server it was originally installed on.
38:42
It's an aggressive form of digital rights management.
38:44
It is a massive, crushing pain point during an act of recovery.
38:49
Imagine the scenario. Your primary engineering server
38:52
is fully encrypted by ransomware.
38:54
You do everything right. You grab a brand new spare
38:56
server from the IT closet. You successfully execute a bare
39:00
metal restore from an offline backup.
39:01
The server boots up, the operating system loads.
39:04
You click on the critical OT management software to get the
39:06
plant running, and the software wakes up, scans the hardware,
39:10
realizes it's on a different motherboard with a different MSE
39:13
address, invalidates its own license, and stubbornly refuses
39:16
to run. Just brutal.
39:18
The factory is burning down and the software is asking you to
39:20
insert a licensing dongle or call customer support.
39:23
So your backup and recovery strategy has to include
39:26
meticulous management of licensed backup utilities,
39:28
physical USB dongles or pre map transfer mechanisms outlined in
39:33
a playbook. It takes immense planning.
39:35
You also have to utilize agent free backup operations whenever
39:38
possible. Instead of installing a heavy IT
39:41
backup agent that might crash the legacy OT software, you use
39:45
native tools like Microsoft's Volume Shadow Copy Service VS.
39:49
It says VSS allows the system to take a point in time snapshot of
39:52
the hard drive without freezing the running applications or
39:55
interrupting the determinism of the OT processes.
39:58
And finally, you must have absolute ironclad tamper
40:02
protection for these backups, because modern attackers are
40:05
incredibly smart. They know that if you have
40:06
clean, accessible backups, you will simply wipe your machines
40:09
and you won't pay their ransom. So their first objective upon
40:12
entering the network isn't to encrypt the plant, is to quietly
40:15
hunt for your backup servers, delete the archives, or encrypt
40:18
the backups. First before they trigger the
40:20
main attack on the PLCS. Which is why you must use
40:23
immutable storage. Immutable storage is a
40:26
technology where data, once written to the disk, is
40:29
mathematically locked. It cannot be altered,
40:31
overwritten or deleted for a set period of time, say 30 days.
40:35
Not even by a user with top level administrative privileges.
40:38
If the attacker gains full control of the network and
40:41
issues a command to delete the backup repository, the storage
40:44
array simply rejects the command.
40:46
It is wild to think about the physical reality of this.
40:49
Your ability to recover a modern hyper connected smart
40:52
manufacturing facility relies entirely on having a completely
40:56
offline ruggedized laptop in a safe, a closet full of physical
41:00
spare parts, immutable hard drives, and literal paper print
41:03
outs of cause and effect matrices and input output lists.
41:06
Paper print outs. Yes, the absolute certainty of
41:09
your physical offline backups dictates whether you are forced
41:12
to hand millions of dollars to a cyber cartel or if you can look
41:15
them in the eye and actually restore operations on your own
41:18
terms. It is the ultimate defining
41:20
paradox of modern industry as IT and OT rapidly converge to make
41:25
our physical industry smarter, more efficient, and more
41:27
remotely connected. The very cybersecurity tools,
41:30
the VPNs and the network switches meant to protect the
41:33
physical world are becoming the primary vectors used to attack
41:36
it. Our safety, our water, our power
41:39
relies entirely on trusting the untrustable.
41:41
That's all for this episode of Cybersecurity Under Pressure.
41:44
Real attacks, real lessons. Technical details matter.
41:47
The board's perspective matters. What matters most is what you do
41:51
with both of them tomorrow.