Sicherheitsaspekte industrieller Ethernet-Netze
Schutz durch dezentrale Security
Die Anbindung von Produktionsnetzen per Ethernet gewinnt für viele IT-Administratoren immer mehr an Bedeutung. Dass die zusätzliche Infrastruktur einen besonderen Schutz benötigt, ist den meisten klar. Doch wie gut eignen sich die aus der IT bekannten Sicherheitsmechanismen tatsächlich?
Die Ethernet-Technik, die heute in der Datenkommunikation der Office-Welt dominiert, gewinnt
auch in der industriellen Automatisierung immer mehr an Bedeutung. Die Vorteile liegen zum einen in
einer standardisierten Kommunikation, zum anderen in einer nahtlosen Infrastruktur, die vom
Schreibtisch im Büro bis zur Maschine oder dem Sensor in der Produktionshalle reicht. Damit stehen
Prozess- und Fertigungsdaten nicht nur auf der Feldebene zur Verfügung, sondern auch in
bereichsübergreifenden Datenerfassungssystemen. Diese Entwicklung bedingt nun, dass sich die
Betreiber dieser Netze zunehmend mit Fragestellungen zur Netzwerksicherheit konfrontiert sehen, die
bisher nicht in ihrem Blickfeld lagen. Speziell für den Einsatz im industriellen Umfeld konzipierte
Security-Komponenten sollen für eine Lösung des Problems sorgen.
Die Zahlen sprechen eine deutliche Sprache: Laut einer Studie der ARC Advisory Group aus dem
Jahr 2005 [1] wird die Menge der für den Einsatz in der Automatisierungstechnik neu ausgelieferten
Endgeräte mit Ethernet-Interface bis 2009 jährlich um zirka 50 Prozent wachsen. Wenn sich dieser
Trend so fortsetzt, könnte die Vision einer völligen Ablösung der Feldbussysteme durch Ethernet und
IP in nicht ferner Zukunft Realität werden. Aus derselben Studie geht weiter hervor, dass die
Anlagenbetreiber intensiv nach Lösungen suchen, ihre heute zu einem Großteil noch physikalisch
getrennten Industrienetze mit den Office-Netzen zu verbinden und dennoch logisch und natürlich auch
sicherheitstechnisch zu segmentieren.
Berichte wie zum Beispiel der des British Columbia Institute of Technology (BCIT) und der PA
Consulting Group (PA) aus dem Jahr 2003 [2] untermauern die Notwendigkeit einer
sicherheitstechnischen Trennung mittlerweile mit konkreten Sicherheitsvorfällen aus der Praxis.
Gefahrenquellen und Lösungsszenarien
Die Lieferanten von Maschinen oder Produktionseinheiten wie Druckmaschinen oder Roboterstraßen
stehen vor der Herausforderung, dass ihre Kunden Informationen aus der Produktion in Echtzeit und
damit durch direkten Zugriff auf die Maschine erhalten wollen. Wenn diese Eingriffe in das
Maschinennetzwerk nicht reglementiert werden können, stellen sie jedoch ein hohes Gefahrenpotenzial
dar – vor allem vor dem Hintergrund bestehender Gewährleistungsansprüche.
Auch das Thema Fernwartung gewinnt durch die Integration der Maschinen in die Kundennetze einen
völlig neuen Stellenwert. Waren es in der Vergangenheit oft direkte analoge oder digitale
Telefonverbindungen, die im Prinzip zwei firmeninterne Bereiche verbanden und so dem Techniker
einen Zugriff auf seine Maschine ermöglichten, so muss man heute auch das dahinter liegende
Kundennetz in Betracht ziehen und umgekehrt.
Innerhalb der Firmen ist es in erster Linie die Kopplung von Produktion und Büro, die den
Administratoren Kopfschmerzen bereitet. Durch die Anbindung der bisher isolierten Produktionszellen
an das unternehmensweite Netzwerk und das in der Regel mit diesem verbundene Internet bekommt
plötzlich eine fast unbegrenzte Zahl von potenziellen Angreifern Zugang zu den Fabrikationsnetzen.
Auf der anderen Seite kann man nun von der Produktionszelle aus wiederum auf zentrale
EDV-Ressourcen des Unternehmens zugreifen.
Vor allem die Zugänglichkeit des Netzes für Servicezwecke (Local Access) ist dabei als
Gefahrenquelle zu sehen. In vielen Werken haben beispielsweise externe Mitarbeiter bei Wartungs-
oder Inbetriebnahmeeinsätzen uneingeschränkten Zugang zu nicht genutzten Ethernet-Ports. Noch
dramatischer wird die Situation, wenn für die Fernwartung von Produktionsanlagen bereits
Modem-Verbindungen installiert wurden.
Selbst ein ohne böse Absicht unterlaufener Fehler, wie zum Beispiel ein Zahlendreher bei der
Eingabe der IP-Adresse, kann schon dafür sorgen, dass ein User nicht wie angenommen auf die
Maschine zugreift, die sich direkt vor ihm befindet. Stattdessen führt er über das Netzwerk
unbewusst und unkontrolliert Manipulationen auf einem beliebigen System aus, die fatale finanzielle
oder gar lebensbedrohliche Auswirkungen nach sich ziehen können.
Eine weitere – von eigentlich autorisiertem Personal ausgehende – Gefahr ist die Verbreitung von
Schadsoftware innerhalb der Produktionsnetze. So können zum Beispiel mittels der für Servicezwecke
eingesetzten Notebooks Viren in das Produktionsnetz gelangen. Die Ursache eines solchen Befalls
liegt also im Inneren des Netzwerks. Sicherheitsfunktionen, die am Übergang vom Unternehmensnetz
zum Internet oder auch an zentraler Stelle zwischen Produktionsnetzwerk um Büronetz installiert
sind, nützen in einem solchen Szenario nur bedingt.
In der Office-Welt sind derartige Szenarien meist durch die bestehende IT-Infrastruktur mithilfe
von Firewalls und aktuellen Virenscannern sowie neuesten Betriebssystem-Patches auf sämtlichen
Endgeräten abgesichert. In der Automatisierungstechnik allerdings ist ein durchgängiges
Software-Patch-Management aufgrund unterschiedlicher Betriebssysteme innerhalb einer Anlage und der
langwierigen Freigabeprozesse in den meisten Fällen unmöglich. Auch fehlt vielen
Automatisierungssystemen schlicht die nötige Leistung zur Unterstützung lokaler
Security-Technik.
Lösungsansätze (Beispiel: Hirschmann-Sicherheitsarchitektur [3]) sehen zur Eindämmung der
genannten Sicherheitsrisiken unter anderem eine Unterteilung der Industrienetze in von der
Topologie unabhängige Security-Compartments vor. Die Frage nach der optimalen Größe für ein solches
Compartments oder eine Sicherheitszone ist pauschal nicht zu beantworten. Klar ist, dass eine
einzige Sicherheitslösung am Übergang von Office- und Produktionsnetzwerk in vielen Fällen nicht
hinreichend ist, da ein Großteil der Gefährdungspotenziale im Inneren der Netzwerke liegt.
Das andere Extrem: Der Schutz jedes einzelnen Endgeräts durch eine dort installierte
Security-Software ist in den meisten Fällen jedoch ebenfalls nicht sinnvoll. Gründe hierfür liegen
in der mangelnden Leistung der Endgeräte, den unterschiedlichen Betriebssystemen und
Softwareständen und natürlich auch in der Tatsache, dass der entsprechende Pflegeaufwand für die
Betreiber von Automatisierungsnetzwerken nicht umsetzbar ist.
Eine Security-Lösung ist demzufolge zwischen den beiden oben genannten Extremen zu suchen und
muss auf den jeweiligen Anwendungsfall zugeschnitten sein. Zudem ist die Akzeptanz beider Parteien,
also der IT-Abteilung und des leittechnischen Personals erforderlich.
Grundlegende Voraussetzung bei der Planung von sicherheitsrelevanten Aspekten in das Netzwerk
ist die Kenntnis über die erlaubten Kommunikationsbeziehungen: Wer darf was, wann und wo ist
hierbei die grundsätzliche Fragestellung. Leider sind die von verschiedenen Applikationen oder
Geräten verwendeten Netzwerkdienste und Protokolle im Produktionsumfeld nur in seltenen Fällen
bekannt.
Die IAONA (Industrial Automation Open Networking Alliance) versucht diesem Manko mit dem
Security Datasheet (SDS) zu begegnen. Die Grundidee des SDS ist ein auf jedem in der Produktion
eingesetzten Gerät in Form einer XML-Datei hinterlegtes Kommunikationsprofil. Alle zum Betrieb der
Komponente benötigten Dienste werden so in vereinheitlichter Form dokumentiert und stehen auch den
Security-Administratoren für ihre Planungen zur Verfügung. Um diesen positiven Ansatz weiter zu
forcieren, sind nun die Anwender aufgerufen, eine SDS-Unterstützung auch von ihren
Systemlieferanten einzufordern. Bei bestehenden Anlagen kommt man nach heutigem Stand um eine
Analyse des Datenverkehrs in der Regel jedoch nicht herum, denn es ist zu vermeiden, dass
notwendiger oder gewollter Datenverkehr versehentlich abgeschnitten wird.
Die Hersteller von Hardware und Anbieter entsprechender Lösungen reagieren auf die
Anforderungen: Zur Vereinfachung diese Prozesses aus der Analyse des bestehenden Netzverkehrs und
der anschließenden Erstellung passender Firewall-Regeln bietet Hirschmann in Partnerschaft mit
Innominate einen iterativen und automatisierten Prozess für seine Firewall-Appliance an.
Auch wenn nach einer entsprechenden Analyse alle nicht benötigten Dienste gesperrt werden,
verbleibt natürlich ein Restrisiko hinsichtlich der frei geschalteten Ports. Dieses Risiko hängt
nun wiederum sehr stark von den genutzten Protokollen selbst ab. Allein gelassen muss sich der
Kunde dennoch nicht fühlen: Auch zur Beurteilung dieses Risikos versucht die IAONA entsprechende
Hilfestellung zu geben. Im Rahmen des "IAONA Handbook Network Security" [4] wurde eine Vielzahl der
in der Automatisierung verwendeten Protokolle hinsichtlich ihres Missbrauchspotenzials bewertet.
Die Lektüre zahlt sich sicher aus.
Lesen Sie mehr zum Thema
