Security architecture for a railway interlocking landscape
Six months of testing on an interlocking landscape, without intervening in live traffic. The result was a risk assessment with a zone and conduit model rather than a list of scanner findings.
An infrastructure manager wanted to know how its interlocking landscape stood on security, without touching traffic. The testing ran over six months alongside normal operation.
Brief, scope and constraints
Six months alongside the timetable, and not one intervention in live traffic.
Environment
An interlocking landscape grown over time, with installations of different ages, connected to the operations control centre, diagnostics and maintenance.
Duration and approach
Around six months of testing, mostly passive. Active work only in released network areas and in windows that followed the timetable.
Form of the result
A risk assessment with a zone and conduit model to IEC 62443-3-2, not a list of scanner findings.
The network plan no longer worked as evidence
The installations had grown over decades, and the documentation with them. With the IP migration and the connection of diagnostic and maintenance systems it had become unclear which communication relationships actually existed and where the boundaries between areas really ran.
At the same time, evidence was due. But a zone concept on paper does not answer the question of whether the firewall rule sets implement it.
Six months in four phases
The long period came not from the effort but from the windows available.
Architecture and documentation
Network plans, plant documentation and zone models as the starting point, with the aim of understanding the intended state before the actual one is surveyed.
Passive communication analysis
Captures at agreed transition points showed which paths actually existed. This is where documentation and reality parted company.
Active testing in the window
Only in released areas, with abort criteria fixed beforehand and in agreement with those responsible for operations.
Zone and conduit model
From the surveyed paths came a model reflecting the real communication, with an assessment of the transitions and prioritised measures.
What the operator had at the end
A picture of the actual communication relationships, a zone and conduit model derived from it, and a list of measures prioritised by likelihood and impact. For producing evidence, what mattered was that the statements rest on captures and not on documentation.
That no intervention in traffic was needed over six months is not a side note. It was the condition under which testing was permitted at all.
What was not tested, and why
In a rail environment the scope decides whether testing can happen at all.
No intervention in approved states
Approved configurations were not changed. Where a finding could only have been obtained by intervening, it was left open or reproduced on a lab rig.
Released areas only
Active work was confined to network areas agreed beforehand. Segments not released were neither reached nor assessed.
Timetable before project plan
Test windows followed operations. That extended the duration, and it was the reason traffic stayed untouched.
What you can take from this
First: testing in a rail environment happens in possessions and maintenance windows. Whoever plans for that early gets more out of it than someone who waits for a possession.
Second: the greatest gain comes from the passive analysis. In installations that have grown over time, the real communication regularly differs from the documented one, and that is visible without a single active test.
Third: a zone and conduit model is worth more than a list of findings, because it serves evidence and planning alike.
Related to this case study.
A similar project?
Referenzdetails nennen wir nach Freigabe und im persönlichen Gespräch.