OT und IoT

Ja, ab dem Pro-Plan. NetSenX liest Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm aus passivem Mitschnitt an einem SPAN- oder TAP-Port. Als OT klassifizierte Geräte werden nie aktiv abgefragt — kein Risiko für SPS oder SCADA-Systeme.

Ja, mit passiver Überwachung: Der Sensor liest eine Kopie des Verkehrs von einem SPAN-Port oder TAP und schickt nie etwas an die Steuerungen. So arbeitet NetSenX ab dem Pro-Plan, und als OT eingestufte Geräte fragt es nie aktiv ab.

Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm, aus passiver Erfassung, im Pro-Plan und darüber.

Eine NetSenX-Appliance ist nicht nötig: Der Agent ist Software auf einem Host Ihrer Wahl. Ein Agent an einem SPAN- oder TAP-Port beobachtet das ganze Segment und zählt als ein Gerät.

NIS2 gilt für Einrichtungen in Sektoren wie Energie, Verkehr, Trinkwasser, Gesundheit und Herstellung bestimmter Waren (Anhänge I und II der Richtlinie (EU) 2022/2555). Die Maßnahmen aus Art. 21 betreffen die Netz- und Informationssysteme, die eine Einrichtung für ihren Betrieb nutzt, und dazu können OT-Systeme gehören. Klären Sie den Geltungsbereich mit Ihrer nationalen Behörde.

Passive Überwachung kann das nicht, weil sie nur eine Kopie des Verkehrs mithört und nie etwas an die Steuerungen sendet. Aktives Scannen ist etwas anderes: Manche ältere SPS und Fernwirkstationen stürzen ab, starten neu oder gehen in einen Fehlerzustand, wenn ein Discovery-Tool oder Schwachstellenscanner sie abfragt. Deshalb halten viele Werke Scanner ganz aus dem Steuerungsnetz heraus. Holen Sie die Kopie von einem SPAN-Port eines Industrie-Switches oder von einem passiven Netzwerk-TAP und klären Sie mit dem Switch-Hersteller, dass das Spiegeln einen alten Switch nicht überlastet. NetSenX liest ab dem Pro-Plan Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm aus der passiven Erfassung und fragt als OT eingestufte Geräte nie aktiv ab. Auf den Steuerungen wird nichts installiert, und keine ihrer Einstellungen ändert sich.

Ja. Kameras, Drucker, Türsteuerungen, Bildschirme und Sensoren sind oft alt, werden selten aktualisiert und lassen sich nicht mit einem Endpunkt-Agenten ausstatten. Das macht sie zu einem häufigen Einfallstor und zu einem guten Versteck für einen Angreifer, der schon im Netz ist. Beginnen Sie mit den kostenlosen Schritten: Geräte erfassen, Standardpasswörter ändern, Firmware aktualisieren, ungenutzte Cloud-Funktionen abschalten und die Geräte in ein eigenes Netzsegment legen, dessen Regeln nur das Nötige erlauben. Die Überwachung zeigt dann, ob diese Regeln halten. Ein Sensor in diesem Segment sieht ihren Verkehr, ohne die Geräte zu berühren; NetSenX erkennt Scans, Beaconing und ungewöhnliche ausgehende Datenmengen von ihnen, in jedem Plan, und die Netzwerkkarte listet die Geräte, die es kommunizieren sieht. Ein Gerät, das schweigt oder in einem nicht gespiegelten Segment hängt, bleibt unsichtbar.

Ein geringeres, aber ja. Ein eigenes virtuelles LAN (VLAN) hilft nur, wenn die Regeln zwischen ihm und dem übrigen Netz streng sind, und Kameras und Rekorder bekommen oft großzügige Ausnahmen, damit Mitarbeitende das Bild von jedem PC oder Telefon aus sehen können. Außerdem brauchen sie meist Internetzugang für Apps und Updates, und das ist zugleich ein Weg nach draußen für einen Angreifer. Lassen Sie nur den Arbeitsplatz für die Bildansicht oder den Videoserver zu den Kameras, sperren Sie das Kamera-VLAN gegenüber allem anderen, blockieren Sie nicht benötigten Internetzugang, ändern Sie Standardpasswörter und aktualisieren Sie die Firmware. Ein Sensor in diesem VLAN sieht ihren Verkehr; NetSenX erkennt Scans, Beaconing und ungewöhnliche ausgehende Datenmengen von ihnen, in jedem Plan, sodass eine Kamera auffällt, die plötzlich neue Ziele anspricht.

Beobachten Sie den Verkehr zu und von den Steuerungen, denn eine speicherprogrammierbare Steuerung (SPS) führt so gut wie kein eigenes Sicherheitsprotokoll. Die nützlichen Signale sind einfach: ein Schreibzugriff oder Programm-Download von einem Rechner, der nicht Ihre Engineering-Station ist, ein ungeplanter Stopp- oder Startbefehl, Büro-PCs, die direkt mit Steuerungen sprechen, und Aktivität nachts oder am Wochenende, wenn niemand an der Linie arbeitet. Beginnen Sie mit kostenlosen Schritten: Legen Sie fest, welche Stationen jede SPS programmieren dürfen, prüfen Sie, dass das Büronetz das Steuerungsnetz nicht erreicht, und lassen Sie die Betriebsartenschalter der Steuerungen auf RUN, wo Ihre Hardware sie hat. Ab dem Pro-Plan liest NetSenX Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm von einem SPAN- oder TAP-Port und löst vier Arten von OT-Alarmen aus: unerlaubte Schreibzugriffe, Verkehr über die Ebenen des Werksnetzes hinweg, OT-Aktivität außerhalb der Arbeitszeit und S7comm-Befehle. Es fragt die Steuerungen nie ab und sieht weder serielle Verbindungen noch Segmente, die Sie nicht spiegeln.

Weil es weder Authentifizierung noch Verschlüsselung kennt: Jedes Gerät, das eine Modbus/TCP-Steuerung erreicht, kann ihre Werte lesen und, sofern die Steuerung es nicht selbst einschränkt, ihre Spulen und Register beschreiben. Modbus wurde 1979 für serielle Verbindungen zwischen vertrauenswürdigen Geräten entworfen, lange bevor Steuerungsnetze mit Büronetzen und dem Internet verbunden wurden. Eine abgesicherte Variante mit TLS gibt es, aber nur wenige installierte Geräte unterstützen sie. In der Praxis schützen Sie Modbus von außen: Port 502 gehört nicht ins Internet, nur benannte Engineering- und SCADA-Hosts dürfen die Steuerungen erreichen, und einen Schreibschutz der SPS sollten Sie nutzen, wo es ihn gibt. Da der Verkehr unverschlüsselt ist, kann ein passiver Sensor lesen, welche Station von welcher Steuerung liest oder auf sie schreibt. NetSenX tut das ab dem Pro-Plan und alarmiert, wenn ein Host schreibt, der nicht schreiben darf; es ändert weder das Protokoll noch blockiert es den Befehl.

Sie brauchen etwas, das das Industrieprotokoll auf der Leitung liest und weiß, welche Hosts schreiben dürfen, denn die SPS nimmt den Schreibzugriff normalerweise klaglos an und protokolliert nichts. Legen Sie zuerst fest, welche Stationen überhaupt Einstellungen ändern sollen: meist eine oder zwei Engineering-Workstations sowie die SCADA- oder HMI-Server. Setzen Sie das dann, wo möglich, im Netz durch, mit Firewall-Regeln, die nur diese Hosts zu den Steuerungen lassen. Die Überwachung deckt ab, was die Regeln übersehen: ein an die Linie gestecktes Notebook, einen Büro-PC mit vergessener Route, Schadsoftware auf einer erlaubten Station. Ab dem Pro-Plan liest NetSenX Schreibanfragen aus der passiven Erfassung an einem SPAN- oder TAP-Port und alarmiert, wenn ein Schreibzugriff von einem Host kommt, der nicht schreiben darf, mit Quelle, Steuerung, Funktion und Uhrzeit. Den geschriebenen Wert und die Person an der Tastatur erfasst es nicht.

Die, die eine Änderung am Prozess bedeuten: ein Schreibzugriff oder Programm-Download von einem unerwarteten Rechner, eine Steuerung, die gestoppt, gestartet oder in eine andere Betriebsart geschaltet wird, Büroverkehr, der die Steuerungsebene erreicht, und all das außerhalb der Arbeitszeit. Im Normalbetrieb kommt das selten vor, deshalb verdient jeder dieser Alarme einen Anruf bei der für die Linie verantwortlichen Person. Alarme zu Datenmengen oder neuen Zielen sind ebenfalls wichtig, aber auf der IT-Seite, wo die meisten Angriffe auf Werke beginnen. Legen Sie vorab fest, wer OT-Alarme erhält, wie schnell jemand hinschaut und dass niemand einen Produktionsrechner ohne Rücksprache mit der Schichtleitung vom Netz nimmt, denn eine abrupte Trennung kann mehr kosten als der Alarm. Ab dem Pro-Plan löst NetSenX genau diese OT-Alarme aus: unerlaubte Schreibzugriffe, Verkehr über Ebenen des Werksnetzes hinweg, OT-Aktivität außerhalb der Arbeitszeit und S7comm-Befehle, neben den Alarmen zu Beaconing, Scans, lateraler Bewegung und ungewöhnlichen ausgehenden Datenmengen, die es in jedem Plan auslöst.

Kombinieren Sie eine Aufzeichnung, wann Ihre Ingenieure tatsächlich an den Steuerungen arbeiten, mit einem Sensor, der Programm-Downloads und Schreibzugriffe im Netz sieht. Eine Programmänderung sonntags um 2:00 Uhr beweist keinen Angriff, denn Wartung findet oft statt, wenn die Linie steht, aber am nächsten Morgen sollte jemand sie erklären können. Führen Sie ein einfaches Änderungsprotokoll mit den geplanten Wartungsfenstern, vergleichen Sie es mit dem, was das Netz zeigt, und bewahren Sie von jedem SPS-Programm eine geprüfte Kopie offline auf, um vergleichen und wiederherstellen zu können. Manche Steuerungen melden eine Programmänderung auch an das SCADA-System. Ab dem Pro-Plan markiert NetSenX OT-Aktivität außerhalb der Arbeitszeit und dekodiert S7comm-Anfragen wie den Download eines Programmbausteins samt Bausteinname, von einem SPAN- oder TAP-Port. Den Inhalt des Programms liest es nicht, und Versionen vergleicht es nicht; das erledigt Ihre Engineering-Software.

Ja, wenn der Stoppbefehl über das Netz in S7comm läuft, dem Protokoll, das Siemens-S7-Steuerungen für Programmierung und Diagnose nutzen. S7comm ist unverschlüsselt, daher kann ein passiver Sensor, der eine Kopie des Verkehrs erhält, die Anfrage als Stopp erkennen, zusammen mit dem sendenden Rechner und der Uhrzeit. Ein Stopp über den Schalter oder das Bedienfeld der Steuerung selbst läuft nie über das Netz, also sieht ihn kein Sensor. Neuere Steuerungen können einen geschützten Nachfolger nutzen, S7comm-plus; fragen Sie uns, bevor Sie sich bei solchem Verkehr auf NetSenX verlassen. Ab dem Pro-Plan dekodiert NetSenX S7comm-Anfragen in Befehlsnamen wie SPS-Stopp, Variablen-Schreibzugriff oder Download eines Programmbausteins und löst einen S7comm-Befehlsalarm aus, von einem SPAN- oder TAP-Port, ohne etwas an die SPS zu senden. Es informiert Ihre Ingenieure; den Befehl blockiert es nicht.

Sie kann zeigen, welcher Rechner den Schreibzugriff gesendet hat und wann, und das reicht meist, um die Person zu finden. Die meisten Industrieprotokolle übertragen keinen Benutzernamen, das Netz kennt also nur die Quelladresse. Die Verbindung zur Person liefern der Audit-Trail von HMI oder SCADA, das Protokoll der Engineering-Software und der Schichtplan. Damit das später möglich ist, geben Sie jeder Engineering-Station eine feste Adresse, verlangen Sie persönliche Anmeldungen an HMI und SCADA und bewahren Sie deren Protokolle so lange auf wie Ihre Qualitätsaufzeichnungen. Ab dem Pro-Plan liest NetSenX Schreibzugriffe aus der passiven Erfassung an einem SPAN- oder TAP-Port und alarmiert, wenn der Schreibende nicht schreiben darf, mit Quellhost, Steuerung, Funktionscode und Uhrzeit. Den geschriebenen Wert erfasst es nicht, und es identifiziert nie eine Person: Es beobachtet Geräte und Verbindungen, keine Menschen.

Nein. NetSenX hält fest, dass ein Schreibzugriff stattfand, von welchem Host, auf welche Steuerung, mit welchem Funktionscode und wann, aber nicht den geschriebenen Wert und nicht den Inhalt eines Programmbausteins. Das ist eine bewusste Grenze: Prozesswerte und Programme sind Ihr Know-how, und ein Alarm braucht das Wer und Wann, nicht das Rezept. Wenn Sie die Werte brauchen, etwa um eine fehlerhafte Charge nachzuvollziehen, kommen sie aus dem Historian, dem Audit-Trail von SCADA oder HMI oder aus der Diagnose der Steuerung. Planen Sie das, bevor Sie es brauchen: Prüfen Sie, wie lange Ihr Historian Daten aufbewahrt und ob Änderungen am HMI mit Benutzernamen protokolliert werden. NetSenX liest ab dem Pro-Plan Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm aus der passiven Erfassung und sendet nie etwas an die Geräte.

Ja, als eine Beweisquelle unter mehreren. Ein OT-Alarm sagt Ihnen, dass eine Steuerung einen Schreibzugriff von einem Host erhielt, der nicht schreiben darf, einen S7comm-Befehl oder Verkehr außerhalb der Arbeitszeit, mit Quellhost, Steuerung und Uhrzeit. Legen Sie ihn auf eine Zeitachse neben die Historian-Daten, den HMI-Audit-Trail, das Schichtbuch und die Wartungsberichte, dann lässt sich meist eingrenzen, wann und woher eine Änderung kam. Sorgen Sie dafür, dass die Uhren übereinstimmen, denn schon wenige Minuten Abweichung zwischen Systemen machen eine Zeitachse irreführend. Beachten Sie auch, was Alarme nicht abdecken: Ein erlaubter Schreibzugriff während der Schicht löst keinen Alarm aus, daher bleibt der HMI-Audit-Trail Ihre Aufzeichnung der alltäglichen Änderungen. NetSenX bewahrt Alarme für die Alarmhistorie Ihres Plans auf; Sie lesen sie im Dashboard, ab dem Pro-Plan über die API oder ab dem Business-Plan in Ihrem SIEM. Sie enthalten keine geschriebenen Werte und nennen keine Person.

Nein. NetSenX liest fünf Industrieprotokolle, Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm, aber es gibt keinen eigenen Anomaliealarm pro Protokoll, etwa für ungewöhnliches Modbus-Polling oder auffälligen BACnet-Verkehr. Seine OT-Alarme sind vier Arten, die über alles hinweg arbeiten, was es liest: ein Schreibzugriff auf eine Steuerung von einem Host, der nicht schreiben darf, Verkehr über Ebenen des Werksnetzes hinweg, OT-Aktivität außerhalb der Arbeitszeit sowie S7comm-Befehle wie Stopp oder Programm-Download. Zusätzlich beobachten die allgemeinen Erkennungen dieselben Hosts: Beaconing, Scans, laterale Bewegung und ungewöhnliche ausgehende Datenmengen. Verlangt Ihre Risikobewertung eine tiefe, protokollspezifische Anomalieerkennung, etwa für die Fernwirktechnik eines Versorgers, fragen Sie uns vorher, was abgedeckt ist, oder setzen Sie neben NetSenX ein spezialisiertes OT-Werkzeug ein. Die OT-Funktionen gibt es ab dem Pro-Plan.

Nein. NetSenX hört eine Kopie des Verkehrs mit und informiert Ihre Ingenieure; es sitzt nicht im Datenpfad, kann also kein Paket verwerfen, und es greift nie in den Prozess ein. Das ist Absicht: Ein Inline-Gerät, das Industriebefehle blockiert, kann versehentlich eine Linie anhalten, und NetSenX ist kein Sicherheitssystem im Sinne der funktionalen Sicherheit. Schutz vor gefährlichen Befehlen bieten andere Schichten: eine Firewall zwischen Zonen, die nur benannte Hosts durchlässt, Schreibschutz und Betriebsartenschalter an den Steuerungen sowie ein sicherheitsgerichtetes System, das nicht vom Steuerungsnetz abhängt. NetSenX ergänzt ab dem Pro-Plan den Alarm, wenn ein Host schreibt, der nicht schreiben soll, wenn eine Steuerung einen S7comm-Befehl wie einen Stopp erhält oder wenn nachts OT-Verkehr auftaucht, damit jemand vor Beginn der nächsten Schicht nachsehen kann.

Derzeit nicht. NetSenX liest ab dem Pro-Plan aus der passiven Erfassung fünf Industrieprotokolle: Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm. Anderer Industrieverkehr in einem überwachten Segment ist weiterhin als Verbindungen zwischen Hosts sichtbar: Beaconing, Scans, laterale Bewegung und ungewöhnliche ausgehende Datenmengen greifen weiter, und die Netzwerkkarte listet die Geräte. Es fehlt die Dekodierung der Befehle dieses Protokolls, daher decken die OT-Alarme für Schreibzugriffe und Befehle es nicht ab. Läuft Ihr Werk hauptsächlich mit PROFINET, OPC UA oder dem Fernwirkprotokoll IEC 60870-5-104, sagen Sie uns das vor dem Kauf und fragen Sie, was in Ihrem Netz abgedeckt wäre, oder kombinieren Sie NetSenX mit einem Werkzeug, das diese Protokolle dekodiert. Besser, Sie wissen das jetzt, als dass Sie die Lücke in einem Audit entdecken.

Nein. Ein Netzwerksensor sieht den Ethernet- und IP-Verkehr, der ihm gespiegelt wird. Serielle Verbindungen wie Modbus RTU über RS-485, Profibus DP und andere Feldbusse erreichen nie das Ethernet, ihre Befehle liegen also außerhalb seiner Sicht. Sehen kann er das Gateway, das zwischen Ethernet und seriellem Bus übersetzt: wer mit dem Gateway spricht, wann und wie oft. In vielen Werken ist das ein nützliches Signal, denn wer aus dem Netz ein serielles Gerät erreichen will, muss über dieses Gateway gehen. Erfassen Sie Ihre Gateways, schützen Sie sie wie Steuerungen und spiegeln Sie das Segment, in dem sie hängen. NetSenX liest ab dem Pro-Plan Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm aus der passiven Erfassung. Für die serielle Seite verlassen Sie sich auf die Diagnose der Steuerungen selbst und auf abgeschlossene Schaltschränke.

Es bedeutet, dass der Sensor nie ein Paket an ein als OT eingestuftes Gerät sendet: kein Discovery-Scan, kein Portscan, keine Protokollabfrage, kein Anmeldeversuch. Er liest nur eine Kopie des Verkehrs, den Ihre Systeme ohnehin austauschen, abgegriffen an einem SPAN-Port oder Netzwerk-TAP. Aktive Werkzeuge arbeiten anders: Sie stellen jedem Gerät Fragen, und manche ältere SPS, Fernwirkstationen und HMIs reagieren schlecht auf unerwartete Anfragen, von langsamen Antworten bis zum Absturz. Für die Werksleitung heißt das praktisch: Das Einschalten von NetSenX bringt keinen zusätzlichen Verkehr ins Steuerungsnetz und kann den Zustand einer Steuerung nicht ändern, an den Steuerungen selbst braucht es also kein Wartungsfenster. Der Preis: Ein passiver Sensor weiß nur, was Geräte sagen. Eine Steuerung, die nie in einem gespiegelten Segment kommuniziert, wird nicht gesehen. OT-Überwachung gibt es ab dem Pro-Plan.

Nein. Passive Überwachung braucht keine Software, keine Konfigurations- und keine Firmware-Änderung an SPS, HMIs oder Antrieben. Die Änderung findet im Netz statt: Ein SPAN-Port (Spiegelport) an einem verwalteten Switch oder ein passiver TAP in einem Kabel schickt eine Kopie des Verkehrs an einen kleinen Rechner, auf dem der Sensor läuft. Planen Sie diese Änderung wie jede andere im Produktionsnetz: mit dem OT-Ingenieur abstimmen, prüfen, ob der Switch die nötigen Ports ohne Überlast spiegeln kann, und sie in einem Wartungsfenster vornehmen, wenn Ihre Regeln das verlangen. Entscheiden Sie dann, wo der Sensor-Host steht und wie er Alarme nach außen sendet, am besten über eine Firewall-Regel, die nur das erlaubt. Bei NetSenX läuft der Agent auf einem Linux-Host Ihrer Wahl und liest ab dem Pro-Plan Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm; ein Agent an einem Spiegelport zählt als ein Gerät.

Dann nehmen Sie einen Netzwerk-TAP oder ergänzen einen verwalteten Switch dort, wo Sie Sichtbarkeit brauchen. Nicht verwaltete Switches, wie sie in Maschinenschaltschränken üblich sind, können keinen Verkehr spiegeln. Ein TAP ist ein kleines Gerät, das in ein Kabel eingesetzt wird, zum Beispiel in die Verbindung zwischen Linien-Switch und Werks-Backbone, und den Verkehr in beide Richtungen an einen Monitorport kopiert, ohne im Netz sichtbar zu sein. Viele Modelle halten die Verbindung auch bei Stromausfall aufrecht; prüfen Sie das für das Modell, das Sie kaufen. Wählen Sie die Verbindung, die den für Sie wichtigsten Verkehr trägt: zwischen Büro und Produktion oder zwischen SCADA-Servern und Steuerungen. Verkehr zwischen zwei Geräten am selben nicht verwalteten Switch läuft nie über diese Verbindung und bleibt unsichtbar. NetSenX arbeitet an einem SPAN-Port oder an einem TAP; ein Agent dort zählt als ein Gerät, und die OT-Protokolle werden ab dem Pro-Plan gelesen.

Ja. Alles, was die Maschine im Netz tut, lässt sich von außen beobachten, aus einer Kopie ihres Verkehrs an einem SPAN-Port oder TAP. So geht man üblicherweise bei Steuerungen, HMIs, Prüfständen, Medizingeräten und jedem System vor, bei dem der Lieferant Änderungen verbietet oder die Gewährleistung daran knüpft. Sie sehen sein Verhalten: mit welchen Hosts es spricht, zu welchen Zeiten, wie viele Daten und, bei den dekodierten Industrieprotokollen, was es von den Steuerungen verlangt. Was im Inneren passiert, sehen Sie nicht: Dateien, Prozesse und lokale Anmeldungen bleiben verborgen, ebenso Verkehr auf nicht gespiegelten Verbindungen. So arbeitet NetSenX: Ein Agent an einem Spiegelport beobachtet das ganze Segment und zählt als ein Gerät. Beaconing, Scans, laterale Bewegung und ungewöhnliche ausgehende Datenmengen werden in jedem Plan erkannt; die OT-Protokolle und OT-Alarme gibt es ab dem Pro-Plan.

Ja. Die meisten Angriffe, die eine Produktion stoppen, beginnen im Büronetz, über E-Mail, ein gestohlenes Passwort oder den Zugang eines Dienstleisters, und ein flaches Netz lässt sie direkt bis zu den Steuerungen durch. Trennung muss keinen Air Gap bedeuten. Das übliche Design setzt eine Firewall zwischen Büro und Produktion, mit einer kleinen demilitarisierten Zone (DMZ) dazwischen für Systeme, die beide Seiten brauchen, etwa eine Historian-Kopie, einen Patch-Server oder das Gateway für den Fernzugang, und ohne direkte Verbindung von einem Büro-PC zu einer Steuerung. Erfassen Sie zuerst die Verbindungen, die die Produktion wirklich braucht, lassen Sie nur diese zu und protokollieren Sie, was abgewiesen wird. Prüfen Sie danach, ob die Trennung in der Praxis hält, denn Ausnahmen sammeln sich an. Ab dem Pro-Plan alarmiert NetSenX, wenn Verkehr Ebenen des Werksnetzes überschreitet, etwa von einem Büro-Host direkt zu einer Steuerung, auf Basis eines SPAN- oder TAP-Ports.

Das Purdue-Modell ist ein Referenzaufbau, der die Systeme eines Werks in Ebenen ordnet: unten der physische Prozess mit seinen Sensoren, darüber die Steuerungen, dann Überwachungssysteme wie HMI und SCADA, darüber der Werksbetrieb mit Historian und Produktionsplanung und ganz oben das Geschäftsnetz. Entscheidend ist die Regel, dass jede Ebene hauptsächlich mit ihren Nachbarn spricht und Verkehr zwischen Geschäft und Produktion über eine kontrollierte Grenze läuft, meist eine DMZ. Verkehr, der Ebenen überspringt, etwa ein Büro-PC, der direkt mit einer SPS spricht, ist entweder ein Designfehler oder etwas, das ein Angreifer nutzt, und gehört zu den deutlichsten Warnzeichen in der OT. Viele reale Werke passen nicht sauber ins Modell, und das ist in Ordnung; wichtig ist, dass Sie wissen, welche Übergänge gewollt sind. Ab dem Pro-Plan markiert NetSenX Verkehr über Purdue-Ebenen hinweg, aus der passiven Erfassung.

Testen, dann beobachten. Für den Test nehmen Sie ein normales Büro-Notebook und versuchen, in Absprache mit dem OT-Ingenieur, eine Verbindung zur Adresse und zum Port einer Steuerung sowie zu den HMI- und SCADA-Servern aufzubauen; verwenden Sie einen einfachen Verbindungstest, gegen Produktionsgeräte niemals einen Scanner. Prüfen Sie die Firewall-Regeln zwischen Büro und Produktion auf zu weit gefasste Freigaben und alte Ausnahmen, die niemand erklären kann. Beobachten Sie dann einige Wochen lang den echten Verkehr, denn entscheidend sind oft die vergessenen Wege: ein PC mit je einer Netzwerkkarte in beiden Netzen, ein VPN eines Dienstleisters, das in der Produktion endet, eine Funkbrücke. Ab dem Pro-Plan markiert NetSenX Verkehr über Ebenen des Werksnetzes hinweg, etwa einen Büro-Host, der eine Steuerung erreicht, sodass ein Weg, den es nicht geben sollte, bei der ersten Nutzung auffällt. Ein Weg, der existiert, aber nie genutzt wird, bleibt für jeden passiven Sensor unsichtbar.

Ja, und das ist der häufigste Weg, auf dem ein Cybervorfall die Produktion stoppt, selbst wenn die Maschinen unberührt bleiben. Linien hängen von IT-Systemen für Aufträge, Rezepturen, Etiketten, Versand und Qualitätsnachweise ab; wenn ERP, Etikettenserver oder Dateifreigaben verschlüsselt sind, halten viele Werke lieber an, als ohne Rückverfolgbarkeit zu produzieren. Andere fahren die Produktion vorsorglich herunter, bis klar ist, wie weit der Angreifer gekommen ist. Der Schutz der Produktion beginnt also auf der IT-Seite: Erfassen Sie die IT-Systeme, die jede Linie braucht, planen Sie, wie Sie einen Tag ohne sie arbeiten, halten Sie Offline-Backups dieser Systeme vor und testen Sie die Wiederherstellung. NetSenX beobachtet in jedem Plan die Schritte auf der IT-Seite, die vor der Verschlüsselung kommen: Beaconing, Scans, laterale Bewegung und ungewöhnliche ausgehende Datenmengen. Ab dem Pro-Plan zeigt es OT-Verkehr im selben Dashboard. Ransomware stoppt es nicht; es verschafft Ihnen Zeit zum Handeln.

Behandeln Sie sie wie Besucher mit Schlüssel: für einen Auftrag hereingelassen, über einen bekannten Port und beobachtet, solange sie da sind. Vereinbaren Sie mit jedem Maschinenbauer und Integrator, welches Notebook sich wo und wofür verbinden darf. Geben Sie ihnen einen eigenen Wartungsport oder ein VLAN, das nur ihre Maschine erreicht, statt irgendeiner freien Buchse am Linien-Switch, und schalten Sie diesen Port nach dem Einsatz ab. Lassen Sie das Notebook vor dem Anschluss auf Schadsoftware prüfen oder leihen Sie dem Techniker ein firmeneigenes Notebook mit der Engineering-Software, was viele Werke vorziehen. Führen Sie ein kurzes Besuchsprotokoll: wer, wann, welche Maschine. Im Netz erscheint das Notebook als neues Gerät auf der Netzwerkkarte von NetSenX, in jedem Plan, und wenn es scannt oder mit vielen Hosts zu sprechen beginnt, schlagen die Alarme für Scans und laterale Bewegung an. Ab dem Pro-Plan löst ein Schreibzugriff auf eine Steuerung von einem Host, der nicht schreiben darf, einen OT-Alarm aus.

Ja, wenn das Segment, das das Notebook genutzt hat, an einen Sensor gespiegelt wird: Jede seiner Verbindungen lief über das Netz und lässt sich nachträglich anhand der Adresse auflisten. Das beantwortet die Frage, die Werksleitungen und Auditoren nach einem Besuch stellen: Hat das Notebook nur die Maschine berührt, für die es gekommen ist? Machen Sie es sich leichter, indem Sie Besuchern Adressen aus einem bekannten Bereich oder ein eigenes Wartungs-VLAN geben, damit sich ihr Verkehr leicht von Ihrem unterscheiden lässt. Auf der Netzwerkkarte von NetSenX, in jedem Plan, erscheint das Notebook als Gerät mit den Hosts, mit denen es gesprochen hat, und dem Zeitpunkt, wann es zuerst und zuletzt gesehen wurde. Ab dem Pro-Plan dekodiert NetSenX außerdem Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm, sodass Schreibzugriffe von Hosts ohne Schreibrecht und S7comm-Befehle OT-Alarme auslösen. Eine Verbindung über den eigenen 4G-Router des Maschinenbauers oder über einen nicht gespiegelten Switch in der Maschine läuft nie über Ihr überwachtes Netz und wird nicht gesehen.

Über einen einzigen kontrollierten Zugangspunkt, der Ihnen gehört und nur bei Bedarf eingeschaltet wird. In der Praxis: ein Fernzugangs-Gateway oder Jump-Server in der DMZ zwischen Büro und Produktion, Multi-Faktor-Authentifizierung für jedes Herstellerkonto, ein persönliches Konto pro Techniker statt eines gemeinsamen, Zugriff nur auf die Maschinen, die dieser Hersteller betreut, Sitzungen auf Anfrage freigeschaltet und danach wieder abgeschaltet, dazu Protokolle oder Aufzeichnungen dessen, was getan wurde. Sobald dieser Weg besteht, entfernen Sie die dauerhaften eigenen Werkzeuge der Hersteller, etwa Fernwartungs-Apps auf HMIs und 4G-Router in Schaltschränken. NIS2 verlangt außerdem Maßnahmen zur Sicherheit der Lieferkette, also schreiben Sie diese Regeln in die Verträge. Im Netz erscheint eine Herstellersitzung als Verbindungen vom Gateway in die Produktion; NetSenX erkennt Scans und laterale Bewegung davon in jedem Plan und ab dem Pro-Plan Schreibzugriffe von Hosts, die nicht schreiben dürfen. Wer Zugang erhält, entscheidet nicht NetSenX, sondern Ihr Gateway.

Ja. Ein für die Fernwartung eingebauter Mobilfunkrouter verbindet die Maschine über das Mobilfunknetz mit dem Internet, vollständig an Ihrer Firewall vorbei, sodass keine Ihrer Regeln, Protokolle oder VPN-Kontrollen für ihn gelten. Wird das Portal des Herstellers oder der Router selbst kompromittiert, oder wurde das Standardpasswort nie geändert, landet ein Angreifer in Ihrem Produktionsnetz. Viele dieser Router stehen in keinem Plan, weil sie mit der Maschine geliefert wurden. Fragen Sie jeden Maschinenlieferanten schriftlich, ob seine Anlage ein Modem oder einen Mobilfunkrouter enthält, prüfen Sie die Schaltschränke und entfernen Sie das Gerät dann, lassen Sie es ausgeschaltet, bis eine Wartungssitzung vereinbart ist, oder ersetzen Sie es durch Ihren eigenen kontrollierten Fernzugang. Ein Netzwerksensor sieht die 4G-Verbindung selbst nicht, weil dieser Verkehr nie über Ihr Netz läuft; er sieht nur die LAN-Seite des Routers, wenn dieses Segment an ihn gespiegelt wird.

Schauen Sie sich Schaltschränke und Netz gemeinsam an. Physisch: Öffnen Sie beim nächsten geplanten Stillstand die Maschinenschaltschränke und suchen Sie nach kleinen Routern, Modems und Antennen, und fordern Sie von jedem Lieferanten eine Liste der Kommunikationsgeräte in seiner Anlage an. Im Netz: Suchen Sie Geräte, die sich wie Gateways verhalten, etwa eine Maschine, deren Verkehr an eine Adresse geht, die nicht Ihr Router ist, ein Gerät, das selbst Adressen vergibt, oder einen Host, der zu Zeiten Verbindungen von außen erhält, zu denen niemand auf Ihrer Seite etwas gestartet hat. Ein Gerät, das auf Ihrer Netzwerkkarte, aber in keinem Plan auftaucht, verdient eine Nachfrage. Die Netzwerkkarte von NetSenX listet in jedem Plan die Geräte, die es in überwachten Segmenten kommunizieren sieht, mit erstem und letztem Auftreten, und Geräte, die in regelmäßigen Abständen nach außen rufen, werden als Beaconing markiert. Einen Router, der nur über seine Mobilfunkverbindung spricht und in Ihrem LAN still bleibt, finden Sie nicht über das Netz; den findet die Schrankbegehung.

Umgeben Sie ihn mit Schutz, wenn Sie ihn schon nicht reparieren können. Bedienpanels, HMIs und Prüfstandsrechner laufen oft auf einem Betriebssystem, das der Hersteller nicht mehr unterstützt, und der Maschinenlieferant verbietet Änderungen. Nehmen Sie ihn aus jedem Netz, das er nicht braucht, sperren Sie seinen Internetzugang, erlauben Sie nur die Verbindungen zu den Steuerungen und Servern, mit denen er arbeitet, deaktivieren Sie USB-Ports und unnötige Dienste, wo der Lieferant es zulässt, nutzen Sie Application-Whitelisting, wenn der Hersteller es unterstützt, und halten Sie ein geprüftes Image bereit, um ihn neu aufsetzen zu können. Fordern Sie vom Lieferanten einen Migrationspfad an und dokumentieren Sie das Restrisiko. Beobachten Sie ihn dann vom Netz aus, da sich nichts auf ihm installieren lässt: NetSenX sieht seine Verbindungen von einem SPAN- oder TAP-Port und erkennt in jedem Plan Beaconing, Scans, laterale Bewegung und ungewöhnliche ausgehende Datenmengen, ab dem Pro-Plan auch Schreibzugriffe auf Steuerungen von Hosts ohne Schreibrecht. Was im Inneren des PCs läuft, sieht es nicht.

Eine Maßnahme, die ein Risiko verringert, das sich an der Quelle nicht beseitigen lässt. Wenn eine Steuerung nicht gepatcht werden kann, kein Passwort hat oder auf einem nicht mehr unterstützten System läuft, schützen Sie sie von außen: durch Segmentierung und Firewall-Regeln, sodass nur benannte Hosts sie erreichen, keinen Internetzugang, einen kontrollierten Fernzugang, abgeschlossene Schaltschränke, Offline-Sicherungen von Programmen und Konfigurationen und eine Überwachung, die meldet, wenn der Schutz umgangen wird. Auditoren, die mit IEC 62443 oder dem NIS2-Risikomanagement arbeiten, erwarten in der Regel, dass solche Maßnahmen dokumentiert sind: welches Risiko, welche Maßnahme, wer verantwortlich ist und wie Sie prüfen, dass sie noch wirkt. Die Überwachung ist der Teil, der diesen Prüfnachweis liefert. NetSenX kann ihn beisteuern: Von einem SPAN- oder TAP-Port aus zeigt es, wer mit dem Altsystem spricht, und ab dem Pro-Plan löst es OT-Alarme zu unerlaubten Schreibzugriffen, Verkehr über Ebenen des Werksnetzes, Aktivität außerhalb der Arbeitszeit und S7comm-Befehlen aus.

Kombinieren Sie drei passive Quellen: was Ihre Unterlagen sagen, was Ihre Engineering-Werkzeuge wissen und was das Netz zeigt. Beginnen Sie mit den Plänen, den Engineering-Projektdateien, die jede konfigurierte Steuerung, jeden Antrieb und jede dezentrale Peripherie aufführen, und der Lieferantendokumentation jeder Maschine. Gehen Sie dann durch das Werk: Schaltschränke, Bedienpulte, Außenstandorte. Ergänzen Sie schließlich, was der Verkehr zeigt: Ein passiver Sensor an einem Spiegelport sieht jedes Gerät, das in diesem Segment kommuniziert, auch jene, die niemand aufgeschrieben hat. Erfassen Sie für jedes Asset Adresse, Funktion, Verantwortlichen, Firmware-Stand und ob es gepatcht werden kann. Die Netzwerkkarte von NetSenX listet in jedem Plan die in überwachten Segmenten gesehenen Geräte mit den Namen, die sie selbst melden, sowie erstem und letztem Auftreten, und ab dem Pro-Plan liest NetSenX Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm. OT-Geräte fragt es nie ab, Firmware-Stände ermittelt es also nicht; die liefern Ihre Engineering-Werkzeuge.

Geräte, die nicht in einem gespiegelten Segment sprechen. Dazu gehören Geräte, die die meiste Zeit schweigen, etwa eine Reservesteuerung oder eine Baugruppe, die nur einem Master antwortet, den Sie nicht sehen; Geräte an seriellen Feldbussen wie Modbus RTU oder Profibus; Geräte hinter einem nicht verwalteten Switch, deren Verkehr die gespiegelte Verbindung nie erreicht; Anlagen, die nur über ihren eigenen Mobilfunkrouter kommunizieren; und Außenstandorte ohne Sensor. Passive Überwachung sieht außerdem weniger in verschlüsselten Protokollen und kann keinen Firmware-Stand lesen, den das Gerät nicht selbst meldet. Schließen Sie diese Lücken mit einer Begehung, den Engineering-Projektdateien und, wo das Werk es zulässt, einer sorgfältig geplanten Abfrage mit den Werkzeugen des Herstellers in einem Wartungsfenster. NetSenX arbeitet ausschließlich passiv, seine Netzwerkkarte zeigt also, was in überwachten Segmenten kommuniziert, und nicht mehr.

Meist einen pro Netzsegment, das Sie an jedem Standort beobachten wollen, also typischerweise einen bis drei pro Werk. Die Zahl hängt davon ab, wo sich Verkehr kopieren lässt: Ein SPAN-Port am Core-Switch eines Werks sieht oft den Verkehr zwischen Büro und Produktion sowie zwischen SCADA-Servern und Linien-Switches, während Verkehr innerhalb des eigenen Switches einer Maschine einen Sensor oder TAP näher an ihr braucht. Beginnen Sie in jedem Werk mit der Grenze zwischen Büro und Produktion und ergänzen Sie dann die Segmente, in denen Steuerungen programmiert werden. Jedes Werk braucht einen kleinen Host für den Sensor und einen Weg, Alarme nach außen zu senden. Bei NetSenX zählt jeder Agent an einem SPAN- oder TAP-Port als ein Gerät für das ganze Segment, das er beobachtet, alle Werke erscheinen in einem Dashboard, und die OT-Protokolle werden ab dem Pro-Plan gelesen. Wie viele Geräte jeder Plan umfasst, steht auf der Preisseite.

Ja, wenn jemand die Zeit hat, sie zu betreiben. Es gibt ausgereifte Open-Source-Netzwerkmonitore, die mehrere Industrieprotokolle von einem SPAN-Port lesen können. Die Kosten liegen nicht in der Lizenz, sondern in der Arbeit: Sensoren installieren und aktualisieren, Regeln für Ihr Werk schreiben oder anpassen, Protokolle speichern, Dashboards bauen und vor allem jemand, der sich die Alarme ansieht. In einem Werk mit einem OT-Ingenieur, der diese Arbeit gern macht, kann das ein guter Anfang sein. Hat niemand diese Zeit, häufen sich ungelesene Protokolle, und Sie haben das Gefühl einer Überwachung ohne deren Ergebnis. NetSenX ist die betreute Alternative: ein Agent an einem SPAN- oder TAP-Port, Alarme mit verständlicher Erklärung und die OT-Protokolle ab dem Pro-Plan, ohne dass Sie Regeln pflegen müssen. Wofür Sie sich auch entscheiden: Beginnen Sie an der Grenze zwischen Büro und Produktion.

IEC 62443 ist eine Reihe internationaler Normen für die Sicherheit industrieller Automatisierungs- und Steuerungssysteme. Sie behandelt das Sicherheitsprogramm des Betreibers, die Pflichten von Integratoren und Dienstleistern, die Anforderungen an ein ganzes System, das in Zonen und Conduits (Kommunikationskanäle) gegliedert ist, und die Anforderungen an die Produkte selbst, mit Security Levels, die beschreiben, welchen Angreifern eine Zone standhalten soll. Sie ist freiwillig: Ein typischer Hersteller ist gesetzlich nicht verpflichtet, sich danach zertifizieren zu lassen, aber Kunden, Versicherer und Auditoren nutzen sie zunehmend als Maßstab, und der Ansatz aus Zonen und Conduits ist ein praktischer Weg, die NIS2-Risikomaßnahmen in einem Werk zu ordnen. Ein Zertifikat brauchen Sie dafür nicht: Teilen Sie das Werk in Zonen, erfassen Sie die Conduits dazwischen und legen Sie fest, was jeder transportieren darf. Die Überwachung prüft die Conduits dann in der Praxis. NetSenX kann diesen Nachweis beisteuern: Ab dem Pro-Plan liest es Industrieprotokolle passiv und markiert Verkehr über Ebenen des Werksnetzes hinweg.

Meist den Nachweis, dass Erkennung existiert, die richtigen Stellen abdeckt und zu Handlungen führt: welche OT-Segmente wie überwacht werden, welche Ereignisarten erkannt werden, wer Alarme prüft und wie schnell, Beispiele bearbeiteter Alarme mit der getroffenen Entscheidung und wie lange Aufzeichnungen aufbewahrt werden. In Deutschland hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung für Betreiber kritischer Infrastrukturen veröffentlicht, die Prüfer oft als Referenz nutzen; andere Länder haben eigene Erwartungen, prüfen Sie diese bei Ihrer nationalen Behörde. Eine Werkzeugliste allein genügt nicht: Prüfer suchen einen gelebten Prozess. Eine Netzwerkkarte mit erstem und letztem Auftreten, Alarme mit Zeitstempeln und Ihre Notizen zu jeder Entscheidung machen diesen Prozess sichtbar. NetSenX bewahrt Alarme für die Alarmhistorie Ihres Plans auf und ergänzt ab dem Pro-Plan OT-Alarme zu unerlaubten Schreibzugriffen, Verkehr über Ebenen hinweg, Aktivität außerhalb der Arbeitszeit und S7comm-Befehlen. Es zertifiziert Sie nicht und ersetzt nicht das Urteil des Prüfers.

Ja, und ein unterschätztes. Heizung, Lüftung, Beleuchtung, Aufzüge und Zutrittskontrolle laufen heute auf vernetzten Steuerungen, oft mit BACnet/IP, mit Fernzugang für die Servicefirma und einer Cloud-App für das Facility Management. Sie werden selten gepatcht, behalten oft Standardpasswörter und werden meist von einem anderen Team oder einem externen Dienstleister betreut, nicht von der IT. Ein Angreifer kann sie nutzen, um den Gebäudebetrieb zu stören, oder als unauffälligen Brückenkopf ins Büronetz, wenn beide nicht getrennt sind. Fragen Sie Ihren Gebäudetechnik-Dienstleister, wohin das System verbindet, wer Fernzugang hat und wie, und legen Sie die Gebäudesteuerungen in ein eigenes Netzsegment mit einem Internetzugang, der auf das beschränkt ist, was der Hersteller wirklich braucht. NetSenX liest ab dem Pro-Plan BACnet/IP aus der passiven Erfassung und erkennt in jedem Plan Beaconing, Scans und ungewöhnliche ausgehende Datenmengen von diesen Steuerungen. Einen eigenen BACnet-Anomaliealarm gibt es nicht.

Ja, wenn beide ein Netz teilen oder die Regeln dazwischen locker sind. Gebäudesysteme werden oft von einem Dienstleister an denselben Switches und im selben Adressbereich wie das Büro installiert oder mit einer bequemen Route, damit das Facility Management die Steuerungssoftware auf einem Büro-PC öffnen kann. Ein Angreifer, der über den Fernzugang der Gebäudetechnik oder eine schwache Steuerung hereinkommt, erreicht dann Bürorechner, als säße er im Haus. Prüfen Sie, wo die Gebäudesteuerungen und ihr Server stehen, ob sie Büro-Hosts erreichen und ob Büro-Hosts sie erreichen; meist braucht das nur eine Leitstation. Trennen Sie sie mit einer Firewall oder einem VLAN mit strengen Regeln und führen Sie den Fernzugang des Dienstleisters über Ihr eigenes Gateway. In einem überwachten Segment erkennt NetSenX in jedem Plan Scans und laterale Bewegung von einer Gebäudesteuerung in Richtung Büro-Hosts, sodass eine Steuerung auffällt, die anfängt, das Netz zu erkunden.

Das kann sein, aber Sie sollten wissen, warum. Viele Kamerarekorder halten eine ständige Verbindung zur Cloud des Herstellers, damit die Handy-App Bilder zeigen kann, ohne einen Port am Router zu öffnen, und diese Server können in einem anderen Land oder auf einem anderen Kontinent stehen. Diese Verbindung ist zugleich ein Fernzugangskanal, den Sie nie eingerichtet haben und den ein Dritter betreibt, und ältere Rekorder haben eine lange Geschichte von Sicherheitslücken. Klären Sie mit dem Errichter oder anhand der Herstellerdokumentation, um welchen Dienst es sich handelt, entscheiden Sie, ob Sie die Fernansicht überhaupt brauchen, und wenn nicht, schalten Sie die Cloud-Funktion ab und sperren Sie den Internetzugang des Rekorders. Brauchen Sie sie, halten Sie die Firmware aktuell und ändern Sie die Standardpasswörter. NetSenX zeigt die Ziele des Rekorders von einem SPAN- oder TAP-Port aus und erkennt in jedem Plan Beaconing und ungewöhnliche ausgehende Datenmengen, sodass ein Rekorder auffällt, der plötzlich viel mehr hochlädt als sonst. Ob die Cloud des Herstellers akzeptabel ist, bleibt Ihre Entscheidung.

Er kann eines sein. Smart-TVs, Konferenzbildschirme und Raumbuchungspanels laufen mit eigenen Betriebssystemen, rufen beim Hersteller Updates, Apps und Werbung ab und werden nach der Installation selten aktualisiert. Im Büronetz stehen sie neben den Notebooks, die auf ihnen präsentiert werden, und manche haben Mikrofone und Kameras. Der Großteil dieses Verkehrs geht an Dienste des Herstellers, aber von außen erkennen Sie das nicht, ohne nachzusehen. Schalten Sie ungenutzte Funktionen ab, etwa Sprachsteuerung, App-Stores und Nutzungsstatistiken, aktualisieren Sie die Firmware und verlegen Sie Bildschirme in ein eigenes Gerätenetz mit einem Internetzugang, der auf das Nötige beschränkt ist, und ohne Zugriff auf Büro-Hosts. Notebooks können ihren Bildschirm dann per Kabel oder über ein Casting-Gerät in diesem Netz teilen. NetSenX beobachtet solche Geräte ohne jede Software auf ihnen, von einem SPAN- oder TAP-Port, und erkennt in jedem Plan Beaconing, Scans und ungewöhnliche ausgehende Datenmengen.

Meist aus gewöhnlichen Gründen: Firmware-Updates, Toner- und Nutzungsmeldungen an den Lieferanten, Cloud-Druck und Scan-to-Cloud. Managed-Print-Verträge enthalten oft diese Meldungen, fragen Sie also Ihren Lieferanten, was der Drucker sendet und wohin. Das Risiko: Drucker sind vollwertige Rechner mit alter Software, Verwaltungsoberflächen mit Standardpasswörtern und gespeicherten Kopien gescannter Dokumente, und niemand beobachtet sie. Prüfen Sie in den Druckereinstellungen Cloud- und Fernfunktionen, die Sie nicht nutzen, und schalten Sie sie ab, aktualisieren Sie die Firmware, setzen Sie ein Administratorpasswort und beschränken Sie den Internetzugang auf die Dienste des Lieferanten. Ein Drucker, der beginnt, sich mit vielen internen Adressen oder mit neuen Zielen draußen zu verbinden, verdient noch am selben Tag einen Blick. NetSenX sieht Drucker von einem SPAN- oder TAP-Port ohne Software auf ihnen, listet sie auf der Netzwerkkarte und erkennt in jedem Plan Scans, Beaconing und ungewöhnliche ausgehende Datenmengen.

Vor allem über das Netzdesign, denn auf diesen Geräten läuft keine Sicherheitssoftware. Legen Sie Handscanner, Etikettendrucker, Fördertechniksteuerungen und das Lager-WLAN in ein eigenes Netzsegment, das nur den Server des Lagerverwaltungssystems und die benötigten Drucker erreicht, nicht Büro-PCs oder das Internet allgemein. Nutzen Sie ein eigenes WLAN mit Authentifizierung pro Gerät oder per Zertifikat statt eines gemeinsamen Passworts, das jede ehemalige Aushilfe kennt, halten Sie Betriebssystem und Apps der Handhelds über ihr Verwaltungswerkzeug aktuell und sperren Sie sie auf die Lager-App. Mustern Sie Geräte aus, die der Hersteller nicht mehr aktualisiert. Beobachten Sie dann das Segment, denn ein kompromittiertes Handheld in einem flachen Lagernetz erreicht alles andere. NetSenX beobachtet das Segment mit einem Agenten an einem SPAN- oder TAP-Port: Die Netzwerkkarte listet die Geräte, und Scans, Beaconing und ungewöhnliche ausgehende Datenmengen werden in jedem Plan erkannt.

Nein. NetSenX zählt die Agenten, die Sie betreiben, nicht die Geräte, die sie beobachten. Ein Agent an einem SPAN- oder TAP-Port zählt als ein Gerät für das gesamte überwachte Segment, sodass vierzig Handscanner, die Etikettendrucker und die Fördertechniksteuerung in einem gespiegelten Segment mit diesem einen Agenten abgedeckt sind. Ein Agent, der direkt auf einem Server oder Notebook installiert ist, zählt ebenfalls als ein Gerät und beobachtet diesen Host. Die Planungsfrage lautet also, wie viele Segmente Sie beobachten wollen und wo sich ihr Verkehr kopieren lässt, nicht, wie viele Geräte Sie besitzen. Ein Lager mit eigenem Switch braucht dort meist einen Agenten. Handhelds an WLAN-Access-Points, die an diesem Switch hängen, sind sichtbar, wenn ihr Verkehr über den gespiegelten Port läuft. Die Geräteanzahl jedes Plans, vom Free-Plan aufwärts, finden Sie auf der Preisseite.

Vom Netz aus, genauso wie Industrieanlagen. Analysegeräte, Bildgebung, Infusionspumpen und Laborinstrumente laufen oft mit alten Betriebssystemen, die der Hersteller zertifiziert und deren Änderung er untersagt, ein Endpunkt-Agent kommt also nicht in Frage. Legen Sie sie in ein eigenes Netzsegment, das nur die Systeme erreicht, an die sie berichten, etwa das Laborinformationssystem oder das Bildarchiv, sperren Sie nicht benötigten Internetzugang und führen Sie den Fernservice jedes Herstellers über Ihr eigenes Gateway. Ein Sensor an einem SPAN- oder TAP-Port dieses Segments sieht dann ihre Verbindungen, ohne sie zu berühren. NetSenX listet die Geräte auf der Netzwerkkarte und erkennt in jedem Plan Beaconing, Scans, laterale Bewegung und ungewöhnliche ausgehende Datenmengen. Medizinische Protokolle wie HL7 oder DICOM dekodiert es nicht, und es entschlüsselt nie Verkehr. Klären Sie vor dem Einschalten mit Ihrem Datenschutzbeauftragten, wie sich die Überwachung in Ihr Verzeichnis von Verarbeitungstätigkeiten einfügt.