Der Einsatz von Open Source Tools für Safety und Security

Transkript

1 Der Einsatz von Open Source Tools für Safety und Security Thomas Schütz Protos Software GmbH Safety & Security Day Rhein-Main Flörsheim,

2 Story Kann man mit Open Source Tools und Software Anforderungen an Safety und Security erfüllen?

3 Steigende Safety & Security Anforderungen Safety und Security werden immer abhängiger voneinander Durch zunehmende Umsetzung von Funktionen in Software werden werden für viele Projekte die Themen Safety oder Security relevant Verschärfung der gesetzlichen Vorschriften Stark steigende Komplexität beschleunigt die Problematik

4 Warum Open Source für Safety und Security? offene Standards und Software -> kein Vendor lock in größere Transparenz nachhaltig und interoperabel durch offene Schnittstellen und Implementierungen unabhängige Verifizierbarkeit Zusammenarbeit vieler Organisationen (z.b. openetcs) Verhinderung von Back Doors (z.b. Borland Interbase)

5 Beispiele für Open Source Projekte im Bereich Security Open SSH und Pretty Good Privacy (PGP) Sehr weit verbreitete Verfahren zur Verschlüsselung, welche auch in vielen kommerziellen Produkten eingesetzt werden. Wireshark Network Protocol Analyzer VeraCrypt (ehem. TrueCrypt) Verschlüsselung von Datenspeichern Snort Network Intrusion Detection & Prevention System

6 Beispiele für Open Source Konsortien und Projekte im Bereich Safety Eclipse IWG Polarsys Industriekonsortium für Entwicklung und Long Time Support von Open Source Software Tools für Embedded Systeme Mitglieder: Viele Firmen aus den Bereichen Avionik, Automotive, und Telekommunikation (z.b. Airbus, Ericsson, Thales), sowie viele Open Source Tool Provider Tools: Papyrus (UML), CDT (C/C++ IDE), Capella (Modeling), EGIT/EGERRIT (VC und Code Review), Titan (TTCN3 Test Tool), und viele mehr openetcs Open Source Plattform für das Europäische Zugsicherungssystem APIs, Frameworks, Werkzeugumgebung zur Spezifikation, Modellierung, Entwicklung und Verifikation und Validierung (Test) der Software AUTOSAR Tool Platform (Artop) Sicherstellung der Interoperabilität von AUTOSAR Tools durch eine gemeinsame Plattform Eclipse bildet die Open Source Plattform für Artop CompCert: Vollständig formal verifizierter C-Compiler

7 Was ist zu tun für Safety? Prozesse die durch Tools unterstützt oder übernommen werden: Requirementmanagement Changemanagement Versionsverwaltung Verifikation & Validierung Systementwurf (Modellierung) Implementierung (Codegenerierung, Codierung und Compilierung) Dokumentation Traceability Tools müssen Qualitätsanforderungen erfüllen Tool Confidence Level

8 Hauptproblem: TCL ISO Tool Confidence Level (TCL) Tool Error Detection: Wie hoch ist das Vertrauen daß Fehler im Werkzeug durch geeignete Massnahmen entdeckt werden können? TD 1 (hoch) TD 2 (mittel) TD 3 (klein) Tool Impact: Kann eine Fehlfunktion des Tools Safety Anforderungen verletzen? TI 1 (nein) TI 2 (ja) TCL 1 (hoch) TCL 1 (hoch) TCL 2 (hoch) TCL 3 (hoch) Tool Confidence Level: Wie hoch ist das Vertrauen daß ein Fehler im Werkzeug keine Verletzung der Safety Requirements verursachen kann?

9 Beispiel Toolchain Anforderungen Ursprüngliche Anforderungen: Schnelle Entwicklung von Produktlinien im Bereich Transportation Hohe Anforderungen an Zuverlässigkeit Sehr hohe Varianz (Produktlinie) Ursprünglich geringe formale Anforderungen an Safety oder Security Umsetzung: Komplette Open Source Toolchain Sehr hoher Grad an Code Generierung aus Modellen Sehr hoher Automatisierungsgrad (Continuous Integration) Gute Testabdeckung (Unit-, Integrations-, SIL-, HIL-Tests) Neue Anforderungen: Neue Projekte werden voraussichtlich als SIL 0,1 oder 2 eingestuft (nach EN 50128) oder ASIL A oder B (nach ISO 26262) Gute Toolchain soll weiter verwendet werden

10 Beispiel Open Source Toolchain Requirementmanagement: Redmine Changemanagement: Redmine Versionsverwaltung: GIT Verifikation & Validierung: etunit (Testreporting für Modell- und Integrationstests) etrice (Simulation für SIL und HIL) Google Test (Unit Tests) Cppcheck (statische Codeanalyse) Valgrind (dynamische Codeanalyse) Jenkins (Continuous Integration) GNU Coverage Systementwurf (Modellierung): etrice Implementierung: Codegenerierung (C/C++): etrice Codierung: Eclipse CDT Compilierung: MinGW, GNU Compiler Betriebssystem: Linux Dokumentation: generierte Modelldokumentation (etrice) Traceability: fehlt

11 Toolchain Demo

12 Open Source Toolchain Beispiel (SIL 0-2) Requirementmanagement: Redmine -> derzeit noch keine Alternative analysiert Changemanagement: Redmine Versionsverwaltung: GIT Verifikation & Validierung: etunit (Testreporting für Modell- und Integrationstests) etrice (Simulation für SIL und HIL) Google Test (Unit Tests) Cppcheck (statische Codeanalyse) Valgrind (dynamische Codeanalyse) Jenkins (Continuous Integration) GNU Coverage -> kein MC/DC Kombinatorische Testcasegenerierung fehlt Systementwurf (Modellierung): etrice -> nicht kritisch (Tests auf Code Ebene) Implementierung: Codegenerierung (C/C++): etrice Codierung: Eclipse CDT Compilierung: MinGW, GNU Compiler -> CompCert oder Qualifizierung Betriebssystem: Linux -> Free RTOS? Dokumentation: generierte Modelldokumentation (etrice) Traceability: fehlt -> kommerzielle Lösungen verfügbar

13 Der nächste Schritt: Contract based Design E=mc 2 Formal Verification Generate Testcases Generate Robust Interfaces or Monitoring Generate Documentation

14 Fazit Mit Open Source Werkzeugen können in vielen Bereichen die Anforderungen niedriger SIL Levels gut abgedeckt werden und haben sich dort auch bereits durchgesetzt (z.b. Continuous Integration) In manchen Bereichen gibt es derzeit noch keine Open Source Lösungen für Safety, insbesondere bei validierten Tools Viele Firmen und Konsortien arbeiten am Aufbau von Open Source Werkzeugen und Plattformen für Safety und Security

15 ... any questions? Thomas Schütz