klasen.de Klasen.de
Deutsch [ger] [eng]
Sie befinden sich hier: klasen.de Projekte IT Security / Industrial Security

Industrial Security / IT-Sicherheit in der Produktion

Herausforderungen

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, weil die Systeme und Komponenten in einem Anwendungsumfeld eingesetzt werden, für das sie möglicherweise nicht ausgelegt wurden.

Dies lässt die Bedeutung von IT-Security-Aspekten sprunghaft ansteigen. Bislang war das Bedrohungspotential eher gering, da häufig proprietäre technologiespezifische Kommunikationsprotokolle eingesetzt und damit eng begrenzte “Kommunikationsinseln“ gebildet wurden. Durch die einheitliche Kommunikationsinfrastruktur wachsen diese Inseln jetzt zu Landschaften zusammen. Störungen und mögliche 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, unbeabsichtigte Fehlbedienungen und Fehlhandlungen der Nutzer sowie gezielte Angriffe.

Dennoch: in der industriellen Automatisierung wurde dem Thema Informationssicherheit (IT-Security) in der Vergangenheit nur wenig Beachtung geschenkt. Und in vielen Unternehmen wird das Thema auch immer noch nicht angemessen berücksichtigt.

Blinder Fleck

Sicherheitskonzepte existieren daher in vielen produzierenden Unternehmen häufig nur für das Office-Netzwerk. Auch die im Rahmen von Basel II und KonTraG durchgeführten Assessments betrachten meist nur die Sicherheit der Business-IT jedoch nicht die Sicherheit der Produktionsnetze. Eine Vorgehensweise, die sich zukünftig ändern wird.

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 -technologien.

Unterschiede zur Business IT

Der zunehmende Einsatz von Informations- und Netzwerktechnik in der Automation kann schnell zu der Einschätzung führen, dass die für die IT Welt entwickelten Lösungen auch für vernetzte Produktionsanlagen und Automatisierungssysteme ausreichend sind und einfach auf die Produktionsumgebung übertragen werden können. Tatsächlich aber bestehen eine Reihe deutlicher Unterschiede zwischen der Business-IT und der Automatisierungswelt hinsichtlich der Anforderungen und der einsetzbaren Lösungen.
Auf die wesentlichen Unterschiede wir im Folgenden näher eingegangen.

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 beinhalten daher häufig nicht die Security-Funktionen, wie man sie in typischen Rechnersystemen der Business- und Office-IT antrifft.

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.
Häufig sind die entsprechenden Security-Massnahmen auf die Serversysteme ausgerichtet (Zugriffschutz, Backup, etc.). In Produktionsanlagen herrschen 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 einen Neustart des Rechers 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.


Trotz der dargestellten Unterschiede zur Business-IT lassen sich deren bewährte 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 Produktion sowie eine klare Aufteilung der Verantwortungen.

Die Erfahrung zeigt, dass hier ein gegenseitiges Verständnis für die jeweiligen Kenntnisse, Erfahrungen und Fähigkeiten zwischen den Abteilungen eher selten anzutreffen ist. Zu verschieden sind häufig auch die Ziele, Prioritäten und organisatorischen Randbedingungen.
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.

Schwachstellen

Industrielle Anwender verlassen sich oft darauf, dass sie fertige Lösungen geliefert bekommen – auch hinsichtlich Security. Aber kennen die Hersteller alle Anforderungen und das organisatorische Umfeld beim Anwender? Und wissen die Anwender welche Security-Eigenschaften die Produkte und Lösungen besitzen und unter welchen Randbedingungen diese zum Einsatz kommen sollen? Mit diesen Fragestellungen sind Anwender wie Hersteller zunehmend konfrontiert.

Eng verbunden mit der Diskussion um IT-Security ist daher auch die Frage nach den Eigenschaften und möglichen Schwachstellen von Geräten und Systemen der Automatisierungstechnik.

Dabei kommt dem Begriff ’Schwachstelle’ eine sehr vielschichtige Bedeutung zu:
Was aus Automatisierungssicht eine sinnvolle Eigenschaft darstellt (z.B. die Möglichkeit, mit einem Programmiergerät ohne Authentifizierung auf eine Steuerung zugreifen zu können) erscheint aus Security-Sicht als mögliche Schwachstelle.

Grundsätzlich lassen sich daher Schwachstellen in mehrere Kategorien einteilen:

Konzeptionell geplante und akzeptierte Schwachstellen
Hierzu zählen also alle „Feature“, 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

Die dargestellten, konzeptionellen Schwachstellen trifft man in der Automatisierungstechnik häufig an. Dies darf aber nicht verwundern und muss auch nicht beunruhigen; hängt es doch einerseits mit den begrenzten System-Ressourcen von Automatisierungskomponenten zusammen und andererseits mit den gewünschten Produkteigenschaften und den Schutzzielen, die verfolgt werden.
Hierzu ein Beispiel: praktisch alle Automatisierungsprotokolle übertragen ihre Prozessdaten im Echtzeitbetrieb unverschlüsselt. Dies ist eine potentielle Schwachstelle, aber nur, wenn es darum geht, ein ’Abhören’ der Daten zu verhindern. Nur wenn dieses Schutzziel erreicht werden soll, wäre also auch eine entsprechende Schutzmaßnahme erforderlich.

Dieses Beispiel soll zweierlei verdeutlichen: erstens geht nicht von jeder Schwachstelle unmittelbar eine Gefährdung aus und zweitens ist es wichtig, die Schutzziele zu klären, bevor man Schutzmaßnahmen implementiert.

Schutzziele

Im Bereich der IT-Sicherheit unterscheidet man üblicherweise zwischen den folgenden drei Schutzzielen:

• 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). Dabei müssen für ein Asset nicht immer alle drei Schutzziele gelten.

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 (Daten-) Integrität die wichtigste Rolle spielt.

Aus diesen Betrachtungen geht hervor, dass eine Schwachstelle also nur dann relevant ist, wenn durch sie ein gefordertes Schutzziele verletzt werden kann. Gleichzeitig bedeutet dies aber auch, dass es wenig sinnvoll ist, planlos Security-Massnahmen zu ergreifen und Lösungen zu implementieren, solange die Schutzziele als Anforderung noch nicht definiert und die Schwachstellen nicht bekannt sind. Ansonsten entspricht die Lösung möglicherweise dem bekannten Gartentor, das ohne Einfriedung an der Grundstücksgrenze steht. Selbst im abgeschlossenen Zustand hilft dieses Gartentor nicht gegen Eindringlinge

Bedrohungen und Risikoanalyse

Für die Entwicklung einer Security-Lösung ist neben den Schwachstellen noch ein weiterer Aspekt zu beachten: die mögliche Bedrohung. Denn auch hier gilt, dass eine Schwachstelle solange nicht relevant ist, solange keine Bedrohung vorliegt, die diese Schwachstelle entsprechend ausnutzen kann. Umgekehrt gilt, dass von einer Bedrohung keine Gefährdung ausgeht, wenn keine ’passende’ Schwachstelle vorliegt.

Genau von diesen drei hier dargestellten Aspekten (Schutzzielen, Schwachstellen, Bedrohungen) gehen Risikoanalysen aus, indem sie den möglichen Schadensumfang und die Wahrscheinlichkeit eines Schadensfalls bewerten.

Erst auf Basis dieser Ergebnisse lassen sich angemessene Security-Maßnahmen ableiten, die auch wirtschaftlich vertretbar sind.

Security - ein Gemeinschaftsprojekt

Kenntnisse über Schutzziele, Schwachstellen und Bedrohungen sind wesentlich, um Risiken abschätzen und angemessene Security-Lösungen entwickeln zu können. Nicht alle Hersteller liefern derzeit mit ihren Geräten umfassende Informationen über die eingesetzten Protokolle, Dienste und Kommunikationseigenschaften. Häufig ist der Systemintegrator oder Anwender gefordert, die Eigenschaften mit aufwändigen Testverfahren zu ermitteln.

Kein Wunder, dass die Forderung nach ’sicheren’ Automatisierungskomponenten steigt. Eine vollständige Absicherung kann aber letztlich nie am einzelnen Gerät erfolgen. Denn Produkte und Technologien sind weder das alleinige Problem noch die alleinige Lösung.
Die immer wieder diskutierte Security-Zertifizierung von Geräten ist daher auch wenig sinnvoll. Zu schnell ändern sich die Randbedingungen und die Bedrohungslagen. Security ist kein statisches Gebilde – Lösungen und Maßnahmen müssen dynamisch auf die sich ändernden Anforderungen reagieren.

Security ist ein Gemeinschaftsprojekt – es erfordert daher eine zwischen Herstellern, Integratoren und Betreibern abgestimmte Vorgehensweise.

Die Lösung: Personen, Prozesse, Technologien

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

Richtlinie VDI/VDE 2182
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 beinhaltet. Das Arbeitsergebnis des Fachausschusses wurde Form der Richtlinie VDI 2182 ‚Informationssicherheit in der industriellen Automatisierung’ veröffentlicht. Dabei werden die Sichtweisen von Herstellern, Systemintegratoren und Maschinenherstellern sowie Betreibern gleichermaßen berücksichtigt.

Projektpartner

  • NAMUR
  • PNO
  • VDI
  • VDE
  • VDMA
  • ZVEI

 



 
top