Deutsche Bahn AG Klaus-Rüdiger Hase Technik, Systemverbund und Dienstleistungen Braunschweig,

Transkript

1 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,

2 Übersicht 1. Komplexe Software hat immer Fehler! 2. EU Parlament erkennt Backdoor als Sicherheitsrisiko 3. Angreifbarkeit der ETCS Onboard Unit 4. Open Proofs als Ausweg 5. openetcs: Vorschlag auf der Basis von Open Source Software Seite 2

3 Rechnerprogramme haben (fast) immer Fehler: Bugs Erster nachgewiesener Computer Bug am 9. Sept. 1947, 15:45 Uhr (Harvard Mark II) Seite 3

4 Mit wie vielen Bugs müssen wir rechnen? Produktionsreife Software hat meist 1 bis 10 Fehler je Codezeilen (LOC). Langjährig betriebserprobte Software erreicht typisch 0,5 Fehler auf LOC Für eine der hochwertigsten SW-Produkte sind folgende Daten bekannt: Weniger als 1 Fehler je LOC Zu Kosten von ca 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 bis LOC Das bedeutet: ca unerkannte Fehler je EVC-Fahrzeuggerät Aufdeckungszeit für Fehler kann einige tausend Betriebsjahren betragen Frage: Wie hängen Fehlerzahl und Softwarepflege zusammen? Seite 4

5 Fehlerhistorie einer Software ähnlicher Größe für einen Kommunikationsserver der Firma AT&T Δ LOC: Δf: 7 bug fixing release : Methode Zielgerichtete verliert Fehlersuche Wirksamkeint bringt anfangs in schnell an späteren schnelle Verbesserung Stadien! new functions new bugs Neue Funktionen verursachen überproportionales Fehlerwachstum Fehlerbeharrung : In einer Spätphase des Lebenszyklusses bleibt die Fehleranzahl fast konstant Ist in sicherheitssensiblen Systemen kritsch Risiko 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 Seite 5

6 Auswirkungen von Software- Bugs Von ärgerlich, störend, gefährlich bis katastrophal August 14, 2003: A programming error has been identified as the cause of the Northeast power June 4, 1996: blackout. The European Courtesy Ariane5 of Microsoft. rocket explodes 40 s into its maiden flight due to a 16. Oktober software 2007: Unfall bug. auf der Lötschberg-Basisstrecke nahe Frutigen wegen eines Softwarefehlers in der ETCS-Streckenzentrale (RBC) *) *) aus Unfallbericht, Quelle: Seite 6

7 ETCS-Software-Produktion heute: Suboptimaler Resourceneinsatz Closed Source Software ETCS SRS Prosa Human Factor Software Specification 1 Human Factor Website der ERA: System Requirement Specification (SRS 3.0.0) Human als Prosa -Text veröffentlicht. Human Factor Softwaredesigner des Herstellers erstellen daraus eine funktionale Softwarespezifikation. Dabei bleibt Raum für Interpretation & Human Factor Software Software Software Specification Programmierer 2 entwickeln Specification daraus 3 die eigentliche Specification 4 Software für ein Embedded Control System. Human Factor Factor Human Factor Human Factor Auch hier Raum für Interpretation & Human Factor Human Factor EVC EVC EVC EVC Vehicle Equipment 1 Vehicle Equipment 2 Vehicle Equipment 3 Vehicle Equipment 4 Seite 7

8 Auszug: 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 Seite 8

9 ETCS OBU ist angreifbar: Security Gap Safety Gap) Train Driver JRU Downloading tool FIS FIS FFFIS TIU MMI ETCS Onboard Jur. Recording Prinzipschaubild aus ERA SRS subset 26: STM FFFIS Kernel Odometry BTM LT M EURORADIO FIS FFFIS FFFIS FFFIS GSM- Mobile GSM fixed network FIS FIS National System EUROBALISE EUROLOOP EURO- RADIO Radio infill unit EURORADIO (FFFIS) (FFFIS) (FIS) FIS RBC 1 FIS Key Management C t Seite 9

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 Verhalten 76 Pakete mit möglicherweise schädlichem Code 21 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 *) *) Seite 10

11 Aus: Seite 11

12 Aus: Seite 12

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 13 *)

14 Problemlösung des Thompson Hack von David A. Wheeler in 2005 vorgestellt, mit der als Double Diverse Compiling bekannten Methode, basiert auf Open Source Tools! Aus: Seite 14

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-Review gingen, 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: Seite 15

16 16 *)

17

18

19 ETCS-Software-Production heute: Geringer Standardisierungsgrad SRS Prosa Entspricht das dann noch den Human Human Human Anforderungen Factor Factor Factor Human Factor Software Specification 1 Software Specification 2 Software Specification 3 Software Specification 4 Human Factor Human Factor Human Factor Human Factor EVC EVC EVC EVC Vehicle Equipment 1 Vehicle Equipment 2 Vehicle Equipment 3 Vehicle Equipment 4 Seite 19

20 Testfälle & Strecken SRS Prosa Formale System Spezifikation Formale SW Spezifikation Validierung von Umsetzung Modellbasierte der EVC-Produkten SW-Entwicklung Prosa - SRS Referenz-EVC Standardardisierte und in formale eine EVC-HW/SW- open proof formale Validierung SRS Schnittstelle (HW-in-the-Loop) open reduziert proof mittels Application Standard Traindurch Interpretationen Simulation Programming Interface (STI) realer und ermöglicht Strecken-, reduziert Kosten Interface Modellierung. Betriebs- (API) und für Engineering Störszenarien mit ermöglicht Software Standardisierung herstellen geringen Kosten. (SW-in-the-Loop) bei Homologation openetcs Simulator STI EVC API HW Fahrzeuggerät Seite 20

21 Gesamtprojekt openetcs Open Source Software Engineering Tools Open Source Software Architecture Seite 21

22 In der Automobilindustrie ist die Standardisierung für Steuerelektronik und Software bereits Realität Referenz: Seite 22

23 AUTOSAR: An open standardized software architecture for the automotive industry Referenz: Seite 23

24 Scope of the openetcs Project Open Software Engineering Tools Seite 24

25 FLOSS-Werzeugumgebung bei TOPCASED Seite 25

26 Toolkit in Open-Source for Critical Application & System Development Reference: Seite 26

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-Kosten EUPL: 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 Sprachversionen Konsistent mit Urheberrecht in den EU-Mitgliedsländern Beschaffungsleitfaden für FLOSS-Produkte Seite 27

28 Jetzt gibt es eine Idee! Wie geht es weiter? Die Deutsche Bahn AG hat das Konzept openetcs der CER, bei der UIC, bei internationalen 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 28

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 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 29

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 dem Schluss kommt, dass Open Source Software bezüglich Sicherheit und Zuverlässigkeit tendenziell überlegen und 2. außerdem im Mittel sogar kostengünstiger ist und zudem 3. 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-Angebote für die nächste Beschaffung von ETCS-Fahrzeugausrüstungen! Seite 30

31 Vielen Dank für Ihre Aufmerksamkeit Seite 31

32 Back-up Seite 32

33 Significant LCC savings by launching openetcs combined with a Frame procurement contract rather than per class procurements Scenario comparison for 3814 Units (25% EU market share) - Net present values based on CBA migration estimates and assumptions m 233 T per Unit - 27% 646 m 169 T per Unit -28% SW & HW Maintenance Costs Unit-Based Hardware Costs Software Development Costs One-Time Engineering Costs m 103 T per Unit 369 m 97 T per Unit Proprietary ETCS SW (class base procurements) Proprietary ETCS SW (frame contract) openetcs (worst case) openetcs (best case) Methodology: Net present value for equipment with proprietary ETCS SW vs. openetcs, for units (2.873 vehicles) assuming a 25% market share of total 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). Seite 33

34 Seite 34

35 Reference: Seite 35

36 Seite 36 Reference: www topcased org

37 Seite 37 Reference: Seite 37

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 users Freedom to obtain the Source Code (in order to study how the software works) Freedom to share, to redistribute copies of the software Freedom to modify, adapt, improve the software according to specific needs and to share these modifications. Seite 38