TSN ist eine Reihe von Ergänzungen zu den IEEE-Bridging-Spezifikationen und dient dazu, deterministische Kommunikation über gewöhnliches Ethernet zu ermöglichen. Der Hintergrund: Wenn kritische Prozesskommunikation und IT-Verkehr dieselbe Ethernet-Infrastruktur teilen, wird Verkehrskonkurrenz zum Sicherheitsproblem. In der klassischen Unternehmens-IT lassen sich kollidierende Pakete einfach erneut senden. In der OT dagegen müssen synchronisierte Steuerbotschaften zwischen Controllern und Feldgeräten innerhalb von Mikrosekunden ankommen, sonst schlagen Watchdog-Timer an und versetzen Maschinen in den Schutzabschaltbetrieb. TSN priorisiert deshalb die kritischsten Verkehrsklassen. “Wenn Sie etwa Sicherheitssignale für Notaus-Taster haben, sind das die höchste Priorität, und Sie müssen sicher sein, dass diese Nachricht nicht durch anderen Best-Effort-Verkehr blockiert wird, der das Netz in diesem Moment überlastet”, erläutert Cremona.
“Verfügbarkeit und Sicherheit liegen sehr nah beieinander”, sagt Cremona. “Ein Protokoll, das nicht abgesichert ist, ist auch nicht garantiert verfügbar.”
Beim Analysieren des Protokollverkehrs fiel Cremona eine Ähnlichkeit zu GOOSE auf, einem Protokoll aus der Energieverteilung, bei dem eine vorhersagbare Zeitsequenzierung bereits bekannte Probleme verursacht hatte. Einer Vermutung folgend übertrug er die gegen GOOSE bekannten Angriffstechniken auf CC-Link IE TSN — nach einigem Feilen mit Erfolg. Das Team rekonstruierte das Synchronisationsverhalten, um gültige Werte vorherzusagen und zyklische E/A-Signale zu manipulieren. Ergebnis ist eine Protokollschwachstelle: Speziell präparierte Signale lassen sich in den passenden Zeitschlitz einspeisen und werden dort als scheinbar legitime, planmäßige Kommunikation akzeptiert.
Blieb die Frage, wie ein Angreifer überhaupt in das normalerweise nicht nach außen exponierte TSN-Netz gelangt. Dafür nahm das Team TSN-Switches von Phoenix Contact ins Visier und fand bislang unbekannte Fehler, über die sich vom Remote-Management-Interface der Techniker aus auf den Prozessport des Switches zugreifen lässt. “Der wichtigste Einstiegspunkt ist das Management-Interface des TSN-Switches”, so Cremona — entweder in einem größeren Netz exponiert oder über ein gefälschtes oder manipuliertes Gerät in Netznähe erreichbar. Ist der Switch angreifbar, sei man “im Grunde fertig”.
Zwar verfügt CC-Link IE TSN über ein Sicherheitsmodell und optionalen kryptografischen Schutz der Nutzdaten. Die Lücken bei den Layer-2-Schutzmechanismen erleichtern Angreifern jedoch das Einspeisen von Verkehr in den Kommunikationsstrom. Für die Switch-Schwachstellen von Phoenix Contact existiert bereits ein Firmware-Patch; Cremona rät OT-Teams, die Firmware aller Netzgeräte so aktuell wie möglich zu halten.
Nozomi, das laut eigener Aussage als eigenständig operierende Tochter mit herstellerneutraler Roadmap arbeitet und über eine lauffähige CC-Link-IE-TSN-Installation im Forschungslabor verfügte, arbeitet mit dem Mutterkonzern an einer langfristigen Behebung. Erwogen werden kryptografische Primitive, die auch den Absender einer Nachricht belegen. “Verschlüsselung in ein System einzubauen, das schnell sein muss, ist immer eine Qual”, sagt Cremona — bei einer Zeitpräzision von unter einer Mikrosekunde sei es schwer, ausreichend schnelle Verfahren zu finden. Erste Tests deuten aber auf Machbarkeit hin.
Bis dahin bleibt laut Cremona nur eine wirksame Maßnahme: konsequente Netzsegmentierung, damit Angreifer nicht ohne entsprechende Berechtigung von einem Netz ins andere springen. Die Forschung beschränkt sich bislang auf ein einzelnes TSN-Protokoll, soll aber als Ausgangspunkt für die Prüfung weiterer Protokolle dienen, die auf TSN-Primitiven aufbauen.