Dürfen wir uns zivile Sicherheitssysteme mit Closed Source ... · zu treffen, die er nach dem jeweiligen Stand der Technik als verständiger, umsichtiger und gewissenhafter Fachmann

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


EVC

Vehicle Equipment 2


EVC

Vehicle Equipment 3


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

Seite 11Aus: https://buildsecurityin.us-cert.gov/daisy/bsi/events.html

Seite 12Aus: 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

16

*) http://www.dwheeler.com/

Seite 19

ETCS-Software-Production heute:“Geringer Standardisierungsgrad”


Vehicle Equipment 2


EVC

Vehicle Equipment 1

Human Factor

Human Factor

≠EVC


EVC

Vehicle Equipment 3


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 24

Open Software Engineering Tools

Scope of the openETCS Project

Seite 25

FLOSS-Werzeugumgebung bei TOPCASED

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 31

Vielen Dank für Ihre Aufmerksamkeit

Seite 32

Back-up

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 34

http://www.dwheeler.com

Seite 35Reference: www.topcased.org

Seite 36Reference: www topcased org

Seite 37Seite 37

Reference: www.topcased.org

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