Safety and Security in Industry 4.0

Transkript

1 INFORMATIK CONSULTING SYSTEMS AG Safety and Security in Industry 4.0 Ort Mittelstandstag Esslingen Datum 23. November 2016 Stand

2 Agenda Top down Safety Bottom up Security Data Privacy Proaktiv Ausblick 2

3 Motivation gestern Systemgedanke Top Down Fahrdienstvorschriften und andere Regelwerke sind mit Blut geschrieben 3 Bildquelle: Wikipedia

4 Beschreibung von Safety Safety: Schutz vor (unbeabsichtigter) Fehlfunktion (bei bestimmungsgemäßer Verwendung) 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) Abwesenheit unzumutbarer Risiken Bei entsprechender Anwendung von Methoden sinkt die Anzahl von Unfällen Viele bewährte Methoden in Normen festgeschrieben (mathem.; Top down) Fehler vermeiden; gemachte finden; mit im Betrieb auftretenden umgehen Im Notfall in sicheren Zustand wechseln 4 Safety braucht Security Fragil -> Robust How much Security is safe enough?

5 Agenda Top down Safety Bottom up Security Data Privacy Proaktiv Ausblick 5

6 Motivation heute Der Wert von Sicherheit wird oft erst dann erkannt, wenn sie nicht mehr gewährleistet ist 6

7 Security Lehren 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 (zu damaliger Zeit) Völlig unterschätzt: Größe der SW-Anteils in Produktionsanlagen Technische Möglichkeit Laden von Schadsoftware in proprietären Systemen Hohe Motivation der Angreifer (s.o.) Potentielle Auswirkungen 7

8 Beschreibung (IT- und Informations-) Security Security: Schutz vor (absichtlichen) Angriffen (und Zufällen/ Unglücke) Stellt Funktionale Korrektheit bei aktiven Attacken sicher (System, Kontrolle, Zugriffsschutz, ) Security auch: Maß für Risikoreduktion bzgl. Safety Schwachstellen werden gezielt gesucht und ausgenutzt Funktionalität muss erhalten bleiben Security darf Safety nicht stören Performance: Codierte vs. chiffrierte Nachrichten Organisatorische Maßnahmen (z.b. Identifizierung/ Autentifikation) Fortgeschrittene computer-kontrollierte Safety-Features vs. Angriffsfläche für Safety-critical Aktionen (z.b. CAN-Message-Injection [MiVa2014]) Interessenskonflikt; induktiv; bottom up; Antizipieren 8 Robust -> Antifragil. Emergenz.

9 9 Sicherheitsgrundsatz: Körperliche Abwesenheit ist besser als Geistesgegenwart gilt nicht mehr!

10 Behandlung von Risiken Safety (z.b. IEC 61508) vs. Security (z.b. BSI Grundschutzkataloge BSI 100-3) Reduktion: weitere Sicherheitsmaßnahmen Vermeidung: durch Um- Strukturierung Übernahme: Akzeptanz Transfer: Übertrag an eine andere Institution 10

11 11 Interessenskonflikt. Beispiele: Implementierungsangriff vs. Seitenkanalangriff

12 Agenda Top down Safety Bottom up Security Data Privacy Proaktiv Ausblick 12

13 Datenschutz: Art. 2 Abs. 1 GG: Persönlichkeitsrecht -> Informationelle Selbstbestimmung 13 Vertrauen ist die neue Währung im Internet

14 Personenbezogene (sensible) Daten Möglicherweise übermittelte Daten Uhrzeit, Unfallzeitpunkt, Position (inkl. Spurrichtung), Grad der Deformierung Identität des Autos, Fahrzeugtyp/ -klasse, Mobilnumner der SIM-Karte die für ecall genutzt wird Anzahl geschlossener Gurte/ belegte Sitzpositionen (-> #Opfer) Anzahl und Position der ausgelösten Airbags (-> Art und Schwere) Kilometerzähler Daten/ Black Box: Lenkung, Beschleunigung, Geschwindigkeit, Bremsmanöver, Geschwindigkeitsprofil ABS-Bremsdaten, ESP-Daten, Erlaubte Geschwindigkeit Antriebsart; Art des Treibstoffes, 14

15 Safety vs. Security Safety: möglichst viele nützliche Daten, möglichst exakt, redundant, schneller Zugriff um Services zu optimieren 15 Security: möglichst wenige personalisierte/ sensible Daten ohne Redundanz und Speicherung/ restriktiver Zugriff (minimal set of data)

16 Privacy by Design Prinzipien Proaktiv statt reaktiv; Präventiv statt sanieren Datenschutz als Default Datenschutz im Design eingebettet (kein add-on) Volle Funktionalität, keine Nullsumme Schutz über den gesamten Lebenszyklus Sichtbarkeit und Transparenz Respekt vor Datenschutz der Nutzer 16

17 Agenda Top down Safety Bottom up Security Data Privacy Proaktiv Ausblick 17

18 Zulassung von Systemen Zentrale Steuerungen werden von einer (unabhängigen) Kontrolleinheit überwacht (IEC 61508) Teile eines Systems sind selbst für Safety zuständig (Bsp. ABS, Assistenzsysteme, ; ISO 26262) Zulassung Produkt/ Serie: Geschlossene statische Systeme zur Entwicklungszeit Offene, dynamische (sich selbst konfigurierende) Systeme zur Betriebszeit 18 Zeit

19 Parallele Elemente im Safety- und Security-Prozess [GGH15+] 19

20 Schutzziele in der IT-Sicherheit 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 (irgendwann) ausgenutzt werden. Bekannte Lücken müssen also schnell geschlossen (s.a. Zero-Day-Exploit) 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] Im Vergleich: Safety: Risiken mit sehr kleiner Wahrscheinlichkeit können in weiteren Betrachtungen vernachlässigt werden 20

21 Teststrategien Functional Testing Erfüllung der Anforderungen (Kryptografie, Authentifizierungsprotokolle) Vulnerability Scanning Aufspüren bekannter Sicherheitslücken/ -schwächen (z.b. hartcodierte Passwörter/ offene Ports ) Systematic Fuzzing Systematisches Einbringen/ Senden von Daten zum Auffinden von undokumentierten/ unbekannten Verhalten/ Eigenschaften Penetration Testing Individuelle Tests um gefundene Schwächen auszunutzen/ Fault Injection um Routinehecks zu umgehen Im Vergleich: Safety: V-Modell/ Fehlerkombinationen auf jeder System-(Integrations-) Ebene Verifikation/ Test/ Prüfung (Dinge richtig gemacht) 21 Validierung (die richtigen Dinge gemacht)

22 IEC 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, elektron. und programmierb. Bahnsignalanlagen Risiken aufgrund von böswilligen Angriffen Zusätzliche Anforderungen an Systeme die sich durch Bedrohungen der Security ergeben Security Assurance Level Bedeutung Angriffe Hilfsmittel Wissen Ressource Motivation 22 SL 1 zufällig/ gelegentlich SL 2 Absicht einfach allgemein niedrig gering SL 3 Absicht komplex spezifisch moderat moderat SL 4 Absicht komplex spezifisch groß hoch

23 OWASP Top 10 Angriffe 1. (1) Injection 2. (3) Broken Authentication and Session Management 3. (2) Cross-Site Scripting (XSS) 4. (4) Insecure Direct Object References 5. (6) Security Misconfiguration 6. (7) Sensitive Data Exposure 7. (8) Missing Function Level Access Control 8. (5) Cross-Site Request Forgery (CSRF) 9. (-) Using Components with known vulnerabilities 10.(10) Unvalidated Redirects and Forwards 23

24 CERT X Secure Coding Standard CERT Computer Emergency Response Team Behandlung von Coding Errors die Ursache von Software Verwundbarkeiten. Wahrscheinlichkeiten für Ausnutzung und Abhilfe Kritisches Codieren Fehler die zu Buffer Overflow führen (z.b. Integer Overflow) 98 Regeln (MISRA C*: 144 Regeln; nicht ausreichend!!) 24

25 Zusammenfassung/ Ausblick Lösungsansätze Derzeit verstärkt verfolgt: Konsequente(re)s "Security by Design" (durch Norm geregelt) Standardisierung von Protokollen im Internet der Dinge/ Industrie 4.0 wie z.b. OPC UA/ MQTT/ Schulung/ Know-How- und Bewusstseinserhöhung/ Sensibilisierung Drang zur Zertifizierung Einsatz von security-proven IT-Komponenten; Security-Gateway, Crypt- Module Beobachtung von Anomalien (Vorbeugung von Zero-Day-Exploits) 25

26 Fragen? 26 Kontakt: Autor: Dr. Stefan Lewandowski

27 Literatur/ Referenzen [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 ( ) [Dam07] Lars-Ola Damm Early And Cost-Effective Software Fault Detection Measurement And Implementation in an Industrial Setting ; Doctoral Dissertation Series No. 2007:09; Blekinge Institute of Technology; School of Engineering [Den91] Ernst Denert: Software-Engineering. Springer, Berlin 1991, 1992 [DZGSP08] CHIP, Markus Mandau, [Eck11] Claudia Eckert: IT-Sicherheit: Konzepte Verfahren Protokolle ; Oldenbourg Wissenschaftsverlag; 2011 [GGH+15] Benjamin Glas, Carsten Gebauer, Jochen Hänger, Andreas Heyl, Jürgen Klarmann, Stefan Kriso, Priyamvadha Vembar, Philipp Wörz, Integration Challenges, Konferenz Automotive Safety and Security 2015 [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 2014 [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),

28 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 ( ) [Dam07] Lars-Ola Damm Early And Cost-Effective Software Fault Detection Measurement And Implementation in an Industrial Setting ; Doctoral Dissertation Series No. 2007:09; Blekinge Institute of Technology; School of Engineering [Den91] Ernst Denert: Software-Engineering. Springer, Berlin 1991, 1992 [DZGSP08] CHIP, Markus Mandau, [Eck11] Claudia Eckert: IT-Sicherheit: Konzepte Verfahren Protokolle ; Oldenbourg Wissenschaftsverlag; 2011 [GGH+15] Benjamin Glas, Carsten Gebauer, Jochen Hänger, Andreas Heyl, Jürgen Klarmann, Stefan Kriso, Priyamvadha Vembar, Philipp Wörz, Integration Challenges, Konferenz Automotive Safety and Security 2015 [IEC-61508] Standard Functional safety of electrical/electronic/programmable electronic safety-related systems 28

29 Literatur/ Referenzen -2 [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 2014 [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 30 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

31 Bewährte Vorgehensweisen (Safety) Rollentrennung/ Personaltrennung Dokumentenstruktur: Plan -> Spezifikation -> Bericht Traceability: Anforderung -> Source Code -> Validierung Anforderungen/ Testspezifikation: mindestens semi formal Mit dem Testen so früh wie möglich (auf jeder Ebene) beginnen Testsautomatisierung um Häufigkeit von Regressionstests erhöhen zu können Validierung: Anpassung der Tests an das System und die grundlegenden Anforderungen (funktionale und strukturelle Abdeckung) Anwendung von Methodentabellen aus entsprechenden Standards V-Modell 32

32 Safety-Aspekt -1 ecall ist ein passives Sicherheitssystem ecall wird Unfälle nicht vermeiden die Auswirkung wenn es einen Unfall gab lindern (s. Airbag) Bewertung: Nach einem schweren Unfall ist die Zeit bis Hilfe eintrifft um Verletzten zu helfen ein kritischer Faktor ecall kann durch sofortige präzise (ausführliche) Meldung diese Zeit verkürzen Passiv Safety/ IVS (In Vehicle System) 33

33 Komplexität und Umfang von Anforderungen an technische Systeme steigt Dezentralisierung von Steuerungen: Verteilung einfachster Anforderungen über mehrere Steuergeräte Kommunikation von Steuergeräten über mehrere Kanäle/ Busse Wachsender Einsatz unterschiedlicher smarte Endgeräte und Bedienungskonzepte: Integration unterschiedlicher Systeme (z.b. Car2x, IoT, ) Flexible Tablet-/ Touch-Steuerung/ Funktionsaufruf via App (Security an zweiter Stelle) 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 Offene Schnittstellen (USB, Bluetooth, WLAN, ) Hang zu immer raffinierteren Services (realisiert in Software) 34 Industrie 4.0/ IIC/ Industrie du Futur, Internet der Dinge, Losgröße 1, Smart grid, Smart City, Home Automation,

34 Komplexität der Entwicklungsprozesse steigt Produktlebenszeiten (z.b. System Auto) länger als Lebenszyklen von Software und Betriebssystemen Beispiel: ecall Übertragungstechnik vs. Lebensdauer Auto (OTA update? SW IVS) Embedded-Systeme sind die Dinge : Mehrere Standards für jede Anforderung machen 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 Möglichkeit zur hohen Variantenzahl Vernetzung horizontal und vertikal: Flexibilität, Autonomie, Teleservices 35 Standardisierung vs. Pragmatismus

35 (IT-) Security Datenschutzmanagement -1 Schutzziele (Assets): schützende Güter: Informationen, Daten, Budget Zugriff ist zu beschränken/ kontrollieren (s.a. Zutritt, Zugang). 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/ Pseudoanonymisierung Verfügbarkeit: autorisierten und berechtigten Subjekten ist Zugriff zu festgelegten Zeiten im festgelegten Umfang zu ermöglichen 36

36 (IT-) Security Datenschutzmanagement -2 Verbindlichkeit/ Zuordenbarkeit: Urheberschaft eines Zugriffs/ Aktion ist im Nachhinein möglich. Revisionssicherheit/ nicht Abstreitbarkeit Datenintegrität (integrity): zu schützende Daten können nicht unbemerkt/ unautorisiert manipuliert werden (Rechtefestlegung, Methoden, Signaturen, ) Informationsvertraulichkeit (confidentitiality): keine unautorisierte Informationsgewinnung. Datenschutz. (BDSG 9) Transparenz: Verfahren sind vollständig dokumentiert Ausführliche Definitionen: Basiswerk: [Eck11] 37

37 Keine Security Anforderungen aus Systemsicht verlieren Prozess/ Vorgehensmodelldefinition Management-/ Organisationsprozesse Datenschutz, Datensicherheit Risikoanalyse auf Systemebene; Durchgängigkeit/ kritischer Pfad Angriffsvektoren/ -szenarien; Durchgängig sicherer SW- Entwicklungsprozess Modellierung/ Coding Standards Defensiver Code/ MISRA/ CERT C Normen/ Richtlinien für Organisationen/ Produkte Reifegradmodelle; Management Systeme; Zertifikate Systembetrachtung: Dekomposition; Assets; Angriffsszenarien; Rückwirkungsfreiheiten Secure Coding; Implementierung; Compiler-Optionen Verifikation und Absicherung auch außerhalb ihrer funktionalen Spec Penetrationstests; Fuzzy Tests; 38

38 Zusammenfassung/ Ausblick Aktuelle Themen Weitere Stichwörter: Error seeding/ Honey Pots Model based testing (MBT) for Security (auch Fuzzing) Nichtfunktionale Anforderungen Emergente Systemeigenschaften fragil -> robust -> antifragil Induktiv vs. deduktiv Lernende Modelle: Antizipation 39

39 Zusammenfassung/ Ausblick Überblick 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 for existing not existing 40