Why Generic Threat Intelligence Doesn't Work for Rail

Key takeaways

• Generic threat intelligence assumes fast remediation. Rail's fail-safe design means patches often cannot be applied immediately. As such, intelligence needs to help prioritise exploitability, not just flag vulnerabilities.

• Legacy protocols like GSM-R sit outside what standard IT-focused intelligence feeds monitor. This means that threats specific to rail's own technology can go unseen unless intelligence is scoped to those systems directly.

• UK rail's ownership structure means risk regularly materialises at third parties rather than the operator itself. As such, intelligence needs to extend to named suppliers and contractors, not just the organisation's own footprint.

• A shortage of professionals who understand both cybersecurity and rail operations means raw intelligence often cannot be translated into a usable decision without specialist, analyst-led interpretation.

• These constraints point toward analyst-led, rail-specific intelligence rather than a generic feed or detection tool as the more effective starting point.

Part one of this series covered the numbers: rising investment, ransomware as the leading threat, and a UK incident that showed the risk is already present. The natural response to that kind of evidence is to buy threat intelligence. The problem is that most threat intelligence is built around assumptions that do not hold up in a railway environment, and a feed that works well for a corporate IT can quietly fail to tell a rail operator anything useful.

Safety Rules Change What Intelligence Needs to Deliver

Generic threat intelligence is built around a straightforward feedback loop: identify an indicator of compromise, a piece of active threat actor tradecraft, or a vulnerability being exploited in the wild, alert the security team, and expect remediation to follow quickly, whether that means blocking an indicator, isolating a host, or patching.  That loop assumes the recipient can act on the advice quickly. Rail cannot always do that. Signalling systems are deliberately fail-safe, and the NCSC's Cyber Assessment Framework requires cyber incident response to integrate with existing physical safety protocols rather than override them. This means an alert cannot simply say "patch now" if the only safe way to apply it is during a scheduled maintenance window months away.

Intelligence that does not account for this is not just unhelpful; it is actively hard to prioritise against. What a rail security team actually needs is intelligence that tells them whether a vulnerability is being actively exploited elsewhere. This means that they can then judge whether it is worth an out-of-cycle intervention or safe to hold for the next window.

Legacy Protocols Mean Generic Feeds Miss the Threat Entirely

Standard threat intelligence platforms are built around IT vendors, common enterprise software, and well-documented CVEs. Much of the UK's signalling system runs on GSM-R, a system built on 1990s mobile technology using encryption that has since been withdrawn from other critical uses, and it will remain part of the network for years yet. Weaknesses in GSM-R's underlying A5/1 cipher have been publicly demonstrated by academic researchers since the late 1990s and discussed in less visible corners of the internet. This is exactly the kind of niche, specialist chatter a generic IT-focused intelligence feed has no reason to be monitoring for and would likely never surface.

This is the gap dark web and specialist forum monitoring is built to close, provided it is scoped to the specific OT vendors, legacy protocols, and signalling systems a rail operator actually runs. Intelligence that only watches for brands being mentioned misses the conversation that matters most: someone discussing a weakness in the exact protocol running underneath trains.

Intelligence Has to Cover Suppliers, Not Just Your Own Organisation

UK rail's ownership structure compounds the problem. Infrastructure sits with Network Rail, operations sit with multiple train and freight operating companies, and rolling stock is leased in from separate organisations again, each with its own suppliers and contractors. Threat intelligence scoped only to an organisation's name and infrastructure misses exactly where risk tends to materialise in this sector: at a third party.

Part one's case study showed this directly. The September 2024 incident that took Wi-Fi offline at UK stations originated through an insider account at a third-party provider, not inside the rail operator's own network. Intelligence monitoring the rail operator's own footprint may not have caught it. What is actually needed is dark web and criminal forum monitoring extended to named suppliers and contractors. This means that a leaked credential or an initial access broker's listing tied to a vendor shows up before it becomes an incident, not after.

The Skills Gap Between the Signal Box and the SOC

None of the above matters if nobody can turn it into a decision, and this is where rail's expertise problem becomes most acute. Interpreting rail-specific intelligence requires understanding both cybersecurity and how a railway actually operates. A cybersecurity analyst can assess how serious a piece of intelligence looks from a technical standpoint. Without rail-specific operational context, they are less likely to know whether it applies to a system that is safety-critical or merely inconvenient, whether the affected component sits on the trackside or in a back office, or whether a described attack technique is even physically possible against the equipment in question. Signalling and OT engineers have the opposite problem: deep knowledge of the systems, but little grounding in how threat actors actually operate.

Very few professionals sit comfortably across both. That is not a gap most rail operators can hire their way out of quickly. It is also precisely why analyst-led intelligence, where someone with both the threat context and the rail-specific grounding, is worth more in this sector than a raw feed.

Why This Points Toward Analyst-Led Intelligence, Not a Bigger Feed

These three constraints, namely safety-limited response options, legacy protocols invisible to generic tooling, and a supply chain that sits outside networks, all point in the same direction. Rail does not need more threat data; it needs threat intelligence built specifically for how this sector operates. This should be interpreted by people who understand both halves of the problem and is a different proposition to a detection tool or an off-the-shelf intelligence subscription. It is why most rail operators end up building this capability with specialist support rather than in-house from scratch.

Part three of this series sets out a practical roadmap for building that capability, starting with the questions worth answering before choosing where that support comes from.