Engineering · OT-Audit-Appliance
Eine Box, die mithört — und den Audit-Nachweis mitliefert.
Aus meiner Ingenieurspraxis heraus habe ich ein eigenes Werkzeug entwickelt: eine tragbare, rein passive Appliance für Sicherheits- und Compliance-Audits im Anlagennetz. Sie inventarisiert automatisch die kommunizierenden Geräte, überwacht den industriellen Datenverkehr, meldet Auffälligkeiten verständlich — und erzeugt den prüffähigen Bericht für Ihr NIS2-Risikomanagement. Komplett vor Ort, ohne Cloud.
01 Der Ausgangspunkt
Aus der Praxis gebaut, nicht am Reißbrett.
In der Beratung sehe ich immer wieder dasselbe Grundproblem: Bevor über NIS2-Maßnahmen, Compliance 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 habe ich als Ingenieur selbst ein 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 verlangen NIS2 und IEC 62443 ein vollständiges Asset-Inventar und nachweisbares Risikomanagement. Viele Unternehmen stehen vor genau diesem Widerspruch: Sie sollen Sichtbarkeit schaffen, dürfen die Anlage dabei aber nicht anfassen.
Die Idee
Eine Appliance, die ausschließlich mithört — eine Kopie des Netzwerkverkehrs über einen SPAN-Port und die Log-Meldungen von Firewalls, Switches und Servern. Aus diesem reinen Zuhören baut sie ein vollständiges Lagebild: Geräte, Kommunikationsbeziehungen, Schwachstellen, Auffälligkeiten. Sie sendet selbst nichts ins OT-Netz und kann die Produktion technisch nicht stören.
02 Kernmerkmale
Sechs Eigenschaften, die den Unterschied machen.
Rein passiv
Die Box 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.
NIS2-fokussiert
Ein automatisches Inventar, ein fertiger PDF-Report, gezielte Audit-Vorbereitung — aufbereitet für das NIS2-Risikomanagement und nutzbar für IEC 62443, BSI und weitere Rahmenwerke.
Audit-fertig
Der vorzeigbare Nachweis auf Knopfdruck: Executive 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 Box leitet ihre Erkenntnisse per Syslog, CEF, LEEF oder Webhook an das zentrale SIEM weiter.
03 Funktionsweise
Von der Leitung 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.
Erfassen
Unterschiedliche Log-Formate werden in ein einheitliches Ereignis übersetzt (Normalisierung).
Bewerten
Baseline (was ist normal?), Regeln (was ist verboten?) und Prozess-Anomalien prüfen jedes Ereignis.
Melden
Auffälliges wird zum Alert — mit Asset-Rolle, Schwachstellen, Bedrohungs-Treffern und Priorität.
Korrelieren
Zusammenhängende Alerts werden zu einem Vorfall gebündelt und in MITRE ATT&CK for ICS eingeordnet.
04 Blick ins Produkt
So sieht das im Einsatz aus.
Drei Ausschnitte aus der Oberfläche — aufgenommen in einer simulierten Anlagenumgebung, in der die Appliance einen laufenden Angriff erkennt.
ALLE AUFNAHMEN AUS EINER SIMULATIONSUMGEBUNG — KEINE KUNDENDATEN.
05 Module
Jede Sicht ein eigenes Werkzeug.
Die Appliance 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 — die Grundlage jedes Audits. 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. Verbotene Zonenübergänge werden sofort rot hervorgehoben — der Klassiker im OT-Audit.
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-Downloads 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 Audit-Report
Der fertige Nachweis als PDF auf Knopfdruck — mit Executive Summary, Vorfällen, MITRE-Übersicht und Zonen-Status, gemappt auf NIS2, IEC 62443 und BSI.
06 Das Herzstück
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 habe ich eine zusätzliche Ebene darüber gebaut und ihr einen Namen gegeben: 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.
Vier Fragen, die FlowSR aus rohen Flows beantwortet
Geräte-Rolle
Ist das eine SPS, ein HMI, ein Historian, eine Engineering-Workstation oder ein Netzgerät? — erkannt am Kommunikations-Fingerabdruck.
Funktion
Tut eine Verbindung vermutlich Lesen, Schreiben, einen Programm-Download oder einen Steuerbefehl?
Verkehrsform
Zyklische Steuerung, Massentransfer, Abfrage/Antwort oder Datenstrom — unabhängig vom verwendeten Port.
Maschine vs. Mensch
Steckt hinter einer Verbindung ein automatischer Prozess oder ein Mensch am Keyboard?
Aus einer Verbindung wird Bedeutung.
Aus einer nackten Verbindung wird eine verständliche Einordnung — etwa „vermutlich Engineering-Workstation → SPS, Programm-Download, manuell, außerhalb der Schicht — prüfenswert". Ohne neue Hardware, ohne Cloud, ohne Eingriff in die Produktion.
Und alles Bestehende wird klüger.
Die Baseline-, Regel- und Prozess-Anomalie-Engines wissen, was normal und was auffällig ist — FlowSR legt die fehlende semantische Ebene darüber und sagt, was ein Gerät ist und was ein Flow tut. So wird aus „eine Verbindung ist ungewöhnlich" ein priorisierbares „Schreibzugriff auf eine vermutete SPS".
FlowSR reichert die Netzwerk-Landkarte nach Rollen an, ergänzt Alerts und Vorfälle um Kontext und Blast-Radius und ermöglicht rollenbewusstes Baselining — etwa, wenn eine SPS, die sonst nur antwortet, plötzlich selbst Verbindungen aufbaut.
Das Prinzip: Maximum aus Minimum. Der Hebel ist genau dort am größten, wo am wenigsten Sensorik vorhanden ist.
07 Einsatz & Rolle
Wo die Appliance zum Einsatz kommt.
Im Assessment
Ich setze die Appliance in meinen Assessments dort ein, wo sie der schnellste Weg zum Lagebild ist — tragbar, in Minuten angeschlossen, rückwirkungsfrei. Das Ergebnis fließt direkt in Ihr NIS2-Risikomanagement: Asset-Inventar, Kommunikationsmatrix, Schwachstellen-Überblick, prüffähiger Bericht.
Im Dauerbetrieb
Für das dauerhafte OT-Monitoring empfehle ich herstellerunabhängig die Plattform, die zu Ihrer Anlage, Ihrem Team und Ihrem Budget passt — ob Claroty, Nozomi, Dragos oder eine andere. Die Appliance ersetzt diese Entscheidung nicht; sie liefert die Datengrundlage, auf der Sie sie fundiert treffen.
Zugriffskontrolle
Eine Box im sensiblen OT-Netz muss selbst höchsten Ansprüchen genügen: Login mit Rollen (RBAC), API-Token und ein lückenloses Audit-Log jeder einzelnen 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 audit-tauglich.
Neugierig, wie das in Ihrer Anlage aussähe?
Ich zeige die Appliance gerne in einer Live-Demonstration und bespreche, wie sich passive OT-Visibility konkret auf Ihre Umgebung übertragen lässt.