IT-Sicherheit in cloudbasierten Produktionslösungen

Use-Cases aus der Sicht der IT-Security

Das BMBF-Projekt Picasso hat das übergeordnete Ziel eine industrielle Steuerung in die Cloud zu verlagern. Dazu ist es erforderlich, Kommunikationskanäle über zum Teil offene Netze zu bilden und Daten zu übertragen. Die Steuerungsmodule, die Datenspeicherung und die möglichen Mehrwertdienste sind nicht mehr lokal in der Anlage bzw. im Werk gespeichert, sondern befinden sich auf externen Rechnern in der Cloud.


In den letzten Jahren ist die Anzahl und die Qualität von Angriffen auf industrielle Anlagen stark gestiegen. Im Jahr 2014 hat beispielsweise ein Angriff auf einen Hochofen in Deutschland zu massiven Beschädigungen und einem längeren Stillstand der Anlage geführt. Die vorhandenen Sicherheitsmaßnahmen in der Industrie und das Bewusstsein der Akteure für dieses Thema sind dagegen immer noch ungenügend. Aus diesem Grund gilt es, bei neuen Anwendungsfällen die Anforderungen an IT-Sicherheit sorgsam zu untersuchen und geeignete Sicherheitsmaßnahmen anzuwenden. Die grundlegenden Sicherheitsanforderungen sind dabei:

  • • Datenvertraulichkeit: Die übertragenen Daten dürfen nur den berechtigten Instanzen in Klartext zur Verfügung gestellt werden.
  • • Datenintegrität: Die übertragenen bzw. gespeicherten Daten sind gegen bewusste Manipulation abzusichern.
  • • Datenverfügbarkeit: Die Verfügbarkeit der Daten muss auch bei Ausfall von einzelnen Komponenten gewährleistet sein.
  • • Authentifizierung: Nur berechtigte Instanzen dürfen auf die bereitgestellten Ressourcen zugreifen.

Im Rahmen einer Sicherheitsanalyse definierten die Mitarbeiter des Projektes Sicherheitsmaßnahmen, die für das Erreichen der oben vorgestellten Anforderungen notwendig sind. In einer Risikobewertung stellten sie im zweiten Schritt die definierten Sicherheitsmaßnahmen nach Kosten und Nutzen der Maßnahme gegenüber und bewerteten sie. Das Ergebnis dieser Risikoeinschätzung zeigt die Sicherheitsmaßnahmen, deren Umsetzung zwingend notwendig, zu empfehlen bzw. nicht vordringlich ist. Die im Anwendungsfall als absolut notwendig angesehenen Sicherheitsmaßnahmen sind:

  • • Transportabsicherung: Die während des Transportes über offene Kanäle übertragenen Daten sind durch Verschlüsselungsalgorithmen und kryptografische Prüfsummen vor dem Auslesen und Manipulation zu schützen.
  • • Authentifizierung: Die im System vorhandenen Schnittstellen dürfen nur nach erfolgter starker Authentifizierung mit Zertifikaten oder einer Zwei-Faktor-Authentifizierung benutzt werden.
  • • Rollenmodelle: Die Benutzer im System müssen über feingranulare Rollen voneinander unterscheidbar sein.

Diskussion: Geschlossener Tunnel vs. Zwischenschnittstelle

Als wichtigstes Asset identifizierten die Projektmitarbeiter bei der Sicherheitsanalyse den Kommunikationskanal. Im Rahmen des Projektes wurde die Transportverschlüsselung unter Nutzung eines Produktes des Projektpartners Sotec umgesetzt. Wird der Kommunikationskanal kompromittiert, ist das Gesamtsystem in Gefahr. Hierbei haben die Mitarbeiter des Projektes festgestellt, dass es zwei fundamental unterschiedliche Standpunkte gibt. Ein Standpunkt ist der des Betreibers der Anlage. Es ist in seinem Interesse, dass die Anlage funktioniert, für ihn ist es wichtig, dass der Zugang zur Maschine streng kontrolliert ist, keine unerwünschten Änderungen vorgenommen werden und dass keine unerlaubten Daten abfließen. Für die im Projekt Picasso vorgeschlagene Architektur bedeutet dies, dass der Betreiber sicherstellen muss, dass alle Steuerbefehle vom richtigen Adressaten kommen und dass dieser nicht kompromittiert wurde. Deshalb ist es aus Sicht des Betreibers notwendig, den Datenstrom zu überwachen und somit keine Ende-zu-Ende-Verschlüsselung (E2E) zu erlauben. Demgegenüber steht die Sichtweise des Integrators. Für den Integrator ist die Funktion der Maschine ebenfalls wichtig, doch zusätzlich ist es für ihn essentiel sein Know-how zu schützen. Je nach Funktionsumfang und der konkreten Maschine, enthalten die übertragenen Daten Know-how des Integrators. Deswegen ist es für ihn von großer Bedeutung, dass der Kommunikationskanal E2E-verschlüsselt ist. Erschwerend aus seiner Sicht ist, dass er nicht in der Lage ist, die Infrastruktur vor Ort, beim Betreiber, zu kontrollieren, sodass diese ggf. ein zusätzliches Risiko darstellt.

Anzeige

Argumente für und gegen eine geschlossene E2E-Verschlüsselung

Mit einer vollständigen E2E-Verschlüsselung gibt es nur die Cloud-Instanz als Angriffsziel. Die Maschine bzw. der Industrie-4.0-Konnektor sollten von der IT des Betreibers ausreichend geschützt sein. Im Falle einer unterbrochenen E2E-Verschlüsselung ist der Liaisonserver, der Netzwerkknoten, der die beiden verschlüsselten Tunnel miteinander verbindet, eine zusätzliche Schwachstelle im System. Doch auch dieser Endpunkt ist von der IT des Betreibers geschützt und lässt sich zudem als Sicherheitskomponente absichern. Der Liaisonserver stellt eine zusätzliche Zwischenstelle im Gesamtaufbau dar und erhöht dadurch die Komplexität. Im Gegensatz zur geschlossenen E2E-Verschlüsselung sind zwei Verbindungen aufzubauen und miteinander zu koppeln. Hierzu ist ein erhöhter Aufwand hinsichtlich Synchronisation und Wartung vorhanden, auch ist ein solches Konstrukt bei Weitem fehleranfälliger. Zusätzlich stellt der Liaisonserver aus Sicht des Integrators eine künstliche Man-in-the-Middle-Attacke auf den Kommunikationskanal dar. Eine E2E-Verschlüsselung ist dagegen einfacher zu handhaben und lässt sich vollständig vom Integrator warten. Der Betreiber ist in dem Fall allerdings gezwungen, dem Integrator zu vertrauen, da er keine weiteren Eingriffs- oder Überwachungsmöglichkeiten hat. Dieser Sachverhalt spiegelt sich auch in der Robustheit des Systemes wieder. Eine geschlossene E2E-Verschlüsselung benötigt die richtigen Zertifikate auf beiden Seiten und die Sicherheit, dass diese nicht kompromittiert sind. Geschieht dies doch, insbesondere auf der Seite des Integrators, ist der Betreiber nicht mehr in der Lage einzugreifen. Hier bietet der Liaisonserver einen zusätzlichen Schutz in der Form, dass sich der Datenstrom in Klartext überwachen lässt und gezielt nach Anomalien oder unerlaubten Kommandos gesucht und gefiltert werden kann. Dies setzt jedoch voraus, dass aufseiten des Betreibers eine entsprechende IT-Abteilung vorhanden ist, die in Zusammenarbeit mit dem Integrator Filterregeln erstellt und diese wartet. Eine Alternative zum Liaisonserver sind Change- und Aktionslogs direkt an der Maschine. Hierfür fehlen derzeit noch die notwendigen Voraussetzungen. Für vollständiges Überwachen und Nachverfolgen der Fehler gilt es, im Picasso-Use-Case alle Steuerungsbefehle über einen ausreichend, bisher noch nicht abschließend identifizierten, großen Zeitraum aufzunehmen. Die Logs müssen zudem manipulationssicher gespeichert werden und sowohl dem Integrator als auch dem Betreiber im Bedarfsfall zur Verfügung stehen. Hierfür fehlen derzeit passende Prozesse und Hardware, um Daten detailiert genug aufzunehmen und anschließend auszuwerten. Hier sind insbesondere Hersteller von Steuerungen und Industrie-4.0-Konnektoren gefragt, passende Lösungen anzubieten.

Datenschutz

Hinsichtlich des Datenschutzes sehen die Mitarbeiter des Projekts derzeit keine Probleme. Bei den aufgezeichneten bzw. überwachten Daten handelt es sich um reine Maschinendaten, die Interaktion des Werkers ist in dem Datenaufkommen marginal und enthält daher keine personenbezogenen Daten.

Empfehlungen der Redaktion

Fazit: Ergebnisse aus der Sicht der IT-Sicherheit

Abschließend lässt sich festhalten, dass es keine allgemeingültige Lösung gibt. Ob ein Liaisonserver zum Einsatz kommt oder nicht, hängt davon ab, welche Sicherheitsanforderungen der Betreiber an eine Cloud-gesteuerte Maschine hat, über welche Ressourcen er in seiner IT-Abteilung verfügt und welches Vertrauen er in den Integrator hat. Eine E2E-Verschlüsselung hat den Vorteil eines einfachen Aufbaus und entspricht dem üblichen Verständnis vom Aufbau eines kryptografischen Protokolles. Der Integrator ist hier in der Bringschuld und muss sicherstellen, dass die Verbindung nicht kompromittiert wird. Der Liaisonserver erhöht die Komplexität des Gesamtsystemes, bietet dafür aber auch eine zusätzliche Kontrollinstanz aufseiten des Betreibers. Im Gegenzug ist es Aufgabe des Betreibers sicherzustellen, dass der Liaisonserver nicht kompromittiert wird. Am Ende gilt es, für jeden Anwendungsfall im Einzeln zu entscheiden, auf welche Lösung zu setzen ist. Wichtige Erkenntnis sollte sein, dass es zwei unterschiedliche Lösungen gibt und sowohl Betreiber als auch Integrator diese nach Möglichkeit offen diskutieren.

Anzeige