Es muss nicht immer ein Industrieroboter oder ein weltumspannendes Netzwerk von Sensoren für proaktive Wartung von Ölförderanlagen sein – OT beginnt bereits mit einer CNC-Fräse, einem Röntgengerät, einer vernetzten Alarmanlage oder der berühmten Kaffeemaschine mit Internetanschluss. Auf den ersten Blick haben diese Vorrichtungen nichts mit der klassischen IT zu tun, die Menschen am Arbeitsplatz hilft, Informationen zu digitalisieren, zu bearbeiten, zu speichern und miteinander auszutauschen. Doch die Protokolle und Dienste, die innerhalb der OT und vor allem als Brücke zwischen IT und OT zum Einsatz kommen, sind die gleichen. Und das eröffnet ein Spannungsfeld, das die Branche viel zu lange ignoriert hat.

Die Entwicklung der klassischen IT ist in erster Linie von Programmierern geprägt. Diese haben sich, wenn auch zum Teil widerwillig, bereits seit Jahrzehnten mit Authentifizierung, Autorisierung und Ressourcenzugriff auf Standardprotokolle wie SMB, LDAP oder SQL befassen müssen. Das bedeutet zwar nicht, dass jedes IT-Produkt zwangsläufig ein Musterbeispiel an sicherem Umgang mit Identitäten und Zugriffsrechten darstellt – tatsächlich hat Microsoft herausgefunden, dass 52 Prozent der NTLM-Authentifizierung in Unternehmen darauf zurückzuführen ist, dass das veraltete Protokoll in Anwendungen hart verdrahtet wurde; es gibt bis heute Branchensoftware, die explizit SMB1 als Dateizugriffsprotokoll fordert.

Doch die Mehrheit der typischen IT-Anwendungen ist mit der Zeit gegangen und verträgt Härtung, Modernisierung und gelegentliche Migrationen der Identitätslandschaft in der Regel ganz gut. Das Risikoprofil von IT-Systemen ist in der heutigen digitalisierten Welt zwar hoch, jedoch ist es bei guter Notfallplanung und Organisation oft möglich, Ausfälle mit anderen Mitteln zu überbrücken. Als die Reederei MAERSK 2017 Opfer der NotPetya-Malware wurde, standen die Terminals zwar im ersten Moment still, die Mitarbeiter haben sich jedoch erstaunlich schnell organisiert und konnten mithilfe von Papierlisten bereits mit der Abwicklung von Logistikvorgängen beginnen, bevor die IT-Systeme wieder ans Netz gingen.

OT-Systeme hingegen entstammen oft dem Reißbrett von Automatisierungsingenieuren. Hier ist Authentifizierung und Autorisierung klassischerweise durch die Physik gelöst – wenn der Techniker beim Aufbau der Anlage den Ausgang A des Steuerungsmoduls mit dem Eingang B eines Antriebsmoduls verbindet, so ist die Absicht klar erklärt, dass hier Daten von A nach B fließen sollen. Nicht selten ist diese Denkweise auch in verteilten OT-Systemen zu finden – die passende Kombination aus IP-Adresse und Zielport kennzeichnet bereits die richtige Kommunikationsbeziehung und eine zusätzliche Authentifizierung oder gar Autorisierung ist nicht notwendig.

In dedizierten OT-Netzen, die sowohl von der Außenwelt als auch von der Bürokommunikation (IT) physisch oder zumindest durch Firewalls abgetrennt sind, ist dies grundsätzlich auch kein Problem. Das Risiko bei Ausfall oder Datenkorruption ist in der OT vollkommen anders gelagert – wenn die Verbindung von der Steuerung zum Antrieb oder vom Kassenterminal zum Hochregallager unterbrochen ist oder das CNC-Programm fehlt oder böswillig verändert wurde, steht die Produktion still, Sensordaten fehlen, und das Chaos ist komplett.

Spannend wird es, wenn OT-Einrichtungen in Netzen laufen, die mit dem Rest der Welt verknüpft sind – und besonders dann, wenn die Netzwerkkommunikation zwischen OT und IT nicht nur technisch möglich, sondern explizit notwendig ist. Aufträge aus der von Menschen bedienten Prozesssteuerung fließen in Echtzeit in Produktion und Logistik, Big-Data-Systeme analysieren das Verhalten von Maschinen und Produkten automatisch und machen die Ergebnisse zur Entscheidungsfindung zugänglich. Plötzlich müssen von Ingenieuren entwickelte, auf Geschwindigkeit und Robustheit hin getrimmte OT-Anlagen in ständigem digitalem Austausch mit von Anwendungsprogrammierern erstellten Softwaresystemen stehen, für die Identität, deren Verifizierung und Zugriffsverwaltung zum Kerngeschäft gehören.

In Bezug auf den Identitätsschutz eröffnet diese Koexistenz einige mögliche Bedrohungsvektoren, deren Ursprung und Ziel sowohl in der IT als auch in der OT liegen können. So verwenden OT-Systeme manchmal keine Identität aus dem IT-Bereich, lassen sich jedoch durch die Netzwerkkonnektivität als Sprungbrett zum Angriff auf IT missbrauchen. Das ist insbesondere dann der Fall, wenn die OT-Systeme ans öffentliche Internet angeschlossen sind – sei es, um Fernwartung durch den Hersteller zu ermöglichen oder durch einen verhängnisvollen Fehler bei der Absicherung von OT-Netzsegmenten. Die Palette von "dummen" Maschinen, die in den letzten zehn Jahren erfolgreich als Einstiegspunkt für Angriffe auf IT dienten, reicht von Druckern über Überwachungskameras bis hin zu automatisierten Produktionslinien.

In anderen Fällen verwenden OT-Systeme wiederum eine Identität aus dem IT-Bereich, um Daten mit IT-Systemen auszutauschen, und diese Identität ist nicht immer ausreichend geschützt. Oft verfügen solche Accounts über viel zu weitreichende Berechtigungen in der IT-Umgebung, insbesondere, wenn die Einrichtung bereits viele Jahre zurückliegt und nicht entlang moderner Best Practices stattfand.

Es kommt auch häufig vor, dass OT-Systeme Identitäten aus dem IT-Bereich verwenden, die durchaus korrekt gemäß dem "Least Privilege"-Prinzip berechtigt sind. Die OT-Systeme verlangen jedoch für die Kommunikation veraltete Protokolle, deren Einsatz im IT-Bereich eigentlich längst vergangene Gefahren neu heraufbeschwört. Die Klassiker sind dabei: SMB1 für Dateiaustausch, SMB1 für Authentifizierung, LDAP ohne Verschlüsselung mit Klartext-Credentials, keine Signierung für SMB und/oder LDAP, SSL 3.0 statt TLS 1.2, NTLM-Authentifizierung. Die Liste ließe sich quasi beliebig fortsetzen.

Veraltete Protokolle machen gerade diejenigen IT-Systeme, die unmittelbar mit der OT-Welt interagieren, besonders angreifbar – und können dadurch wiederum als Sprungbrett für Angriffe auf die OT dienen, nachdem der Angreifer einen Fuß in die Tür des IT-Bereichs bekommen hat. Es wäre fatal anzunehmen, dass Angreifer es immer nur auf digitale Assets abgesehen haben. Angriffe auf kritische Infrastrukturen wie Strom- und Wasserversorgung erzählen eine andere Geschichte. Doch auch innerhalb eines Unternehmens kann eine solche Attacke schwerwiegende Folgen nach sich ziehen. Spielen Industrieanlagen plötzlich verrückt, sind womöglich die Gesundheit und das Leben der Menschen in Gefahr, die Seite an Seite mit den Maschinen in der Produktion tätig sind – oder im Krankenhaus vom Funktionieren medizinischer Gerätschaften abhängen.

In allen Angriffspfaden, die die Grenze zwischen OT und IT überschreiten, spielen Identitäten eine Rolle. Oft sind es Maschinen- oder Serviceaccounts, die den Zugang zur IT-Welt eröffnen oder Lateral Movement und letztendlich Privilege Escalation dort möglich machen. Diese Art von Identitäten genießt in den letzten Jahren eine immer größere Aufmerksamkeit, sowohl seitens der IT-Sicherheitsverantwortlichen als auch der Hersteller von IT-Sicherheitsprodukten. Um diese Art von Konten konzeptionell von klassischen Benutzerzugängen zu unterscheiden, kam sogar ein neuer Begriff ins Spiel: Non-Human Identities (NHI).

Technisch gesehen gibt es zwischen menschlichen und nicht-menschlichen Identitäten mehr Gemeinsamkeiten als Unterschiede. Jede Identität in der IT-Welt ist durch einen Benutzernamen (User-ID) gekennzeichnet. Zu diesem gehört ein Authenticator wie beispielsweise ein Kennwort oder ein Zertifikat, dessen privater Schlüssel idealerweise ausschließlich dem Inhaber der Identität bekannt ist. Dies stellt gleichzeitig einen Unterschied zu der in der Automatisierungstechnik auch heute üblichen Identifizierung von Geräten durch eine Hardware-ID oder Seriennummer dar – ohne einen zusätzlichen Authenticator. Innerhalb der IT-Systeme lässt sich eine solche Identität in Gruppen und Rollen aufnehmen und mit Berechtigungen an anderen Systemen versehen, genau wie eine digitale Identität, die einem Menschen zugeordnet ist. In der klassischen Taxonomie aus der IT ist eine NHI also ein Funktions-, Service- oder auch Computeraccount.

Ein Sonderfall der technischen Umsetzung von NHIs sind API-Keys – meist sind es lange Zeichenfolgen, die ein API bereitwillig gegen einen Access Token tauscht. Hier gibt es zwar keine expliziten, vom Authenticator getrennten Benutzernamen, doch ist innerhalb der berechtigenden Anwendung jedem API-Schlüssel eine Identität zugeordnet. Auf den Quellsystemen werden API-Keys also wie Passwörter verwaltet – möglichst verschlüsselt oder durch Zugriffsrechte geschützt sicher aufbewahrt – beim Zugriff auf das Ziel-API tritt jedoch auch eine User-ID zutage. Auf die Identität des Systems, das Authentifizierung mithilfe eines API-Schlüssels durchführt, gibt der Key selbst jedoch keinen Aufschluss. Hier sind die IP-Adresse, der Agent-String oder ein Cookie gefragt.

In ihrem täglichen Wirken sind NHI auf den ersten Blick "verträglicher" als menschliche Identitäten – sie klicken nicht aus Versehen auf Phishing-Links in ihren E-Mails, sie melden sich nicht auf Endgeräten ihrer Kollegen an, nutzen ihre digitale Identität nicht für private Verrichtungen und fluten die Teams-Kanäle nicht mit den neuesten Urlaubsbildern. Andererseits können Maschinen in der Regel nicht regelmäßig das Kennwort ihres Funktionsaccounts ändern (was fatal wäre, falls ein und dasselbe Konto mehreren Maschinen oder Diensten zugeordnet ist), und Multifaktor-Authentifizierung verstehen sie ebenfalls nicht. Erschwerend kommt hinzu, dass OT-Geräte oft die dort hinterlegten Credentials nicht ausreichend schützen. Doch auch Menschen, die mit der Administration solcher Identitäten betraut sind, gehen mit den Kennwörtern und Zertifikaten oft nicht sorgfältig genug um.

Ein weiterer Angriffsvektor, der aus der menschlichen Komponente der NHI resultiert und sich in letzter Zeit einer großen Aufmerksamkeit sowohl von Angreifern als auch von Administratoren erfreut, ist das Speichern von Zugangsdaten entweder direkt im Quellcode von Anwendungen oder in Konfigurationsdateien. Besonders verschrien sind in diesem Zusammenhang API-Keys, denn diese verfügen oft über keine Gültigkeitsdauer.

Besonders brisant wird es, wenn Credentials in öffentlich zugängliche Repositories wie GitHub, GitLab oder Azure DevOps eingecheckt werden. Dann reichen ein kleiner Glitch im System oder zu liberal vergebene Berechtigungen, damit ein Angreifer solche Repositories klonen kann. Das Perfide dabei: Durch das Wesen der Versionskontrolle sind Geheimnisse, selbst wenn sie seit dem ursprünglichen Check-in entfernt wurden, in einem früheren Commit enthalten. Firmen wie GitGuardian [1] haben ihr Geschäftsmodell darauf aufgebaut, öffentliche und auf Wunsch auch private Repositories auf bekannte Secrets-Formate hin zu scannen und rechtzeitig Alarm zu schlagen.

Bei der Absicherung von Identitäten in einer gemischten IT-/OT-Landschaft ist, wie in einer klassischen IT-Umgebung, die Account- und Berechtigungshygiene das wirkungsvollste Mittel, die Sie als Verteidiger zur Verfügung haben. Nicht zufällig ist eines der maßgeblichen Dokumente, die die kürzlich gegründete Non-Human Identity Management Group veröffentlicht hat, der Lifecycle Management Guide [2]. Einige Disziplinen, die hier aufgeführt sind, tauchen auch im klassischen IT-Betrieb auf:

- Least Privilege, um die Auswirkungen einer Kompromittierung zu begrenzen.

- Rechtzeitiges Deaktivieren und Löschen nicht mehr benötigter Identitäten.

- Rezertifizierung der erteilten und tatsächlich beanspruchten Zugriffsrechte.

- Regelmäßiges Rotieren von Kennwörtern, API-Keys und anderen Secrets. Dies ist gegenüber menschlichen Identitäten oft dadurch erschwert, dass dieselbe Identität in einer Vielzahl von Systemen zum Einsatz kommt und das Secret daher in einer konzertierten Aktion rotiert werden muss.

- Überwachung der Accountbenutzung auf Anomalien hin.

Andere Faktoren wiederum sind NHI-spezifisch und erfordern zusätzliche Prozesse und Überwachungsvorrichtungen:

- Verwendung von NHI-Credentials durch Menschen monitoren. In der klassischen IT existiert seit jeher das umgekehrte Übel – Nutzung von privilegierten persönlichen Accounts als Service- oder Funktionsaccounts – welches ebenso schwer zu bekämpfen ist.

- Sicheres Aufbewahren von Kennwörtern und anderen Secrets außerhalb ihrer direkten Verwendung. Dies ist als "Vaulting" bekannt, in der klassischen IT existiert diese Anforderung beispielsweise für Break-Glass-Accounts.

- Sicheres Aufbewahren von Secrets in den Systemen, die sie produktiv nutzen.

- Vermeiden des Eincheckens der NHI-Secrets in Code-Repositories.

Neben Hygiene und Überwachung ist die strikte Trennung der in IT und OT verwendeten Identitäten ein extrem wirkungsvolles Mittel, um sowohl die Eintrittswahrscheinlichkeit als auch die Auswirkungen einer Kompromittierung von NHIs drastisch zu reduzieren. Auch davon spricht die NHI Management Group, wenn auch nur nachgelagert. In Bezug auf die in der IT gängigen Identitätsspeicher wie Active Directory (für die lokalen OT-Installationen oder Maschinen, die LDAP zur Authentifizierung, Autorisierung, Lookup und beispielsweise SMB für Datenzugriff verwenden) und Entra ID (für cloudbasierte OT wie verteilte Sensoren oder Edge-Computing-Installationen) bedeutet dies:

- Separate Forests für on-premises-OT. Eine separate Domäne innerhalb eines gemeinsamen Forests für IT und OT bietet hier keine echte Sicherheitsabgrenzung und in der Regel auch keine echten Mehrwerte in der Administration.

- Möglichst keine Vertrauensstellungen zwischen IT- und OT-Forests. Falls eine Vertrauensstellung unumgänglich ist, selektive Authentifizierung verwenden. Tatsächlich ist die IT-/OT-Kopplung ein Paradebeispiel für die Verringerung der Angriffsfläche durch selektive Authentifizierung, denn es sind in der Regel nur einige wenige Identitäten aus dem vertrauten Forest, die sich nur gegenüber einigen wenigen Systemen im vertrauenden Forest authentifizieren müssen.

- Separate Entra-ID-Tenants für cloudbasierte OT, Administration mit Gastkonten aus dem IT-Tenant oder aus dem "Red Tenant".

- Conditional Access Policies für den Zugriff auf Cloudressourcen, um die Zugriffe innerhalb der OT zusätzlich zu den regulären Berechtigungen noch strikter zu kanalisieren.

Zusätzlich zu den identitätsspezifischen Trennungsmaßnahmen sollte natürlich stets auch der Netzwerkverkehr durch Firewalls so restriktiv geregelt sein, dass nur Kommunikationsbeziehungen, die Ihre OT tatsächlich benötigt, zwischen der IT und OT erlaubt sind. Sie müssen die Separation stets von einer kompletten Trennung (default deny) ausgehend planen und nicht mit einem "Jeder darf alles"-Zustand beginnen und dann versuchen, die unerwünschten Zugriffe zu unterbinden.

Eine wirksame Schutzmaßnahme für die saubere Trennung zwischen OT- und IT-Umgebung ist das Aufbrechen des direkten Transferprotokolls zwischen beiden Bereichen. Typische Datenübertragungen von IT zu OT umfassen Dateien wie CNC-Programme für die Produktion oder IoT-Rohdaten für Auswertungen und Berichte. Ebenso können Datenbankabfragen erforderlich sein, etwa für Arbeitsaufträge oder konsolidierte Datensätze von Edge-Geräten. In allen Fällen erfordern die Datenspeicher eine Authentifizierung für den Zugriff.

Das Authentifizierungsproblem verschärft sich, wenn beide Seiten Zugriff benötigen. Nutzen IT- und OT-Systeme dasselbe Identitätssystem, kann eine Kompromittierung einer Seite das gesamte System gefährden. Bei separaten Identitätssystemen entsteht ein anderes Problem: Der Datenspeicher (File-, Datenbank- oder Applikationsserver) muss beiden Identitätssystemen vertrauen. Dies führt meist dazu, dass sich die Identitätssysteme gegenseitig vertrauen müssen – was neue Angriffswege schafft und die Systemkomplexität erheblich steigert.

Eine Lösung besteht darin, die Datenübertragungskette zu unterbrechen und damit den direkten Zugriff auf die Identitätssysteme der anderen Seite zu verhindern. Bei der Dateiübertragung lässt sich beispielsweise je ein Fileserver in der IT- und OT-Umgebung installieren. Die Dateibestände werden dann zwischen beiden Servern mit Tools wie SCP oder rsync synchronisiert. Entscheidend ist: Die für diese Synchronisierung benötigten Zugangsdaten stammen aus keinem der primären Identitätssysteme, sondern sind speziell für den Datenaustausch erstellt. Diese Trennung isoliert nicht nur die Identitätssysteme voneinander, sondern ermöglicht auch zusätzliche Sicherheitshärtung. Benötigt die OT-Umgebung beispielsweise das unsichere SMB1-Protokoll ohne Signierung, lässt sich diese Konfiguration ausschließlich auf der OT-Seite implementieren, ohne die IT-Infrastruktur zu gefährden.

Einen vergleichbaren Ansatz bieten Datenbank-Proxies. Diese unterstützen neben der Datenmaskierung auch unterschiedliche Authentifizierungsverfahren: Ein Verfahren für die interne Verbindung zum Datenbankserver, ein anderes für die externe Schnittstelle zur OT-Seite. Zusätzlich können Datenbank-Proxies Verschlüsselungsanforderungen ausgleichen – selbst wenn die OT-Systeme keine starke Verschlüsselung unterstützen, wird die Verbindung zum Datenbankserver trotzdem sicher verschlüsselt.

Die Koexistenz von IT und OT in den gleichen Netzen, Managementparadigmen und vor allem Identitätssystemen ist ein großer Risikofaktor sowohl für den IT-Betrieb als auch für die Produktionsfähigkeit der OT. Eine konsequente Trennung und Anwendung von Account- und Berechtigungshygiene in beiden Bereichen unter Berücksichtigung NHI-spezifischer Faktoren verbessern die Sicherheit erheblich. Den ultimativen Schutz liefern Sicherheitsschleusen, die die Datenübertragungsprotokolle aufbrechen und die IT-Welt von der OT im Sinne der Authentifizierung und Autorisierung isolieren.