Ein OT-IDS, das auf bereits vorhandener Hardware läuft.

Industrielle Betreiber stehen unter neuem Compliance-Druck durch NIS2, IEC 62443 und den IKT-Minimalstandard der Schweiz. Die meisten Produkte zur OT-Intrusion-Detection sind um eine zentrale Appliance herum gebaut, der der Datenverkehr gespiegelt wird. Das funktioniert für einen einzelnen grossen Standort mit eigenem Security-Team. Der Fall, an dem wir arbeiten, ist der andere: viele kleine Standorte, dünne Leitungen, kein ständig besetztes SOC.

In diesem von Innosuisse geförderten Projekt untersuchen wir, wie ein OT-IDS aussehen kann und muss, um viele kleine Standorte effizient abzudecken. Die Erkennung läuft in einem Container auf den Switches, Firewalls und Gateways, die bereits vor Ort sind. Die Baselines kalibrieren sich selbst. Nur Ereignisse, die die lokale Analyse als ernsthaft bestätigt, wandern zu einem zentralen System.

Wo zentrale Appliances an ihre Grenzen kommen

Zentrale Appliances funktionieren, wenn es einen Standort gibt, der gross genug ist, um die Kosten zu rechtfertigen, und eine stabile Leitung, die sie speist. Sobald sich das Netz verteilt (Fernwärme mit vielen kleinen Standorten, Energieversorger mit Unterwerken über LTE, standortübergreifende Logistik), sprechen drei Dinge dagegen:

• Wirtschaftlichkeit
  Preise pro Standort oder pro Appliance skalieren über Hunderte kleiner Standorte nicht linear. Der grösste Teil des Sicherheitsnutzens entfällt auf die ersten ein, zwei Standorte; die vielen übrigen lassen sich schwer rechtfertigen.
• Bandbreite
  Kontinuierliches Spiegeln braucht eine stabile Leitung von jedem Standort zurück zur Appliance. LTE-Backhaul und schmalbandige Anbindungen von Wärmenetzen liefern sie nicht zuverlässig.
• Betreibbarkeit
  Standortübergreifendes Tuning, um Fehlalarme zu unterdrücken, und danach der laufende Unterhalt sind eine eigene Aufgabe. Ein verteilter Betreiber hat selten ein vollständiges Security-Team. Die Erkennung muss auch ohne ein solches funktionieren.

Vier Designentscheidungen

Jede von ihnen folgt aus demselben Ausgangspunkt: viele kleine Standorte statt eines grossen.

Die Erkennung läuft am Edge, in einem Container, auf Hardware, die bereits vor Ort ist. Industrie-Switches, Firewalls und Gateways mit einer Container-Runtime können neben der Weiterleitungsebene eine kleine Erkennungs-Pipeline beherbergen. Keine zweite Appliance pro Standort, kein SPAN-Port zurück ins Rechenzentrum.

Die Baselines kalibrieren sich selbst. Jeder Standort lernt seinen eigenen Normalzustand aus seinem eigenen Verkehr: die OT-Protokolle, die Geräterollen, den täglichen Rhythmus der Anlage davor. Die Erkennung funktioniert ohne Tuning durch Fachleute und kalibriert neu, wenn sich die Anlage verändert.

Nur Ereignisse verlassen den Standort. Das Edge-Gerät hält einen fortlaufenden Puffer von 30–60 Sekunden; überschreitet etwas eine lokale Verdachtsschwelle, wird es gespeichert (der Schritt record-on-suspicion), und nur wenn die lokale Analyse eine ernsthafte Anomalie bestätigt, wandert ein verpacktes Beweisstück ins zentrale System. Der Bandbreitenverbrauch folgt den tatsächlichen Vorfällen statt dem Dauerverkehr: dem Budget, das dünne OT-Leitungen zuverlässig bieten können.

On-Premises-LLMs liefern Alarmkontext und Interaktion in natürlicher Sprache. Betreiber sensibler OT-Umgebungen können den Datenverkehr oft nicht an ein Cloud-Modell senden. Das Projekt prüft, welche lokalen Modelle in welcher Grösse eine nützliche Alarm-Triage und Fragen und Antworten für Betreiber bewältigen, ohne dass etwas den Standort verlässt.

Was die Forschung beantworten muss

Die vier Entscheidungen oben sind die Designabsicht. Die Forschung klärt, ob jede einzelne in der Praxis erreichbar ist:

1. RQ-1
   Kann die Selbstkalibrierung auf OT-Verkehr zuverlässig konvergieren? Industrieprotokolle sind periodisch und in ihrem Asset-Bestand stabil, wie es IT-Verkehr nicht ist: vielversprechend für unüberwachte Baselines, aber in der Präzision, die ein IDS braucht, noch unbewiesen.
2. RQ-2
   Kann vorhandene Edge-Hardware eine sinnvolle Erkennung leisten, ohne das Netz zu beeinträchtigen, auf dem sie sitzt? Die Container-Runtime auf einem Switch im Unterwerk ist der einfache Teil; dort Anomalieerkennung unter realen Paketraten zu betreiben, ohne die Weiterleitungsebene anzutasten, ist die offene Frage.
3. RQ-3
   Lassen sich LLMs on-premises für die Alarmkontextualisierung betreiben? Welche Modelle, in welcher Grösse, mit welcher Latenz und Genauigkeit, und ob der resultierende Footprint einer ist, den ein typischer OT-Standort beherbergen kann.