Gibt es die "richtige Sicherheit" für die Industrie? - Wie verschlüsseln für Industrial Security ?

Der zunehmende Einsatz von Informations- und Netzwerktechnik in der Automation führt leider oftmals zu der Einschätzung, dass die für die IT-Welt entwickelten Lösungen auch für vernetzte Produktionsanlagen und Automatisierungssysteme ausreichend sind und ganz einfach auf die Produktionsumgebung übertragen werden könnten. Tatsächlich aber bestehen eine Reihe signifikanter Unterschiede zwischen der Business-IT und der Automatisierungswelt bezüglich der Anforderungen und der dann einsetzbaren Lösungen.

Die wesentlichen Unterschiede:

Echtzeitanforderungen

Bei typischen IT-Systemen steht der Datendurchsatz und die Zuverlässigkeit der Datenübertragung im Vordergrund; Verzögerungen und Jitter in der Datenübertragung sind tolerabel. Dagegen gehören Verzögerungszeit und Jitter bei Automatisierungssystemen zu den leistungsbestimmenden Merkmalen der Echtzeitfähigkeit.

Begrenzte Ressourcen

Automatisierungssysteme verfügen als “embedded system“ nur über begrenzte Ressourcen und können daher gar nicht über die Security-Funktionen verfügen, wie man sie in typischerweise in Office-IT fordert.

Mensch-Maschine-Interaktion

Technische Prozesse müssen in allen Situationen sicher geführt und bedient werden können. Auch in kritischen Situationen müssen die Automatisierungssysteme und Funktionen verfügbar bleiben und dürfen nicht durch organisatorische oder technische Maßnahmen behindert werden.

Security-Ziele

Ein zentrales Ziel der Business-IT ist der Schutz der Daten vor Verlust oder Änderung.
Primär sind die entsprechenden Security-Maßnahmen auf Serversysteme ausgerichtet (Zugriffschutz, Backup, etc.). In Produktionsanlagen herrschen sehr granulare Strukturen mit Anwendungen vor, die sich auf viele Teilkomponenten verteilen.

Verfügbarkeit und Zuverlässigkeit

Viele technische Prozesse erfordern einen kontinuierlichen Anlagenbetrieb und damit einen unterbrechungsfreien Betrieb der Automatisierungssysteme. Das in der IT-Welt übliche Einspielen von Betriebssystem-Patches, kann daher hier nicht unverändert zum Einsatzkommen, da es oftmals einen Neustart des Betriebssystems erfordert.

Netzwerkinfrastrukturkomponenten

Mit Industrial Ethernet wandern auch Netzwerkinfrastrukturkomponenten wie z.B. Switches in die Produktionsanlagen und werden damit Teil der Maschine. Damit verändern sich auch drastisch die Anforderungen an das Netzwerk¬management dieser Komponenten.

Risiken und Sicherheitsanforderungen (Safety)

Die Anforderungen an die funktionale Sicherheit (Safety) von Produktionseinrichtungen und die damit verbundenen Risiken unterscheiden sich gravierend von den Risiken, die üblicherweise von der Business-IT betrachtet werden. Risikoanalysen sind daher nicht übertragbar und führen in der Regel auch zu anderen Security-Lösungen.

Industrietauglichkeit

Viele Hardware-Komponenten aus der Office-Welt sind niemals für den rauhen Einsatz in der Industrie vorgesehen gewesen und können den dort vorherrschenden Bedingungen auch nicht standhalten.

Verfügbarkeit

Die Business-IT lebt von einer extremen Innovation - viele Produkte sind nur eine sehr übersichtliche Zeitspanne verfügbar. In der Produktion ist das kontraproduktiv - teilweise sind Produktionsmaschinen mehrere Dekaden im Einsatz, Ersatzteile müssen zwingend über den ganzen Einsatzzeitraum zur Verfügung stehen.

Trotz der dargestellten Unterschiede zur Business-IT lassen sich Teile der bewährten Methoden und Technologien bei entsprechender Anpassung durchaus übertragen – vorausgesetzt die jeweiligen Schutzziele und Einsatzszenarien werden berücksichtigt.
Voraussetzung ist hier jedoch eine abgestimmte Vorgehensweise zwischen IT-Abteilung und OT-Abteilung (Produktion) sowie eine klare Aufteilung der Verantwortungen.
Allerdings ist ein gegenseitiges Verständnis für die jeweiligen Kenntnisse, Erfahrungen und Fähigkeiten zwischen den beteiligten Abteilungen eher selten. Zu verschieden sind häufig auch die Prioritäten und Ziele, von der gewachsenen Strukturen sowie deren Erfahrungen mit Lieferanten in den beteiligten Abteilungen ganz zu schweigen.

Die IT-Abteilung hat bereits vielfach gelernt, dass ein einziger Hersteller gar nicht in der Lage ist, für alle internen Anforderungen oder Probleme eine passende Lösung bereitzustellen. Dies ist der Grund, warum es beispielsweise zum Thema IT-Security weltweit etwa 3.500 Anbieter gibt.

Industrielle Anwender hingegen verlassen sich noch oftmals darauf, dass sie fertige Lösungen geliefert bekommen – auch hinsichtlich Security und Schwachstellenmanagement - eng verbunden mit der Diskussion um IT-Security ist nämlich auch die Frage nach den Eigenschaften und möglichen Schwachstellen von Geräten und Systemen der Automatisierungstechnik.
Dem Begriff "Schwachstelle" kommt eine sehr vielschichtige Bedeutung zu: Was aus Automatisierungssicht eine sinnvolle Eigenschaft darstellt (etwa die Möglichkeit, mit einem Programmiergerät ohne Authentifizierung auf eine Steuerung zugreifen zu können) erscheint aus Security-Sicht als potentielle Schwachstelle.

>>>  Grundsätzlich lassen sich also Schwachstellen in mehrere Kategorien einteilen:

Konzeptionell geplante und akzeptierte Schwachstellen Hierzu zählen also alle „Features“, die sich ggf. auch für Angriffszwecke nutzen lassen. Also z.B. auch ein integrierter Webserver in einem Automatisierungsgerät.

Konzeptionelle Schwachstellen, die sich offenbaren, wenn Geräte und Systeme in einer veränderten Umgebung eingesetzt werden (z.B. wenn aus der lokalen Programmierschnittstelle eine netzwerkweit verfügbare Schnittstelle wird).

Schwachstellen aufgrund von Fehlimplementierungen i.e. fehlerhaftes Verhalten eines Gerätes

Schwachstellen aufgrund (fehlender) organisatorischer Maßnahmen

Kenntnisse über derartige Eigenschaften sind wesentlich, um Risiken abschätzen und angemessene Security-Lösungen entwickeln zu können.

Lösungsansätze

Diese konzeptionellen Schwachstellen trifft man aktuell in der Automatisierungstechnik sehr oft an. Dies kann und soll nicht verwundern und muss auch nicht beunruhigen - es hängt einerseits mit den begrenzten System-Ressourcen von Automatisierungskomponenten zusammen und andererseits mit den gewünschten Produkteigenschaften und den Schutzzielen, die bislang verfolgt wurden.
Praktisches Beispiel: Automatisierungsprotokolle übertragen ihre Prozessdaten im Echtzeitbetrieb unverschlüsselt. Dies ist eine potentielle Schwachstelle, aber nur, wenn es darum geht, ein "Abschnorcheln" der Daten zu verhindern. Nur wenn dieses Schutzziel erreicht werden soll, wäre also auch eine entsprechende Schutzmaßnahme erforderlich.

Ergo: Es geht nicht von jeder Schwachstelle unmittelbar eine Gefährdung aus und es ist wichtig, die Schutzziele zu klären, bevor man Schutzmaßnahmen implementiert.

Allerdings ändert sich das alles gerade mit der Digitalisierung. Auch zweitrangige Schwachstellen der OT rücken bei einem Digitalisierungsprojekt in den Fokus und können Auswirkungen haben, welche es vorab zu klären gilt.

Die vorrangigen Schutzziele der IT lauten:

  • Vertraulichkeit (Daten stehen nur autorisierten Benutzern zur Verfügung)
  • Verfügbarkeit (geforderte Funktionen oder Daten werden bereitgestellt)
  • Integrität (keine unautorisierte Änderung der Daten)

Die Eigenschaften dieser drei Schutzziele beziehen sich dabei immer auf ein Asset, worunter man ein materielles oder immaterielles Objekt versteht, das schützenswert ist (z.B. die Daten auf einer Kommunikationsverbindung oder der Programmcode in einer Steuerung). Für ein Asset gelten nicht immer alle drei Schutzziele gleichzeitig.

In der Welt der Automatisierungstechnik hat das Schutzziel Verfügbarkeit die allgemein wichtigste Bedeutung, da hierüber die eigentliche Funktion der Automatisierungslösung sichergestellt wird. Ganz im Gegensatz zur Business-IT, bei der das Schutzziel Integrität der Daten die wichtigste Rolle spielt.

Jetzt darauf zu hoffen, die oben aufgeführten Schutzziele der IT in OT außer Acht lassen zu können, ist bei einem total vernetzten Unternehmen fast schon fahrlässig. Auch historische Daten und möglicherweise heute noch eher unwichtige Daten werden in aktuell noch gar nicht bekannte Systeme morgen vielleicht schon einfließen, so dass auch hier Vertraulichkeit und Integrität der Daten heute bereits oberste Priorität haben, bevor überhaupt die Möglichkeit einer Manipulation aufkommt - das Management oder gar eine KI wird wegweisende Entscheidungen aufgrund dieser Daten treffen!

>>> NICHT ALLE HERSTELLER LIEFERN DERZEIT MIT IHREN MASCHINEN UMFASSENDE INFORMATIONEN ÜBER DIE EINGESETZTEN PROTOKOLLE, DIENSTE UND KOMMUNIKATIONSEIGENSCHAFTEN BEZÜGLICH SECURITY. Häufig ist der Systemintegrator oder gar der Anwender selbst gefordert, die Eigenschaften mit aufwändigen Testverfahren selbst zu ermitteln, sofern nicht gar vertragliche Regelungen dies sogar verbieten (Verbot von Reverse-Engineering!).
Dies ist aber im normalen Betrieb während der Produktion eigentlich gar nicht zu realisieren - es verwundert also nicht, dass die Forderung nach "sicheren" Automatisierungskomponenten steigt. Diese Forderung kann und wird aber so nicht erfüllbar sein, denn Produkte und Technologien sind weder das alleinige Problem noch die alleinige Lösung. Auch die immer wieder vorgebrachte Security-Zertifizierung von Geräten ist daher auch wenig sinnvoll, da sich sowohl die Randbedingungen als auch die Bedrohungslagen zu schnell ändern.

Aktuell erscheint mit heutigem Wissen nur eine vernünftige Möglichkeit, diese Anforderungen halbwegs alle mit einer wirtschaftlich vertretbaren Maßnahme zu vereinen - flächendeckender Einsatz von Kryptographie. Doch wer hier gleich panisch an Zertifikate und große PKI-Umgebungen denkt, kann beruhigt sein. Oftmals bieten die zugrundeliegenden technischen Komponenten die Möglichkeit, komplexe Materie ressourcenschonend zu vereinfachen. Zertifikate sind beispielsweise nicht immer ein Mittel zum Zweck, sondern oftmals reicht ein intelligent konstruiertes Schlüsselmanagement vollkommen aus, - es kommt auf die Anforderung an.

Nur damit lassen sich die primären Bedrohungen für die automatisierungstechnischen Komponenten wie Office-Schadsoftware, unbeabsichtigte Fehlbedienungen und Fehlhandlungen der Nutzer sowie gezielte Angriffe eliminieren, ohne die neuen technische Möglichkeiten/Vorteile der Digitalisierung außen vor zu lassen.

Nun ist es leider nur so, dass genau der Bereich Verschlüsselung und Zertifikate zum teuersten und kompliziertesten Bereich in der IT zählt. Natürlich wäre ein ausgewachsenes Hardware Security Modul an jeder Produktionsmaschine oder einem Edge-Device wünschenswert, um anfallende Schlüssel zu verschlüsseln und die Zertifikate zu verwalten - technisch ungeklärt bei diesem oftmals aufkommenden Wunsch ist nur noch, wie die Produktionsmaschine bzw. ein Edge-Device überhaupt eine Verschlüsselung anstoßen soll. Und natürlich ist es wirtschaftlich gar nicht machbar in Anbetracht der Kosten dieser Geräte. Ganz davon abgesehen - wo sollen denn auf einmal all die Krypto-Experten für OT herkommen, welche bereits in IT händeringend gesucht werden?

Eine charmante und preisgünstige Lösung zu dem Dilemma - welche auch von den etablierten Embedded-Programmierern aus OT beherrscht werden kann -  liefert nun die sematicon AG aus München mit ihrer Produktserie se.SAM. Daneben verfügen die Experten von sematicon über branchenübergreifendes Knowhow aus Industrie und IT und bieten somit ein derzeit in Deutschland einzigartiges Produktportfolio an. sematicon ist DER Partner wenn es um Kryptographie in Embedded-Systemen geht oder darum, den Zugang zu Anlagen (Fernzugriff) abzusichern (siehe sematicon se.MIS).

Daten letztmalig aktualisiert am 02.09.2019 © Peter S. Bachl

Interessiert an mehr Information? Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Partner | Referenzen
  • gieseckedevrient.gif
  • AIRBUS.png
  • TDT-AG.JPG
  • BAYER.png
  • tuev-nord.jpg
  • Exponet Infrakon 4c.png
  • commerzbank.gif
  • 1_LOGO_VARONIS.png
  • dlr.png
  • 1_LOGO_FARSITE.png
  • 1_LOGO_Avalara.jpg
  • sbb.gif
  • NXP.png
  • netcologne.gif
  • deutschepost.gif
  • Postbank.jpg
  • 1_LOGO_VEEAM.png
  • 1_LOGO_SSH.png
  • Tsystems.gif
  • hvb.jpg