In heutigen Industrie-4.0-Umgebungen vergrößert sich die Anzahl der Endgeräte in Ethernet- und Industrial-Ethernet-Netzen durch die Einführung neuer IoT- und IIoT-Systeme und computergesteuerter Anlagen sowie durch die Ablösung von Feldbussen durch Industrial Ethernet. Die vorgesehenen Lebenszyklen der meisten Systeme sind weiterhin sehr viel länger als die der Standard-Office-IT-Systeme, die größtenteils nach drei bis fünf Jahren ausgetauscht werden. Jedoch sind die längeren Lebenszyklen der Hardware nicht gleichbedeutend mit langzeitigen Software- und Sicherheitsupdates der betroffenen Systeme. Diesem Umstand begegnet die IT-Sicherheit in den meisten Fällen mit Netzsegmentierung und Kommunikationseinschränkungen auf Basis von Firewalls und anderen Sicherheitsgateways. Um die so geschaffenen Netzsegmente automatisiert zuzuweisen, kann ebenso wie in Office-Umgebungen eine Netzzugangskontrolle (NAC) genutzt werden.
Grundlegende Funktionalitäten
Eine NAC-Lösung bietet die Möglichkeit, die folgenden Ziele zu erreichen:
- Identifizierung aller angeschlossenen Endgeräte
- Zugriffe von Fremdgeräten erkennen, einschränken oder ablehnen
- Automatische Zuweisung von Netzsegmenten mit unterschiedlichen Sicherheitsniveaus und Berechtigungen, zum Beispiel eingeschränkte Kommunikation für Fremdfirmen und Wartungspersonal
Vereinfacht dargestellt präsentiert ein Endgerät dem Netz seine Identität anhand einer entsprechenden Software (EAP-Supplicant) oder der genutzten MAC-Adresse. Diese Identität wird vom Authenticator (Switch oder WLAN-Komponente) an einen zentralen NAC-Server (RADIUS-Server oder NAC-Appliance) weitergeleitet, der die Identität prüft und auf Basis des Authentisierungsergebnisses dem Netz mitteilt, welche Kommunikation für das betreffende System freizuschalten ist (Autorisierung siehe Abbildung 1).
Abbildung 1: NAC-Grundprinzip
Situation in Office-Netzen
In Office-Umgebungen sind NAC-Lösungen immer weiter verbreitet, getrieben vom funktionalen Vorteil bei der automatisierten Zuordnung von Segmenten, von den je nach Implementierung gesteigerten Sicherheitsniveaus durch Authentisierung und Autorisierung oder auch von den Vorgaben durch KRITIS, BSI-Grundschutz oder ISO 27001. Dabei ist oft die Technik nicht die größte Herausforderung bei der Migration, sondern die Anpassung der etablierten Abläufe beim IT-Betrieb. Durch die Einführung der Netzzugangskontrolle ändern sich nicht nur Konfigurationen an Endgeräten und Netzkomponenten, sondern auch die Art und Weise, wie mit IT-Equipment umgegangen werden muss. Zum Beispiel ist die Installation eines neu beschafften Endgerätes auf einmal nicht mehr so trivial, wenn unbekannte Geräte keinen Zugriff zu internen Ressourcen bekommen sollen.
Die Planung und Einführung einer Netzzugangskontrolle ist ein ganzheitliches IT-Projekt, welches nicht nur auf den Schultern der Netzabteilungen lasten kann. Besonders bei Implementierung starker Authentisierung mittels Zertifikate oder anderer Credentials sind die Änderungen an der vorhandenen Endgerätelandschaft nicht zu unterschätzen. Gerade wenn ein zentrales Endgerätemanagement für das Verwalten von Konfigurationen oder die PKI-Integration für das Zertifikatsmanagement nicht oder nur unzureichend implementiert ist, ist hier mit einem gesteigerten Mehraufwand bei den verantwortlichen Teams oder einem verringerten Sicherheitsniveau (MAC-Adress-Authentisierung) zu rechnen. Werden diese Schwierigkeiten jedoch berücksichtigt und neue Abläufe definiert bzw. die aktuellen an die neue Situation angepasst, bietet eine Netzzugangskontrolle den Grundstein für zukünftige Netzarchitekturen wie Controller-basierte Netzlösungen (Software-Defined Networks) und Mikrosegmentierung. Diese bauen häufig auf einer bestehenden IEEE-802.1X- /RADIUS-Infrastruktur auf.
Besondere Situation in Produktionsnetzen
In Produktionsnetzen unterscheiden sich grundlegende Dinge von der Situation in Office-Netzen: angefangen bei der geforderten Verfügbarkeit und den teilweise veralteten Systemen und Sicherheitsmechanismen über die eingesetzten Endgeräte und zentralen Dienste bis hin zum verbauten Netzequipment. Diese Gegebenheiten erzwingen eine abweichende Implementierung von NAC-Lösungen in Produktionsnetzen. Dies wird im Folgenden anhand der unterschiedlichen Teilnehmer der NAC-Wirkkette (siehe Abbildung 2), welche jeweils in den nächsten Abschnitten näher thematisiert werden, beschrieben.
Endgeräte
In Produktionsumgebungen sind die fortschreitende Öffnung gegenüber dem Internet und entsprechenden Cloud-Diensten einerseits und der Einsatz von IoT-, IIoT- oder ähnlichen Systemen andererseits immer weiter verbreitet. Hinzu kommen zum Teil unsichere Software oder unzureichende Software- und Sicherheitsupdate-Intervalle, die dem Lebenszyklus der Systeme entsprechen. Dies erhöht das Sicherheitsrisiko, da dadurch die Möglichkeit entsteht, mithilfe kompromittierter Endgeräte Anlagenteile oder ganze Anlagen zu stören, Datenverlust, einen Produktionsstopp, Qualitätseinbrüche oder sogar physische Schäden zu verursachen. Wenn unsichere Systeme ausgeschlossen werden oder nur noch eingeschränkt kommunizieren können, kann eine Netzzugangskontrolle zur Risikominimierung dienen, bei deren Implementierung die Besonderheiten des Produktionsumfeldes ebenfalls zu berücksichtigen sind.
Die sicherste Authentisierung von Endgeräten ist die Nutzung von EAP-Credentials. Eine EAP-Authentisierung und damit eine Verwendung eines Supplicants ergibt nur Sinn, wenn Credential- und Konfigurationsmanagement zentral durchgeführt werden können.
Für eine erfolgreiche Authentisierung mittels EAP-Methoden muss eine Anlage oder ein anderes Produktionssystem einen IEEE 802.1X-Supplicant installiert und konfiguriert haben. Am besten wird dies zentral verwaltet. Ist eine Zentralisierung der Supplicant-Konfigurationen nicht möglich, kann die Zuweisung zu einem Netzsegment auf Basis der MAC-Adresse durchgeführt werden.
Dies offenbart die besonderen Herausforderungen von Produktionssystemen. Hier gibt es gegebenenfalls weder für jede Endgerätekategorie ein zentrales Management-Tool noch eine PKI-Infrastruktur für die Authentisierung mittels Zertifikate. Zum Beispiel werden oft veraltete Windows-Versionen ohne Active Directory Integration verwendet.
Ebenfalls gibt es keine weite Verbreitung der Unterstützung von IEEE 802.1X auf Bestandssystemen. Wird IEEE 802.1X unterstützt und ein zentrales Konfigurationsmanagement und eine PKI eingesetzt, kann es vorkommen, dass die gegebenen Anforderungen an Zertifikate nicht von den eingesetzten Systemen unterstützt werden. Beispiele sind hier die verwendete Schlüssellänge oder der zwingende Einsatz von TLS 1.2 oder höher. Aus diesen Gründen kommt es in Produktionsumgebungen oft zur Implementierung von NAC-Lösungen mit überwiegendem Fokus auf der Authentisierung via MAC-Adressen.
Abbildung 2: NAC-Wirkkette
Damit dies problemlos umzusetzen ist, werden einfache und übersichtliche Prozesse für die Registrierung von neuen MAC-Adressen im Rahmen von Hardwaretausch und Neuaufbau benötigt. Das kann durch ein Control Center oder durch entsprechende Self-Service-Portale umgesetzt werden. Bei der Migration von NAC sollten Bestandssysteme automatisiert erkannt und nachträglich untersucht werden. Das Ziel solch einer Untersuchung ist es, herauszufinden, ob sich in diesem Pool von Systemen eines befindet, welches keinen Zugriff bekommen sollte. Dies kann auch durch eine Anbindung von vorhandenen Asset-Management-Systemen umgesetzt werden. Die Erfahrung zeigt aber, dass einheitliche Systeme, in denen alle produktionsrelevanten Endgeräte gepflegt werden, oft nicht vorhanden sind.
Beim Einsatz einer NAC-Lösung basierend auf der Authentisierung von MAC-Adressen kommt es ebenfalls zu Limitierungen, wie zum Beispiel:
- Endgeräte ohne selbstinitiierte Kommunikation
Es gibt Systeme, die nur kommunizieren, wenn sie aktiv angesprochen werden, dadurch findet bei ihrem Anschluss oder bei Aktivierung von IEEE-802.1X auf dem entsprechenden Access Port keine MAC-Address-Authentisierung statt. Während einer NAC-Implementierung kann dies dazu führen, dass diese Systeme plötzlich nicht mehr erreichbar sind und die dazugehörige MAC-Adresse nicht automatisiert der Datenbank des NAC-Servers hinzugefügt wird. Somit ist das Endgerät für die Lösung praktisch unsichtbar. Hier empfiehlt sich eine vorherige Analyse der aktiven Systeme, zum Beispiel durch Auslesen der MAC-Address-Tabellen der Switches und ein späterer Abgleich mit den erlernten Daten. Auch nach erfolgreichem Roll-out einer NAC-Lösung kann dies dazu führen, dass neu beschaffte Systeme nicht authentisiert werden und somit nicht mit dem Netz kommunizieren können.
- Kein DHCP
In Produktionsumgebungen kommt es oft zum Einsatz von statischem DHCP oder sogar zu manuellen IP-Konfigurationen. Letzteres ist nicht kompatibel mit automatisiertem Zuordnen zu Segmenten. Im Speziellen, wenn nachträglich Zonenwechsel stattfinden sollen.
- Kaskadierung von Netzequipment
Endgeräte in Produktionsnetzen sind oft nicht direkt mit dem für die Authentisierung zuständigen Port verbunden. Hier gibt es eine Vielzahl von zu verwendenden Anschlussvarianten von Anlagen-Switches / -Firewalls, Unmanaged Switches und Kopf-PCs bis hin zu virtualisierten Maschinen (siehe Abbildung 3). Dies wird im weiteren Verlauf detaillierter behandelt.
Abbildung 3: Anschlussvarianten
Netzequipment
Bei der Einführung einer Netzzugangskontrolle in Produktionsnetzen ist zu klären, wo die Zuständigkeiten für die IT und die OT liegen. Oft werden zentrale Netzsysteme durch die IT betrieben, wohingegen Anlagen-Switches, -Firewalls oder sogar Router inklusive Network Access Translation (NAT) durch die OT betrieben werden. Diese Systeme sind in vielen Fällen Bestandteil einer Anlage und werden durch den Hersteller mitgeliefert. Dadurch entsteht eine Vielzahl von verschiedenen heterogenen Netzsystemlandschaften, die oftmals ohne Netzmanagement betrieben werden. Der Lebenszyklus des Netzequipments ist häufig an den der Anlage gekoppelt, und so kann es zum Einsatz von veraltetem Netzequipment kommen, das Funktionalitäten wie IEEE 802.1X oder Ähnliches nicht unterstützt. Werden IEEE-802.1X-Funktionen unterstützt, kann es aufgrund der verschiedensten Switches zu unterschiedlichen Authentisierungsverhaltensweisen kommen. Daher ist es wichtig, dass jeder Switch-Typ individuell betrachtet, geprüft und konfiguriert wird.
Hier gibt es, ähnlich wie bei den Endgeräten, ein grundlegendes Problem. Netzequipment ist nicht auf dem neuesten Stand, da eine Aktualisierung durch dezentrales Management in einer heterogenen Landschaft aufwendig ist und zu unerwünschtem Verhalten und dadurch zu Ausfällen führen kann. Demgegenüber kann der Einsatz von veralteter Software in Kombination mit Sicherheitslücken jedoch ebenso zu unerwünschten Ausfällen und somit zu Produktionsstopps führen.
Bei der Einführung von NAC in Produktionsnetzen muss geklärt werden, ob die Funktionalität auf den Anlagen-Switches oder auf den höhergelagerten Switches der IT implementiert wird (siehe Abbildung 4). In einigen Fällen wird versucht, die heterogene Netzlandschaft durch homogene, zentral durch die IT verwaltete Switches mit IEEE-802.1X-Funktionalität zu ersetzen (siehe Ebene 2). Dies wird aus Sicht der IT-Sicherheit favorisiert, ist aber in den seltensten Fällen durchgängig möglich. Soll die Authentisierung auf den Anlagen-Switches der OT stattfinden (siehe Ebene 4), müssen die Anlagen-Switches IEEE 802.1X unterstützen. In beiden Fällen kann NAC direkt am Endgeräteanschluss wirken. Ist dies wegen der heterogenen Infrastruktur oder der möglicherweise unzureichenden IEEE-802.1X-Funktionalität nicht der Fall, muss die Funktionalität auf der nächsthöheren Netzebene implementiert werden (siehe Ebene 1).
Aus den beschriebenen Besonderheiten ergeben sich einige spezifische technische Anforderungen an das Netzequipment:
- Multi-Authentication
Die genutzten Switches auf Ebene 1 müssen an einem Access Port mehrere Authentisierungssitzungen individuell handhaben können (Multi Authentication). Dies schließt die individuelle Behandlung einer Sitzung (zulassen oder sperren) sowie die individuelle Zuweisung eines Netzsegments je Sitzung (MAC-based VLAN) mit ein. Besonders beim Einsatz von nicht IEEE-802.1X-fähigen Anlagen-Switches oder anderen nicht remote managebaren Netzkomponenten kommt es vor, dass am eigentlichen Access Port, der für die Authentisierung zuständig ist, mehrere MAC-Adressen sichtbar werden. Beispiele hierfür sind Mini-Switches und Media-Konverter zur Maximierung der Portdichte oder der Reichweite.
- EAP-Forwarding
Zusätzlich sollten die genutzten Komponenten auf Ebene 2 bis 4 EAPoL-Pakete an die nächsthöhere Netzebene weiterleiten können, wenn sie nicht selbst Authentisierungen durchführen können. Ist dies nicht der Fall, kann eine starke Authentisierung mittels EAP-Methode nicht durchgeführt werden.
- Sitzungsterminierung von nicht mehr angeschlossenen Systemen
Switches mit IEEE-802.1X-Funktionalität sollten Sitzungen von nicht mehr angeschlossenen Systemen erkennen und beenden können. Bei Kaskadierung von mehreren Switches kann es vorkommen, dass der für die Authentisierung genutzte Switch das Ausschalten oder Abstecken eines OT-Systems nicht mitbekommt.
- Unsichtbare Systeme
Beim Einsatz von Anlagen-Routern mit und ohne NAT oder Anlagen-Firewalls kann es vorkommen, dass die NAC-Lösung nicht alle Endgeräte erfassen kann, da die MAC-Adressen an den für die Authentisierung zuständigen Ports nicht sichtbar werden.
Alternativ können NAC-Lösungen außerhalb des Rahmens von IEEE 802.1X genutzt werden. Diese Lösungen realisieren die Autorisierung oft über direkte SNMP- oder SSH-Kommunikationen zwischen dem zentralen Server und den Switches für die Umsetzung der Autorisierung. Dies führt jedoch dazu, dass nur portbasiert gehandelt werden kann und somit die gerade beschriebenen Anforderungen nicht umgesetzt werden können. Vor allem der Mehrwert einer automatisierten Segmentierung geht dann verloren, da eine sitzungsbasierte Authentisierung nur mit einer auf IEEE 802.1X basierenden Lösung umgesetzt werden kann. Mittels SNMP kann ein Port nur einem VLAN zugeordnet werden. Ferner kann der Port entweder Verkehr weiterleiten oder Kommunikation blockieren. Dies gilt dann für alle dahinterliegenden Systeme. Darüber hinaus müsste auch die Autorisierung mittels SNMP für jede der eingesetzten Netzkomponenten geprüft und umgesetzt werden.
Abbildung 4: Netzdesign und Zuständigkeiten
Sichtbarkeit im Netz durch einen geeigneten NAC-Server
Eines der Projektziele bei der Einführung einer Netzzugangskontrolle ist die Erhöhung der Sichtbarkeit von Endgeräten im Netz. Dies ist gerade in heterogenen Produktionsumgebungen mit der Vielfalt der eingesetzten und oft nicht dokumentierten Systeme sinnvoll und wichtig.
Einige Hersteller von NAC-Servern versprechen eine vollumfängliche Visibility-Lösung, bei der sämtliche Systeme inklusive deren Kommunikationsbeziehungen, der registrierten Benutzer, der eingesetzten Softwareversionen und des Updatestatus des jeweiligen Systems gelistet werden. Darüber hinaus soll eine Einschätzung des Gefährdungspotentials vorgenommen werden können. Dies kann nicht über eine klassische Layer-2-Authentisierung stattfinden und bedarf immer einer weiteren Netzanalyse auf höheren Protokollschichten nach der eigentlichen Authentisierung bis hin zu Informationen, die nur vom Endgerät selber kommen können, also eine Art Agent benötigen. Dies bedeutet, dass die Systeme zunächst zumindest rudimentären Zugang zum Netz erhalten müssen, sodass im Nachgang alle weiteren Informationen ausgelesen werden können.
Klassische, auf IEEE 802.1X basierte Lösungen sehen jede an einem NAC-Port sichtbare MAC-Adresse. Endgeräte, die sich hinter Anlagen-Firewalls, NAT-Routern und Kopf-PCs befinden, sieht die Lösung nicht. Über das RADIUS-Protokoll wird im Normalfall erst einmal nur die MAC-Adresse und, bei EAP-Authentisierungen, die EAP-Identity (Benutzername, Computername oder Zertifikatsname) übermittelt. Benötigt man darüber hinaus weitere Informationen, um die Endgeräte klassifizieren zu können, müssen optionale Funktionen genutzt werden. Diese unterscheiden sich von NAC-Server zu NAC-Server. Nicht alle diese Funktionen sind in Produktionsumgebungen sinnvoll einzusetzen.
Eine davon ist das Profiling. Hier bieten fast alle Hersteller die Möglichkeit, mit erweiterten Lizenzen mehr Informationen über die Endgeräte zu bekommen. Dies ist meist so implementiert, dass der NAC-Server weitere Informationen von Netzkomponenten oder –Diensten erhält oder diese Informationen selbst abfragt. Über DHCP- und DNS-Profiling können die IP-Adresse und der DNS-Name der Endgeräte dem NAC-Server mitgeteilt werden. Problematisch ist dies, wenn viele der eingesetzten Produktionssysteme kein DHCP nutzen und DNS auch nicht zum Einsatz kommt. Über den DHCP-Fingerprint werten die meisten Server Details wie Endgerätekategorie, Hersteller und Betriebssystem aus. Diese Angaben sind jedoch nicht eindeutig und immer abhängig von der auf dem Server gepflegten Datenbank. Von einer automatischen Klassifizierung der Endgeräte und einer dadurch automatischen Zulassung der Kommunikation ohne explizite Freigabe und Bestätigung, dass es sich um ein firmenzugehöriges System handelt, ist daher abzuraten. Diese Funktionen verringern zwar den betrieblichen Aufwand, erhöhen aber das Risiko von Fremdgeräten im Netz.
Eine weitere Möglichkeit ist die Nutzung der Informationen der Netzkomponenten, beispielsweise über CDP, LLDP, Netflow, pxGrid und SNMP. Je nach Netzdesign und eingesetzten Spezialswitches kann es sein, dass durch dieses Verfahren nur vereinzelt Informationen über die Endgeräte gesammelt werden können. Oft ist dies auch wieder auf die IP-Adresse und die MAC-Adresse beschränkt. Einige der am Markt verfügbaren Server können die Endgeräte auch aktiv via Nmap scannen oder via SNMP abfragen. Wird dies zu aggressiv durchgeführt, kann das dazu führen, das Endgeräte überlastet werden und ausfallen können. Die Folge ist, dass diese ihren Dienst einstellen und es dadurch zu Betriebsausfällen kommen kann. Wenn man die Häufigkeit und die Intensität der Abfragen aber auf ein Minimum beschränkt, können so weitere Informationen gewonnen werden.
Neben dem Profiling gibt es auch die Möglichkeit der gezielten Überprüfung des Endgerätezustandes. Hierbei wird analysiert, welches Betriebssystem zum Einsatz kommt, welche Applikationen genutzt werden, wie der Patch-Stand ist und wie das System genau konfiguriert ist. Diese Funktionalität wird unter anderem Compliance Check, Posture Compliance, Health Check oder zu Deutsch Richtlinienüberprüfung genannt. Bei den meisten Lösungen geschieht auch das nach der eigentlichen Authentisierung, also mit zumindest eingeschränktem Zugriff auf das Netz. Einzig Microsoft Network Access Protection (NAP) konnte dies zumindest für Windows-Endgeräte auch während der Layer-2-Authentisierung prüfen. Microsoft hat NAP jedoch zugunsten seiner Cloud-Strategie aufgegeben.
Abbildung 5 zeigt, anders als bei Microsoft NAP, eine stufenweise Überprüfung der Endgerätemerkmale. Zuerst wird die Identität geprüft und eine eingeschränkte Kommunikation ermöglicht. Anschließend wird der Zustand des Systems geprüft und nach einer erfolgreichen Prüfung uneingeschränkte Kommunikation ermöglicht.
Abbildung 5: NAC-Grundprinzip inklusive Compliance Check
Die bei der Richtlinienüberprüfung benötigten detaillierten Informationen können oft nur mittels Agentensoftware ermittelt werden. Diese Agentensoftware ist jedoch für den Einsatz innerhalb der heterogenen Endgerätelandschaft einer Produktion nicht zielführend, da es keine Softwareadaption für eine Vielzahl der eingesetzten Systeme gibt.
Die Verwertung der Informationen für eine Richtlinienüberprüfung ohne Agenten kann über ähnliche Methoden wie beim Profiling stattfinden. Die wirklich interessanten Informationen bezüglich der Endgerätekonfiguration und des Patch-Standes können so jedoch nicht ausgelesen werden.
Gerade spezifische Kommunikation in OT-Netzen kann nur über direkte Analyse des Datenverkehrs erkannt werden. Das aktive Scannen der OT-Systeme kann wie oben beschrieben zu Ausfällen oder Störungen der Systeme führen. Eine Lösung muss somit in der Lage sein, Deep Packet Inspection von OT-Kommunikation durchzuführen. Diese Funktionen überschreiten die Standard-Funktionen einer Layer-2-Authentisierung in hohem Maße, sind je nach Hersteller und passender Infrastruktur aber eine Möglichkeit, die Sichtbarkeit in Produktionsnetzen deutlich zu erhöhen.
Die Richtlinienüberprüfung kann auch als ausgelagerte Funktion betrieben werden, bei der ein Sicherheitssystem außerhalb der NAC-Lösung Informationen über die Endgeräte sammelt und auswertet sowie den entsprechenden NAC-Server über eine Programmierschnittstelle (API) anweist, die Systeme entsprechenden Segmenten zuzuweisen.
Fazit
Eine NAC-Lösung in Produktionsnetzen bietet erhöhte Sicherheit, automatisierte Zonenzuordnung und Sichtbarkeit. Jedoch erschweren die heterogene System- und Netzlandschaft sowie das oft nicht vorhandene zentrale Management die Implementierung einer einheitlichen Lösung. Eine zusätzliche Richtlinienüberprüfung ist im Detail nur möglich, wenn NAC-Lösungen optionale und proprietäre Features bieten, die weit über die Funktionen einer Layer-2-Authentisierung hinausgehen.
Wichtige Punkte dabei sind:• Vereinheitlichung der Netzkomponenten soweit wie möglich
• Zentral verwaltete Anlagen-Switches mit IEEE 802.1X
• Zentrales Management von Endgeräten
• Asset Management
• Oft individuelle Lösung nicht out of the box
