site-logo
site-logo
site-logo

Segmentierungsanforderungen nach IEC 62443: Risiken in Netzwerk-Sicherheitskontrollen transformieren

Segmentierungsanforderungen nach IEC 62443: Risiken in Netzwerk-Sicherheitskontrollen transformieren

Segmentierungsanforderungen nach IEC 62443: Risiken in Netzwerk-Sicherheitskontrollen transformieren

Segmentierungsanforderungen nach IEC 62443: Risiken in Netzwerk-Sicherheitskontrollen transformieren
Shieldworkz Logo

Team Shieldworkz

Wenn Sie heute fast jede beliebige Fertigungshalle, jedes Umspannwerk oder jede Wasseraufbereitungsanlage betreten, werden Sie ein Netzwerk vorfinden, das nie für Angriffe ausgelegt war. Es wurde dafür konzipiert, zuverlässig, berechenbar und über Jahrzehnte hinweg zu laufen. Diese Designphilosophie hat die industrielle Welt geschaffen, auf die wir angewiesen sind. Sie hat jedoch auch genau die Bedingungen geschaffen, die die Verteidigung von Operational Technology (OT)-Umgebungen so schwierig machen.

Jahrelang behandelten Industrieunternehmen die Netzwerksegmentierung als ein nettes Extra. Eine Firewall zwischen IT und OT wurde oft als ausreichend erachtet. Heute ist diese Annahme gefährlich. Angreifer müssen Steuerungssysteme nicht mehr direkt kompromittieren – sie benötigen lediglich einen ungespatchten Laptop, ein ungeschütztes Fernwartungstool oder eine nicht ordnungsgemäß isolierte Lieferantenverbindung. Einmal in einem flachen Netzwerk angelangt, bewegen sie sich fast ohne Widerstand lateral und erreichen oft innerhalb weniger Stunden speicherprogrammierbare Steuerungen (SPS/PLC), Engineering-Workstations und sicherheitsgerichtete Systeme (SIS).

Dies ist genau das Problem, für dessen Lösung die IEC 62443 entwickelt wurde. Im Zentrum des Standards steht ein Konzept, das einfach zu beschreiben, aber in der Praxis anspruchsvoll umzusetzen ist: Zones and Conduits (Zonen und Leitungen). Die Segmentierung ist in diesem Framework kein bloßes Kontrollkästchen zum Abhaken, sondern das architektonische Fundament, auf dem alles andere – von der Risikoanalyse bis hin zu den Security-Level-Zielen – aufbaut.

Dieser Artikel schlüsselt auf, was die Segmentierung nach IEC 62443 tatsächlich erfordert, warum so viele Industriestandorte sie immer noch falsch umsetzen und wie OT-Sicherheitsverantwortliche abstrakte Risiken in konkrete, durchsetzbare Netzwerk-Controls überführen können.

Warum Segmentierung das Rückgrat der IEC 62443-Konformität ist

Die IEC 62443 basiert auf einer risikobasierten Philosophie und nicht auf einem starren Regelwerk. Sie berücksichtigt, dass eine Chemieanlage, eine Produktionslinie im Lebensmittelbereich und ein Umspannwerk eines Energieversorgers im Falle einer Kompromittierung völlig unterschiedliche Auswirkungen haben – daher sollten sie nicht alle mit identischen Sicherheitsmaßnahmen geschützt werden. Die Segmentierung ist der Mechanismus, der diesen risikobasierten Ansatz in der Praxis erst ermöglicht.

Ohne klare Zonengrenzen übernimmt jedes Asset im Netzwerk praktisch das Risikoprofil des am wenigsten sicheren Geräts, das mit ihm verbunden ist. Ein einziger HLK-Regler mit Internetverbindung oder ein schlecht konfiguriertes Remote-Access-Gateway kann zum schwächsten Glied werden, das eine gesamte Produktionslinie gefährdet. Segmentierung dämmt dieses Risiko per Design ein, anstatt darauf zu hoffen, dass es nie auf die Probe gestellt wird.

Zudem treibt eine geschäftliche Realität diese Dringlichkeit voran. Versicherer, Aufsichtsbehörden und zunehmend auch Kunden fordern von Industrieunternehmen den Nachweis, dass ihre Steuerungssysteme mit definierten Sicherheitsgrenzen konzipiert und nicht nur durch eine einzige Perimeter-Firewall geschützt sind. Die Segmentierung hat sich von einer rein technischen Best Practice zu einer Governance-Anforderung gewandelt.

Zonen und Conduits nach IEC 62443 verstehen

Der Standard definiert zwei grundlegende Bausteine für die industrielle Netzwerkarchitektur: Zonen und Conduits. Beide tiefgehend und nicht nur oberflächlich zu verstehen, ist der Ausgangspunkt für jedes ernsthafte Segmentierungsprojekt.

Was ist eine Zone?

Eine Zone ist eine Gruppierung von logischen oder physischen Assets, die gemeinsame Sicherheitsanforderungen teilen. Assets werden zusammengefasst, weil sie eine ähnliche Kritikalität, ähnliche Auswirkungen bei einer Kompromittierung und eine ähnliche betriebliche Funktion aufweisen. Eine Zone kann Folgendes enthalten:

  • Alle PLCs und Remote-I/Os, die einer einzelnen Produktionslinie zugeordnet sind

  • Die Historian- und Reporting-Server, die von den Anlagentechnikern genutzt werden

  • Ein Safety Instrumented System (SIS) und die dazugehörigen Logic Solver

  • Die Remote-Access-Infrastruktur, die von externen Dienstleistern genutzt wird

Die Gruppierung erfolgt bewusst und nicht aus Bequemlichkeit. Assets sollten niemals nur deshalb in derselben Zone platziert werden, weil sie sich am selben physischen Switch oder im selben Subnetz befinden. Die Entscheidung zur Gruppierung muss durch die Risikoauswirkungen getrieben sein: Was passiert mit der Sicherheit, der Produktion und der Geschäftskontinuität, wenn diese Gruppe von Assets kompromittiert wird?

Was ist ein Conduit?

Ein Conduit (Leitung) ist der Pfad, über den die Kommunikation zwischen Zonen – oder in manchen Fällen innerhalb einer Zone, wenn der Datenverkehr streng kontrolliert werden muss – verläuft. In den Conduits befinden sich die eigentlichen Sicherheitskontrollen: Firewalls, unidirektionale Gateways, Datendioden, protokollsensitive Inspektion (Deep Packet Inspection) und Zugriffskontrollrichtlinien.

Jeder Conduit sollte drei Fragen beantworten, bevor er zugelassen wird:

  • Welche Daten müssen diese Grenze überschreiten und warum?

  • Welches ist das für diese Anforderung minimale erforderliche Berechtigungsniveau (Least Privilege)?

  • Was passiert, wenn dieser Pfad missbraucht oder kompromittiert wird?

Wenn ein Conduit diese Fragen nicht eindeutig beantworten kann, sollte er in dieser Form in der Regel nicht existieren.

Security Levels: Schutz an die Auswirkungen anpassen

Die IEC 62443 definiert Sicherheitsstufen (Security Levels, SL 0 bis SL 4), die die Stärke des Schutzes beschreiben, der gegen Angreifer mit zunehmenden Fähigkeiten erforderlich ist. Jeder Zone sollte auf Basis einer Risikoanalyse ein Sicherheitszielniveau (Target Security Level, SL-T) zugewiesen werden, und die schützenden Conduits müssen so ausgelegt sein, dass sie dieses Ziel erreichen.

Security Level

Fähigkeiten des Angreifers

Typisches industrielles Beispiel

SL 0

Keine spezifischen Sicherheitsanforderungen

Nicht-kritische, isolierte Testumgebungen

SL 1

Schutz vor unbeabsichtigtem oder zufälligem Missbrauch

Allgemeine, büroseitige OT-Berichterstellungssysteme

SL 2

Vorsätzlicher Angriff mit einfachen Mitteln

Standard-Steuerungsnetzwerke von Produktionslinien

SL 3

Spezialisierter Angreifer mit moderaten Ressourcen

Sicherheitskritische Prozesssteuerung (SIS), Umspannwerke von Energieversorgern

SL 4

Spezialisierter Angreifer mit umfangreichen Ressourcen und spezifischen Fachkenntnissen

Nationale Kritische Infrastrukturen (KRITIS), hochkritische Prozesssicherheitssysteme

Der Wert dieser Tabelle ist nicht akademischer Natur. Sie bietet OT-Verantwortlichen eine fundierte, standardisierte Sprache, um der Geschäftsführung und Auditoren zu erklären, warum eine Zone eine Datendiode erhält und eine andere mit einem Standard-Firewall-Regelwerk abgesichert wird. Die Segmentierung wird damit von einer technischen Meinung zu einer dokumentierten, risikobasierten Entscheidung.

Risiken, Herausforderungen und Branchenerkenntnisse

Auf dem Whiteboard klingt Segmentierung unkompliziert. In der Praxis handelt es sich jedoch um eines der operativ sensibelsten Projekte, die ein Industrieunternehmen durchführen kann – und die Folgen einer fehlerhaften Umsetzung wurden bereits mehrfach öffentlich sichtbar.

Wenn flache Netzwerke auf reale Angreifer treffen

Ende 2015 verschafften sich Angreifer Zugriff auf die Steuerungsnetzwerke mehrerer ukrainischer regionaler Stromverteiler. Einmal im System, konnten sie sich mit relativer Leichtigkeit von den IT-Systemen der Verwaltung in die operativen OT-Netzwerke bewegen, wo sie schließlich Leistungsschalter manipulierten und rund 230.000 Einwohner vom Stromnetz trennten. Ermittler stellten später fest, dass eine stärkere Trennung zwischen Unternehmens- und Steuerungsnetzwerken den Weg der Angreifer zu den Leistungsschaltern erheblich verlangsamt oder blockiert hätte. Dieser Vorfall bleibt eines der deutlichsten Praxisbeispiele dafür, was passiert, wenn IT und OT dieselbe Vertrauensgrenze teilen.

Ein ähnliches Muster zeigte sich 2017, als ein sicherheitsgerichtetes System (SIS) in einer petrochemischen Anlage im Nahen Osten von einer Schadsoftware angegriffen wurde, die speziell für die Manipulation von Sicherheitssteuerungen entwickelt worden war. Der Angriff begann nicht innerhalb des Sicherheitsnetzwerks, sondern über einen Zugriff an anderer Stelle der Umgebung und breitete sich lateral aus, bis er Systeme erreichte, die niemals aus dem allgemeinen operativen Datenverkehr erreichbar sein sollten. Sicherheitssysteme sind konzeptionell als letzte Verteidigungslinie gegen katastrophale Ausfälle gedacht. Wenn sie sich im selben erreichbaren Netzwerkbereich wie alle anderen Systeme befinden, wird diese letzte Verteidigungslinie für einen Angreifer zu einem weiteren Zwischenschritt.

Im Jahr 2019 war ein großer Aluminiumhersteller gezwungen, den Betrieb in mehreren Werken manuell mit Stift und Papier fortzuführen, nachdem sich Ransomware in seinem Netzwerk ausgebreitet hatte, was letztlich die Produktion weltweit lahmlegte. Der finanzielle Schaden ging in die zweistellige Millionenhöhe, und die Wiederherstellung dauerte Wochen. Die Lehre aus fast jeder Post-Incident-Analyse lautete: Ransomware hält sich selten an Netzwerkannahmen. Sie breitet sich überall dort aus, wo uneingeschränkte Konnektivität besteht, und findet jeden flachen, unsegmentierten Pfad.

Bei all diesen Fällen zeigt sich ein klares Muster. Der ursprüngliche Eintrittspunkt war selten das sensibelste System. Der tatsächliche Schaden entstand durch das, was der Angreifer danach erreichen konnte – und diese Erreichbarkeit war fast immer auf einen Fehler in der Segmentierung zurückzuführen, nicht auf das Versagen eines einzelnen Sicherheitstools.

Warum Segmentierungsprojekte häufig ins Stocken geraten oder scheitern

Gespräche mit OT-Sicherheitsverantwortlichen in der Fertigungs-, Energie- und Prozessindustrie zeigen eine Reihe wiederkehrender Herausforderungen, die Segmentierungsbemühungen verlangsamen:

  • Undokumentierte Altsystem-Verbindungen. Viele Anlagen verfügen über Kommunikationspfade, die vor Jahren von einem Dienstleister oder Systemintegrator eingerichtet und nie formal dokumentiert wurden. Eine Segmentierung ohne vorherige Identifizierung dieser Pfade birgt das Risiko, die Produktion zu unterbrechen.

  • Angst vor Betriebsstillständen. Engineering- und Betriebsteams sind verständlicherweise vorsichtig bei Netzwerkänderungen, die einen laufenden Prozess stören könnten, insbesondere in der kontinuierlichen Fertigung oder Energieerzeugung.

  • Mischung aus alter und neuer Ausrüstung. Legacy-PLCs mit eingeschränkter oder fehlender Unterstützung für moderne Authentifizierung stehen neben neueren, IP-fähigen Geräten, was eine einheitliche Durchsetzung von Richtlinien erschwert.

  • Unklare Zuständigkeiten. Die IT verwaltet oft die Netzwerkinfrastruktur, während die OT für den Prozess verantwortlich ist. Entscheidungen zur Segmentierung fallen häufig in eine Lücke zwischen diesen beiden Teams.

  • Übermäßiges Vertrauen in eine einzige Perimeter-Firewall. Viele Standorte betrachten eine einzige IT/OT-Grenz-Firewall immer noch als ausreichend, ohne interne Segmentierung zwischen Produktionslinien, Remote-Access-Punkten für Wartungsdienstleister oder Sicherheitssystemen.

  • Wildwuchs beim Fernzugriff (Remote Access Sprawl). Externe Dienstleister und Systemintegratoren behalten häufig dauerhafte Fernzugriffsrechte, die nach der Inbetriebnahme nie wieder eingeschränkt wurden. Dadurch entstehen Conduits, die die vorgesehenen Zonengrenzen vollständig umgehen.

Keine dieser Herausforderungen ist ungewöhnlich. Sie sind tatsächlich der Normalzustand in den meisten Industrieanlagen, die seit mehr her als einem Jahrzehnt in Betrieb sind. Dies zu erkennen, ist entscheidend: Segmentierungsprojekte scheitern selten an schlechter Technologie, sondern meist an einer überstürzten Planung, die die Erfassung der Assets (Asset Discovery) und die risikobasierte Zonendefinition überspringt.

Praktische Empfehlungen und Best Practices

Die Übertragung der Prinzipien der IEC 62443 in eine funktionierende Segmentierungsarchitektur ist ein strukturierter Prozess und kein einmaliger Projektmeilenstein. Der folgende Ansatz zeigt, wie reife Industrieunternehmen von flachen, risikoreichen Netzwerken zu resilienten Zone-and-Conduit-Architekturen übergehen.

1. Starten Sie mit einem vollständigen Asset-Inventory

Eine Segmentierung kann nicht für Assets konzipiert werden, von deren Existenz man nichts weiß. Ein umfassendes, kontinuierlich aktualisiertes Verzeichnis aller Geräte, Steuerungen, Workstations und Kommunikationspfade ist der unverzichtbare Ausgangspunkt. Dies schließt passive Netzwerkanalyse ein, um undokumentierte oder vergessene Verbindungen aufzudecken, da sich hier häufig die größten Risiken verbergen.

2. Gruppieren Sie Assets nach Auswirkung, nicht nach Bequemlichkeit

Definieren Sie potenzielle Zonen basierend darauf, was operativ, finanziell und sicherheitstechnisch passieren würde, wenn diese Gruppe von Assets kompromittiert würde – nicht basierend auf der vorhandenen physischen Verkabelung oder dem Subnetz-Layout. Ein Sicherheitssystem (SIS), ein PLC-Produktionsnetzwerk und ein Prozessdatenarchiv (Historian) erfordern fast immer separate Zonen, selbst wenn sie derzeit am selben Switch angeschlossen sind.

3. Weisen Sie jeder Zone ein Sicherheitszielniveau (SL-T) zu

Nutzen Sie einen dokumentierten Risikoanalyseprozess, um SL-T-Bewertungen zuzuweisen. Dieser Schritt macht die Segmentierung zu einer nachvollziehbaren, prüfbaren Entscheidung statt zu einem subjektiven Netzwerkdiagramm und unterstützt direkt die Anforderungen zur Risikoanalyse nach IEC 62443-3-2.

4. Konzipieren Sie Conduits nach dem Least-Privilege-Prinzip

Jeder Conduit sollte nur die spezifischen Protokolle, Ports und Verkehrsrichtungen zulassen, die für den legitimen Betrieb zwingend erforderlich sind. Bevorzugen Sie, wo immer möglich, unidirektionale Datenflüsse für Reporting- und Historian-Daten und beschränken Sie Engineering-Zugriffe auf definierte Wartungsfenster, anstatt sie dauerhaft offen zu halten.

5. Isolieren Sie den Fernzugriff vollständig

Zugriffe von Lieferanten und externen Technikern sollten über eine dedizierte, überwachte Jump-Host-Umgebung geleitet werden – niemals direkt in eine Produktionszone. Zugriffe müssen zeitlich begrenzt, protokolliert und regelmäßig überprüft werden, wobei Autorisierungen nach Abschluss der Arbeiten sofort zu entziehen sind.

6. Trennen Sie Sicherheitssysteme vom allgemeinen Steuerungsdatenverkehr

Sicherheitsgerichtete Systeme (SIS) verdienen eine eigene Zone mit den strengsten Conduit-Kontrollen in der gesamten Architektur. Sie sollten niemals eine Broadcast-Domäne, einen Switch oder eine Management-Schnittstelle mit dem allgemeinen Produktionssteuerungs-Datenverkehr teilen.

7. Validieren Sie, bevor Sie Richtlinien aktiv durchsetzen

Bevor Sie strenge Conduit-Regeln aktivieren, sollten Sie Segmentierungsrichtlinien in einem reinen Monitoring-Modus laufen lassen, um sicherzustellen, dass die legitimen Datenflüsse vollständig verstanden wurden. Dies verhindert die häufigste Ursache für segmentierungsbedingte Ausfallzeiten: das Blockieren eines Kommunikationspfads, dessen Existenz dem Betrieb nicht bewusst war, der aber tatsächlich benötigt wird.

8. Betrachten Sie Segmentierung als lebende Architektur

Netzwerke verändern sich, wenn Geräte hinzugefügt, ersetzt oder neu konfiguriert werden. Eine Segmentierungsarchitektur, die bei der Inbetriebnahme präzise war, kann innerhalb eines Jahres unbemerkt veralten. Regelmäßige Überprüfungen, gepaart mit kontinuierlicher Asset-Sichtbarkeit, sorgen dafür, dass Zonen und Conduits mit der realen Umgebung übereinstimmen und nicht mit einem veralteten Diagramm.

Schnellreferenz: Conduit-Controls nach Risikoszenario

Conduit-Szenario

Empfohlener Kontrollansatz

IT/OT-Schnittstelle

Dedizierte Firewall mit Deep Packet Inspection, restriktiven Regelsätzen, kein direktes Routing

Remote-Access für Lieferanten / Dritte

Isolierter Jump-Host, zeitlich begrenzter Zugriff, vollständige Sitzungsprotokollierung

Datenfluss für Historian / Reporting

Unidirektionales Gateway oder Datendiode, wo anwendbar

Grenze des Safety Instrumented System (SIS)

Vollständig isolierte Zone, keine gemeinsam genutzte Infrastruktur, höchstes SL-T

Zugriff auf Engineering-Workstations

Beschränkt auf definierte Wartungsfenster, Multi-Faktor-Authentisierung

Datenverkehr zwischen Produktionslinien

Interne Segmentierung mit überwachter, protokollsensitiver Inspektion

Diese strukturierte Zuordnung bietet Betriebsleitern und CISOs eine gemeinsame Referenz, die technische Segmentierungsentscheidungen in eine Sprache übersetzt, die der Betrieb, das Engineering und die Geschäftsführung gleichermaßen verstehen und mittragen können.

Wie Shieldworkz Unternehmen unterstützt

Die Konzeption und Implementierung einer an der IEC 62443 ausgerichteten Segmentierung ist selten eine Aufgabe, die ein internes Team allein bewältigen kann – insbesondere neben den täglichen Anforderungen der Produktion. Shieldworkz arbeitet an der Seite von Industrieunternehmen, um die Segmentierung von einer stockenden Initiative in eine funktionierende, nachhaltige Architektur zu überführen.

  • Umfassende OT-Asset-Erfassung zum Aufbau eines präzisen, kontinuierlich aktualisierten Verzeichnisses, bevor mit dem Entwurf von Zonen begonnen wird

  • Risikobasiertes Zonen- und Conduit-Design, das direkt an den Anforderungen der IEC 62443-3-2 und 3-3 ausgerichtet und auf das tatsächliche operative Risiko jedes Standorts zugeschnitten ist

  • Bewertungen des Sicherheitszielniveaus (SL-T), die der Führungsebene eine dokumentierte, fundierte Grundlage für jede architektonische Entscheidung bieten

  • Validierung von Conduits und Datenverkehr durch ein vorab geschaltetes Monitoring, um ungeplante Produktionsunterbrechungen zu verhindern

  • Härtung des Fernzugriffs für Lieferanten- und Drittverbindungen, um dauerhafte Zugriffspfade, die geplante Grenzen umgehen, zu schließen

  • Beratung zur Isolation von Sicherheitssystemen, um sicherzustellen, dass SIS-Umgebungen die strengsten Schutzanforderungen der Architektur erfüllen

  • Fortlaufende Architekturüberprüfungen, damit die Segmentierung auch bei Änderungen an Geräten, Lieferanten und Netzwerkbedingungen wirksam bleibt

  • Management-taugliche Berichterstattung, die technische Segmentierungsarbeit in die Risikosprache für Vorstände, Versicherer und Aufsichtsbehörden übersetzt

Das Ziel ist nicht, einfach Zonen auf einem Diagramm einzuzeichnen. Es geht darum, eine Architektur aufzubauen, der der Betrieb vertraut, die Sicherheitsteams verteidigen können und die das Schadensausmaß des nächsten Vorfalls nachweislich minimiert.

Fazit

Segmentierung ist kein einmaliges Projekt mit einer Ziellinie – sie ist eine kontinuierliche Disziplin, die darüber entscheidet, ob ein kompromittiertes Gerät zu einem eingegrenzten Vorfall oder zu einer anlagenweiten Krise führt. Die Zonen und Conduits der IEC 62443 bieten Industrieunternehmen eine strukturierte, risikobasierte Methode, um diese Entscheidung bewusst zu treffen, anstatt sie dem Zufall oder historisch gewachsenem Netzwerk-Wildwuchs zu überlassen.

Unternehmen, die dies erfolgreich umsetzen, teilen ein gemeinsames Merkmal: Sie behandeln die Segmentierung als geschäftliche Risikoentscheidung und nicht nur als Aufgabe für die Netzwerktechnik. Sie binden Betrieb, Engineering und Sicherheitsverantwortliche gemeinsam ein, basieren Zonengrenzen auf Auswirkungen statt auf Bequemlichkeit und validieren, bevor sie Richtlinien aktiv durchsetzen.

Die Vorfälle, die Schlagzeilen machen, beginnen selten dort, wo der Schaden endet. Der Unterschied zwischen einem eingegrenzten Ereignis und einer Katastrophe hängt fast immer davon wie weit das Netzwerk es dem Angreifer erlaubte, als Nächstes vorzudringen.

Buchen Sie eine kostenfreie Beratung mit unseren Experten

Wenn Ihr Unternehmen an der Umsetzung der IEC 62443-Segmentierungsanforderungen arbeitet oder sich unsicher ist, wie exponiert Ihre aktuelle Netzwerkarchitektur tatsächlich ist, steht Ihnen unser Team gerne zur Seite. Buchen Sie eine kostenfreie Beratung mit den OT-Sicherheitsexperten von Shieldworkz und gehen Sie den ersten Schritt hin zu einer Netzwerkarchitektur, die auf resilienten, risikobasierten Zonen und Conduits aufbaut.

Zusätzliche Ressourcen  

Ein herunterladbarer Bericht über den Stryker-Cybervorfall finden Sie hier  
Eine Checkliste zur Evaluierung und Auswahl von Anbietern für Wechselmedien-Scan-Lösungen finden Sie hier  
Eine IEC 62443-basierte OT/ICS-Risikoanalyse-Checkliste für die Lebens- und Genussmittelindustrie finden Sie hier 
IEC 62443-basierte Leitfäden zur Behebung von Schwachstellen finden Sie hier

Wöchentlich erhalten

Ressourcen & Nachrichten

Erfahren Sie, wie unsere branchenführenden OT-Security-Lösungen kritische Sicherheitsherausforderungen gemäß KRITIS-Anforderungen bewältigen

Dies könnte Ihnen auch gefallen.

BG image

Jetzt anfangen

Skalieren Sie Ihre CPS-Sicherheitslage

Nehmen Sie Kontakt mit unseren CPS-Sicherheitsexperten für eine kostenlose Beratung auf.

BG image

Jetzt anfangen

Skalieren Sie Ihre CPS-Sicherheitslage

Nehmen Sie Kontakt mit unseren CPS-Sicherheitsexperten für eine kostenlose Beratung auf.

BG image

Jetzt anfangen

Skalieren Sie Ihre CPS-Sicherheitslage

Nehmen Sie Kontakt mit unseren CPS-Sicherheitsexperten für eine kostenlose Beratung auf.