
In dieser Folge von OT Security Made Simple erläutert unser Gast Moritz Flüchter von der Universität Tübingen, wie ein OT-Monitoring auch dafür genutzt werden kann, um Time Sensitive Networking (TSN) in Netzwerken zu ermöglichen, in denen ein Teil der Systeme und Endgeräte nicht TSN-fähig sind. Nicht zuletzt zeigt er auf, wie eine integrierte Anomalieerkennung die bestehenden Unsicherheiten von TSN überwacht und Denial-of-Service-Attacken erkennt.
Hören Sie uns auf:
Transkript
Klaus Mochalski
Hallo und herzlich willkommen zu einer neuen Episode von OT Security Made Simple. Ich bin Klaus Mochalski, Gründer von Rhebo. Mein Gast heute ist Moritz Flüchter. Moritz ist Doktorand an der Uni Tübingen am Lehrstuhl Kommunikationsnetze. Rhebo und der Lehrstuhl, vertreten durch Moritz, arbeiten seit einiger Zeit an einem Forschungsprojekt im Bereich industrielle Vernetzung. Darüber werden wir heute sprechen.
Wir werden zwar heute über ein Nebenthema zu Security reden, aber im Endeffekt werden wir hoffentlich auch einen spannenden Ausblick zu Security mit einbringen. Bevor wir das tun, Moritz, ganz kurz zu dir und erzähl uns doch mal mit deinen Worten, was wir in diesem Forschungsprojekt gemeinsam gemacht haben, worum es da ging und vielleicht auch, was die Ergebnisse waren.
Moritz Flüchter
Servus, danke, dass ich dabei sein darf. Genau, also wir haben mit Rhebo zusammengearbeitet. Wir haben ein bisschen überlegt, gebrainstormt, was man denn in so einer Kooperation machen kann und da kam relativ schnell die Idee auf, zu schauen, wie man denn das Netzwerkmonitoring, das es von Rhebo schon gibt, erweitern kann im Kontext von TSN [Anm.: Time Sensitive Networking].
Wir haben [durch Rhebo] also ein Gerät, das sich im Netzwerk die Übertragung anschaut und haben gedacht, dass man das nutzen könnte, um Geräten im Netz, die TSN, also diese Technologie an sich, nicht unterstützen, trotzdem Übertragungsqualität zusichern zu können. Also, wenn wir im Bereich von Real-Time-Communication sind oder auch ganz allgemein bei den Quality Service Requirements, dass Anwendungen, die TSN nicht unterstützen, trotzdem die Vorteile von TSN bringen können.
Klaus Mochalski
TSN. Gutes Stichwort. Erkläre unseren Zuhörenden doch einmal ganz kurz, was TSN ist.
Moritz Flüchter
Der Ursprung von TSN kommt aus der Industrie, aus den Herstellungsebenen. Da gibt es bisher ganz viele verschiedene Maschinen natürlich, verschiedene Hersteller und mit Industrie 4.0 und Netzwerkkonvergenz möchte man das alles zusammenziehen in ein großes Netzwerk, wo dann auch die Maschinen untereinander reden können und man nicht so abgekapselte Systeme hat. Und das Problem, du kennst sie wahrscheinlich auch, sind die Protokolle wie Profinet oder EtherCAT. Diese funktionieren auf der Anwendungsebene, können diese Übertragungssicherheiten geben für Software-Time-Übertragungen. Aber das Problem ist, die funktionieren ganz schlecht zusammen, weil sie sich eben nicht miteinander austauschen können und keine Schnittstelle haben.
TSN ist ein Ansatz, dieses Thema im Netzwerkstack weiter unten anzusetzen, also auf der Ebene der Switches, die die eigentlichen Daten weiterleiten. Dort soll quasi eine gemeinsame Plattform auf Ethernet-Basis geschaffen werden, über die alle miteinander kommunizieren können, beziehungsweise auch dann den Übertragungen die Anforderungen – wie zum Beispiel maximaler Zeit, maximaler Delay von Sender bis Empfänger oder so was – zusichern können, eben diese Protokolle so ein bisschen miteinander zu vereinen.
Es funktioniert grundlegend so, dass das TSN-Netzwerk einen sogenannten Admission Control Mechanismus hat. Die Sender und Empfänger kündigen ihre Übertragung dem Netzwerk an, bevor sie überhaupt anfangen zu senden. Das Netzwerk kann dann die Ressourcen reservieren, die es benötigt, zum Beispiel Bandbreite, oder eben eine gewisse Latenz garantieren. Und das Netzwerk konfiguriert sich dann [entsprechend] und meldet dem Sender oder dem Empfänger zurück: „Okay, das funktioniert jetzt.” oder “Das funktioniert nicht." Und das tolle daran ist, was auch ein Riesenvorteil ist, dass man diese Real-Time-Streams machen kann, aber auch Best Effort, also jeglicher sonstiger Verkehr kann auch über das gleiche Netz geschickt werden.
Klaus Mochalski
Das ist, glaube ich, erst mal ganz verständlich. Es geht also um die Dienstgüte oder Quality of Service, wie man es auch nennt. Das ist ja im Internet ein ziemlich, ich sage mal, altes Thema, was eigentlich seit langem als mehr oder weniger gelöst gilt. Was macht man denn hier im Industriebereich anders? Natürlich sprechen wir oft über die Anforderungen an Echtzeitkommunikation. Gerade wenn wir jetzt an eng getaktete Kommunikation zwischen Steuerungen und zum Beispiel Fertigungsrobotern in der Automobilbranche sprechen, dann ist, glaube ich, jedem verständlich, dass wir hier Echtzeitsteuerungsprozesse auf der Kommunikationsebene haben. Was wird denn hier im Vergleich zu dem, was es an Dienstgüte im Internet schon länger gibt, anders gemacht? Was sind die speziellen Herausforderungen im Industriebereich?
Moritz Flüchter
Du hast es ja schon ein bisschen angesprochen. Echtzeitkommunikation, in dem Fall sogar mit TSN, hat, wenn wir in die Industrie reingehen, noch härtere Echtzeitanforderungen als in anderen Bereichen. Bei TSN wird zum Beispiel zum Teil geliebäugelt, das in Flugzeugen oder einem Fahrzeugsystem einzusetzen, aber das ist jetzt mal vorneweg.
Die Zeitanforderungen [sind strikter]. Ein Paket wird gesendet und muss mit einer maximalen Latenz ankommen. Angenommen, du hast eine Steuerung im Netzwerk, und die steuert zum Beispiel einen Roboterarm. Da sind die [Zeitanforderungen] deutlich krasser, als du es bisher im Internet hast.
Das Ethernet an sich unterstützt weder, dass Pakete rechtzeitig ankommen, noch dass Pakete überhaupt ankommen. Das ist [eher] dieser Best Effort, von dem man oftmals spricht. Und wenn man ganz oben am Endnutzer schaut, kann man sagen, wir können [zwar über das TCP-Protokoll] garantieren, dass das Paket überhaupt ankommt. Man sagt dann zum Beispiel: „Okay, ein Paket ist nicht angekommen, melde es dem Sender”, der Sender schickt es noch mal. Aber so weit oben ist [diese Benachrichtigung und Korrektur] problematisch [in Industrieumgebungen]. Denn wenn man erst am Empfänger [z. B. bei einem Roboterarm] überhaupt sagen kann: „Okay, jetzt ist es doch nicht rechtzeitig angekommen", ist das ein bisschen zu spät. Deshalb muss man [in Industrieumgebungen] schon viel weiter vorher angreifen, nämlich auf der eigentlichen Weiterleitungsebene. Und in so einem TSN-Netzwerk hat jeder Switch, jeder Knoten, der Pakete und Daten weiterleitet, besondere Funktionen und konfigurierbare Einstellungen, um eine wirklich gute Echtzeit-Garantie zu geben. Das geht bis in den Mikrosekunden-Bereich runter, je nachdem, was man braucht.
Klaus Mochalski
Das heißt, es geht darum, die Echtzeit-Auslieferung von einzelnen Datenpaketen für zeitkritische Prozesse zu garantieren und auch auf einem viel niedrigeren Zeit-Level, als das jetzt bei Internetkommunikationen, wie wir die zum Beispiel gerade nutzen, der Fall ist. Und du hattest auch gesagt, dass es hier, wenn wir das Schichtenmodell uns mal anschauen – den OSI oder auch den TCP/IP-Schichtenstack –, um die Schichten 1 und 2 geht, die ersetzt werden. Oder die upgegradet werden sollen mit einer zusätzlichen Funktion, dann den höher liegenden Schichten, zum Beispiel Protokollen wie Profinet und EtherCAT, diesen Mehrwert zur Verfügung zu stellen. Ist das so richtig?
Moritz Flüchter
Genau. TSN bezieht sich auf Layer 2, also auf die Ethernet-Switches. Da sind auch die Standards angesiedelt. Die erweitert quasi den Switching-Standard für Ethernet.
Klaus Mochalski
Was sind denn hier die Herausforderungen? Ich denke konkret daran, wie genau oder wie umfassend die Unterstützung einzelner Komponenten und auch der Implementierung durch verschiedene Hersteller sein muss, diese Funktion nutzen zu können? Müssen die dort alle mitspielen? Brauche ich neue Komponenten? Muss ich Softwareupdates einspielen? Wie sieht dort gerade das Bild aus? Das klingt für mich nach einer potenziell sehr heterogenen Unterstützungslandschaft.
Moritz Flüchter
Das Wichtige des TSN ist erstmal, dass es quasi eine Sammlung an Erweiterungen ist. Das ist wie eine Werkzeugkiste. Du hast Möglichkeiten, Bandbreiten zu begrenzen, Pakete zu terminieren, also einen Plan zu machen, wann wo was weitergeleitet wird. Das ist sehr flexibel, je nachdem, was man eben als Anforderung hat. Für die einfacheren Sachen, also bei nicht so starken Echtzeitanforderungen, ist das wahrscheinlich möglich, das zu erweitern. Beziehungsweise da müssen auch nicht alle Geräte das unterstützen. Aber wenn man wirklich voll von den Vorteilen von TSN profitieren möchte, dann muss jeder Switch, über den dieser TSN-Verkehr geleitet wird, das unterstützen.
Klaus Mochalski
Die Switches müssen das auf jeden Fall unterstützen. Wie sieht es denn mit den Endgeräten aus? Also meine Steuerung, zum Beispiel meine Profinet-Steuerung, die dann auch entsprechend Endgeräte direkt ansteuert.
Moritz Flüchter
Das Wichtige ist, dass TSN jetzt nicht irgendwie einen neuen Header einführt oder neue Kit-Arten, sondern das funktioniert alles mit bestehenden Ethernet-Frames. Das wichtige oder der wichtigste Teil daran ist das sogenannte Signaling. Das ist dieser Prozess, wo der Sender oder eben der Controller dem Netzwerk mitteilt: „Ich benötige jetzt diese und diese Anforderungen für eine neue Übertragung". Und das müssen die Endgeräte dann auch unterstützen, sie müssen konfigurierbar sein. Zum Beispiel werden TSN-Frames über das WLAN-Tag identifiziert, und die Sender müssen einen bestimmten Wert einsetzen. Also man braucht eine kleine Unterstützung dafür auf den Endgeräten. Es muss eben irgendjemand dem Netzwerk mitteilen: „Hey, es wird jetzt diese und diese Anforderungen gebraucht".
Klaus Mochalski
Ja, und hier kommen wir, glaube ich, auch an den Punkt, wo [ein OT-Monitoring wie das] von Rhebo [bei eurer Forschung] ins Spiel kommt. Unsere Lösung ist ja im weitesten Sinne eine Monitoring-Lösung, die häufig von Kunden eingesetzt wird, um Security-relevante Vorfälle zu [erkennen und zu] überwachen. Viele unserer Kunden setzen dieses Thema aber auch zur allgemeinen Netzwerküberwachung ein. Wo kommt denn bei der ganzen TSN-Unterstützung [ein OT-Netzwerkmonitoring] ins Spiel?
Moritz Flüchter
Das Grundthema hinter dem ganzen Konstrukt ist, dass den Anwendungen, die TSN nicht unterstützen, die Fähigkeit dieses Signalings, dieser Ankündigung der Übertragung im Netzwerk, fehlt. Und angenommen, [man] könnte das aber irgendwie doch signalisieren, dann könnten Nutzer eben doch von TSN profitieren. Es wird also nicht viel mehr gebraucht.
Und daher war unser Gedanke, dass der Rhebo Industrial Protector im Netz hängen kann, die Übertragung beobachtet und die Daten aufzeichnet. Und sobald er eine Übertragung erkennt, die eben nicht TSN-fähig ist und noch nicht davon profitieren kann, auch erkennt, was für ein Protokoll das ist, und die Parameter, die für TSN benötigt werden, ableitet und dann stellvertretend für dieses Endgerät, das TSN selbst nicht unterstützt, dem Netzwerk die Anforderungen mitteilt.
Klaus Mochalski
Das heißt, es geht hier genau um die Endgeräte, die die TSN-Unterstützung nicht liefern können und dem Netzwerk nicht selbst signalisieren können, was sie an Ressourcen brauchen. Da übernimmt das dann die OT-Monitoring-Lösung stellvertretend. Das heißt, sie überwacht die Kommunikation, lernt dann, um welche Art von System es sich handelt, hat dann in irgendeiner Form wahrscheinlich Kommunikationsprofile hinterlegt, die dann entsprechend signalisiert werden, so als wäre das [OT-Monitoring] das Endgerät selbst.
Moritz Flüchter
Genau. Ja. Für Geräte, die im Netzwerk hängen und die einfach mal so kommunizieren, ist es völlig transparent. Mal angenommen, da sind zwei Rechner angeschlossen und die machen eine Voice-over-IP-Übertragung, eine Sprachübertragung. Für die gibt es keine Veränderungen, außer dass ihre Übertragung damit besser funktioniert, ohne dass Sie [als Nutzende] selbst etwas anpassen müssen im Netzwerk. Das Netzwerk konfiguriert sich damit dann durch den Rhebo-Controller, der das Staking macht. So erfahren die angeschlossenen Endgeräte [und damit die Nutzenden] eine bessere Übertragung.
Klaus Mochalski
Für mich klingt es nach einem perfekten Beispiel dafür, wie Sicherheitslösungen, die für einen ganz anderen Zweck angeschafft werden, auch Zusatznutzen mit sich bringen können. Das sind Dinge, die wir auch bei vielen unserer Kunden beobachten. Unsere Lösung wird häufig angeschafft, Anforderungen für die Risikoreduktion zu erfüllen. Häufig, weil zum Beispiel in kritischen Infrastrukturen ein Informationssicherheitsmanagementsystem eingeführt wurde und da wurde eben festgelegt, wir müssen Vorfälle rechtzeitig, idealerweise in Echtzeit, erkennen können.
Diese Vorfälle finden aber in gut gesicherten Anlagen nur relativ selten statt und dann fragen sich viele Kunden: „Was kann ich denn mit dem Monitoring-System noch alles machen?" Und da fällt eben auf, dass das System die ganze Zeit die Kommunikation überwacht und dort viele Dinge eben einfach mitbekommt, die man als Monitoring im Netz eben so mitbekommt. Das heißt, viele nutzen das dann, technische Störungen zu überwachen, Ausfälle, Überlastsituation zu erkennen.
Das heißt, das ist ein weiteres Anwendungsszenario, wie man in so einer gemischten Infrastruktur – die, glaube ich, viele Kunden noch für längere Zeit haben werden – so ein System mitbenutzen kann, um einen echten Mehrwert zu produzieren und ohne dass man extra etwas Neues installieren muss. Ich finde auch das Konzept an sich sehr interessant, wie du es gerade angesprochen hast, denn es gibt dann dieses Gerät, das eine unglaubliche Informationsmenge sammelt, bereitstellt und visualisiert, um den Leuten auch überhaupt mal zu zeigen, was jetzt tatsächlich alles durchs Netzwerk fließt.
Moritz Flüchter
Ich habe ja auch mit dem Rhebo Industrial Protector gearbeitet und geschaut: „Machen wir jetzt mal einen größeren Traffic. Wie sieht es denn aus mit den Geräten? Wie sind die denn verteilt? Wer kommuniziert mit was?" Das ist, glaube ich, auch mal ganz gut, so einen Überblick zu erhalten und dann eben: Wenn schon diese Daten da sind, die Idee darauf, mehr Funktionen einzubauen. Was kann denn erweitert werden? Denn es wird ja schon gesammelt. Warum das nicht auch nutzen?
Klaus Mochalski
Das ist tatsächlich auch das, was wir oft von Kunden hören, was den Erstnutzen so eines Systems darstellt. Dass man erst mal lernt, wie die eigene Infrastruktur überhaupt aussieht, und zwar auf einer Detailstufe, die man so in der Regel nicht hat. Das heißt, angefangen mit: Welche Systeme sind da? Aber auch: Welche Protokolle werden denn gesprochen? Wie häufig? Über welche Datenvolumina reden wir, wie sind die Paketraten?
Das sind häufig Dinge, die sind den meisten Betreibern solcher Infrastrukturen weitestgehend unbekannt. Und die sind natürlich sehr, sehr wichtig. Nicht nur, um Sicherheit zu gewährleisten, sondern auch den ganz normalen Betrieb, die Stabilität dieser Infrastruktur. Was mich natürlich interessiert, wie gut hat denn das Ganze funktioniert? Ist diese Parallelsignalisierung, die wir über die Erkennung durch das OT-Monitoring zur Verfügung gestellt haben, genauso gut wie direkte Unterstützung durch die Geräte? Ist das ein adäquater Ersatz oder ist das ein Migrationsfahrt? Wie würdest du das sehen?
Moritz Flüchter
Es ist sehr vom Fall abhängig. Was wichtig ist, wenn wir jetzt über TSN reden und über diese wirkliche Hard-Real-Time, dann wollen wir wirklich krasse Echtzeitanforderungen im Milli- bis Mikrosekunden-Bereich haben. Das wird da eigentlich benötigt, dass die Endgeräte auch eine Zeitsynchronisierung mit sich bringen. Denn dann wird wirklich an jedem Gerät mit dem sogenannten Time-Aware-Shaper geplant, zu welchen Zeitpunkt, an welchem Switch, welche Pakete weitergeleitet werden. Da kann man dann wirklich unglaublich geringe Latenzen garantieren – oder besser nicht unglaublich geringe Latenzen, aber eine geringe Variierung in den Latenzen. Und dafür müssen die Endgeräte Zeitsynchronisierung haben. Das ist jetzt in diesem Fall nicht gegeben, aber diese wirklich krassen Echtzeit-Anforderungen haben auch wenige Anwendungen, die jetzt für uns im Fokus stehen.
Ich nehme gerne diese Stimmenübertragung, Voice over IP, als Beispiel. Es hat nicht die Anforderung von einem Robotersteuerungsgerät. Also das können wir damit nicht machen. Aber alles andere, was wir identifiziert haben mit dem Roboter-Controller, nutzt die normale Schnittstelle, um das dem Netzwerk anzumelden. Wir haben Methoden entwickelt, eben diese Parameter, zum Beispiel eine Beschreibung der Übertragungsrate und Form, aus dem Monitoring zu extrahieren. Das ist alles sehr genau. Also da ist die Integrierung top.
Das ist natürlich immer so ein bisschen ein Problem. Wir machen das basierend auf Beobachtungen. Mal angenommen, ein Endgerät ändert sein Verhalten, weil es zum Beispiel umgestellt wurde oder umkonfiguriert wurde. Aber auch da ist dieses Monitoring-Konzept so wichtig als Teil. Man muss immer weiter beobachten: Macht das Gerät noch das, was wir denken? Aber natürlich, wenn man dem Gerät TSN-Fähigkeiten oder die TSN-Unterstützung zufügt und auch das alles manuell konfiguriert, ist man natürlich immer ein bisschen genauer als das, was wir vom Netzwerk her erkennen – von den Beobachtungen, dem Monitoring.
Klaus Mochalski
Aber für existierende Infrastrukturen, das höre ich raus, ist das ein durchaus adäquater Ersatz in vielen Situationen für viele Anforderungen. Ich kann als Betreiber sicher viel Geld sparen, wenn ich eben nicht alle Geräte aufrüsten muss und gegen neue Versionen austauschen muss, sondern meine Bestandsinfrastruktur so auch weiter betreiben kann – bis vielleicht wirklich kritische Teile der Infrastruktur ausgetauscht werden müssen, weil ich eben genau diese Echtzeitanforderungen, die du beschrieben hast, die diese Zeitsynchronisation der Endgeräte erfordern, unbedingt brauche.
Jetzt heißt ja unser Podcast OT Security Made Simple. Deswegen muss ich dich, wenn ich dich einmal in der Show habe, als TSN-Experte oder Allgemeinexperte für Industrievernetzung, doch noch mal fragen: Was sind denn aus deiner Sicht die sicherheitsrelevanten Herausforderungen und Probleme, die man in solchen Netzen findet? Vielleicht habt ihr dort auch im Rahmen des Projektes Dinge beobachtet. Also worauf muss man aus Sicherheitsperspektive achten, wenn man solche eine Infrastruktur betreibt?
Moritz Flüchter
Also, dadurch, dass die Infrastrukturen bzw. die Netzwerke so konfiguriert werden, die Eigenschaften der Streams zuzusichern und eben auch dieses Modell haben, mit dem eine Übertragung angemeldet werden, ist – aus unserer Sicht – erst mal ein großer Problempunkt für Security. Dazu gibt es jetzt auch eine Veröffentlichung von einem Kollegen am Lehrstuhl. Es geht darum, wenn so ein Gerät seine Anforderungen ankündigt, dann kann ja auch sein, dass diese Ankündigungen verändert wurden. Dass zum Beispiel ein Angreifer hingeht und sagt: „Okay, dieses kleine Gerät braucht jetzt 100 Megabyte Bandbreite", übertrieben gesagt.
Klaus Mochalski
Ich könnte also so eine Denial-of-Service-Attacke fahren gegen das Netzwerk, wenn ich diese Funktionalität ausnutzen kann.
Moritz Flüchter
Man könnte irgendwie Pakete einschleusen. Inhalt der Veröffentlichung des Kollegen war eben die Sache gewesen, eins dieser Protokolle, das nennt sich das Resource Allocation Protocol, kurz RAP anzuschauen. Das Protokoll ist für verteilte Netzwerke gemacht. Es propagiert durchs Netzwerk eben diese Anforderungen, damit sich jeder Switch einstellen kann. Das Protokoll an sich ist nicht gesichert. Nachrichten können verändert werden, eingespielt werden und damit kann man eben im Netzwerk Denial-of-Service-Attacken machen, indem man Ressourcen überreserviert oder Prioritäten verändert.
Wenn [so ein Protokoll] nicht abgesichert ist, ist es erst mal sehr problematisch. Man muss erst mal als Angreifer im Netzwerk drin sein, um das überhaupt machen zu können. Und es gibt schon die Basis in den Standards, auf denen so eine Sicherheit eigentlich gegeben werden kann. Also eine Standard für die Industrie für TSN. Da gibt es schon das Konzept der sogenannten Device IDs, beziehungsweise Device Identifiers, das Zertifikate nutzt, eine Zertifikats-Hierarchie. So ähnlich, wie es bei Webbrowsern und den Webservern auch funktioniert, um die Identität von Geräten zu überprüfen. Also, wenn man sich eine neue Maschine einbaut, dass man überprüfen kann, dass es tatsächlich die richtige Maschine ist, beziehungsweise vom richtigen Hersteller. Dass nichts dran verändert ist. Und diese Zertifikate kann man zum Beispiel nutzen, um auch die Kommunikation abzusichern.
Klaus Mochalski
Das heißt, es geht in die gleiche Richtung. Es ist gar kein TSN-spezifisches Problem. Es gibt ja gerade so einen großen Trend in Richtung Zero Trust, auch im OT-Bereich, dass man sagt, alle Geräte, jede Kommunikation sollte authentifiziert werden. Das heißt, das geht in eine ähnliche Richtung, so wie ich das verstehe.
Moritz Flüchter
Genau. Also, wie gesagt, für den Angriff muss man dann vor Ort sein oder irgendeinen Zugriff auf das Netzwerk bekommen, aber dann kann man schon sehr viel Unsinn treiben. Und deshalb auch da die Idee, für wirklich umfassende Security muss man diese Signalisierung, die Kommunikation zwischen dem Controller und dem Gerät, das das Netzwerk konfiguriert, absichern. Ansonsten fängt man sich ganz viele Probleme ein, sobald mal jemand dran kommt.
Klaus Mochalski
Du hast darüber gesprochen, dass es dort schon erste Bestrebungen gibt, das in das Protokoll mit einzubauen. Vielleicht ist das auch schon standardisiert. Ist das denn die ultimative Lösung? Ich denke natürlich spontan daran: Könnte man nicht auch solche security-relevanten Manipulationen, zum Beispiel in der Signalisierungkommunikation, gleich mit dem Monitoring-System mit überwachen? Dass man eben sagt, das sind die Kommunikationsprofile, die in meiner Infrastruktur erlaubt sind. Und wenn ich [mit dem Monitoring in meinem Netzwerk] Anforderungen [von einem Gerät] sehe, die ich in der Vergangenheit noch nicht gesehen habe oder die ganz stark von vorherigen Anforderungen abweichen, dann kann man das in irgendeiner Form alarmieren. Eben die Idee der Anomalieerkennung. Ist das eine mögliche Lösung?
Moritz Flüchter
Ja, solange man Zugriff auf diese Reservierungsdaten hat, absolut, glaube ich das. TSN hat auch intern so ein bisschen Absicherungsmethoden, mit denen man zum Beispiel sagen kann: Wenn ein Gerät mit einer erhöhten Rate sendet, als es eigentlich angekündigt hat, dann wird der Verkehr gedroppt, also fallen gelassen oder mit einer geringeren Priorität eingestuft. Eben um zu garantieren, dass das Netzwerk darunter nicht leidet.
Es gibt auch verschiedene Ansätze in die Richtung, dass, wenn das ins Netzwerk signalisiert wurde, das gesichert werden kann. Aber auch, was du gerade gesagt hast, das wäre auch eine Idee für den Rhebo Controller, dass er im Netzwerk hängt, sich anschaut: Okay, da meldet jetzt eine Anwendung ihre Übertragung an und die fragt was Komisches an oder sagt, sie hätte gerne Echtzeitanforderungen, obwohl es nur ein Datentransfer ist. Dann kann man da ja hellhörig werden.
Klaus Mochalski
Ja, genau. Der Rhebo Controller überwacht ja auch die Kommunikationsprofile von bestimmten Protokollen, dass sie einem regulären Verhalten folgen. Und das könnte man ja durchaus erweitern auf diesen Fall. Das ist auf jeden Fall spannend, dass wir hier doch auch eine Security-Perspektive oder eine Security-Herausforderung haben, die man natürlich immer im Auge haben muss. Vielleicht muss ich dazu tatsächlich noch mal mit einem Kollegen sprechen. Vielleicht wäre das ja Inhalt für eine weitere Episode.
Es hat mich sehr gefreut, dich heute hier gehabt zu haben, Moritz. Es war ein sehr spannender Einblick, auch wenn wir über ein Thema neben der Security gesprochen haben. Aber ich glaube, das ist etwas, das speziell Industrienetzwerke in den nächsten Jahren sehr stark prägen wird und deswegen ist es, glaube ich, auch für unsere Hörer ein sehr spannendes Thema. Und Sicherheit spielt auch hier eine wichtige Rolle. Vielen Dank, dass du hier warst. Es hat mir Spaß gemacht, mit dir darüber zu sprechen.
Moritz Flüchter
Danke, dass ich da sein durfte.