Information Technology Reference
In-Depth Information
freely available tools, in order to search for security gaps and occasionally
(or better: mostly) being successful in finding unauthorized access points
or so-called “backdoors”. Intentionally implemented backdoors by irregularly
working programmers or just due to lax quality assurance enforcement or sim-
ply by mistake are causing serious threats in all software projects. In most
cases intentionally implemented backdoors are hard to find with conventional
review methods and testing procedures. In a typical proprietary R&D envi-
ronment only limited resources are allocated in commercial projects for this
type of “security checks” and therefore stay most likely undiscovered.
That backdoors cannot be considered as a minor issue, has been discussed
in various papers [2], [3], [4], [5] and has already been identified as a serious
threat by the EU Parliament, which has initiated resolution A5-0264/2001
in the aftermath of the “Echelon” interception scandal, resulting in following
recommendations [6]:
“...Measures to encourage self-protection by citizens and
firms:
29.
Urges the Commission and Member States to devise appropriate measures
to promote . . . and . . . above all to support projects aimed at developing
user-friendly open-source encryption software;
30.
Calls on the Commission and Member States to promote software projects
whose source text is made public (open-source software), as this
is the only way of guaranteeing that no backdoors are built into
programmes;
31.
Calls on the Commission to lay down a standard for the level of secu-
rity of e-mail software packages, placing those packages whose source
code has not been made public in the least reliable category;
...”
This resolution was mainly targeting electronic communication with private
or business related content, which most likely will not hurt people or endanger
their lives. However a recent attack by the so called “STUXNET” worm [7],
a new type of highly sophisticated and extremely aggressive malware, which
in particular was targeting industrial process control systems via its tools
chain, even in safety critical applications (chemical and nuclear facilities).
Systems, which are very similar in terms of architecture and software design
standards with signaling and interlocking control systems. This incident has
demonstrated that we have to consider such impact in railway control and
command systems as well, commercially and technically.
2.2
Software Quality Issues in ETCS Projects
Despite a relatively short track record of ETCS in revenue service we had
already received reports on accidents caused by software defects, like the well
documented derailment of cargo train No. 43647 on 16 October 2007 at the
Lötschberg base line in Switzerland [8].
German Railways has been spared so far from software errors with severe
consequences, possibly due to a relatively conservative migration strategy.
