OT/Industrienetze absichern: IT/OT-Trennung in der Praxis

OT/Industrienetze absichern ist heute eine Kernaufgabe für Unternehmen mit Produktion, Energieversorgung, Logistik, Gebäudetechnik oder kritischen Prozessen, weil die Angriffsfläche in den letzten Jahren stark gewachsen ist: Fernwartung, IIoT-Sensorik, MES/ERP-Integration, Cloud-Analytics und zunehmende Standardisierung auf Ethernet/IP bringen Komfort – aber auch IT-typische Risiken in Umgebungen, die ursprünglich für Verfügbarkeit und Sicherheit durch physische Isolation gebaut wurden. Die wirksamste Maßnahme in der Praxis ist eine konsequente IT/OT-Trennung: OT-Systeme (PLC, SCADA, HMI, Engineering-Workstations, Historian, Prozessnetz) werden nicht wie „ein weiteres VLAN“ im Unternehmensnetz behandelt, sondern als eigene Sicherheitsdomäne mit klaren Übergängen, minimalen Kommunikationspfaden und streng kontrollierter Fernzugriffskette. Dabei geht es nicht um „OT vom Internet trennen“ als Schlagwort, sondern um ein belastbares Betriebsmodell: Welche Daten dürfen von OT nach IT? Welche Steuerungs- und Engineering-Zugriffe sind wirklich notwendig? Wie werden Patches, Backups und Logging umgesetzt, ohne Prozesse zu gefährden? Und wie baut man eine Architektur, die in der Produktion stabil bleibt und gleichzeitig moderne Security-Kontrollen zulässt? Dieser Artikel zeigt praxisnah, wie Sie OT/Industrienetze absichern und die IT/OT-Trennung in der Praxis umsetzen – mit Zonenmodell, DMZ-Konzept, Firewall-Policies, Remote-Access-Design, Monitoring und typischen Fehlern, die in OT-Umgebungen besonders teuer werden.

OT vs. IT: Warum Industrienetze anders ticken

Operational Technology (OT) umfasst Systeme, die physische Prozesse überwachen oder steuern: SPS/PLC, SCADA, HMI, DCS, Safety-Systeme, Antriebstechnik, Mess- und Regeltechnik. Die IT dagegen fokussiert klassische Informationsverarbeitung: Office, Server, Cloud, Identity, Collaboration. Das klingt trivial, ist aber für Security entscheidend, weil OT andere Prioritäten und Randbedingungen hat.

• Verfügbarkeit vor allem: Stillstand kostet Geld und kann Sicherheitsrisiken für Menschen und Anlagen erzeugen.
• Determinismus und Echtzeit: Einige OT-Kommunikation ist zeitkritisch, Paketverluste oder Latenzspitzen sind problematisch.
• Lange Lebenszyklen: OT-Komponenten laufen oft 10–20 Jahre; Patching ist komplex und teilweise nicht möglich.
• Legacy-Protokolle: Viele Industriestandards wurden nicht für feindliche Netze gebaut (wenig Auth, wenig Verschlüsselung).
• Change-Management: Änderungen müssen mit Produktion, Safety und Qualität abgestimmt werden.

Die Konsequenz: IT/OT-Trennung muss Sicherheitsgewinn liefern, ohne OT-Verfügbarkeit zu kompromittieren. Das gelingt am besten mit klarer Segmentierung, kontrollierten Übergängen und einem „least privilege“-Ansatz für Datenflüsse.

Bedrohungsmodell: Was Angreifer in OT-Umgebungen typischerweise tun

OT-Angriffe beginnen selten „im OT-Netz“. Häufig ist der Einstieg in der IT (Phishing, VPN, Lieferkette) und die OT wird anschließend über schlecht getrennte Netze, gemeinsame Identitäten oder offene Remote-Zugänge erreicht. Typische Ziele sind Stillstand (Ransomware), Manipulation von Prozessparametern, Datenabfluss, Sabotage oder Erpressung.

• Pivot von IT nach OT: Über gemeinsame Switches/VLANs, Routen, falsch konfigurierte Firewalls oder „temporäre“ Ausnahmen.
• Missbrauch von Fernwartung: Schwache VPN-Accounts, TeamViewer-ähnliche Tools, geteilte Passwörter.
• Engineering-Workstations als Schlüssel: Zugriff auf PLC-Programme, Firmware, Konfiguration.
• Ausbreitung über SMB/RDP: Wenn OT-Windows-Systeme wie normale Clients behandelt werden.
• Blindheit durch fehlendes Monitoring: Angriffe bleiben lange unentdeckt, weil OT-Telemetrie fehlt.

Für eine strukturierte Sicht auf OT-Security empfiehlt sich die Referenzarchitektur aus IEC 62443 (Normenfamilie für industrielle Automatisierung und Control Systems Security) sowie das Zonen-/Conduit-Prinzip.

IT/OT-Trennung in der Praxis: Zonen und Conduits

Der wichtigste Architekturbaustein ist ein Zonenmodell: Systeme mit ähnlichem Schutzbedarf und ähnlicher Funktionalität werden gruppiert, und die Kommunikation zwischen den Zonen wird über definierte Conduits (kontrollierte Übergänge) geregelt. Das verhindert „flache“ Industrienetze, in denen jeder mit jedem sprechen kann.

Typische OT-Zonen

• Enterprise IT Zone: Office, ERP, E-Mail, allgemeine Server, Internetzugänge.
• Industrial DMZ: Pufferzone zwischen IT und OT für Datenaustausch und Remote Access.
• Operations Zone (OT Core): SCADA-Server, Historian, OT-Domain Services (falls vorhanden), zentrale OT-Services.
• Cell/Area Zones: Produktionslinien, Maschinenzellen, Teilanlagen; oft der sinnvollste Segmentierungsanker.
• Safety Zone: Safety-Systeme (SIS), die besonders isoliert und streng kontrolliert werden.
• Engineering Zone: Engineering-Workstations, Programmierstationen, Tools, Konfigurationsmanagement.

Warum die Industrial DMZ unverzichtbar ist

Die Industrial DMZ ist der „Stoßdämpfer“ zwischen IT und OT. Sie verhindert direkte Verbindungen von IT-Systemen in OT-Subsysteme und bietet definierte Dienste für Datentransfer, Patch-Repos, Remote Access, Jump Hosts und Protokoll-Gateways. Das klassische Leitbild orientiert sich am Purdue-Modell (häufig Level 3.5 als DMZ), das in vielen OT-Designs als Denkrahmen dient.

Architektur: Bewährte Referenz-Setups für IT/OT-Trennung

In der Praxis funktionieren wenige, klare Setups besser als hochkomplexe Speziallösungen. Drei Muster sind besonders häufig.

Setup mit zentraler Industrial DMZ und OT-Firewall-Paar

• Pfad: Enterprise IT → Firewall A → Industrial DMZ → Firewall B → OT Core/Cell Zones
• Vorteil: Strikte Trennung, saubere Policies, gute Logging-Punkte
• Wichtig: Keine „Bypass“-Routen, keine direkten Links IT↔OT außerhalb der DMZ

Setup mit Cell/Area Segmentierung und lokalen Zellen-Firewalls

• Pfad: OT Core → Zellen-Firewall → Cell/Area Zone
• Vorteil: Laterale Bewegung wird drastisch reduziert, Ausfälle bleiben lokal
• Wichtig: Standardisierte Regeln pro Zellentyp, um Betriebsaufwand zu kontrollieren

Setup mit Einweg-Datenfluss (Data Diode) für kritische Umgebungen

In besonders sensiblen OT-Umgebungen kann ein Einweg-Datenfluss sinnvoll sein: OT sendet Prozessdaten nach IT (für Reporting/Analytics), aber IT kann nicht zurück in OT sprechen. Das reduziert Risiko erheblich, erfordert aber klare Prozesse für notwendige Rückkanäle (z. B. Wartungsfenster via kontrolliertem Remote Access).

Firewall-Policies: Minimalflüsse statt „praktischer“ Vollzugriff

Firewalls sind in OT-Architekturen nicht nur „Edge-Geräte“, sondern Policy-Enforcer zwischen Zonen. Der entscheidende Qualitätsmaßstab ist, ob Regeln fachlich begründet, minimal und überprüfbar sind.

Grundregeln für IT↔OT

• Direkte IT→OT-Verbindungen vermeiden: Zugriff geht über DMZ-Dienste (Jump Host, Proxy, Broker).
• Default Deny zwischen Zonen: Erlaubt wird nur, was dokumentiert notwendig ist.
• Protokoll und Ziel präzise: IP/Port/Service konkret, keine „Any“-Regeln.
• Keine Admin-Protokolle aus IT: RDP/SSH/WinRM in OT nur über Engineering/Management-Pfade.

DMZ als Datendrehscheibe

• Historian-Replikation: OT-Historian → DMZ-Historian → IT-Analytics, statt IT direkt auf OT-Historian.
• File Transfer: Patch- oder Datenfiles über DMZ-Server mit Malware-Scan und Protokollierung.
• API/Message Broker: OT→DMZ über definierte Gateways, DMZ→IT über standardisierte Schnittstellen.

Cell/Area: „Nur was die Zelle braucht“

• Engineering-Zugriff zeitlich begrenzen: PLC-Programmierung nur im Wartungsfenster, mit Freigabe.
• Keine Zelle-zu-Zelle-Kommunikation als Default: Ausnahmen nur, wenn technisch notwendig.
• Safety besonders isolieren: Safety-Systeme nur mit minimalen Monitoring-/Management-Flows, wenn überhaupt.

Remote Access und Fernwartung: Sicherer Zugang ohne Hintertür

Fernwartung ist einer der häufigsten OT-Risikotreiber. „Schnell mal ein Vendor-Tool“ oder ein dauerhaft offener VPN-Tunnel ist betriebspraktisch, aber sicherheitstechnisch gefährlich. Ein professionelles Modell stellt sicher: Zugang ist kontrolliert, zeitlich begrenzt, nachvollziehbar und technisch auf das Notwendige beschränkt.

Best Practices für OT-Fernzugriff

• Ein Einstiegspunkt: Remote Access endet in der DMZ (nicht direkt im OT-Netz).
• Bastion/Jump Host: Zugriff auf OT-Systeme nur über einen gehärteten Jump Host, idealerweise mit Session Recording.
• MFA und starke Identität: Pflicht für alle externen Zugänge; keine geteilten Konten.
• Just-in-Time: Zugänge nur für Wartungsfenster aktiv, danach automatisch entzogen.
• Least Privilege: Vendor bekommt nur Zugriff auf die betroffene Zelle/Maschine, nicht auf das gesamte OT.

Privileged Access Management (PAM) ist hierfür ein sinnvoller Ergänzungsbaustein, um Accounts, Freigaben und Sessions kontrolliert zu steuern.

OT-spezifisches Monitoring: Sichtbarkeit schaffen, ohne Prozesse zu stören

In OT ist „blind“ besonders gefährlich, weil Angriffe spät erkannt werden und Änderungen große Wirkung haben. Gleichzeitig dürfen Monitoring-Maßnahmen den Prozess nicht destabilisieren. Ein bewährter Ansatz ist passives Monitoring (SPAN/TAP) plus gezielte Logs von Übergangspunkten (Firewalls, Jump Hosts, DMZ-Server).

Telemetriequellen mit hohem Nutzen

• Firewalls zwischen Zonen: Denies, neue Flows, Policy-Changes, ungewöhnliche Ports
• DMZ-Systeme: Jump-Host-Logins, File-Transfers, Proxy-/Broker-Logs
• Netflow/IPFIX: Kommunikationsmuster pro Zelle, neue Kommunikationspartner
• DNS (sofern genutzt): Neue Domains, NXDOMAIN-Spikes, ungewöhnliche Ziele

Detections, die in OT oft gut funktionieren

• Neue IT→OT-Verbindungen: Jeder neue Flow über Zonen hinweg ist verdächtig, wenn nicht geplant.
• Engineering-Protokolle außerhalb Wartungsfenster: PLC/Engineering-Aktivitäten zur Unzeit sind hochkritisch.
• Scanning in OT: Ein Host kontaktiert viele IPs/Ports in kurzer Zeit.
• Ungewöhnlicher Outbound aus OT: OT-Systeme sprechen plötzlich ins Internet oder zu neuen ASNs.

Für strukturierte Erkennung und Taktiken ist MITRE ATT&CK nützlich; für OT-spezifische Sichtweisen gibt es ergänzende OT-Mappings und Use-Case-Kataloge je nach Umgebung.

Patch- und Vulnerability-Management in OT: anders, aber machbar

OT kann nicht „Patch Tuesday“ wie IT. Dennoch ist Patch- und Schwachstellenmanagement möglich, wenn es prozess- und risikoorientiert aufgebaut wird.

• Asset-Inventar: Ohne vollständige Geräte- und Versionsliste ist Risikobewertung unmöglich.
• Wartungsfenster: Patches werden geplant, getestet und in abgestimmten Fenstern ausgerollt.
• Compensating Controls: Wenn Patching nicht möglich ist: Segmentierung verschärfen, Egress begrenzen, Zugriffspfade reduzieren.
• DMZ-Update-Pfade: Updates über DMZ-Repositories statt direkter Internetzugänge aus OT.

Identity und Admin-Pfade: OT-Kronjuwelen schützen

Viele OT-Vorfälle eskalieren über privilegierte Zugänge: Engineering-Accounts, lokale Admins auf HMI/SCADA, gemeinsam genutzte Passwörter. Netzwerkseitig wird es stabiler, wenn Admin-Pfade strikt getrennt und nachvollziehbar sind.

• Dedizierte Engineering-Zone: Engineering-Workstations sind keine normalen Office-Clients.
• Bastion-Access: Admin- und Engineering-Zugriffe laufen über Jump Hosts, nicht direkt.
• Keine Shared Accounts: Individualisierte Konten, Rollenmodell, Rezertifizierung.
• MFA und PAM: Für kritische Systeme und externe Dienstleister besonders sinnvoll.

Datenaustausch OT↔IT: „Sicher integrieren“ statt „einfach routen“

OT muss oft Daten an IT liefern (KPIs, OEE, Qualität, Predictive Maintenance). Unsicher wird es, wenn IT-Services direkt in OT-Netzen „mitlaufen“ oder wenn OT-Systeme beliebig ins Internet sprechen. Besser ist eine kontrollierte Datenpipeline über die DMZ.

• Pull aus IT vermeiden: IT sollte OT nicht direkt „abfragen“, sondern OT liefert Daten an DMZ-Broker/Replicas.
• Protokoll-Gateways: Industrielle Protokolle werden an Übergängen terminiert und kontrolliert weitergegeben.
• Einweg-Optionen: Für hohe Schutzbedarfe: OT→IT als Einwegstrom.

Typische Stolpersteine bei IT/OT-Trennung

• „Temporäre“ Ausnahmen werden dauerhaft: Einmal geöffnet, nie wieder geschlossen – das zerstört das Zonenmodell.
• Keine echte DMZ: IT spricht direkt in OT, weil es „schneller“ ist.
• OT im gleichen Active Directory wie IT: Erhöht das Risiko, dass IT-Kompromittierung OT mitreißt (je nach Design).
• Fernwartung ohne Governance: Dauer-VPN, geteilte Konten, keine Session Logs.
• Zu aggressive Security-Tools: Aktive Scans oder IPS-Policies ohne OT-Testing können Prozesse stören.
• Fehlende Dokumentation: Niemand weiß, warum welcher Flow existiert; Troubleshooting wird riskant.

Praxisfahrplan: IT/OT-Trennung schrittweise umsetzen

OT-Security-Projekte sind am erfolgreichsten, wenn sie iterativ eingeführt werden und Betrieb/Produktion eng eingebunden sind.

Phase: Sichtbarkeit und Inventar

• Assets und Kommunikationsbeziehungen erfassen (Ziel: „wer spricht mit wem und warum“)
• OT-Kronjuwelen priorisieren (Safety, Engineering, Historian, zentrale Steuerung)
• Remote-Access-Inventur: alle Fernwartungswege dokumentieren und bewerten

Phase: Zonenmodell und DMZ etablieren

• Industrial DMZ aufbauen, direkte IT→OT-Verbindungen eliminieren
• Firewalls zwischen IT↔DMZ und DMZ↔OT mit Default Deny
• Standarddienste in DMZ platzieren (Jump Host, File Transfer, Broker, Patch-Repo)

Phase: Cell/Area Segmentierung

• Produktionszellen in eigene Segmente trennen
• Regelsets standardisieren (Zellentypen), Ausnahmen befristen
• Engineering-Zugriffe in Wartungsfenster und über Bastion führen

Phase: Betrieb und kontinuierliche Verbesserung

• Monitoring-Use-Cases priorisieren (neue Flows, Scans, Outbound-Anomalien, Admin-Aktivität)
• Patch-/Change-Prozesse für OT fest verankern
• Regelmäßige Rezertifizierung von Firewall-Regeln, Remote-Zugängen und Vendor-Accounts

Checkliste: IT/OT-Trennung in der Praxis

• Ein Zonenmodell existiert und ist technisch umgesetzt (IT, Industrial DMZ, OT Core, Cell/Area, Engineering, Safety).
• Es gibt keine direkten IT→OT-Verbindungen; alle Übergänge laufen über DMZ-Services und kontrollierte Conduits.
• Firewall-Policies sind minimalistisch: Default Deny, explizite Allow-Regeln, keine „Any-Any“-Ausnahmen.
• Remote Access endet in der DMZ; Zugriff auf OT nur über Bastion/Jump Host, mit MFA und zeitlicher Begrenzung.
• Engineering-Workstations sind getrennt und gehärtet; Admin-Pfade sind nachvollziehbar und rollenbasiert.
• Cell/Area Segmentierung reduziert laterale Bewegung; Zelle-zu-Zelle ist standardmäßig blockiert.
• Egress aus OT ist kontrolliert; Datenflüsse OT↔IT sind über DMZ-Broker/Replicas geregelt.
• Monitoring ist etabliert (Firewalls, DMZ, Netflow/DNS) mit wenigen starken Alerts und klaren Playbooks.
• OT-spezifisches Change- und Patch-Management existiert; kompensierende Kontrollen für ungepatchte Systeme sind definiert.

Weiterführende Informationsquellen

• IEC 62443: Normenfamilie für industrielle Automatisierung und Control Systems Security
• NIST SP 800-82: Guide to Industrial Control Systems (ICS) Security
• MITRE ATT&CK: Taktiken/Techniken für Erkennung und Incident Response
• CISA ICS Resources: Empfehlungen und Alerts für ICS/OT-Security
• BSI: IT-Grundschutz und Orientierung zu Segmentierung, Betrieb und Resilienz

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.