In this interview with Help Net Security, Jorge Aldegunde, Global Head of Railway Services at DNV, talks through what happens when old operational technology meets newer IT in monorail systems. He explains why open networks widened the attack surface, how teams decide whether to patch a signalling flaw without stopping trains, and who carries the liability.

Aldegunde covers regulation like CRA and NIS2, training veteran engineers to think about threat actors, and spotting intruders who have been inside for months. His main rule: manage your risks and plan for resilience, not perfection.

Monorail control sits at the awkward seam between operational technology that was commissioned decades ago and the IT layer bolted on afterward. Walk me through a moment when those two worlds collided on your watch. What broke, and who in the room understood the problem first?

This may just as well go case by case. Our flagship project SDLC monorail is brand-new construction, so state of the art IT-OT applies. However, the point is well noted: railway applications would traditionally piggyback on vendor-specific SCADAS and dedicated communication systems (SDH-PDH).

Projects realized the benefit of employing IP-oriented networks (open standards, different vendors, lower costs). This broke the paradigm: open standards soon yielded open networks. SCADA systems became open and connected through middlewares, and data from public transport systems, stored in public / private clouds became available for users to build nice apps upon. This shift was further accelerated by condition-based maintenance and data-driven services, turning previously isolated assets into continuous data producers.

Last, but not least, AI came along. Attack surfaces and vectors multiplied. The key lesson is that the IT/OT boundary is no longer a boundary, it is an interface that must be actively managed.

A train cannot wait for a patch window the way an email server can. When you have a known vulnerability in a signalling or door-control component but cannot take the line out of service, what is the decision process, and who carries the liability if you choose to keep running?

The first step is whether the known vulnerability is exploitable and how. Then, secondly, assuming that it is, is the underlying risk-based approach towards the vulnerability (likelihood and impact).

From there, the decision branches. If a patch is available, the objective is to integrate it into planned maintenance windows without compromising operations, or if no patch is available, compensating measures must be considered, including network segmentation, monitoring or operational restrictions.

New horizontal regulation (CRA, NIS2) paves the way for accountability, and yet the issue remains adoption and stakeholder harmonization and clarity in complex railway contracts.

The real challenge lies in the integration layers, within components, subsystems and systems managed by different stakeholders. Responsibility is rarely concentrated in one entity. Back on the legislative front, there are ongoing working groups to help guide the implementation thereof and find the right trade-off with vertical regulation. This is far from perfect (take the example of the “expert guidance on implementation of CRA” – where there is still lack of consensus).

When you onboard a new operations engineer who has spent twenty years keeping trains moving and has never thought about threat actors, how do you change their instincts without insulting the expertise that keeps people alive?

This reminds me of the time RAMS (Reliability, Availability, Maintainability and Safety) came along and shifted the paradigm from silo engineering to a systems integration approach. Twenty years back such change seemed insurmountable – and now RAMS is railway ABC. Maybe this is a good angle of attack – railway cybersecurity practitioners usually come from “related” rail disciplines (safety, signalling, communications). As with any other paradigm change, it all starts with people, communication and awareness.

Solid, well-understood and widely adopted regulation must come as big enabler: we in DNV have a solid track record when it comes to applying IEC 62443 series and are part of the IEC 63452 PT. We are also active in the conformity assessment field by representing NB Rail (European association of RCABs – Railway Conformity Assessment Bodies) and participate in WG’s to adopt technical cybersecurity documents as “building blocks” for adoption in the TSI’s (Technical Specifications of Interoperability).

Suppose an attacker is already inside your network and has been for months. What signal in a monorail environment would you trust to tell you that, and what signal have you learned to ignore?

We would look for changes in OT traffic patterns (assuming these are known and controlled), undesired component behaviour or unavailability and uncontrolled configuration changes. Vigilance through systems (EDR, IDS, SIEM) is great, never underestimating processes at SOC level or the right training to railway staff. Plus, of course, rehearsing business continuity plans assuming worst-case scenarios.

Perhaps the latent threat is that where relaxation is perceived and awareness by rail staff (operations, maintenance, contractors) is little or diminishing. Much harm can also be caused by weak / uncontrolled supply chains – especially when these are shaped up as industrial SME’s that may struggle to find a business case to apply paradigms like “security by design”, “SBOM” or a lifecycle view to patch management.

If you had to hand your successor one hard-won rule that no certification course teaches, written on a single index card, what would it say?

Manage your risks. A risk-based approach is more than just a good start. Assume uncertainty principle inequation: attackers’ ability ≥ yours. Never assume that visibility equals control.

The objective is resilience. Systems must be able to operate safely even under degraded or uncertain conditions. In practical terms, this means combining:

• Risk-based decision making
• Continuous monitoring
• Preparedness for worst-case scenarios

Ultimately, if we fail to prepare, we are simply preparing to fail.

Apply today: Simplify security management with CIS SecureSuite Platform