Analyse der Cyber-Sicherheit von Industrie 4.0-Technologien auf Basis des RAMI 4.0 und Identifikation von Lösungsbedarfen

Analyse der Cyber-Sicherheit von Industrie 4.0-Technologien auf Basis des RAMI 4.0 und Identifikation von Lösungsbedarfen Dr.-Ing. Holger Flatt, M.Sc. Sebastian Schriegel, Prof. Dr.-Ing. Jürgen Jasperneite, Fraunhofer IOSB-INA, Lemgo; Dr.-Ing. Henning Trsek, rt-solutions.de, Köln; Dipl.-Ing. Heiko Adamczyk, Knick Elektronische Messgeräte GmbH Co. KG, Berlin Kurzfassung Die vollständige Digitalisierung der industriellen Produktion und die entstehende neue Qualität an Informationstransparenz sind die Grundlage für die Mehrwerte Effektivität, Qualität und Individualität. Diesem Mehrwertpotential stehen Gefahren der Cyber-Sicherheit entgegen: Jede Steigerung der Digitalisierung, Informationstransparenz und Standardisierung macht Produktionsanlagen angreifbarer. Das Referenz Architektur Model Industrie 4.0 (RAMI 4.0) ermöglicht die Abbildung aller Instanzen einer Industrie 4.0-Anwendung über den gesamten Lebenszyklus und kann so bei der Analyse der Cyber-Sicherheit von Industrie 4.0- Technologien unterstützen. In diesem Beitrag wird am Beispiel einer Cloud-basierten Produktionsüberwachung das Vorgehensmodel einer Cyber-Sicherheitsanalyse anhand RAMI 4.0 und der Richtlinie VDI/VDE 2182 gezeigt. Das Vorgehen unterstützt bei der Identifikation von Schutzbedarfen spezifischer Applikationen und ermöglicht die Risiko-basierte Auswahl von Gegenmaßnahmen zur Absicherung. Abstract The exhaustive digitalization of the economy, and to be more specific, of industrial production systems results in a new quality of information transparency. This is the basis for added values in terms of effectiveness, quality, and individuality. However, these added values also result in an increased exposure to Cyber-Security threats, due to the increased digitalization, information transparency and standardization. The architecture reference model Industry 4.0 (RAMI 4.0) allows to represent all instances of an Industry 4.0 application along the life-cycle and can be used to analyze the Cyber-Security of Industry 4.0 applications. In this work, the procedural model for a Cyber-Security analysis based on RAMI 4.0 and the VDI/VDE guideline 2182 is exemplarily shown for the use case of a Cloud-based monitoring of the produc-

tion. The derived procedure supports the identification of protection demands and allows a risk-based selection of suitable countermeasures. 1. Einleitung Industrie 4.0 beschreibt die digitale Vernetzung von Menschen, Produkten und Maschinen sowie die darauf aufbauende intelligente Datenverarbeitung, neue digitale Mehrwertdienste und Geschäftsprozesse. Um eine Standardisierung zu ermöglichen, wurden in den letzten Jahren die Referenzarchitekturmodelle Industrie 4.0 (RAMI 4.0) [1] und IIC IIRA entwickelt [2]. Die mit den Modellen entstehende neue Qualität an Informationstransparenz und digitaler Öffnung physikalischer Systeme [3] (z.b. Produktionsmaschinen) wirft vielfältige Fragen der Cyber-Sicherheit [4] wie z.b. Verhinderung von Prozessmanipulation oder -stilllegung durch Cyber-Angriffe [5], Know-how Schutz/ Produktschutz oder informationelle Selbstbestimmung auf. Während das Thema IT-Sicherheit beim IIRA-Modell eine höhere Bedeutung einnimmt wird es im RAMI 4.0 nur peripher adressiert. Insbesondere ist bisher nicht vorgesehen, Sicherheitsbewertungen anhand des RAMI 4.0 durchzuführen. In diesem Beitrag wird daher eine ausgewählte Industrie 4.0-Technologie aus der SmartFactoryOWL 1 am Beispiel Cloud-basierter Services auf Gefahrenpotentiale (konkrete Bedrohungen, Schwachstellen) analysiert. Die einzelnen Analyseergebnisse werden zunächst auf Basis des Referenzarchitekturmodells Industrie 4.0 (RAMI 4.0) strukturiert [1]. Die identifizierten und RAMI 4.0-strukturierten Angriffs- bzw. Risikoszenarien (Eintrittswahrscheinlichkeit, Schadenshöhe) werden bestehenden Lösungsansätzen und Best-Practices [6] [7] [8], wie z.b. Security-by-Design, Cyber-Security-Konzepte und Architekturen (Verschlüsselung, Kryptografie, Virenscanner, Signaturscanner, IKT-Anomalieerkennung/ IDS [9], IT-Forensik [10]) sowie erforderlichen organisatorischen Maßnahmen (Process-Product- People) auf Basis der VDI/VDE Richtlinie 2182 [8] analysiert und bewertet. Nicht gedeckte Lösungsbedarfe werden identifiziert. Ziel ist zukünftig eine ganzheitliche Betrachtung der Cyber-Sicherheit von Industrie 4.0-Produktionsstandorten zu ermöglichen. Der Beitrag gliedert sich wie folgt: Abschnitt 2 stellt zunächst das RAMI 4.0 und die damit verbundenen Aspekte in Bezug auf IT-Security vor. Im dritten Abschnitt erfolgt eine Vorstellung der SmartFactoryOWL und eines Cloud-basierten Services, welcher als Use Case im Rahmen des Beitrages untersucht wird. Auf Basis dieses Use Cases erfolgt im 4. Abschnitt 1 www.smartfactory-owl.de

eine Risikoanalyse in Bezug auf IT-Security mit anschließender Bewertung. Abschnitt 5 fasst die Arbeit zusammen und gibt einen Ausblick. 2. Kurzvorstellung RAMI 4.0 Das Referenzarchitekturmodell Industrie 4.0, kurz RAMI 4.0, besteht aus einem dreidimensionalen Koordinatensystem, das die wesentlichen Aspekte von Industrie 4.0 beinhaltet. Komplexe Zusammenhänge können so in kleinere, überschaubare Pakete aufgegliedert werden [1]. Das Modell besteht aus den drei Achsen Layers, Life Cycle & Value Stream und Hierarchy Levels. Basierend auf der IEC 62264 spiegeln die Hierarchy Levels die unterschiedlichen Funktionalitäten vom Produkt bis zur vernetzten Welt wider. Die Achse Life Cycle & Value Stream stellt auf Grundlage der IEC 62890 den Lebenszyklus von der Entwicklung bis zur Wartung bzw. dem Produkteinsatz dar. Nach Abschluss der Prototypenfertigung wird aus dem Typ eine Instanz. Die Achse Layers, welche in sechs Schichten unterteilt ist, beschreibt die IT-Repräsentanz. Die Beschreibung beginnt bei der Asset-Schicht und endet bei der Business-Schicht. In Bezug auf die IT-Sicherheit ermöglichen die drei Achsen des RAMI 4.0-Modells dabei eine vollständige Abbildung der Gefahren und Angriffspunkte und insbesondere die Auswirkung von Angriffen auf andere Elemente der Gesamtarchitektur. 3. Use Case Intelligente Produktionsüberwachung und Optimierung als Cloud-Service 3.1 Beschreibung des Use Cases Ein zukünftig bedeutsames Industrie 4.0-Anwendungsfeld sind Cloud-basierte Services, welche z.b. für eine intelligente Produktionsüberwachung (Condition Monitoring, Predictive Maintenance), Produktionsanalyse (Fehlerdiagnose, Reparatur) und Produktionsoptimierung (Energieeffizienz, Taktzeiten, Qualität) genutzt werden können. Dabei werden Auftragsdaten, Prozessdaten und Materialdaten aus der laufenden Produktion mit Hilfe einer Cloud- Infrastruktur erfasst und ausgewertet. Die Auswertung erfolgt mit verschiedenen mathematischen Methoden wie z.b. Korrelationsanalysen, Kausalitätsanalysen oder Methoden des maschinellen Lernens [11]. Nachfolgend werden am Beispiel einer realen I4.0- Produktionsanlage der SmartFactoryOWL derartige Cloud-basierte Services in Ihrer Architektur (Prozess, Kommunikation, Datenhaltung) und Ihrer Daten beschrieben und analysiert. Die SmartFactoryOWL, eine Initiative der Fraunhofer-Gesellschaft und der Hochschule OWL, ist ein herstellerunabhängiges Industrie 4.0-Demonstrationszentrum und reales Testbed.

Im Rahmen dieses Beitrages wird eine Produktionsanlage zur Abfüllung von Schüttgut der SmartFactoryOWL als Use Case betrachtet werden. Die Anlage ist modular aufgebaut. Die einzelnen Module sortieren Schüttgut, wiegen dieses und füllen es in Flaschen ab. Ziel des I4.0 Use Case ist, die Produktqualität zu verbessern (Sortierung ohne Fehler; richtige Abfüllmenge), eine höhere Anlagenverfügbarkeit zu erreichen (Ausfallzeiten verringern) sowie die Ausbringung (Durchsatz, Taktzeit) der Anlage zu steigern. Dazu soll ein intelligenter, auf Daten basierender Service zur Überwachung und Optimierung der Anlage implementiert werden. Die hierzu erforderlichen Daten werden u.a. mittels smarter Sensoren erfasst. Die Services sollen als Cloud-Lösung implementiert und genutzt werden. Bild 1 stellt allgemein das Szenario Cloud-basierter Services aus logischer Sicht dar. Zu berücksichtigen ist, dass es sich hierbei um eine Interaktion verschiedener Instanzen handelt. Diese beinhalten primär Produkte (hier I4.0-Lösungen), Prozesse (z.b. Vertragsdialog bei Aufbau Wertschöpfungskette) und Daten (Vertragsdaten, Produktionsdaten). In Bezug auf eine Sicherheitsanalyse ist zu berücksichtigen, dass Cyber-Angriffe auf alle dargestellten Blöcke erfolgen können. Dieser Beitrag fokussiert auf eine etablierte Wertschöpfungskette, in welcher der Vertragsdialog bereits abgewickelt (Bild 1: gestrichelte Linie) und eine dauerhafte Verbindung zur Übertragung von Produktionsdaten (Bild 1: durchgängige Linie) etabliert ist. Prozesse Produkt I40 Geräte Hersteller Daten Verwaltungs schale Internet Provider Prozesse Produkt I40 Betreiber Prozesse Daten Produkt A Produkt B Prozesse Software Produkt Software Produkt A Software Produkt B Anlage A Daten Prozesse Produkt C Software Hersteller Cloud Service Provider Bild 1: Industrie 4.0-Anwendung: Cloud-basierter Service 3.2. Abbildung des Use Cases auf das RAMI 4.0-Modell Um die IT-Sicherheit der beschriebenen Industrie 4.0-Anwendung zu überprüfen, wurden die Funktionalitäten und Daten zunächst auf das Referenz Architektur Model Industrie 4.0 abge-

bildet. Bild 2 zeigt die Architektur des Use Cases mit den eingesetzten Kommunikations- und Analysetechnologien. Die roten Würfel innerhalb des RAMI 4.0 zeigen Datenpunkte oder Interaktionspunkte des Use Cases; dies bedeutet, dass der Use Case hier im RAMI 4.0 ausgeprägt ist. Der Use Case spielt zur Laufzeit der Anlage, d. h. während des operativen Betriebs des Produktionssystems statt. Die Würfel befinden sich entsprechend auf der Achse Layers, Life Cycle & Value Stream nur im Bereich Betrieb und nicht im Bereich Herstellung des Produktionssystems. Dargestellt ist weiter, dass das individuelle Produkt per RFID identifiziert wird und auf dieser Basis der Produktionsanlage die (schützenwerte) Rezeptur vorgibt. Die Anlage verwendet für die Echtzeitprozesskommunikation PROFINET. Die vertikale Integration der Anlage wird über eine mit VPN-gesicherte TCP/IP-Verbindung und OPC UA mit einer Cloud-Lösung verbunden. Es werden spezifische Daten der Produkte (Identifikation mit RFID) und Prozessdaten mittels smarter Sensoren aufgenommen und in einem Cloud- Speicher des Cloud Service Providers abgelegt. Business Functional Information Communication Integration Asset Maschinelles Lernen Cloud Speicher Anlagenmodelle Maschinelles Lernen Cloud Speicher Produktmodelle/ Rezepte PROFINET RFID Cloud Service Condition Monitoring VPN, TCP/IP OPC UA Bild 2: Abbildung der intelligenten Produktionsüberwachung und Optimierung als Cloud- Service auf RAMI 4.0-Modell Aus den Daten werden mittels Methoden des maschinellen Lernens Modelle erzeugt, die als Referenz für eine Anomalieerkennung, Condition Monitoring und Predictive Maintenance während des Produktionsbetriebes genutzt werden. Die Modelle enthalten somit Wissen über die Produkte und über die Produktionssysteme und deren Parameterkonfiguration. Hier wird sichtbar: Es zeigen sich insbesondere zur Bewertung der IT Sicherheit neue Aspekte, die sich aufgrund der Bildung von I4.0-Wertschöpfungsketten ergeben.

4. Risikoanalyse des Industrie 4.0 Use Case Szenarios Aspekte der IT Sicherheit werden in AG3 der Industrie 4.0 Plattform bearbeitet. Der Fokus aktueller Arbeiten liegt zunächst auf der Darstellung technischer Aspekte zu den Themen sichere unternehmensübergreifende Kommunikation und Sichere Identitäten. Ein Modell zur Bewertung eines I4.0 Szenarios ist nicht Gegenstand aktueller Arbeiten. Dieser Beitrag bezieht sich daher auf den aktuellen Stand der Wissenschaft und Technik. Zur Berücksichtigung von IT Security im gesamten Lebenszyklus von industriellen Lösungen hat sich bis heute die VDI/VDE Richtlinie 2182 etabliert, die ein allgemeines Vorgehensmodell definiert. Auf internationaler Ebene fokussieren sich die Arbeiten an der Spezifikation der IEC 62443. Die IEC 62443 besteht aus mehreren Teilen und hat demnach im Vergleich zur 2182 einen größeren Detailierungsgrad. Dieser Beitrag wendet zunächst das Vorgehensmodell der VDIVDE 2182 auf das skizzierte Use Case Szenario an. Konkrete technische und organisatorische Schutzmaßnahmen liefert die 2182 jedoch nicht. Hier setzen die IEC 62443 und auch der BSI Grundschutz an. 4.1. Vorgehensmodell für eine Risikoanalyse Für eine Risikoanalyse ist zunächst ein Vorgehensmodell auszuwählen. Hierzu wird die VDI/VDE Richtlinie 2182 herangezogen [8]. Sie beschreibt für Hersteller, Integratoren/Maschinenbauer und Betreiber, wie IT Security im Lebenszyklus berücksichtigt wird und wie man zu einer wirtschaftlichen Lösung gelangt. Das Modell, welches in Bild 3 dargestellt ist, definiert dabei acht Schritte, die als iterativer bzw. kontinuierlicher Prozess zu sehen sind.

Zyklisch Trigger Start (Strukturanalyse) Assets identifizieren Bedrohungen analysieren Prozessaudit durchführen Prozessdokumentation Relevante Schutzziele ermitteln Schutzmaßnahmen umsetzen Risiken analysieren und bewerten Schutzmaßnahmen auswählen Schutzmaßnahmen aufzeigen & Wirksamkeit bewerten Bild 3: Vorgehensmodell der VDI/VDE Richtlinie 2182 [8] 4.2. Detailierung des Use Cases Bild 1 skizziert grob eine I4.0-Anwendung, die als Basis für eine Risikoanalyse herangezogen werden soll. Dazu ist der Use Case aus Abschnitt 3 zu konkretisieren, um die Konnektivität und die damit verbundenen Datenflüsse beschreiben zu können. Bild 4 reduziert daher die allgemeine I4.0-Anwendung aus Bild 1 auf einen spezifischen Anwendungsfall, konkret einer Condition Based Maintenance Anwendung. Diese Anwendung wird über eine externe Logik (Cloud-Dienst) dem Anlagenbetreiber zur Verfügung gestellt. Die Logik liest Rohdaten oder bereits aggregierte Daten eigenständig von einem Smart Sensor ein und führt eine anschließende Datenanalyse durch. Im konkreten Fall geht es um eine Parameterüberwachung mit dem Ziel, anhand von z.b. der Anzahl von Kalibrier-/Reinigungszyklen, Dauer der Prozessbelastung, Wartungsintervallen, Prozess- und Umweltparametern eine zustandsorientierte Wartung (engl. Condition Based Maintenance) durchzuführen. Diese Maintenance- Logik bedarf einiges an Expertenwissen und insbesondere über die Anwendung. Ein Hersteller von Software-Lösungen bietet dieses Expertenwissen als Cloud-Dienst zur Verfügung. Dieser Dienst wird von einem Cloud Service Provider gehostet. Dabei bestehen Multipunkt- Verbindungen, die von einem oder mehreren Internet Providern realisiert werden. Bild 4 zeigt fünf Kommunikations- und Vertragspartner.

Hersteller Smart Sensor Internet Provider Anlagenbetreiber Firmware Betriebsanleitung Verwaltungs schale Internet Smart Sensor Anlage A Software App Condition Based Maintenance Hersteller Maintenance Logik Cloud Service Provider Bild 4: Konkreter Use Case eines externen Maintenance Services unter Verwendung eines Cloud Dienstes 4.3. Ermittlung des Schutzbedarfes anhand identifizierter Assets Zur Bestimmung des Schutzbedarfes sind zunächst die Assets zu ermitteln. Für den Smart Sensor-Hersteller sind das: Verfügbarkeit der OPC UA-Schnittstelle, Integrität der Smart Sensordaten, Vertraulichkeit aller internen Daten (insbesondere die Firmware als Know-how Schutz). Für den Maintenance Logik-Hersteller sind das: Verfügbarkeit der Logik, Integrität der Ergebnisdaten, Vertraulichkeit aller internen Daten (insbesondere die Logik als Knowhow-Schutz). Für den Anlagenbetreiber sind das: Verfügbarkeit der Anlage. 4.4. Analyse von Bedrohungen und bestehenden Risiken Der in Abschnitt 3.1 und 4.2 definierte Use Case, eine I4.0 Anwendung, ist in einer ersten Näherung vergleichbar mit einer externen Verbindung (z.b. zur Fernwartung), wobei es sich heute bei klassischen Fernverbindungen meist um Punkt-zu-Punkt-Verbindungen handelt. Dieser Use Case ist eine Multi-Punkt-Verbindung über das Internet. Der klassische Fernzugriff ist nach der BSI Studie [12] TOP10 Bedrohungen für ICS die Nr. 5 der Bedrohungen. Dabei führt das BSI folgende Bedrohungspotenziale auf: 1. Direkter Angriff auf einen externen Zugang (z. B. mittels Brute Force Attacke auf passwortgeschützte Zugänge, etc.)

2. Indirekter Angriff über die IT-Systeme des Dienstleisters, für den der externe Zugang geschaffen wurde (z. B. Trojaner, welcher den Zugang direkt auf dem externen Wartungsrechner ausnutzt, o.ä.) 3. Ausnutzung von unbekannten Schwachstellen oder sogenannten Zero-Day Exploits, die unbekannte Angriffsvektoren ohne Erkennungsmöglichkeiten ermöglichen 4. Komponenten werden durch nicht-zielgerichtete Schadsoftware (z. B. Würmer) infiziert und in ihrer Funktionalität beeinträchtigt. 5. Eindringen in benachbarte Netzwerke bzw. Netzwerksegmente (z.b. in das Office Netzwerk) Darüber hinaus werden diese Bedrohungen durch Cloud-spezifische Aspekte erweitert, die nachfolgend auszugsweise aufgeführt sind: 6. Cloud Ressourcen sind nicht in ausreichendem Maße isoliert, sodass physikalische Ressourcen durch virtuelle Maschinen (VM) mehrerer Kunden verwendet werden. Dies kann zu einer nicht autorisierten Offenlegung von kritischen Daten durch Schwachstellen in den VMs führen. 7. Service Level Agreements (SLA) werden von Cloud Service Providern (CSP) nur in standardisierter Form angeboten und ermöglichen keine Anpassung in Bezug auf die Anforderungen, z.b. ist dem CSP die uneingeschränkte Einsichtnahme aller Daten innerhalb seiner Cloud-Infrastruktur gestattet. 8. Anwendung ist stark abhängig von der Verfügbarkeit des Internet Service Providers (ISP) und dessen Infrastruktur, welche nur in geringem Maße beinflussbar ist. Das BSI bewertet die Bedrohungen 1-5 nach einem festen Bewertungsschema. Für das Kriterium Ausnutzbarkeit, das als technischer Sachverstand und benötigter Aufwand definiert wird, wurde die Stufe Moderat gewählt. Um detaillierte Anforderungen und Lösungsansätze der IEC 62443 entnehmen zu können, muss diese vom BSI durchgeführte Bewertung der Bedrohungen auf die IEC 62443 abgebildet werden. Die IEC definiert Security Level (SL), die sich an die Stärke einer Bedrohung orientieren. Hier lässt sich das BSI Kriterium in etwa dem SL2 Niveau zuordnen. SL2 betrachtet Schutz gegen einen absichtlichen Verstoß mit einfachen Mitteln und geringem Aufwand (z. B. Passwort erraten, Virus). Mit dem SL2 als Zielvorgabe, auch als Target SL bzw. SL-T bezeichnet, können nun entsprechende Anforderungen aus der IEC 62443 abgelesen werden. Aus den genannten Bedrohungen können im Wesentlichen zwei Risiken abgeleitet werden: (i) die Offenlegung von kritischen Unternehmensdaten und (ii) die Manipulation von Daten. Die Offenlegung von kritischen Unternehmen erlaubt den Zugriff auf wichtiges Know-how des Unternehmens und kann in Abhängigkeit der offengelegten Information ein sehr hohes

Geschäftsrisiko bedeuten. Die Manipulation von Daten kann genutzt werden, um boshaft Produktqualität zu verschlechtern oder Wartungsaufträge so weit zu verzögern, bis es zu Maschinenschäden kommt. Ein weiteres Risiko besteht in einer eingeschränkten Verfügbarkeit des Dienstes, die im schlimmsten Fall zu einer reduzierten Verfügbarkeit der gesamten Anlage führen kann. Neue Dienste exponieren somit nicht nur die bestehenden Systeme und vereinfachen somit Cyber-Angriffe, sondern sie sind ebenfalls angreifbar und müssen angemessen geschützt werden. 4.5. Identifikation und Festlegung von Schutzmaßnahmen Die Definition von angemessenen Schutzmaßnahmen erfordern die Berücksichtigung der Risikoanalyse und deren Ergebnis. Exemplarisch werden in dieser Arbeit die in Abschnitt 4.4 identifizierten Target Security Level SL-T 2 herangezogen, um spezifische Anforderungen hinsichtlich zu treffender Schutzmaßnahmen auf Geräte- und Systemniveau zu ermitteln. Mögliche Schutzmaßnahmen auf Geräteniveau sind: Die Geräteanforderungen liefert der Teil 3-3, mit dem Beispiel SR 7.1 Schutz gegen Denial-of-Service (DoS) Ereignisse und der Zielgröße SL-T 2 ist nur SR 7.1 RE1 Netzbelastung steuern zu erfüllen. RE1 fordert eine Fähigkeit vom Automatisierungssystem, die Kommunikationsauslastung so zu verwalten (etwa durch eine Beschränkung der Übertragungsrate), dass die Auswirkungen eines DoS- Ereignisses mit Datenüberflutung gemindert werden. Auf Systemebene werden Zones und Conduits definiert (Teil 3-2, aktuell nur als Entwurf verfügbar). Das Schutzniveau orientiert sich nicht an den SLs sondern auf Basis einer High-Level-Risikoanalyse. Auf Betreiberseite liefert diese Analyse auf Basis des Use Cases Condition Monitoring das Asset Smart Sensor: OPC-UA Schnittstelle. Dieses Asset ist eine Geräteschnittstelle des Smart Sensors, der beim Anlagenbetreiber in der Anlage A lokalisiert ist (siehe Bild 4). Mögliche Schutzmaßnahmen auf Systemniveau sind: Anlage A ist eine schützenswerte Zone, ebenso die Zonen des Herstellers Smart Sensor und des Cloud Service Providers (CSP). Zur Umsetzung der systemweiten Schutzmaßnahmen wird das Zones- und Conduits- Modell der IEC umgesetzt. Eine dieser vertrauenswürdigen Zonen stellt gemäß Bild 5 der CSP dar. Hier stellt sich die Frage, wie ein solcher externer Anbieter im Sinne der IEC 62443 eingebunden werden kann? Eine solche Einbindung ist nur auf Basis einer sicherheitsrelevanten Analyse und Bewertung potentieller Service Dienstleister sinnvoll. Hier bietet das Portal Cloud Privacy Checks [14] eine Lösung an, um CSPs systematisch zu evaluieren. Während der Analyse wurde festgestellt, dass bei vielen Anbietern nicht garantiert werden kann, dass die Daten das Land und damit den deutschen Rechtsraum in keinem Fall verlas-

sen. Dies führt zu der Lösung, dass die zu entwickelnde Cloud-basierte Anwendung mit der gerade veröffentlichten Trusted Cloud in Deutschland [13] realisiert wird. Die vom BMWI initiierte Plattform bietet Transparenz für den Cloud-Markt und vergibt unter Verwendung von definierten und transparenten Kriterien das Label Trusted Cloud. Sie ist unabhängig von Anbieterinteressen und unterstützt Anwender im gesamten Lebenszyklus der Nutzung von Cloud Diensten. Diese Trusted Cloud wird daher als trusted Zone gemäß IEC 62443 angesehen. Die Verbindung zur Trusted Cloud bzw. Trusted Zone (CSP) wird über einen bzw. mehrere Conduits realisiert (Bild 5). Die Anforderungen an den Conduit werden ebenfalls im zukünftigen Teil 3-2 definiert. Heute lassen sich diese Anforderungen im Wesentlichen per Service Level Agreement (SLA) mit dem Internet Service Provider festlegen. Hersteller Smart Sensor Internet Provider Anlagenbetreiber Zone (Vendor) Conduit Conduit Conduit Zone (Operator) Zone (CSP) Hersteller Maintenance Logik Cloud Service Provider Bild 5: Anwendung der Zones and Conduits aus der IEC 62443 [6] 5. Zusammenfassung und Ausblick In diesem Beitrag wurde am Beispiel einer Cloud-basierten Produktionsüberwachung das Vorgehensmodel einer Cyber-Sicherheitsanalyse anhand RAMI 4.0 und VDI/VDE 2182 gezeigt. Das Vorgehen hilft bei der Identifikation von Schutzbedarfen spezifischer Applikationen und ermöglicht die Risiko-basierte Auswahl von Schutzmaßnahmen. Das angewandte Vorgehensmodell der 2182 ist in seiner aktuellen Ausprägung sehr generisch und kann daher anwendungsunabhängig eingesetzt werden. Es basiert allerdings weitestgehend und im praktischen Sinne auf der klassischen Automatisierungspyramide, die einen sehr statischen Charakter hat.

Die bisher identifizierten und zukünftigen Industrie 4.0 Anwendungen werden dieses starre, hierarchische Modell Schritt für Schritt ablösen. Das bestehende Vorgehensmodell muss daher ebenfalls in verschiedenen Bereichen angepasst werden, sodass es die neuen Randbedingungen in Industrie 4.0 Anwendungen berücksichtigt. Beispielsweise werden Auftrags- und Produktionsprozesse zunehmend automatisiert abgewickelt und die Systeme agieren in hohem Maße autonom. Die rechtlichen Aspekte (Verträge, Service Level Agreements) müssen daher ebenfalls von den Systemen in hinreichendem Maße adressiert werden. Ein weiteres Beispiel ist die virtuelle Repräsentanz jeder physischen I4.0 Komponente im System, welches durch das Konzept der Verwaltungsschale beschrieben wird. Die enthaltenen Metainformationen beschreiben u.a. die Funktionalitäten der Komponente und die grundlegende Merkmale und müssen daher hinreichend abgesichert werden. Zukünftige Arbeiten werden die identifizierten Herausforderungen von Industrie 4.0 Anwendungen behandeln, die mit dem aktuellen Vorgehen nicht oder nur schwer zu adressieren sind. Dies geschieht unter Einbeziehung der weiteren Entwicklungen im Bereich der Standardisierung und akzeptierter Best Practices.

Referenzen [1] ZVEI: Das Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0), Plattform Industrie 4.0, Mai 2015. [2] Industrial Internet Consortium: Industrial Internet Reference Architecture, http://www.iiconsortium.org, 2015. [3] BMBF-Verbundprojekt: Unbekannte Bedrohungen in Industrienetzen sicher aufspüren (INDI), http://www.vdivde-it.de/kis/sichere-ikt/kritische-infrastrukturen-kritis/indi, 2014. [4] Jasperneite, J.: IT-Sicherheit in der Industrie 4.0. In: Maschinenbau und Metallbearbeitung Deutschland (Kuhn Fachverlag GmbH & Co. KG), Jun 2014. [5] Schriegel, S.; Jasperneite, J.: Anforderungen an Datenschutz und Datensicherheit von Smart Grid-Technologien. In: e&i Elektrotechnik und Informationstechnik, Wien, April 2012. [6] IEC 62443: IT-Sicherheit für industrielle Leitsysteme Netz- und Systemschutz. [7] NIST SP 800-82 Guide to Industrial Control Systems (ICS) Security, NIST, USA. [8] VDI/VDE Richtlinie 2182: Informationssicherheit in der industriellen Automatisierung, Jan 2011. [9] Pethig, F.; Schriegel, S.; Niggemann, O.: Analyse und Diagnose von Echtzeit-Ethernet mit intelligenten Assistenzverfahren, Automation VDI, Baden-Baden, Jul 2014. [10] BSI: Leitfaden IT-Forensik, Version 1.0.1, März 2011. [11] Windmann, S.; Maier, A.; Niggemann, O.; Frey et al.: Big Data Analysis of Manufacturing Processes. In: 12th European Workshop on Advanced Control and Diagnosis (ACD2015), Pilsen, Polan, Nov 2015. [12] BSI: Industrial Control System Security - Top 10 Bedrohungen und Gegenmaßnahmen, Version 1.10, https://www.allianz-fuer-cybersicherheit.de, März 2014. [13] BMWi: Vertrauenswürdige Cloud Services für die Wirtschaft, https://www.trustedcloud.de, 2016. [14] EuroCloud Austria: Cloud Privacy Check, http://www.cloudprivacycheck.eu, 2016.