Engineering · Eigenentwickelte Plattform

OT-Netzwerkmonitoring, das zuhört — und Anomalien erkennt.

Aus der Ingenieurspraxis heraus hat Aganum eine eigene Plattform für OT-Netzwerkmonitoring mit Anomalieerkennung entwickelt. Sie arbeitet rein passiv: Sie inventarisiert die kommunizierenden Geräte, kartiert die Netztopologie entlang des Purdue-Modells, versteht die industriellen Protokolle — und meldet Auffälligkeiten verständlich, mit Bericht auf Knopfdruck. Vollständig on-premise, ohne Cloud.

Rein passiv On-Premise Anomalieerkennung Kein Cloud-Zwang

Aus der Praxis gebaut, nicht am Reißbrett.

In Projekten zeigt sich immer wieder dasselbe Grundproblem: Bevor über Maßnahmen oder Architektur gesprochen werden kann, fehlt das Fundament — ein vollständiges, belastbares Bild davon, was im OT-Netz überhaupt existiert und miteinander kommuniziert. Klassische IT-Werkzeuge passen dafür nicht, weil sie in einer Produktionsanlage Schaden anrichten können. Also hat Aganum ein eigenes Werkzeug gebaut, das genau diese Lücke schließt.

Das Problem

Aktive Scans sind in der OT tabu — jeder Eingriff ins Netz kann eine Steuerung stören oder einen Anlagenstillstand auslösen. Gleichzeitig braucht jede fundierte Sicherheitsentscheidung ein vollständiges Asset-Inventar und ein ehrliches Bild der Kommunikationsbeziehungen. Viele Unternehmen stehen vor genau diesem Widerspruch: Sie sollen Sichtbarkeit schaffen, dürfen die Anlage dabei aber nicht anfassen.

Die Idee

Eine Plattform, die ausschließlich zuhört. Sie wertet aus, was das Netz ohnehin preisgibt — Verkehr und Log-Meldungen —, und baut daraus ein vollständiges Lagebild: Geräte, Kommunikationsbeziehungen, Schwachstellen, Anomalien. Sie sendet selbst nichts ins OT-Netz und kann die Produktion technisch nicht stören.

Sechs Eigenschaften, die den Unterschied machen.

Rein passiv

Die Plattform hört nur zu und sendet niemals Pakete ins OT-Netz. Sie kann die Produktion technisch nicht stören, blockieren oder auslösen — der wichtigste Grundsatz in jeder Anlage.

On-Premise

Kein Cloud-Backend, kein „Phone-Home". Alle Daten bleiben im Werk. Internet ist nur optional, um Schwachstellen- und Bedrohungslisten zu aktualisieren — und auch das geht offline.

Anomalieerkennung

Baseline, Regeln und Prozess-Analytik prüfen jedes Ereignis: Was ist normal, was ist verboten, was fällt aus dem Rahmen? Auffälliges wird gemeldet — verständlich eingeordnet statt als Rohdaten-Flut.

Bericht auf Knopfdruck

Das vorzeigbare Lagebild als PDF: Management-Summary, Vorfälle, kritische Meldungen, MITRE-Übersicht und Zonen-Status — statt tagelanger Handarbeit in Excel.

OT-nativ

Versteht die industrielle Sprache der Maschinen (Modbus, S7, EtherNet/IP, DNP3 …), erkennt Prozess-Anomalien und ordnet jedes Gerät dem Purdue-Modell zu — nicht nur den IT-Verkehr drumherum.

Ergänzt das SIEM

Kein Konkurrent zu bestehenden Sicherheitssystemen, sondern der OT-Zulieferer: Die Plattform leitet ihre Erkenntnisse per Syslog, CEF, LEEF oder Webhook an das zentrale SIEM weiter.

Vom Rohdatenstrom zum bewertbaren Vorfall.

Jede einzelne Beobachtung durchläuft dieselbe Kette. Das ist der Kern: Aus einem rohen Ereignis wird Schritt für Schritt ein verständlicher, eingeordneter Vorfall — angereichert mit Asset-Rolle, offenen Schwachstellen und Bedrohungs-Kontext.

01

Erfassen

Unterschiedliche Log-Formate werden in ein einheitliches Ereignis übersetzt (Normalisierung).

02

Bewerten

Baseline (was ist normal?), Regeln (was ist verboten?) und Prozess-Anomalien prüfen jedes Ereignis.

03

Melden

Auffälliges wird zum Alarm — mit Asset-Rolle, Schwachstellen, Bedrohungs-Treffern und Priorität.

04

Korrelieren

Zusammenhängende Alarme werden zu einem Vorfall gebündelt und in MITRE ATT&CK for ICS eingeordnet.

So sieht das im Einsatz aus.

Drei Ausschnitte aus der Oberfläche — aufgenommen in einer simulierten Anlagenumgebung, in der die Plattform einen laufenden Angriff erkennt.

Netzwerk-Topologie in der Purdue-Ansicht: eine Engineering-Workstation baut auffällige Verbindungen zu zehn Steuerungen auf, rot markiert
FIG. 01 Purdue-Topologie: Eine Engineering-Workstation kontaktiert plötzlich jede SPS im Segment — die Plattform markiert jede dieser Verbindungen als Anomalie. · simulierte Anlagenumgebung
Vier Protokoll-Karten (S7comm, Modbus/TCP, EtherNet/IP, DNP3) mit Event-Zahlen, Lese-/Schreib-Verhältnis und erkannten Anomalien
FIG. 02 OT-Protokolle voll dekodiert: Lese- gegen Schreibzugriffe je Protokoll, Ports, letzte Aktivität — und die Anomalien, die aus dem Rahmen fallen. · simulierte Anlagenumgebung
MITRE-ATT&CK-Technik-Panel T0812 Default Credentials mit Statistik, Gegenmaßnahmen, Threat Groups und ausgelösten Alarmen
FIG. 03 MITRE ATT&CK for ICS: Jeder Treffer wird der Technik zugeordnet — inklusive Gegenmaßnahmen, bekannter Angreifergruppen und der ausgelösten Alarme. · simulierte Anlagenumgebung

ALLE AUFNAHMEN AUS EINER SIMULATIONSUMGEBUNG — KEINE KUNDENDATEN.

Jede Sicht ein eigenes Werkzeug.

Die Plattform bündelt mehrere spezialisierte Module — jedes ist eine eigene Perspektive auf dieselben mitgehörten Daten.

01 Asset-Inventar

Das automatische Verzeichnis aller Geräte im Netz. Aus jedem Ereignis werden Geräte erkannt und eingetragen, pflegbar mit Zone, Kritikalität und Owner.

02 Netzwerk-Topologie

Eine interaktive Landkarte: Wer spricht mit wem? Umschaltbar in die Purdue-Modell-Ansicht. Unerwünschte Zonenübergänge werden sofort rot hervorgehoben.

03 OT-Protokolle

Die Sicht auf die industrielle Sprache der Maschinen. Erkennt Protokolle und Funktionscodes — etwa Lese- gegenüber Schreibbefehl an eine Steuerung oder Programm-Transfers im Netz.

04 Prozess-Anomalien

OT-spezifische Auffälligkeiten direkt am Produktionsprozess: plötzlicher Stillstand, langsame Drift, Aktivität außerhalb der Schicht oder ein Messwert außerhalb des erlaubten Bereichs.

05 Schwachstellen

Erkannte Produkte werden mit der offiziellen CVE-Datenbank und der „wird aktiv ausgenutzt"-Liste (CISA KEV) abgeglichen — priorisiert nach tatsächlicher Gefährdung.

06 Bericht

Das fertige Lagebild als PDF auf Knopfdruck — mit Management-Summary, Vorfällen, MITRE-Übersicht und Zonen-Status.

FlowSR — wo deterministische Methoden an die Wand laufen.

Regeln, Signaturen, Baselines — deterministische Methoden sind das Fundament jeder Erkennung, und sie sind gut. Aber in realen Anlagen sind sie nicht genug: Der Verkehr ist unvollständig, die Sensorik lückenhaft, und die entscheidende Frage bleibt offen — was ist dieses Gerät eigentlich, und was tut diese Verbindung?

Also bekam die Plattform eine zusätzliche Ebene darüber: FlowSR — Flow Signal Reconstruction. Ein Machine-Learning-Kern, der Netzwerk-Flows rekonstruiert und Geräte-Rollen aus unvollständigem Verkehr ableitet. Wo die deterministischen Methoden an die Wand laufen, füllt FlowSR die Lücken.

FlowSR – Flow Signal Reconstruction Aus minimalen Flow-Daten rekonstruiert FlowSR sechs Antworten: Geräte-Rolle, Funktion grob und fein, Verkehrsform, zeitlicher Kontext sowie Maschine oder Mensch. MINIMALE EINGABE Nur NetFlow oder nur Firewall BYTES · DAUER · RICHTUNG · PORT (± MAC / HOSTNAME) FLOW SIGNAL RECONSTRUCTION FlowSR rekonstruiert Flows aus unvollständigem Verkehr Geräte-Rolle 01 Funktion, grob 02 Funktion, fein 03 Verkehrsform 04 Zeitlicher Kontext 05 Maschine / Mensch 06 MAXIMUM AUS MINIMUM
SCHEMA 01 Flow Signal Reconstruction: Aus minimalen Flow-Daten — Bytes, Dauer, Richtung, Port — rekonstruiert FlowSR die Antworten, die sonst nur teure Tiefenanalyse liefert.

Sechs Modellfamilien, sechs Antworten aus rohen Flows

Geräte-Rolle

SPS, HMI/SCADA, Engineering-Workstation, Historian, Netzgerät oder IT-Server — erkannt am Kommunikations-Fingerabdruck.

Funktion, grob

Liest eine Verbindung Werte — oder schreibt und steuert sie?

Funktion, fein

Schreibwert, Programm-Transfer, Steuerbefehl oder Konfiguration.

Verkehrsform

Zyklische Steuerung, Massentransfer, Abfrage/Antwort oder Datenstrom — unabhängig vom verwendeten Port.

Zeitlicher Kontext

Löst mehrdeutige Flowmuster über Periodizität, Volumenverlauf und Off-Hours-Verhalten auf.

Maschine vs. Mensch

Steckt hinter einer Verbindung ein automatischer Prozess oder ein Mensch am Keyboard?

Die Erweiterung · Tiefen-Analyse

Aus Verbindungen wird Prozessverständnis.

FlowSR arbeitet in zwei Schichten: Die sechs Modellfamilien lesen jeden Flow einzeln — was ist das Gerät, was tut die Verbindung. Die Tiefen-Analyse liest darüber die zeitliche Abfolge und die Struktur des gesamten Netzes — und beantwortet, was kein einzelner Flow beantworten kann.

Schicht 2 · Tiefen-Analyse

Sequenzlernen

die zeitliche Abfolge

Graphlernen

die Netzstruktur

Fusion

beide Sichten vereint

Schicht 1 · Sechs Modellfamilien

liest jeden Flow einzeln — Rolle, Funktion, Form, Kontext, Akteur

SCHEMA 02 Zwei Schichten: Die Modellfamilien deuten jeden Flow einzeln — die Tiefen-Analyse liest Abfolge und Netzstruktur darüber und vereint beide Sichten.

Sieben Fragen, die die Tiefen-Analyse beantwortet

Beziehungszweck

Wozu existiert diese Verbindung im Prozess — Steuerung, Überwachung, Engineering, Datenhaltung?

Prozessphase

In welcher Betriebsphase befindet sich die Kommunikation — Anlauf, Normalbetrieb, Eingriff?

Asset-Rolle, grob

Die Rollenzuordnung der sechs Familien, bestätigt aus der zweiten, unabhängigen Sicht.

Asset-Rolle, fein

Feinere Rollenbilder — welche Aufgabe eine Station im Verbund übernimmt.

Kritikalität

Welche Assets tragen den Prozess — eine Rangordnung aus der Kommunikationsstruktur.

Verhaltensänderung

Hat ein Asset sein Verhalten gegenüber der eigenen Geschichte verändert?

Künftige Beziehungen

Welche Kommunikationsbeziehungen das Werk als Nächstes zeigen wird — der Blick nach vorn.

Aus einer Verbindung wird Bedeutung. Aus einer bloßen Verbindung wird eine prüfbare Einordnung: Engineering-Workstation zu SPS, Programm-Transfer, manuell, außerhalb der Schicht.

FlowSR als semantische Ebene FlowSR legt sich als semantische Ebene über Baseline-, Regel- und Prozess-Anomalie-Engine und macht aus einer ungewöhnlichen Verbindung einen priorisierbaren Befund. SEMANTISCHE EBENE FlowSR Was ist das Gerät? Was tut der Flow? 01 Baseline-Engine kennt den Normalzustand 02 Regel-Engine kennt das Verbotene 03 Prozess-Anomalien kennt den Prozess BESTEHENDE ENGINES · UNVERÄNDERT »Eine Verbindung ist ungewöhnlich« »Schreibzugriff auf eine SPS« PRIORISIERBAR
SCHEMA 03 FlowSR als semantische Ebene über den unveränderten Engines — aus »ungewöhnlich« wird ein priorisierbarer Befund.

Das Prinzip: Maximum aus Minimum. Der Hebel ist genau dort am größten, wo am wenigsten Sensorik vorhanden ist.

Wo die Plattform zum Einsatz kommt.

Im Projekt

Aganum setzt die Plattform in Visibility-Projekten dort ein, wo sie der schnellste Weg zum Erst-Lagebild ist. Das Ergebnis fließt direkt in die Entscheidungsgrundlage: Asset-Inventar, Kommunikationsmatrix, Schwachstellen-Überblick, Bericht.

Neben etablierten Plattformen

Die eigene Plattform ersetzt keine herstellerneutrale Empfehlung: Wo Claroty, Nozomi, Dragos oder eine andere Lösung besser zur Anlage passt, wird sie empfohlen und aufgebaut. Die Toolauswahl folgt der Anlage — nicht dem eigenen Produkt.

Zugriffskontrolle

Eine Plattform im sensiblen OT-Netz muss selbst hohen Ansprüchen genügen: Login mit Rollen (RBAC), API-Token und ein vollständiges Protokoll jeder Aktion — von Anfang an Teil des Designs.

Nachvollziehbar

Jede Erkennung ist begründet und bis zum auslösenden Ereignis rückverfolgbar — keine Blackbox. Genau das macht die Befunde belastbar.

Neugierig, wie das in Ihrer Anlage aussähe?

Aganum zeigt die Plattform gerne in einer Live-Demonstration — und bespricht, wie sich passives OT-Netzwerkmonitoring konkret auf Ihre Umgebung übertragen lässt.