Office-Lösungen nicht einfach übertragen

Verschlüsseln allein verhindert weder Datenklau noch Sabotage in der Fabrik

23.05.2008 | Autor / Redakteur: Prof. Dr. Frithjof Klasen / Reinhard Kluger

IT-Security in der Automation wird von vielen Unternehmen immer noch nicht ernst genommen. Die Herausforderung ist komplexer als nur eine Firewall, ein Virenschutzprogramm oder eine Verschlüsselungssoftware zu installieren. Wer darüber hinaus Security-Techniken aus dem Office-Bereich ungeprüft auf Industrieanlagen überträgt, handelt grob fahrlässig. Sowohl die Hersteller automatisierungstechnischer Komponenten als auch Integratoren, Maschinenbauer und Anlagenbetreiber müssen IT-Security in der Automation als Gemeinschaftsprojekt verstehen.

Zunehmende Dezentralisierung der Automatisierungsfunktionen prägt derzeit die industrielle Automation. Damit steigt der Kommunikationsbedarf zwischen den einzelnen Automatisierungskomponenten, und es ergeben sich neue Anforderungen an Kommunikationssysteme hinsichtlich Leistungsfähigkeit und Integration. Ein weiterer Trend: der zunehmende Einsatz von Informationstechnologien in der Automation. Hierzu zählen PC-basierte Automatisierungslösungen ebenso wie der Einsatz von Schnittstellentechnologien und Protokollen wie z.B. OPC, XML oder TCP/IP.

Die genannten Technologien sind wichtige Treiber für die Entwicklung von Lösungen in den folgenden Bereichen:

  • Zusammenführung von Technischen Prozessen und Geschäftsprozessen (Vertikale Integration),
  • Einsatz internetbasierter Dienste z.B. im Bereich der Fernwartung,
  • Einsatz von Web-Technologien als Benutzerschnittstelle (Mensch/Maschine-Schnittstelle) und
  • Integration wissensbasierter Dienste (eServices, Computational Services).

Voraussetzung für die Entwicklung und Nutzung derartiger Lösungen ist der Einsatz einer einheitlichen Kommunikationsinfrastruktur. Dieser Umstand führt derzeit zu einer zunehmenden Verbreitung Ethernet-basierter Infrastrukturen in der Automation, die damit die bisherigen Feldbussysteme ablösen. Als Oberbegriff für die (unterschiedlichsten) Ethernet-basierten Lösungen in der Automation hat sich der Begriff Industrial Ethernet etabliert.

Die Trends und die Risiken

Mit der zunehmenden Vernetzung industrieller Produktionsanlagen auf der Basis von Ethernet bis in die Feldebene hinein ergeben sich neue technische Möglichkeiten. Gleichzeitig steigt aber auch das Bedrohungspotential für die Automatisierungssysteme und Produktionsanlagen − und es ergeben sich teilweise unerwartete Bedrohungen.

Das lässt die Bedeutung von IT-Security-Aspekten sprunghaft ansteigen. Bislang war das Bedrohungspotential eher gering, da häufig hersteller- und technologiespezifische Kommunikationsprotokolle eingesetzt und damit eng begrenzte „Kommunikationsinseln“ gebildet wurden. Durch die einheitliche Kommunikationsinfrastruktur wachsen diese Inseln jetzt zu Landschaften zusammen. Störungen und Bedrohungen sind somit nicht mehr auf lokale Bereiche begrenzt und Industrieanlagen sind damit anfällig für alle Varianten der aus der Office-Welt bekannten Sicherheitsrisiken.

Zu den primären Bedrohungen für die automatisierungstechnischen Komponenten zählen dabei insbesondere: Office-Schadsoftware, Fehlbedienungen und Fehlhandlungen der Nutzer sowie gezielte Angriffe.

Lösungen der IT-Welt sind nicht übertragbar

Zur Schadsoftware: Bei der Betrachtung von Risiken verursacht durch Office-Schadsoftware wird aus einer reinen IT-Sicht schnell in Analogie zur Office-Welt die Hauptbedrohung in Form von Viren identifiziert. Die Folge in der Praxis: Anwender in der Automation propagieren vorschnell den Einsatz von Virenscannern und das regelmäßige Einspielen von Security-Patches. Tatsächlich gilt: Diese Lösung der IT-Welt ist aber nicht unmittelbar auf die Welt der Automation übertragbar.

Betrachtet man die Wirkung und die Schutzmaßnahmen gegen Schadsoftware genauer, so ist zunächst zwischen PC-basierten Systemen und Embedded-Systemen zu unterscheiden. Bei PC-basierten Systemen verbietet sich häufig der Einsatz von Virenscannern weil sie eine zusätzliche Systemlast erzeugen, die für die Echtzeitanwendung nicht tolerierbar ist – zum anderen können oder dürfen Security-Patches häufig nicht ohne weiteres eingespielt werden.

Bei der großen und zunehmenden Anzahl von Embedded-Komponenten ist eine Software-Aktualisierung häufig nur durch das ‚flashen’ der Software möglich. Wichtig ist in diesem Zusammenhang, dass die Wirkung von Office-Schadsoftware auf diese Komponenten nicht vorhersehbar ist. Office-Schadsoftware ist für bekannte Sicherheitslücken der in der Office-Welt gängigen Betriebssysteme ausgelegt − für diese ist die Reaktion vorhersagbar. Trifft jedoch z.B. ein Wurmangriff auf eine Embedded-Komponente, ist die Reaktion nicht vorhersagbar. Die Erfahrung hat jedoch gezeigt, dass es zu durchaus relevanten Störungen und Systemausfällen kommen kann.

Sicherheit wird vernachlässigt

Zu Fehlbedienungen: Eine der häufigsten Ursachen für Störungen liegt in der Möglichkeit ungewollter, unberichtigter Zugriffe auf Systemkomponenten, z.B. durch Fehladressierungen. Fehlparametrierungen oder Fehlprogrammierungen sind die Folge. Neben zahlreichen organisatorischen Maßnahmen sind technische Lösungen durch zusätzliche Authentifizierung und benutzergerechte Mensch-/Maschine-Schnittstellen anzustreben.

Zu gezielten Angriffen: Die in der Automation eingesetzten Protokolle und Dienste sind – ebenso wie die Protokolle der IT-Welt – grundsätzlich angreifbar. Erschwerend kommt hinzu, dass insbesondere im Bereich des Nutzdatenverkehrs keine verschlüsselte Datenkommunikation eingesetzt wird − und aus Performance-Gründen auch nicht eingesetzt werden kann. Insbesondere Funktionsstörungen lassen sich daher mit relativ geringem Aufwand verursachen, wenn sich ein Angreifer Zugang verschaffen kann. Aktuelle Lösungen basieren häufig auf Zonenkonzepten, die von sicheren Netzbereichen (Zonen) ausgehen. Innerhalb dieser Zonen wird sichergestellt, dass kein unautorisierter Zugriff erfolgen kann.

Trotz dieser Situation existieren zahlreiche Sicherheitskonzepte in vielen produzierenden Unternehmen häufig nur für das Office-Netzwerk. Auch die im Rahmen von Basel II durchgeführten Ratings betrachten meist nur die Sicherheit der Business-IT; nicht aber die Sicherheit der Produktionsnetze. Selbst das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat erst vor Kurzem eine erste Empfehlung für den Betrieb von vernetzten Prozesssteuerungssystemen veröffentlicht.

Doch auch die Unternehmen, die sich Gedanken über die Sicherheit ihres Produktionsnetzes machen, unterliegen zunächst häufig einer Fehleinschätzung. Sie beauftragen zunächst die IT-Abteilung mit der Erstellung eines Sicherheitskonzeptes. Doch bei näherer Betrachtung zeigt sich sehr schnell, dass die in der Office-Umgebung gewachsenen Security-Konzepte nicht einfach auf die Produktion übertragen werden können. Viel zu unterschiedlich sind die Anforderungen an Sicherheitskonzepte, -maßnahmen und -produkte. Hier zeigt sich, dass die Technik schneller zusammenwächst als die Menschen in den Unternehmen. Aber nur gemeinsame Ansätze sind erfolgversprechend − die IT-Abteilung und die Produktion gehören hierzu an einen gemeinsamen Tisch.

Anwendungsszenarien gibt es zahlreiche

Der Einsatz einheitlicher Infrastruktur und die Verwendung von IP-basierten Diensten in Geräten und Systemen der Automatisierungstechnik ermöglicht eine direkte Ende-zu-Ende-Kommunikation mit allen Bereichen der Automatisierungspyramide. Damit sind die Nutzungsszenarien und technischen Randbedingungen für den Einsatz von Komponenten der Automatisierungstechnik äußerst vielfältig. So ist es etwa denkbar, mit einem Visualisierungssystem der Betriebsführungsebene über die gleichen Kommunikationsmechanismen auf die Prozessdaten zuzugreifen, wie man das mit einem Vor-Ort-Bediengerät kann.

Welche Kommunikationsbeziehungen tatsächlich zugelassen werden, hängt von der gewählten Architektur und Lösung des Anwenders ab – und den Möglichkeiten der eingesetzten Automatisierungskomponenten. Hier liegt erfahrungsgemäß der größte Klärungsbedarf. Denn woher weiß der Anwender, wofür der Hersteller sein Produkt auslegte − und woher weiß der Hersteller, wofür und wie der Anwender das Produkt einsetzen wird? Schnell kommt es zu möglichen Missverständnissen wie das folgende Beispiel zeigt: nur weil ein Gerät über ein Web-Interface verfügt, bedeutet dies noch nicht, dass es auch für Fernwartungszwecke im firmeneigenen Intranet oder gar im Internet eingesetzt werden kann.

Nicht alle Hersteller liefern mit ihren Geräten umfassende Informationen über die eingesetzten Protokolle, Dienste und Kommunikationsmechanismen. Allzu häufig ist der Systemintegrator oder Anwender gefordert, die Eigenschaften mit Reverse-Engineering Methoden zu ermitteln.

Aber auch eine vollständige technische Beschreibung mit ‚Data Security Sheets’ und ‚Environmental Requirements’ wie sie zunehmend von den Herstellern bereitgestellt werden, löst nicht alle Probleme. Denn Produkte und Technologien sind weder das alleinige Problem noch die alleinige Lösung.

Schnell wird die Forderung nach ‚sicheren’ Automatisierungskomponenten laut und Herstellerkonzepte wie ‚designed for security’ unterstützen diese Erwartungshaltung beim Kunden. Sicherlich sind die in den letzten Jahren eingesetzten Methoden und Testverfahren für die Prüfung der Security-Eigenschaften von Geräten und Systemen auch verfeinert worden − eine Absicherung kann aber letztlich nie am einzelnen Gerät erfolgen.

Hier sind Lösungen gefragt, die sich am jeweiligen Anwendungsfall orientieren und in eine unternehmensspezifische Gesamtlösung integrieren. Ein systematischer, auf das tatsächliche Gefährdungspotenzial abgestimmter Ansatz ist daher erforderlich, der Personen, Prozesse und Produkte gleichermaßen berücksichtigt und damit zu einer Lösung führt, die aus organisatorischen und technischen Maßnahmen besteht.

Lösungswege in der Praxis

Der VDI/VDE GMA-Fachausschuss „Security“ hat sich dieses wichtigen Themas angenommen und einen derartigen prozessorientierten Ansatz für die Entwicklung von Security-Maßnahmen erarbeitet, der alle wesentlichen Aspekte der eingesetzten Geräte, Systeme und Anwendungen berücksichtigt. Das Arbeitsergebnis des Fachausschusses wurde am 1. August 2007 in Form der Richtlinie VDI 2182/Blatt 1 ‚Informationssicherheit in der industriellen Automatisierung’ veröffentlicht. Dabei werden die Sichtweisen von Herstellern, Systemintegratoren und Maschinenherstellern sowie Anwendern gleichermaßen berücksichtigt.

Auf einem prozessorientierten und zyklischen Ansatz basiert das Vorgehensmodell der Security-Maßnahmen nach VDI-Richtlinie 2182.
Auf einem prozessorientierten und zyklischen Ansatz basiert das Vorgehensmodell der Security-Maßnahmen nach VDI-Richtlinie 2182.

Das entwickelte Vorgehensmodell basiert auf einem prozessorientierten und zyklischen Ansatz (Bild 3). Der beschriebene Prozess unterstützt den Anwender des Vorgehens-modells bei der Bestimmung und Validierung einer angemessenen und wirtschaftlichen Sicherheitslösung für einen konkreten Betrachtungsgegenstand. Die Methodik kann sowohl auf bereits existierende als auch auf in der Entwicklung befindliche Betrachtungsgegenstände angewendet werden. Der konsequente Einsatz des Vorgehensmodells führt zu definierten, angemessenen Sicherheitsmaßnahmen und zur Dokumentation der Produkt- und Lösungsmerkmale.

Die Gründung des GMA-Fachausschusses Security geht auf eine gemeinsame Initiative von ZVEI, VDI/VDE, PNO, VDMA und NAMUR zurück. Die Ergebnisse und Erfahrungen beim Einsatz der Richtlinie werden im Rahmen eines Expertenforums am 16. September 2008 in Frankfurt vorgestellt.

Prof. Dr. Frithjof Klasen, Direktor Institut für Automation & Industrial IT der FH Köln. Leiter Zentrum für Webtechnologien in der Automation. Mitarbeit in Gremien von ZVEI, GMA und PNO.

 

Verschlüsseln allein verhindert weder Datenklau noch Sabotage in der Fabrik

 

Verschlüsseln allein verhindert weder Datenklau noch Sabotage in der Fabrik

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 257257 / Jubiläum)