Warum Deep Network Detection and Response für die OT- und KRITIS-Sicherheit unverzichtbar wird

Einheitliche, verhaltensbasierte Netzwerksichtbarkeit über IT- und OT-Geräte hinweg – von PLCs und RTUs bis hin zu Firewalls und SIEM.

Die meisten Industrieunternehmen verfügen bereits über eine gewisse Form der Netzwerksichtbarkeit. Ein Firewall-Protokoll hier, ein Switch-Bericht dort, vielleicht ein Dashboard, das anzeigt, wie viel Bandbreite der SCADA-Historian in dieser Woche verbraucht. Das ist Verkehrssichtbarkeit (Traffic Visibility), und lange Zeit galt dies als ausreichend.

Das ist es heute nicht mehr.

Verkehrssichtbarkeit zeigt Ihnen, was sich über die Leitung bewegt. Sie sagt Ihnen jedoch nicht, ob diese Bewegung plausibel ist. Sie sagt Ihnen nicht, ob eine PLC plötzlich mit einer Engineering Station kommuniziert, mit der sie noch nie zuvor verbunden war, oder ob ein Historian-Server an einem Sonntag um 2 Uhr morgens unbemerkt Daten an eine externe Adresse überträgt. Genau diese Lücke zwischen dem Erkennen von Datenverkehr und dem Verstehen von Verhalten nutzen moderne Angreifer aus – und genau diese Lücke soll Network Detection and Response (NDR) schließen.

Dieser Blogbeitrag erläutert, was NDR-Netzwerküberwachung für OT- und ICS-Umgebungen tatsächlich bedeutet, wie eine NDR-Architektur ohne Beeinträchtigung des Betriebs in Produktionsnetzwerken konzipiert und implementiert wird und warum der Verhaltenskontext, nicht das reine Datenvolumen, die eigentliche Währung der industriellen Bedrohungserkennung ist.

Was NDR-Netzwerküberwachung in Industrieumgebungen tatsächlich bedeutet

Network Detection and Response wird oft als „Netzwerksichtbarkeit mit Analytik“ beschrieben. Diese Beschreibung ist technisch korrekt, greift jedoch zu kurz, wenn es um die Leistung einer ausgereiften NDR-Plattform in einer OT-Umgebung geht.

Ein einfaches Überwachungstool beantwortet Fragen wie: Wie viel Datenverkehr lief über diesen Switch? Welche Ports sind offen? Wie hoch ist die Bandbreitenauslastung in diesem Segment? Dies sind nützliche Betriebsmetriken, aber sie sind deskriptiv, nicht diagnostisch. Sie beschreiben das Volumen, nicht die Absicht.

Eine für industrielle Netzwerke konzipierte NDR-Plattform beantwortet ganz andere Fragen:

• Ist dieses Kommunikationsmuster konsistent mit dem historischen Verhalten dieses Geräts?

• Hat ein Gerät, das normalerweise nur mit dem Historian kommuniziert, plötzlich eine Sitzung mit einer externen IP-Adresse initiiert?

• Gibt es Muster von Netzwerk-Scans oder Port-Probing, die eher auf eine Aufklärung (Reconnaissance) als auf ein normales Polling hindeuten?

• Gibt es Anzeichen für Lateral Movement zwischen der Engineering-Station-Ebene und der Prozesssteuerungsebene?

• Entspricht dieser Datenverkehr bekannten Command-and-Control-Kommunikationsmustern, selbst wenn die Nutzlast verschlüsselt oder obfuskiert ist?

Dies ist der Unterschied zwischen einer Autobahnkamera, die lediglich Autos zählt, und einem Verkehrsanalysten, der genau weiß, welche Fahrzeuge auf diese Straße gehören, wann sie diese normalerweise befahren, und dem sofort auffällt, wenn ein unbekanntes Fahrzeug eine Ausfahrt nimmt, die es noch nie zuvor genutzt hat.

Einfache Verkehrssichtbarkeit vs. echte NDR-Netzwerküberwachung

NDR-Architektur und Bereitstellung: Sichtbarkeit schaffen ohne Betriebsunterbrechung

Die größte Sorge von OT-Teams bei der Einführung von NDR ist eine mögliche Betriebsunterbrechung. Betriebsleiter und Steuerungsingenieure kennen die Horrorszenarien von IT-Sicherheitstools, die Fehlalarme auslösen, serielle Verbindungen überlasten oder Agenten erfordern, die von älteren PLCs nicht unterstützt werden können. Eine gut konzipierte NDR-Architektur ist von vornherein auf diese Realität ausgelegt.

1. Passive Out-of-Band-Bereitstellung

NDR-Sensoren für OT-Umgebungen werden passiv integriert, typischerweise über Switch-Port-Spiegelung (SPAN-Ports) oder Netzwerk-TAPs. Das bedeutet, dass der Sensor eine Kopie des Netzwerkverkehrs empfängt, ohne direkt im Datenstrom (inline) zu sitzen. Dadurch können keinerlei Latenzen, Paketverluste oder Störungen in der produktiven Steuerungsdatenübertragung entstehen. In Umgebungen, in denen selbst Verzögerungen im Millisekundenbereich kritisch sind, ist dieser passive Ansatz nicht verhandelbar.

2. Abgestufte Sensorplatzierung gemäß dem Purdue-Modell

Anstatt nur einen einzelnen Sensor am Netzwerkperimeter zu platzieren, positioniert eine effektive NDR-Architektur Sensoren an strategischen Punkten über die Schichten des Purdue-Modells hinweg: im Unternehmensnetzwerk, in der DMZ, auf der Prozessleitebene und direkt auf der Steuerungsebene. Diese mehrschichtige Platzierung stellt sicher, dass eine Bedrohung, die die Perimeter-Abwehr überwindet und versucht, sich von Level 3 zu Level 1 zu bewegen, nicht unbemerkt bleibt.

3. Deep Protocol Parsing für OT-spezifischen Datenverkehr

Generische, IT-fokussierte Überwachungstools behandeln industrielle Protokolle oft als unbekannten Datenverkehr und ignorieren diese oder stufen sie pauschal als verdächtig ein. Speziell entwickelte OT-NDR-Plattformen parsen Protokolle wie Modbus, DNP3, OPC-UA, PROFINET und EtherNet/IP hochgradig granular. Sie verstehen nicht nur, dass ein Befehl gesendet wurde, sondern auch, was dieser Befehl auf dem Zielgerät bewirkt – eine entscheidende Differenzierung, um unbefugte Firmware-Änderungen oder riskante Grenzwertmodifikationen zu erkennen.

4. Kontinuierliche Erstellung von Verhaltens-Baselines

Direkt nach der Implementierung durchläuft eine NDR-Plattform eine Lernphase, in der sie die normalen Kommunikationsmuster erfasst: Welche Geräte kommunizieren miteinander, wie häufig, zu welchen Zeiten und über welche Protokolle. Diese Baseline dient als Referenzwert für alle zukünftigen Analysen. Einmal etabliert, kann jede Abweichung – eine neue Verbindung, ein ungewöhnliches Datenvolumen, eine Aktivität außerhalb der Arbeitszeiten – im entsprechenden Kontext bewertet werden, anstatt sie als isoliertes, bedeutungsloses Ereignis zu betrachten.

5. Integration in den bestehenden Security Stack

NDR agiert nicht isoliert. Die Bereitstellungsarchitektur umfasst in der Regel Integrationspunkte zu SIEM-Plattformen für eine zentralisierte Protokollierung, zu Firewalls für automatisierte Eindämmungsmaßnahmen und zu SOC-Workflows, damit Alarme mit ausreichend Kontext ankommen, sodass Analysten sofort zielgerichtet handeln können.

Abgestufte Sensorplatzierung über Enterprise-, DMZ-, Prozessleit- und Steuerungsebene hinweg zur Speisung einer zentralen Engine für Verhaltensanalysen.

Risiken, Herausforderungen und Branchenerkenntnisse

Die Konsequenzen, die sich aus dem Verlassen auf reine Verkehrssichtbarkeit ohne Verhaltenskontext ergeben, sind nicht theoretischer Natur. Industrie- und KRITIS-Unternehmen haben diese Lücke bereits leidvoll erfahren. Das Muster hinter schwerwiegenden Vorfällen ist auffallend konsistent: Die Netzwerkaktivität des Angreifers war technisch sichtbar, aber es gab kein System, das sie als abnormal meldete, bevor der Schaden bereits angerichtet war.

Das Muster von der Aufklärung bis zur Sabotage

Beim Angriff auf das ukrainische Stromnetz im Jahr 2015 verbrachten die Angreifer Monate in den Netzen der Energieversorger, bevor es zur eigentlichen Unterbrechung kam. Sie nutzten legitime Fernzugriffstools und Zugangsdaten, um sich zwischen IT- und OT-Systemen zu bewegen. Das Datenaufkommen während dieser Aufklärungsphase war unauffällig – die Aktivitäten gingen im normalen administrativen Datenverkehr unter. Eine verhaltensbasierte Baseline, die erfasst hätte, welche Konten und Workstations üblicherweise mit den Schaltanlagen-Steuerungen interagieren, hätte diese Bewegungen als Anomalie gemeldet, lange bevor die Lichter ausgingen.

Ein ähnliches Muster zeigte sich beim darauffolgenden Angriff auf das Stromnetz im Jahr 2016. Auch hier nutzten die Angreifer native Protokolle und legitim wirkende Sitzungen, um unbefugte Befehle zu erteilen. Dies verdeutlicht, dass industrielle Angriffe zunehmend nach der „Living-off-the-land“-Methode vorgehen, anstatt offensichtliche Schadsoftware einzusetzen, die von signaturbasierten Tools erkannt werden könnte.

Schadsoftware mit Prozessverständnis

Der Vorfall im Jahr 2017 in einer saudi-arabischen petrochemischen Anlage, bei dem die Schadsoftware TRITON/TRISIS gezielt auf Sicherheitssteuerungssysteme (SIS) abzielte, zeigte eine Herausforderung auf, mit der OT-Sicherheitsteams noch heute kämpfen: Die Malware war nicht darauf ausgelegt, Daten zu stehlen oder Dateien zu verschlüsseln. Sie sollte Sicherheitssteuerungen manipulieren, die speziell zur Verhinderung katastrophaler physischer Ereignisse dienen. Die Erkennung solcher Bedrohungen erfordert eine Überwachung, die die Kommunikation auf der Prozessebene versteht, und nicht nur IT-typische Indicators of Compromise (IoCs) sucht.

Die IT-OT-Konvergenz als Angriffspfad

Der Ransomware-Vorfall im Jahr 2019 bei einem großen Aluminiumproduzenten zeigte, wie schnell ein in der IT begonnener Kompromiss zu betrieblichen Stillständen in der OT führen kann, wenn beide Umgebungen nicht klar segmentiert und als verbundenes System überwacht werden. Die Produktionslinien in mehreren Werken mussten auf manuellen Betrieb umgestellt werden. Dies verdeutlicht, dass IT-Sicherheitsvorfälle und OT-Sicherheitsvorfälle in einer konvergenten Umgebung keine getrennten Risikokategorien mehr darstellen.

Gefährdung durch Drittanbieter und Fernzugriffe

Der Stillstand eines großen Kraftstoffpipeline-Betreibers im Jahr 2021, der durch kompromittierte Zugangsdaten für einen Fernzugriff ausgelöst wurde, zeigte erneut, wie ein einziger ungesicherter Zugangspunkt – oft nicht einmal direkt im OT-Netzwerk selbst – aus Sicherheitsgründen zu einer vollständigen Betriebsunterbrechung führen kann, wenn die nötige Sichtbarkeit fehlt, um die Folgemaßnahmen im Netzwerk zu bewerten. Ohne verhaltensbasierte Überwachung auf Netzwerkebene treffen Unternehmen im Ernstfall oft Entscheidungen nach dem Worst-Case-Szenario, da sie das tatsächliche Ausmaß einer Kompromittierung nicht schnell genug verifizieren können.

Über all diese Beispiele hinweg zieht sich ein roter Faden: Die Angreifer befanden sich über längere Zeiträume im Netzwerk und erzeugten Datenverkehr, bevor realer Schaden entstand. Die betroffenen Unternehmen verfügten über Firewalls. Viele hatten eine Form der Überwachung. Was ihnen jedoch konsequent fehlte, war der Verhaltenskontext – ein System, das erkennen konnte, dass der beobachtete Datenverkehr zwar technisch legitim war, aber absolut nicht dem normalen Betriebsverhalten entsprach.

Warum sich diese Herausforderung verschärft

• Die IT-OT-Konvergenz vergrößert die Angriffsfläche schneller, als die meisten Sicherheitsprogramme angepasst werden können.

• Ältere PLCs und RTUs, die teilweise seit Jahrzehnten im Einsatz sind, unterstützen keine Endpoint-Agenten. Damit ist die netzwerkbasierte Sichtbarkeit die einzig realisierbare Erkennungsebene für große Teile der Infrastruktur.

• Angreifer nutzen vermehrt legitime Zugangsdaten und native Protokolle, für deren Erkennung signaturbasierte Tools nicht ausgelegt sind.

• Fernzugriffe und Verbindungen von Drittanbietern haben sich durch die Dezentralisierung des Betriebs supports vervielfacht, was die Anzahl legitimer Zugangspfade erhöht.

• Regulatorische Vorgaben (wie das IT-Sicherheitsgesetz, NIS-2 und KRITIS-Standards) fordern für die Bereiche Energie, Industrie und Versorgung zunehmend den Nachweis aktiver Netzwerküberwachung und Incident-Response-Fähigkeiten, anstatt reiner Perimeter-Abwehr.

Praktische Empfehlungen und Best Practices für die NDR-Einführung

Unternehmen, die den größten Nutzen aus einer NDR-Netzwerküberwachung ziehen, verfolgen in der Regel eine strukturierte Einführungsphilosophie. Sie betrachten Sichtbarkeit als ein phasenweises, betriebsbezogenes Programm und nicht als einmaligen Technologieeinkauf.

Starten Sie mit der Asset- und Kommunikationsanalyse

Bevor Verhaltensanalysen wirksam werden können, benötigt ein Unternehmen ein präzises Bild aller im Netzwerk aktiven Komponenten. Eine passive Erkennung (Passive Discovery) über mehrere Wochen hinweg deckt in der Regel Geräte und Kommunikationspfade auf, die zuvor nicht dokumentiert waren – eine häufige und überraschende Erkenntnis selbst in gut geführten Anlagen.

Priorisieren Sie die passive Bereitstellung in Produktivumgebungen

In Segmenten, in denen Betriebszeit und Sicherheit an oberster Stelle stehen, sollte eine passive Out-of-Band-Überwachung der Standard sein. Inline-Verfahren oder aktive Scans bergen das Risiko, sensible Steuerungsdaten zu stören, und sollten nur in Segmenten eingesetzt werden, in denen dieses Risiko explizit analysiert und akzeptiert wurde.

Etablieren Sie die Baseline vor der Alarm-Feinabstimmung

Vermeiden Sie es, am ersten Tag aggressive Alarmierungsregeln zu aktivieren. Eine Baseline-Phase von mehreren Wochen bis zu einigen Monaten, die auch Schichtzyklen und saisonale Unterschiede der Anlage berücksichtigt, liefert weitaus zuverlässigere Erkennungsraten als eine Engine, die mit unvollständigen Daten konfiguriert wurde.

Segmentieren Sie Überwachungsprioritäten nach Risiko, nicht nur nach Netzwerktopologie

Nicht jedes Segment hat die gleiche Relevanz für den Gesamtbetrieb. Sicherheitsgerichtete Systeme (SIS), Schutzrelais und direkt in den physischen Prozess eingreifende Steuerungen erfordern engmaschigere Überwachungsschwellenwerte als beispielsweise ein Segment der Gebäudeautomation mit geringem betrieblichen Risiko.

Definieren Sie klare Eskalations- und Reaktions-Workflows vor dem Live-Gang

Ein Alarm, auf den niemand zu reagieren weiß, erzeugt lediglich Rauschen. Definieren Sie vor der vollständigen Inbetriebnahme, wer welche Alarmkategorie erhält, wie die erwartete Reaktionszeit aussieht und wie das OT-Betriebspersonal mit den Cybersecurity-Analysten im Falle eines echten Verdachtsfalls kooperiert.

Empfohlene Checkliste für die NDR-Bereitstellung

Wie NDR Firewalls, IDS, EDR und SIEM ergänzt – statt sie zu ersetzen

Ein häufiges Missverständnis ist, dass NDR bestehende Sicherheitskontrollen ersetzen soll. Das ist nicht der Fall. Jede Ebene im Security Stack beantwortet eine andere Fragestellung, und NDR schließt eine Lücke, die andere strukturell nicht abdecken können.

• Firewalls kontrollieren, was eine Segmentgrenze passieren darf, können jedoch nicht bewerten, ob sich der erlaubte Datenverkehr im Inneren anomal verhält.

• Intrusion Detection Systeme (IDS) sind stark im Abgleich bekannter Angriffssignaturen, stoßen jedoch bei neuartigen Angriffen oder „Living-off-the-land“-Techniken, die legitime Protokolle nutzen, an ihre Grenzen.

• Endpoint Detection and Response (EDR) setzt einen installierten Agenten auf dem Gerät voraus – was auf den meisten älteren PLCs, RTUs und Embedded Controllern in der Fabrikhalle unmöglich ist.

• SIEM-Plattformen zentralisieren und korrelieren Protokolle, sind jedoch von der Qualität der eingespeisten Daten abhängig; NDR liefert die tiefen Verhaltensdaten des Netzwerks, die der SIEM-Korrelation einen echten analytischen Wert verleihen.

Die NDR-Netzwerküberwachung positioniert sich im Zentrum dieses Sicherheitskonzepts und bietet genau das, was keine andere Komponente leisten kann: kontinuierliche, agentenlose und verhaltensbasierte Sichtbarkeit für jedes kommunizierende Gerät im Netzwerk – unabhängig davon, ob es einen Agenten ausführen kann oder ob sein Datenverkehr einer bekannten Angriffssignatur entspricht.

NDR-Positionierung an der Seite von Firewalls, IDS, EDR und SIEM innerhalb einer ganzheitlichen OT-Sicherheitsarchitektur.

Wie Shieldworkz Ihr Unternehmen unterstützt

Shieldworkz unterstützt Industrieunternehmen, Energieversorger und KRITIS-Betreiber bei der Konzeption und dem Betrieb von NDR-Netzwerküberwachungsprogrammen, welche die Realitäten produktiver Industrieumgebungen berücksichtigen. Unser Ansatz folgt dem Grundsatz: Betriebssicherheit zuerst, Sicherheitsziele direkt danach. Denn ein Überwachungsprogramm, das den Betrieb stört, wird in der Praxis niemals dauerhaft toleriert.

• Passive, rückwirkungsfreie Installation von NDR-Sensoren, speziell konzipiert für OT- und ICS-Netzwerksegmente – mit Nulltoleranz für Betriebsunterbrechungen.

• Tiefgehende Sichtbarkeit auf Protokollebene für Modbus, DNP3, OPC-UA, PROFINET, EtherNet/IP und weitere industrielle Kommunikationsstandards.

• An dem Purdue-Modell ausgerichtete Platzierungsstrategie für Sensoren zur lückenlosen Abdeckung über Enterprise-, DMZ-, Leitebenen- und Steuerungsschichten hinweg.

• Auf die tatsächlichen Betriebsmuster, Schichtpläne und saisonalen Abweichungen der jeweiligen Anlage abgestimmte Verhaltens-Baselines anstelle generischer Standard-Schwellenwerte.

• Unterstützung bei der Integration in bestehende SIEM-, Firewall- und SOC-Strukturen, um den Wert Ihrer bereits getätigten Sicherheitsinvestitionen zu maximieren.

• Kontinuierliches Threat Hunting, Alarm-Triage und Incident-Response-Begleitung durch Analysten, die industrielle Prozesse verstehen und nicht nur IT-Netzwerkdatenverkehr interpretieren.

• Compliance-konforme Berichterstattung gemäß etablierten Standards der industriellen Cybersicherheit (z. B. IEC 62443) und gesetzlichen Anforderungen im KRITIS-Umfeld.

Das Ergebnis ist ein Überwachungsprogramm, dem Betriebsleiter vertrauen, das Steuerungsingenieure unterstützen und das Sicherheitsverantwortliche fundiert gegenüber dem Vorstand vertreten können – weil es darauf ausgerichtet ist, wie industrielle Prozesse tatsächlich funktionieren, und nicht auf theoretischen IT-Szenarien basiert.

Fazit

Die reine Verkehrssichtbarkeit war nie dafür ausgelegt, die im industriellen Umfeld entscheidende Frage zu beantworten: Ist das, was ich in meinem Netzwerk sehe, tatsächlich normal? Bandbreitendiagramme und Verbindungsprotokolle können zwar bestätigen, dass Daten fließen, sie sagen einem Betriebsleiter oder CISO jedoch nicht, ob diese Aktivitäten den normalen Betrieb darstellen oder die Vorbereitung eines schwerwiegenden Sicherheitsvorfalls.

Die NDR-Netzwerküberwachung schließt diese Lücke, indem sie OT- und ICS-Umgebungen den notwendigen Verhaltenskontext liefert. Sie macht aus einfachen Netzwerkaktivitäten ein Frühwarnsystem für Aufklärung, Lateral Movement, Command-and-Control-Aktivitäten und Datenabflussversuche – lange bevor es zu einer Beeinträchtigung des operativen Betriebs kommt.

Für Betreiber kritischer Infrastrukturen und Industrieanlagen, in denen Ausfallzeiten direkte finanzielle Schäden oder Sicherheitsrisiken nach sich ziehen, ist dieser Schritt von der bloßen Sichtbarkeit zum echten Verständnis keine Option mehr. Er wird zunehmend zur Mindestanforderung von Regulierungsbehörden, Versicherern und Aufsichtsräten gleichermaßen.

Zusätzliche Ressourcen  

Ein downloadbarer Bericht zum Stryker-Cybervorfall finden Sie hier  
Checkliste zur Bewertung und Auswahl von Lösungen für das Scannen von Wechselmedien finden Sie hier  
Auf IEC 62443 basierende OT/ICS-Risikoanalyse-Checkliste für die Lebensmittel- und Getränkeindustrie finden Sie hier 
Auf IEC 62443 basierende Leitfäden zur Behebung von Schwachstellen finden Sie hier