dürfen wir uns zivile sicherheitssysteme mit closed source ... · zu treffen, die er nach dem...
TRANSCRIPT
Dürfen wir uns zivile Sicherheitssysteme mit Closed Source Software überhaupt noch leisten?
Denkansätze am Beispiel der ETCS-Migration bei der Eisenbahnsignaltechnik
Deutsche Bahn AG
Klaus-Rüdiger Hase
Technik, Systemverbund und Dienstleistungen
Braunschweig, 03.12.2009
Seite 2
Übersicht
1. Komplexe Software hat immer Fehler !2. EU Parlament erkennt „Backdoor“ als Sicherheitsrisiko3. Angreifbarkeit der ETCS Onboard Unit4. „Open Proofs“ als Ausweg5. openETCS: Vorschlag auf der Basis von Open Source Software
Seite 3
Rechnerprogramme haben (fast) immer Fehler: „Bugs“
Erster nachgewiesener „Computer Bug“am 9. Sept. 1947, 15:45 Uhr(Harvard Mark II)
Seite 4
Produktionsreife Software hat meist 1 bis 10 Fehler je 1.000 Codezeilen (LOC).
Langjährig betriebserprobte Software erreicht typisch 0,5 Fehler auf 1.000 LOC
Für eine der hochwertigsten SW-Produkte sind folgende Daten bekannt:
• Weniger als 1 Fehler je 10.000 LOC
• Zu Kosten von ca. 1.000 US$ pro LOC (1977)
• US Space Shuttle mit 3 Mio. LOC kosteten 3 Mrd. US$
Typische Herstellkosten im Eisenbahnsektor: ≈ 100 €/LOC
ETCS-OBU-Softwaregröße ca. 100.000 bis 350.000 LOC
• Das bedeutet: ca. 100 … 1.000 unerkannte Fehler je EVC-Fahrzeuggerät
• Aufdeckungszeit für Fehler kann einige tausend Betriebsjahren betragen
Frage: Wie hängen Fehlerzahl und Softwarepflege zusammen ?
Mit wie vielen „Bugs“ müssen wir rechnen?
Seite 5
Fehlerhistorie einer Software ähnlicher Größe für einen Kommunikationsserver der Firma AT&T
1234
5
OSTRAND, Thomas J. ; u.a.: “Where the Bugs Are”, In: ROTHERMEL, Gregg (Hrsg.): Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis, Bd. 29, 2004, S. 86–96
“Fehlerbeharrung”:In einer Spätphase des Lebenszyklusses bleibt die Fehleranzahl fast konstantIst in sicherheitssensiblenSystemen kritsch Risiko
“bug fixing release”: Methode verliert schnellan Wirksamkeint in späteren Stadien!
“bug fixing release”: Zielgerichtete Fehler-suche bringt anfangsschnelle Verbesserung
new functions new bugs Neue Funktionen verursachenüberproportionales Fehler-wachstum
Δ LOC: 142.278 Δf: 7
Seite 6
Auswirkungen von Software-“Bugs“Von ärgerlich, störend bis katastrophal, gefährlich
Courtesy of © Microsoft.
August 14, 2003: A programming error has been identified as the cause of the Northeast power blackout.June 4, 1996:
The European Ariane5 rocket explodes 40 s into its maiden flight due to a software bug. 16. Oktober 2007: Unfall auf der Lötschberg-Basisstrecke nahe Frutigen
wegen eines Softwarefehlers in der ETCS-Streckenzentrale (RBC) *)*) aus Unfallbericht, Quelle: http://www.uus.admin.ch//pdf/07101601_SB.pdf
Seite 7
Website der ERA: “System Requirement Specification”(SRS 3.0.0) als “Prosa”-Text veröffentlicht.
Softwaredesigner des Herstellers erstellen daraus einefunktionale Softwarespezifikation.
Dabei bleibt Raum für “Interpretation” & “Human Factor”
Programmierer entwickeln daraus die eigentlicheSoftware für ein “Embedded Control System”.
Auch hier Raum für “Interpretation” & “Human Factor”
Software Specification 1
EVC
Vehicle Equipment 1
Software Specification 2
EVC
Vehicle Equipment 2
Software Specification 3
EVC
Vehicle Equipment 3
Software Specification 4
EVC
Vehicle Equipment 4
Human Factor
Human Factor
Human Factor
Human Factor
Human Factor
Human Factor
Human Factor
Human Factor
≠ ≠≠
ETCS SRS“Prosa”
ETCS-Software-Produktion heute:Suboptimaler ResourceneinsatzClosed Source Software
Seite 8
EU Parlament Entschließung A5-0264/2001
Backdoor (auch Trapdoor oder Hintertür) bezeichnet einen (oft vom Autor eingebauten) Teil einer Software, der es Benutzern ermöglicht, unter Umgehung der normalen Zugriffssicherung Zugang zum Computer oder einer sonst geschützten Funktion eines Computerprogramms zu erlangen. *)
*) Wikipedia „Backdoor“
Auszug:
Seite 9
ETCS OBU ist angreifbar: Security Gap Safety Gap)
(FIS)
MMI
EURORADIO
EURORADIOBTM LT M
Kernel
Odometry
TIU Jur. Recording
GSM-Mobile
GSM fixednetwork
RBC 1 KeyManagement
C t
EURO BALIS E EUROLOOP
STM
FISFFFIS
FFFISFFFIS
FIS FIS FFFIS
(FFFIS)
FIS
FFFIS
(FFFIS)
Natio nalSystem
DriverTrainJRU
Downloadingtool
ETCS
Onboard
FIS
FIS
FIS
Radioinfill unit
EURO-RADIO
http://www.era.europa.eu/core/ertms/Pages/Approved_Documents_List_of_mandatory_Specifications.aspx
Prinzipschaubild ausERA SRS subset 26:
Seite 10
„Backdoors“: Ist das überhaupt ein relevantes Problem?
Aus 100 Paketen, zufällig ausgewählter COTS / Open Source-Anwendungen: 79 Pakete mit totem Code (dead code)23 Pakete mit unerwünschtem Code (Backdoors, etc.) 89 Pakete mit verdächtigem Verhalten76 Pakete mit möglicherweise schädlichem Code21 Mit bekannten Würmern, Trojanern, Rootkits, etc. 69 Möglicherweise mit Würmern, Trojanern, Rootkits, etc.
Quelle: Reifer Consultants Präsentation auf DHS & DoD SwA Forum Oktober 2007 *)
*) https://buildsecurityin.us-cert.gov/daisy/bsi/events.html
13
Problems with hiding source & vulnerability secrecy
• Hiding source doesn’t halt attacks– Dynamic attacks don’t need source or binary– Static attacks can use pattern-matches against
binaries, disassembled & decompiled results– Presumes you can keep source secret
• Attackers may extract or legitimately get it– Secrecy inhibits those who wish to help, while not
preventing attackers• Vulnerability secrecy doesn’t halt attacks
– Vulnerabilities are a time bomb and are likely to be rediscovered by attackers
– Brief secrecy works (10-30 days), not years*) http://www.dwheeler.com/
Seite 14
ProblemlProblemlöösung des sung des „„Thompson HackThompson Hack““ von von David A. Wheeler in 2005 vorgestellt, mit der David A. Wheeler in 2005 vorgestellt, mit der
als als „„Double Diverse Double Diverse CompilingCompiling““ bekannten bekannten Methode, basiert auf Open Source Tools !Methode, basiert auf Open Source Tools !
Aus: https://buildsecurityin.us-cert.gov/daisy/bsi/events.html
Seite 15
High Assurance and Free/Libre Open Source Software (FLOSS)...David A. Wheeler (Institute for Defense Analysis, VA, USA) *)
„Sicherheit“ und „Open Source Software“: Wie geht das zusammen?
Sicherheitssoftware bedarf eines „Sicherheitsnachweises“, also: „Beweis der Korrektheit“!
Im Idealfalle wird der „Beweis“ mathematisch formal geführt.
„ ‚Normale‘ Mathematiker veröffentlichen ihre Beweise und sind dann auf weltweites ‚Peer-Review‘ angewiesen, um eventuelle Fehler in ihrer Beweisführung zu finden.
Aus gutem Grund, denn selbst Artikel, die vor Veröffentlichung durch ein Experten-Reviewgingen, hatten Fehler, mussten später entweder korrigiert oder sogar zurückgezogen werden.
Nur durch weltweites, öffentliches Review sind diese Probleme aufgedeckt worden!
Wenn also diejenigen, die ihr Leben der Mathematik widmen, öfters Fehler machen, ist es nur naheliegend zu vermuten, dass Software-Entwickler, die ihren Programmcode und ihre Codeverifikation vor anderen verbergen, viel eher Gefahr laufen Fehler zu machen.“ …
„Zumindest für sicherheitskritische Aufgaben wären FLOSS (zumindest veröffentlichter) Programmcode und Codeverifikationen sinnvoll. Sind mathematische Beweise wirklich wichtiger als Software, die das Leben von Menschen schützen soll?“
*) aus: http://www.dwheeler.com/essays/high-assurance-floss.html
Seite 19
ETCS-Software-Production heute:“Geringer Standardisierungsgrad”
Software Specification 2
Vehicle Equipment 2
Software Specification 1
EVC
Vehicle Equipment 1
Human Factor
Human Factor
≠EVC
Software Specification 3
EVC
Vehicle Equipment 3
Software Specification 4
EVC
Vehicle Equipment 4
Human Factor
Human Factor
Human Factor
Human Factor
Human Factor
Human Factor
≠≠
SRS 3.0.0“Prosa”
EntsprichtEntspricht das das danndann nochnoch denden
AnforderungenAnforderungen
Seite 20
Validierung von EVC-ProduktenReferenz-EVC“open proof”
(HW-in-the-Loop)Standard Train-Interface (STI)
reduziert Kostenfür Engineering
ermöglichtStandardisierungbei Homologation
StandardardisierteEVC-HW/SW-Schnittstelle mittels
AApplicationPProgrammingIInterface (API)
Umsetzung der“Prosa”- SRS
in eine“formale” SRS
reduziertInterpretationenund ermöglichtModellierung.
ModellbasierteSW-Entwicklung
und formaleValidierung
“open proof”durch Simulation realer Strecken-,
Betriebs- und Störszenarien mitgeringen Kosten.(SW-in-the-Loop)
APIHW
Simu-lator
EVCFahrzeuggerät
Testfälle & Strecken
Formale SW Spezifikation
SRS 3.0.0“Prosa”
openETCSopenETCS
Software herstellen
Formale SystemSpezifikation
STISTI
Seite 21
Open Source Software Architecture
Open Source Software Engineering Tools
Gesamtprojekt openETCS
Seite 22
In der Automobilindustrie ist die Standardisierungfür Steuerelektronik und Software bereits Realität
Referenz: www.autosar.org
Seite 23
AUTOSAR: An open standardized software architecture for the automotive industry
Referenz: www.autosar.org
Seite 26
Toolkit in Open-Source for Critical Application & System Development
Reference: www.topcased.org
Seite 27
EU-Kommission unterstützt FLOSS-Projekte in vielerlei Hinsicht
EU-Kommission unterstützt mit:Studien, die die Vorteile von FLOSS aufzeigen:
• “Study of the economic impact of Free/Libre or Open Source Software (FLOSS) on the European ICT sector” (UNU-MERIT; 2007).
• Studie belegt ca. 36% Einsparung bei R&D-KostenEUPL: European Union Public License
• Kompatibel zu populären OSS-Lizenzen:GNU General Public License (GNU GPL)v.2 (FSF,USA)Open Software License (OSL) v. 2.1, v. 3.0 (USA)Common Public License v. 1.0 (IBM, USA)Eclipse Public License v. 1.0 (EF, Canada)Cecill v. 2.0 (CEA, CNRS and INRIA; France )
• Mit EU-Recht vereinbar:22 offizielle SprachversionenKonsistent mit Urheberrecht in den EU-Mitgliedsländern
Beschaffungsleitfaden für FLOSS-Produkte
Seite 28
Jetzt gibt es eine Idee! Wie geht es weiter?
• Die Deutsche Bahn AG hat das Konzept openETCS der CER, bei der UIC, beiinternationalen Herstellern und den übrigen Stakeholdern vorgestellt.
• Es wurde zusammen mit interessierten EVUs (SNCF, NS, ATOC, DB) ein“Memorandum of Understanding” (MuO) ausgearbeitet.
• Der MoU beschreibt den Rahmen und die Ziele eines openETCS-Vorprojektes
• Kerngruppe und Erstunterzeichner sind: SNCF, NS und DB (offen für EVUs)
• Die Gruppe wird innerhalb der nächsten 6 Monate das Projekt definieren:
Ökonomische Rahmenbedingungen
Technische Ziele
Rechtliche Randbedingungen
- Legalstruktur für eine Organisation (z.B. EEIG),
- Verantwortlichkeiten,
- IPR, Fördermöglichkeiten, etc.
Seite 29
Rechtliche Rahmenbedingungen
EBO, §2 Abs. 1 „Bahnanlagen und Fahrzeuge müssen so beschaffen sein, dass sie den Anforderungen der Sicherheit und Ordnung genügen. Diese Anforderungen gelten als erfüllt, wenn die Bahnanlagen den Vorschriften der EBO und … den anerkannten Regeln der Technik entsprechen.“
„Rheinweiler-Urteil“(BGH Urteil vom 10.10.1978 – VI ZR 98 und 99/77)„Der Bahnunternehmer hat diejenigen Sicherheitsvorkehrungen zu treffen, die er nach dem jeweiligen Stand der Technik als verständiger, umsichtiger und gewissenhafter Fachmann für ausreichend halten darf, um andere Personen vor Schäden zu bewahren, und die den Umständen nach zumutbar sind.“
Seite 30
Resultierende Fragestellung Schlussfolgerung
Derzeitige ETCS-Anlagen sind gemäß den CENELEC-Normen (EN50128, etc.) entwickelt und ausschließlich „Closed Source“ lizenziert. Das entspricht den “anerkannten Regeln der Technik”.Frage: Wenn aber entsprechend dem ‚Stand der Technik‘:
1. eine Vielzahl internationaler wissenschaftlicher Analysen zu demSchluss kommt, dass Open Source Software bezüglich Sicherheit und Zuverlässigkeit tendenziell überlegen und
2. außerdem im Mittel sogar kostengünstiger ist und zudem3. das EU-Parlament Open Source Software für besonders förderwürdig
hält, weil es Closed Source Software in die Kategorie “am wenigsten zuverlässig” einstuft, kann dies dann der verständige, umsichtige und gewissenhafte Fachmann des Eisenbahnwesens einfach ignorieren und auf Open Source Software verzichten?
Folgerung: Die DB AG erwartet von der Industrie OSS-Angebotefür die nächste Beschaffung von ETCS-Fahrzeugausrüstungen!
Seite 33
Significant LCC savings by launching openETCS combined with a Frame procurement contract rather than per class procurements
Scenario comparison 2009 – 2025 for 3814 Units (25% EU market share) - Net present values based on CBA migration estimates and assumptions -
0
100
200
300
400
500
600
700
800
900
Proprietary ETCS SW(class base procurements)
Proprietary ETCS SW(frame contract)
openETCS(worst case)
openETCS(best case)
SW & HW Maintenance CostsUnit-Based Hardware Costs
One-Time Engineering CostsSoftware Development Costs
888 m€
646 m€
392 m€ 369 m€
169 T€per Unit
103 T€per Unit
233 T€per Unit
97 T€per Unit
Methodology: Net present value for equipment with proprietary ETCS SW vs. openETCS, for 3.814 units (2.873 vehicles) assuming a 25% market share of total 11.492 vehicles to be equipped in 60% of EU’s railway undertakings, differential costs are evaluated only, no full costs been considered (without STMs, e.g. for PZB/LZB).
- 27%
- 28%
Seite 38
Understanding FLOSS principles
EUPL is a Free/Libre/Open Source Software (FLOSS) license. EUPL meets the terms of the Open Source Definition (OSI) and the conditions expressed by the Free Software Foundation (FSF), which can together be summarized as ensuring four main freedoms to the licensee:
Freedom to use or run it for any purpose and any number of usersFreedom to obtain the Source Code (in order to study how the software works)Freedom to share, to redistribute copies of the softwareFreedom to modify, adapt, improve the software according to specific needs and to share these modifications.
http://ec.europa.eu/idabc/7330