Ringvorlesung: Forum Software und Automatisierung

Transkript

1 INFORMATIK CONSULTING SYSTEMS AG Ringvorlesung: Forum Software und Automatisierung Softwareprüfung für sichere (Safety + Security) Systeme Name Dr. Thomas Liedtke thomas.liedtke@ics-ag.de Funktion R&D Datum 15. Januar 2015 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 2 1

2 Vorstellung wer bin ich? Dr. Thomas Liedtke Seit 01. Dezember 2007 bei der ICS AG tätig als Leiter Research & Development Senior Projektleiter sicherheitsgerichteter Projekte Leiter Competence Center Implementierung Software Reifegradmodelle Davor: Studium der Informatik mit Nebenfach Mathematik an der Universität Stuttgart Promotion Informatik/ Mathematik an der Universität Stuttgart 14 Jahre bei Alcatel/ Alcatel Lucent Bereich Vermittlungssysteme: Qualitätsabteilung/ SPI/ SEPG (CMM)/ Projektleiter für MOD-Projekte der DTAG Bereich Mobilfunk: Abteilungsleiter in der Entwicklung Oberprojektleiter für Mobilfunkprojekte (GPRS/ UMTS/ GSM/ ) Bereich Übertragungssysteme: Leiter Supply Chain OND Leiter des RSLC (Repair Service Logistic Center) Weilimdorf 3 Das Unternehmen Rechtsform Aktiengesellschaft Grundkapital 2,4 Mio. EUR Vorstand Franz-Josef Winkel, Cid Kiefer Aktionäre Die Familien: Hämer, Winkel und Kiefer Hauptstandort Stuttgart Geschäftsstellen Berlin, Braunschweig, Ingolstadt, Immenstaad, Leipzig, München, Rüsselsheim, Ulm Anzahl der Mitarbeiter 150+ Umsatz EUR Handelsregister Amtsgericht Stuttgart HRB Nr.: UST. Id.Nr: DE ,0 10,0 8,0 6,0 4,0 2,0 0, Umsatz in Mio. Euro Anzahl der Mitarbeiter

3 Kunden nach Domänen Automotive Industrial Solutions Transportation Aero Space & Defence 5 Philosophie Partner für den gesamten Produkt Life Cycle Vordenken Beraten Umsetzen Betreuen Machbarkeitsstudien, Evaluierungen Technologien Methoden Werkzeuge Standards Prozesse Systems und Safety Engineering Produkt Design und Entwicklung Kapazitäts- und Kompetenzergänzung Test und Validierung RAM und Safety Management Assessment Maintenance von Software und Systemen V 6 3

4 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 7 Motivation gestern: Spektakulärer Eisenbahnunfall am Gare Montparnasse (Dienstag, ) -> Systemgedanke! 8 Bildquelle: Wikipedia 4

5 Motivation - heute -> Virtualität/ Modellierung Der Wert von Sicherheit wird oft erst dann erkannt, wenn sie nicht mehr gewährleistet ist 9 Komplexität der Anforderungen an technische Systeme steigt Industrie 4.0*)-Anwendungen (u.a. [SESAMO14, Svo10, Bau14]): Dezentralisierung von Steuerungen: z.b.: Energiegewinnung/ -verteilung, wachsender Einsatz "SMARTer"/ unterschiedlichster Endgeräte, MES, Car2x, einfachste Funktionen werden über mehrere Steuergeräte verteilt, Steuergeräte kommunizieren über immer mehr Kommunikationskanäle/ Busse miteinander,... Neuartige unterschiedlichste Endgeräte und Bedienungskonzepte: z.b.: Flexible Tablet-/ Touch-Steuerung einer begehbaren Maschine, Bessere Integration des Menschen (analog Automotive), WLAN an Maschinen, Aktoren und Sensoren werden immer leistungsfähiger und intelligenter Erhöhte Anzahl von Sicherheitslücken: Jede neue Technologie, die Sicherheitslücken schließt, bringt neue mit sich. *) Industrie 4.0 hier: Vernetzung von CPS, Anlagen, Fabriken, Steuergeräten zur intelligenten Fabrik im Internet der Dinge. Massenindividualisierte Produkte: Konsument gestaltet das Produkt, Produktionsanlagen richten sich danach (autonom) 10 5

6 Komplexität der Entwicklungsprozesse steigt Anlagenlebenszeiten (Investitionsgüter) werden länger; umgekehrt zu Lebenszyklen von Software und Betriebssystemen Embedded-Systeme sind die Dinge : Mehrere Standards für jede Anforderung macht Entwicklungsprozesse komplex Mögliche Marktsegmentierung macht Economy-of-Scale unsicher (Konsumgütermarkt, Industrieanwendungen, Cloud-Computing, Telecom- Infrastrukturen, ) Standardisierung/ Player vs. Kosten Trust : richtige Technologien zeitnah und vertrauenswürdig liefern Infrastruktur für die smarte Fabrik Statische Produktionsabläufe entwickeln sich zu dynamischen Prozessketten Vernetzung horizontal und vertikal: Flexibilität, Autonomie, Teleservices (z.b. Visual Online Support), 11 Motivation/ Begriffe Verschiedene Begriffe sind in verschiedenen Domänen unterschiedlich belegt Verifikation: oft: überprüfen, ob Dinge richtig gemacht wurden (vertikal/ unten im V-Modell), meist direkte Verknüpfung mit der Testdurchführung Validierung: oft: überprüfen, ob die richtigen Dinge gemacht wurden (horizontal/ oben im V- Modell), nachweisen u.u. ohne direkte Testdurchführung Integration/ Testen/ Prüfen Wozu Prüfung? Softwaresysteme spielen in einem zunehmend großen Teil des Lebens eine wichtige Rolle: Steuerung von Transportmitteln, Steuerung von Kraftwerken, Assistenzsysteme in Autos, Smart Grid, IoT, Industrie 4.0 Relativ neu: Security! Gefahr für Leib und Leben, Umwelt, Personenschäden, Sachschäden, finanzielle Schäden, Imageschäden und Katastrophen sind möglich 12 6

7 Berühmte Softwarepannen -> Notwendigkeit Fast der 3. Weltkrieg Ozonloch Ziviles Flugzeug als Kampfjet interpretiert 13 [DZGSP08] Prüfen und Testen sind Vorschrift Beispiele: DIN EN :2001 Anhang A - Leitfaden für die Auswahl der Verfahren und Maßnahmen EN 50128:2011 Anhang A5 Verifikation und Testen 14 [IEC-61508] [EN-50128] 7

8 Systematischer Ausfall nach IEC Im Folgenden geht es beim Testen/ Prüfen um systematische Ausfälle: Systematischer Ausfall (sind zu vermeiden): Systematisches Versagen/ Ausfall, bei dem eindeutig auf eine Ursache geschlossen werden kann, die nur durch eine Modifikation des Entwurfs oder des Fertigungsprozesses, der Art und Weise des Betreibens, der Bedienungsanleitung oder anderer Einflussfaktoren beseitigt werden kann. Zufälliger Hardwareausfall (unvorhergesehenes Verhalten ist sicher zu machen): Ausfall, der zu einem zufälligen Zeitpunkt auftritt und der aus einem oder mehreren möglichen Mechanismen in der Hardware resultiert, die zu einer Verschlechterung der Eigenschaften der Bauteile führen. Klassifizierung der Fehler anhand folgender Fragen: War der Fehler zum Zeitpunkt der Inbetriebnahme bereits eingebaut? Ist der Ausfall prinzipiell reproduzierbar? Wichtiges Unterscheidungsmerkmal: Systemausfallraten, die aus zufälligen Hardwareausfällen herrühren, können mit vernünftiger Genauigkeit statistisch quantifiziert werden, jene die durch systematische Ausfälle entstehen nicht, weil die Ereignisse, die zu diesen führen, nicht leicht vorausgesagt werden können. 15 Anforderungen an die Softwareprüfung Fehlervermeidung: Fehler wie die auf den vorigen Folien beschriebenen sollten so weit wie möglich ausgeschlossen werden oder gefunden werden, bevor sie sich auswirken Fehlervorhersagen Aussagen der Form in welchem Teil der Software sind anteilsmäßig wie viele Fehler zu erwarten? sollen gemacht werden können Risiko = Wahrscheinlichkeit seines Eintretens x Schaden im Falle seines Eintretens Risiko soll minimiert werden Risikoreduktion durch Verringerung der Wahrscheinlichkeit mit der ein Fehler auftritt und durch die Begrenzung der Konsequenzen von unvermeidbaren Fehlern 16 8

9 Was sind Softwarefehler? Genaue Unterscheidung, was mit Fehler gemeint ist Fehlhandlung (error): Mensch verursacht einen Fehler in der Software Fehlerzustand (defect oder fault): im Code einer Software, in einem System oder in einem Dokument (z.b. inkorrektes Teilprogramm, inkorrekte Anweisung oder inkorrekte Datendefinition), verursacht durch eine Fehlhandlung, kann zu einer Fehlerwirkung führen Fehlerwirkung/ Fehlverhalten (failure): Wenn der Defekt im Code ausgeführt wird, kann das System nicht das tun, was es tun sollte (oder etwas tun, was es nicht tun sollte) und dabei eine Fehlerwirkung hervorrufen oder ausfallen. Im Englischen weitere Begriffe: mistake, bug, malfunction, issue, incident, flaw, vulnerability, error-prone, Beispiel: Telefon funktioniert nicht <- kein Freizeichen <- Codefehler 17 Bringt Testen Vertrauensgewinn? Ausführung des Programms 18 Verhalten (Semantik) [Lie14] 9

10 Grundsätze der Softwareprüfung Softwareprüfung kann nur gegen Vorgaben (Anforderungen/ Vergleichsresultate) erfolgen Prüfverfahren müssen definiert sein und reproduzierbare Ergebnisse liefern Prüfergebnisse müssen dokumentiert werden (Nachvollziehbarkeit) Erkannte Fehler müssen (üblicherweise) anschließend korrigiert werden, indem die Fehlerursachen erkannt und behoben werden Systematisch prüfen Prüfung planen Prüfungen nach Vorschriften durchführen (am besten automatisiert ausführen) Nicht nur die Software selbst prüfen, sondern auch alle Dokumente im Umfeld (zum Beispiel Anforderungen! Siehe Reviews) Testen ist: der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen [Den91] 19 Testen: Ziele und Probleme -1 Fehlerzustände und wirkungen nachweisen Durch Fehlerhandlungen Fehlerzustände provozieren Vertrauen in das Programm erhöhen Je weniger gefundene Fehler, desto höheres Vertrauen in die Software (manche nennen das Qualität ) Fehlerwirkungen vorbeugen Aber: Je früher Fehler entdeckt werden, desto billiger die Fehlerkorrektur desto weniger Folgefehler -> vgl. Methoden, die durch Konstruktion in frühen Phasen Fehler so unwahrscheinlich wie möglich machen (Abstrakte Spezifikation, Modellierung, Generierung der Testspezifikation...) Vollständiges Testen ist nicht möglich Vorsicht vor der Fehlermaskierung keine Fehler heißt noch nicht brauchbares System Korrelation zum Lebenszyklusmodell. Z.B.: Wie verträgt sich der Anspruch mit dem agilen Manifest? 20 10

11 Testen: Ziele und Probleme -2 Wann ist man fertig mit Testen? Aufwand verbraucht? Es werden wenige/ keine Fehler mehr gefunden? Termin für Auslieferung steht an? Tester fallen keine neuen Testfälle mehr ein? Nie? Umfang/ Abdeckungskriterium Anforderungsabdeckung Äquivalenzklassenabdeckung Komponentenabdeckung Strukturabdeckung (Instruktionsüberdeckung ; C0, C1, ) Integrationsschritteüberdeckung Traceabiltiy (Rück-)verfolgbarkeit von Anwendungsforderung -> Implementierung (Sourcecode-Funktion) -> Testfall und zurück Keine Anwendung darf vergessen werden (zu implementieren, zu testen, ) Kein Sourcecode ohne Funktion 21 Bewährte Vorgehensweise beim Test Rollen beachten (z.b. Testmanager, Testanalyst, Testspezialist, Test- Automatisierer, Testsupport) Personaltrennung (besonders zwischen Entwickler und Tester!) Anforderungen/ Testspezifikation: Möglichst formal Mit dem Testen so früh wie möglich beginnen Nutzung des Pareto-Prinzips (Fehler sind nicht gleichverteilt, sondern häufen sich) Nutzung von Regressiontests und Ergänzung durch neue Tests der Testresistenz entgegenwirken Testsautomatisierung um Häufigkeit von Regressionstests erhöhen zu können Anpassung der Tests an das System und die grundlegenden Anforderungen Tests sind nicht die einzige Maßnahme im Qualitätsmanagement der Softwareentwicklung, aber oft die letztmögliche. Je später Fehler entdeckt werden, desto aufwändiger ist ihre Behebung [Spi04] 22 11

12 Sichten auf Programmanalyse Überblick Analysemethoden 4 Schichten Modell Dynamische Programmanalyse Experimente Induktion Beobachtung Deduktion Statische Programmanalyse 23 [Zel03] 23 Methoden statisch vs. dynamisch Review Feststellung von Mängeln, Fehlern, Inkonsistenzen, Unvollständigkeiten, Verstößen gegen Vorgaben, Richtlinien, Standards, Pläne Code-Inspektion Formalisiertes Review zur Qualitätseinschätzung Statische Analyse Werkzeuggestütztes Auffinden von Fehlern ohne direkte Ausführung des Systems 24 Walkthrough Designer/ Programmierer führt Teammitglieder und andere Stakeholder durch ein Software- Produkt, Teilnehmer stellen Fragen und geben Kommentare ab Symbolische Ausführung, Simulation Testen Intensives Testen von Systemen und Dokumentation kann helfen, das Risiko, dass Probleme im operativen Betrieb auftreten, zu reduzieren Fehler vor der Freigabe in der operativen Verwendung finden und beheben Softwaretesten kann auch notwendig sein, um vertragliche oder gesetzliche Vorgaben oder spezielle Industrienormen zu erfüllen. 12

13 Unterscheidung Prüf- und Testverfahren Dynamischer Test Symbolischer Test Formale Verifikation Statische Analyse Testende Verfahren Verifizierende Verfahren Spezielle Analysen Analysierende Verfahren 25 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 26 13

14 Beschreibung von Safety Safety: Schutz vor (unbeabsichtigter) Fehlfunktion Realisierte Ist-Funktionalität entspricht spezifizierte Soll-Funktionalität Funktionalität unter allen (normalen) Betriebsbedingungen Dependabilty (Verlässlichkeit), RAMS (Reliability (Zuverlässigkeit), Availability (Verfügbarkeit), Maintainability, Safety), FuSi (Funktionale Sicherheit) Safety braucht Security Gesicherte Nachrichtenübermittlung Stellwerk zu Weiche 27 Funktionale Sicherheit in diversen Szenarien Verkehrsführung, Wetter, Human Factor Systemversagen, Vogelschlag Material Konzeption, Common Cause 28 Systematischer Ausfall vs. Zufälliger Ausfall Bildquelle: Wikipedia 14

15 Risikograph: Implizites Risikoakzeptanzkriterium 29 Beispiel ASIL-Einstufung - Automotive 30 [Sch12] 15

16 Entwicklungsprozesse und deren Wechselwirkungen 31 Automotive Safety Standard ISO V V V 32 [ISO26262] 16

17 Vereinfachte Darstellung einer beispielhaften Struktur von Abhängigkeiten Modulprüfbericht Software- Validierung Technische Anforderungen Validierungs- Testspezifikation Software- Architektur Integrations- Prüfspezifikation Modell- Prüfspezifikation Modelle Validierungstestprotokoll Integrationsprüfbericht Modellprüfbericht Modell- Dokumentation Modul- Spezifikation Modul- Prüfspezifikation 33 C-Code Statischer Analysebericht Teststufen im Beispiel V-Modell 34 Modultest: Aufdeckung aller Abweichungen der Implementierung von der Modulspezifikation Integrationstest: Aufdeckung von Fehlern in Schnittstellen und im Zusammenspiel zwischen integrierten Modulen Systemtest: Aufdeckung aller Abweichungen des Systemverhaltens in Bezug auf das in der Anforderungsdefinition spezifizierte Systemverhalten Abnahmetest: Aufdecken aller Fehler, die auf Missverständnissen bei Absprachen zwischen Benutzer und Entwickler, falschen Schätzungen von Datenmengen, unrealistischen Annahmen bezüglich der realen Systemumgebung beruhen 17

18 Testvorgehensweise - Beispiel 1. Vorbereitung des Testobjekts 2. Bereitstellung einer Testumgebung Simulation der realen Einsatzbedingungen für ein Testobjekt Ggf. auch (noch) nicht vorhandener Ressourcen oder Daten oder Nachrichten 3. Testfallermittlung Blackbox-Ansätze: Spezifikationsbasiert (Äquivalenzklassenbildung, Grenzwertanalyse, Ursachen-Wirkungsanalyse, Error Guessing) Whitebox-Ansätze: Implementierungsbasiert (Anweisungs- / Zweig- / Pfadüberdeckung, Datenflussanalyse, Symbolischer Test) Erfahrungsbasierte Verfahren 4. Auswahl geeigneter Testfälle und Testdaten Meist stichprobenartig, um mit möglichst wenigen Tests möglichst viele Fehler finden zu können, idealerweise (zum Teil) automatisierbar welche Abläufe sind wichtig /häufig / typisch, wichtig auch Randfälle 5. Testausführung 6. Testauswertung 35 Testdokumentation nach der IEEE 829 Übersicht - Testplan Testplan: Umfang, Vorgehensweise, Terminplan, Testgegenstände Testspezifikation (test specification) Testdesignspezifikation: Die im Testplan genannten Vorgehensweisen im Detail. Testfallspezifikationen: Die Umgebungsbedingungen, Eingaben und Ausgaben eines jeden Testfalls. Testablaufspezifikationen: In Einzelschritten, wie jeder Testfall durchzuführen ist. Test-(Ergebnis-) Beschreibung (test reporting) Testobjektübertragungsbericht: Wann wurden welche Testgegenstände an welche Tester übergeben Testprotokoll: Chronologisch alle relevanten Vorgänge bei der Testdurchführung Testvorfallbericht: Alle Ereignisse, die eine weitere Untersuchung erforderlich machen. Testergebnisbericht: Beschreibt und bewertet die Ergebnisse aller Tests

19 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 37 Safety versus Security 38 19

20 Sichere Systeme Safety Betriebssicherheit Zuverlässigkeit, Verlässlichkeit Security Angriffssicherheit Schutz vor Angriffen Ausfallsicherheit Verhinderung v. Schäden (Personen, Sachen, Umwelt) Schutz der Sicherheitsziele gegen Bedrohungen Vertraulichkeit, Integrität, Verfügbarkeit, Verbindlichkeit 39 Safety vs. Security Safety Mensch/ Umwelt M/U darf durch TS nicht gefährdet werden Technisches System Gefährdung des TS durch M/U darf keine Konsequenzen haben Mensch/ Umwelt 40 Security TS = Technisches System M/U = Mensch und Umwelt 20

21 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 41 Beschreibung (IT-) Security (IT-) Security: Schutz vor (absichtlichen) Angriffen Stellt Funktionale Korrektheit bei aktiven Attacken sicher (System, Kontrolle, Zugriffsschutz, ) Security darf Safety nicht stören Performance: Codierte vs. chiffrierte Nachrichten bei ABS Maintainability vs. Obfuscation Umso mehr fortgeschrittene computer-kontrollierte Safety-Features verwendet werden, desto anfälliger sind Safety-critical Aktionen gegenüber Angriffe (s.z.b. CAN-Message-Injection [MiVa2014]) Security will i.g. zu Safety geschlossene Türen: Geschlolssene Türen zw. Cockpit und Passagieren vs. einfachem Luftdruckausgleich Automatisches Türschließen beim Anfahren im Auto vs. einfaches Retten beim Unfall 42 21

22 Bemerkungen/ Beispiele Security Störfälle können die Verlässlichkeit von Systemen beeinträchtigen Konsequenz: Limitierung von Nutzbarkeit und Safety bis hin zu (D) Denial of Service Verlässlichkeit bestimmt die Wahrscheinlichkeit für den Verlust von Security SCADA: Attacke durch ungesicherte Kommunikationskanäle (Australien Maroochy Abwasserunfall, [SM08]) Automotive: Angriff über ungesicherte Schnittstellen, [CMK+11] 43 (IT-) Security -1 Schutzziele (Assets): schützende Güter: Informationen, Daten, Budget Zugriff ist zu beschränken/ kontrollieren. Nur frei für eindeutig identifizierte (zu verifizieren!) und autorisierte Subjekte Authentizität von Subjekten (Echtheit/ Glaubwürdigkeit). Bsp.: Benutzername (account) + Passwort/ biometrische Merkmale, (Credentials) Kryptografische Verfahren notwendig bei unsicheren Transportmedien Verfügbarkeit: autorisierten und berechtigten Subjekten ist Zugriff zu ermöglichen Verbindlichkeit/ Zuordenbarkeit: Urheberschaft eines Zugriffs/ Aktion ist im Nachhinein möglich Datenintegrität (integrity): zu schützende Daten können nicht unbemerkt/ unautorisiert manipuliert werden (Rechtefestlegung, Methoden) Informationsvertraulichkeit (confidentitiality): keine unautorisierte Informationsgewinnung Ausführliche Definitionen: Basiswerk: [Eck11] 44 22

23 (IT-) Security -2 Schutzziele müssen zunächst definiert werden. Diese sind nicht automatisch gleich Mensch, Leib, Leben und Umwelt Eine Sicherheitslücke in der IT-Sicherheit wird einmal bekannt mit großer Wahrscheinlichkeit auch ausgenutzt werden. Bekannte Lücken müssen also schnell geschlossen werden und können nicht statistisch erfasst werden Fehlverhalten sind meist Ergebnisse von Angriffen über mehrere (Zwischen-) Stufen und nicht unabhängig. Sie können deshalb mit konventionellen Safety- Methoden nicht offenbart werden [Svo10] Stuxnet: Schadprogramm um das SCADA-System Simatic S7 (Siemens) zu stören. Eingesetzt in Teheran in finnischen Geräten um Atomprogramm/ Urananreicherungsanlage oder Kernkraftwerk zu stören. 10 Jahre Entwicklungszeit mit 5-10 Entwicklern 1 Jahr um von Experten System nachzubauen Kenntnisse über unbekannte Sicherheitslücken mehrere Firmen Komplexer Verbreitungsweg 45 Common Criteria für IT Security Evaluation: ISO/ IEC International harmonisierte Kriterien zur Sicherheits-Evaluierung von IT-Technik EAL 7 Formal verifizierter Entwurf und getestet Katalog zur Spezifikation von Sicherheitsanforderungen Vergleichbarkeit der Ergebnisse von Evaluierungen Stufen der Vertrauenswürdigkeit (EAL) Gefährdungsfaktoren: Höhere Gewalt (Blitzschlag, Feuer, Überschwemmung, ) Fahrlässigkeit (Irrtum, Fehlbedienung, unsachgemäße Bedienung, ) Vorsatz (Manipulation, Einbruch, Hacking, Spionage, Sabotage, ) EAL 6 EAL 5 EAL 4 EAL 3 EAL 2 Semi-formal verifizierter Entwurf und getestet Semi-formal entworfen und getestet Methodisch entwickelt, getestet und durchgesehen Methodisch getestet und überprüft Strukturell getestet 46 Technisches Versagen (Stromausfall, HW- Ausfall, ) Organisatorische Mängel (unberechtigter Zugriff, Raubkopie, ungeschultes Personal, ) EAL 1 Funktionell getestet 23

24 Normen/ Richtlinien -1 IT-Sicherheit für industrielle Leitsysteme Netz- und Systemschutz: ISA 99/ IEC (Industrial Automation and Control Systems (IACS) Security) Empfehlungen für die Entwicklung, den Betrieb und die Beschaffung von IT- Systemen in elektrischen, elektronischen und programmierbaren Bahnsignalanlagen Risiken aufgrund von böswilligen Angriffen Zusätzliche Anforderungen an Systeme die sich durch Bedrohungen der Security ergeben 47 Security Assurance Level SL 1 Bedeutung Angriffe Hilfsmittel Wissen Ressource Motivation zufällig/ gelegentlich SL 2 Absicht einfach allgemein niedrig gering SL 3 Absicht komplex spezifisch moderat moderat SL 4 Absicht komplex spezifisch groß hoch Normen/ Richtlinien -2 Reihe von Standards der IT-Sicherheit: ISO/ IEC 27k Erfüllungsgrad zur Konformität ISMS (Information Security Management System) kann nach beurteilt und zertifiziert werden Vorgaben für Risikoanalyse und bewältigung Ergänzbar durch den Grundschutzkatalog der BSI (Bundesamt für Sicherheit in der Informationstechnik, ) 48 [Wikipedia] 24

25 implizit initial Erhöhung Effizienz Umfassend Software Assurance Maturity Model (SAMM) Open Web Application Security Project (OWASP) Vier kritische Business Funktionen für Organisationen: Governance: managen von overall -SW-Aktivitäten Strategie, Metriken, Policy, Compliance, Schulung, Richtlinien, Construction: Definition von Zielen und SW-Entwicklung, Produktmanagement, Anforderungsanalyse, Risikomanagement, Security-Anforderungen, Sicherheitsarchitektur, Verification: Überprüfung und Test von bei der SW-Entwicklung produzierten Artefakten Design Reviews, Code Reviews, Security Testing, Deployment: Releaseverwaltung, Lieferung, Betrieb in Echtsystemen Schwächenmanagement, Umgebungen härten, Ermöglichen des Betriebs Startpunkt Verstehen von Security- Methoden Effektivität der Security- Methoden steigern Beherrschung der Security- Methoden 49 s. Auch BSIMM (Building Security In Maturity Model)/ SDL (Security Development Lifecycle) Lösungskonzepte Derzeit verstärkt verfolgt: Konsequente(re)s "Security by Design" (durch Norm geregelt) Standardisierung von Protokollen wie z.b. OPC UA Schulung/ Know-How- und Bewusstseinserhöhung/ Sensibilisierung Drang zur Zertifizierung Einsatz von security-proven IT-Komponenten; Security-Gateway, Chrypt-Module Beobachtung von Anomalien (Vorbeugung von Zero-Day-Exploits) 50 25

26 Beispiel 1 für Methoden: CORAS Prozess zur Security-Risiko-Analyse (basierend auf AS/ NZS 4360 (australische/ neuseeländische Risikomanagementnorm (erste international akzeptierte Risikomanagement-Norm)) Sprache/ Diagramme: grafische Sprache zur Unterstützung der Analyse Kommunikationsbasis/ Dokumentation Semantik: schematische Übersetzung vom Diagramm in Sprache Kalkül: Menge von Regeln für Diagramminterpretation Editor: Tool zur Unterstützung der Diagrammerstellung Freies Tool: Richtlinie zur optimalen Nutzung 51 Beispiel 1 für Methoden: CORAS : Risikomaßnahmen Gefahren Schwachstellen Unerwünschte Ereignisse Assets Angriffs-Szenario Konsequenzen 52 Risiko- Maßnahmen Wahrscheinlichkeiten p(ereignis) + Konsequenz -> Risiko 26

27 Beispiel 2: Model-Based Security Testing (MBST) ITEA2-Projekt DIAMONDS (Fraunhofer Institut FOKUS, Berlin) [SGS12] Validierung von Software System-Anforderungen bezogen auf Security- Eigenschaften (Vertraulichkeit, Datenintegrität, Authentizität, Verfügbarkeit, ) Systematische und effiziente Spezifikation und Dokumentation von Security-Test- Objekten, Security-Testfällen und Security-Testsuiten Bestandteile: Security Funktionale Tests Model-Based Fuzzing Risiko- und Gefahren-orientiertes Testen Security Test-Pattern Aussagen der Studie: 90% aller SW-Security Störfälle werden durch Angreifer, die Schwachstellen kennen verursacht Die meisten Schwachstellen entstehen durch Software-Fehler oder Design-Mängel Systematisches Testen erhöht die Wahrscheinlichkeit Fehler und Schwachstellen während Design aufzudecken. 53 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 54 27

28 Zusammenfassung/ Ausblick Weitere Stichwörter: Error seeding Model based testing Design oriented testing Toolsqualifikation (normengefordert) Nichtfunktionale Anforderungen 55 Zusammenfassung - Ausblick Ausblick dimension Safety Security functional attack definition by functional safety/ RAMS definition of assets: access, authenticity, prevention of accidential failures intentional attacks standards well-known methods in preparation (domain dependent) kind of hazard technical systems harms people and people harms technical systems by environment without intention intention parameter to define risk level risk for life and body/ environment; risk attacker view: motivation, intention, graph; frequency x damage available tools, ressourced, skill, techniques FMEA, hazop, FTA, hazop, CRAMM, CORAS, ATA, failures are considered as independant not independant severity/ ranking according safety integrity level/ performance level/ security/ evaluation assurance design assurance level/ (confidence) operation mode safe under normal conditions further operation in case of attacks reaction on events redundancy/ switch into fail-safe state faile-secure, keep normal operation awareness high: safety first (to) low: security only for safety/ availability first (known) gaps in a system will have an impact randomly/ by accident will be exploited someday by someone implementation simple and easy to understand obfuscation; prevent re-engineering dependency safety needs security security needs no safety willingness to pay additionally existing for not existing 56 28

29 Literatur/ Referenzen -1 [Bau14] Vortrag Klaus Bauer, Sicherheit aus dem Blickwinkel einer Maschine ; Kongress Sicherheit und Automation 2014 [CMK+11] Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, and Stefan Savage University of California, San Diego; Karl Koscher, Alexei Czeskis, Franziska Roesner, and Tadayoshi Kohno University of Washington Comprehensive Experimental Analyses of Automotive Attack Surfaces ( ) [Den91] Ernst Denert: Software-Engineering. Springer, Berlin 1991, 1992 [DZGSP08] CHIP, Markus Mandau, , 2008 [Eck11] Claudia Eckert: IT-Sicherheit: Konzepte Verfahren Protokolle ; Oldenbourg Wissenschaftsverlag; 2011 [IEC-61508] Standard Functional safety of electrical/electronic/programmable electronic safety-related systems [Lie14] Dynamische Programmanalyse Seminar: Verfahren zur Analyse von Programmcode. Julian Liedtke; [MiVa2014] A Survey of Remote Automotive Attack Surfaces ; Charlie Miller & Chris Valasek; Black Hat USA 2014, Las Vegas; August Literatur/ Referenzen -2 [Sch12] Vortrag D. J. Schwarz: Einführung der ISO in die Automobilindustrie Umfängliche Prozesse nachhaltig in eine laufende Entwicklung integrieren ; [SESAMO14] EU-ARTEMIS-Projekt ( ) [SGS11] Ina Schieferdecker, Jürgen Großmann, Martin Schneider (Fraunhofer FOKUS; Model-Based Security Testing ( ) [SM08] Jill Slay, Michael Mille, ifip, International Federation for Information Processing; Critical Infrastructure Protection; Chapter 6 LESSONS LEARNED FROM THE MAROOCHY WATER BREACH ( ) [Spi04] Basiswissen Softwaretest, Andreas Spillner, Tilo Linz, Dpunkt Verlag; Auflage: 2. überarb. A. (2004) [Sto09] Ketil Stolen, SINTEF & UiO, Security Analysis: The CORAS Approach [Svo10] Milos Svoboda; 8. Safetrans Industrial day; Safety and Security in Industrial environments [Zel03] A. Zeller. Program Analysis: A Hierarchy. Proceedings of ICSE Workshop on Dynamic Analysis, (WODA 2003),

30 Glossar 59 BSI = Bundesamt für Sicherheit in der Informationstechnik BSIMM = Building Security In Maturity Model CEN = European Committee for Standardization CRAMM = CCTA Risk Analysis and Management Method CPS = Cyber-physisches System DDoS = Distributed Denial of Service (Dienstverweigerung) EAL = Evaluation Assurance Level IEC = International Electrotechnical Commission FOKUS = Fraunhofer Institut für Offene Kommunikationssysteme ISMS = Information Security Management System ISA = International Society of Automation ISO = International Organization for Standardization ITEA = Information Technology for European Advancement MBST = Model Based Security Testing MES = Manufacturing Execution System OPC UA = OLE (Object Linking and Embedding) for Process Control Unified Architecture OWASP = Open Web Application Security Project SAMM = Software Assurance Maturity Modell SCADA = Supervisory Control and Data Acquisition (Überwachen und steuern technischer Systeme) SDL = Security Development Lifecycle SEI = Software Engineering Institute SIL = Safety Integrity Level S(A)L = Security (Assurance) Level Fragen/ Diskussion/ AOB 60 30