Die Produktionslinie steht. Fehlermeldungen fluten die Leitwarte, Maschinen wechseln in den Nothalt. Dabei hatte alles mit einem Routine-Eingriff begonnen: Ein kritischer Patch sollte auf einer Engineering-Workstation installiert werden, um einer Schwachstelle zuvorzukommen.
Das Problem: Niemand konnte sicher vorhersagen, wie das jahrzehntealte Geflecht aus Software, Steuerungssystemen und Maschinen auf die Änderung reagiert. Was als Security-Maßnahme startete, legte den Betrieb lahm.
Dieses Szenario illustriert eine Kernherausforderung der OT-Security. Während man in der klassischen IT fehlerhafte Systeme meist isolieren, neu starten oder ersetzen kann, hängen in der Produktion reale, physische Prozesse an den Datenkabeln. Ein unbedachter IT-Scan oder ein fehlschlagendes Update gefährden hier nicht nur Daten, sondern die Anlagenverfügbarkeit und im Extremfall Menschen. Ein Cyberrisiko wird zum physischen Risiko.
Genau an dieser Schnittstelle zwischen Cybersecurity und Safety setzt die IEC 62443 an. Der Standard für Industrial Automation and Control Systems (IACS) - zu Deutsch: industrielle Automatisierungssysteme – fordert von klassischen IT-Security-Spezialisten ein konsequentes Umdenken.
Die Leitfrage lautet nicht mehr nur: „Wie schützen wir dieses System vor einem Angriff?“. Sie muss lauten: „Was passiert mit dem physischen Prozess im Fall einer Kompromittierung und wie verhindern wir, dass ein einzelner Vorfall die gesamte Anlage lahmlegt?“
Der Unterschied zwischen IT und OT
IT-Security und OT-Security verfolgen grundsätzlich dasselbe Ziel: Systeme und Prozesse vor unbefugtem Zugriff, Manipulation und Ausfall zu schützen. Die Rahmenbedingungen, unter denen dieses Ziel erreicht werden muss, unterscheiden sich jedoch erheblich.
In der klassischen IT wird häufig mit dem CIA-Modell gearbeitet: Confidentiality, Integrity und Availability. Je nach Anwendungsfall können diese drei Schutzziele unterschiedlich gewichtet werden. In vielen industriellen Umgebungen haben Availability und Integrity jedoch eine besonders hohe Bedeutung. Ein Systemausfall kann unmittelbar einen Produktionsstillstand verursachen; eine Manipulation von Steuerungsdaten kann dazu führen, dass ein physischer Prozess falsch oder unkontrolliert abläuft.
Hinzu kommt eine Dimension, die in der klassischen CIA-Betrachtung nicht ausreichend sichtbar wird: Safety. Ein Cyberangriff auf ein industrielles System kann über digitale Manipulationen physische Konsequenzen haben – beispielsweise beschädigte Maschinen, gefährliche Prozesszustände oder Umweltbeeinträchtigungen.
Weitere Unterschiede ergeben sich aus den technischen und betrieblichen Rahmenbedingungen:
- Lange Lebenszyklen: Während IT-Systeme häufig innerhalb weniger Jahre erneuert oder grundlegend aktualisiert werden, können industrielle Anlagen und ihre Komponenten 15, 20 oder mehr Jahre im Einsatz sein.
- Determinismus und Echtzeitanforderungen: In vielen Automatisierungsumgebungen müssen Steuerungs- und Regelungsprozesse innerhalb definierter Zeitfenster reagieren. Zusätzliche Latenzen oder unerwartete Last können deshalb nicht einfach als normales Performanceproblem betrachtet werden.
- Begrenzte Wartungsfenster: Ein Server lässt sich häufig außerhalb der Geschäftszeiten neu starten. Eine kontinuierlich laufende Produktionsanlage lässt sich dagegen unter Umständen nur selten oder gar nicht kurzfristig unterbrechen.
- Physische Konsequenzen: Ein kompromittiertes IT-System kann erhebliche wirtschaftliche Schäden verursachen. Ein kompromittiertes OT-System kann darüber hinaus direkt Einfluss auf Maschinen, Anlagen und Prozesse nehmen.
Gerade für Betreiber Kritischer Infrastrukturen ist dieser Zusammenhang besonders relevant – mehr dazu auf der Themenseite KRITIS – Bedeutung und Schutz.
Genau diese Rahmenbedingungen machen deutlich, warum Security-Maßnahmen in der OT nicht einfach nach den gleichen Regeln umgesetzt werden können wie in einem klassischen Unternehmensnetzwerk. Die Herausforderung besteht nicht darin, weniger Security zu betreiben, sondern Sicherheitsmaßnahmen so zu gestalten, dass sie die besonderen Anforderungen industrieller Prozesse berücksichtigt.
Warum Security in OT-Umgebungen andere Hebel braucht
Die grundlegenden Ziele der Security gelten auch in der OT: Systeme härten, Zugriffe kontrollieren, Netzwerke segmentieren. Der entscheidende Unterschied liegt im Wie. Was in der Unternehmens-IT als Best Practice gilt, kann in einer Produktionsumgebung unkalkulierbare Risiken erzeugen.
Ein simples „Copy-Paste“ von IT-Konzepten in die Fabrikhalle funktioniert nicht. Das zeigt sich an vier klassischen Reibungspunkten:
Patch Management (Sicherheit vs. Verfügbarkeit)
In der IT schließt man Schwachstellen durch sofortige Updates. In der OT zieht ein einzelner Patch einen gewaltigen Rattenschwanz an Abhängigkeiten nach sich – von der Engineering-Software bis zur physischen Maschine. Die Leitfrage lautet daher nicht: „Warum ist das System noch ungepatcht?“, sondern: „Wie reduzieren wir das Risiko der Schwachstelle (z.B. durch Einschränkung der Kommunikation), ohne ein neues Risiko zu erzeugen?“
Vulnerability Scanning (Sichtbarkeit ohne Nebenwirkungen)
Aktive Netzwerk-Scans sind in der IT Standard. In der OT kann schon unerwarteter Traffic eine jahrzehntealte Steuerung zum Absturz bringen. Die Lösung liegt oft in passiven Verfahren: Der Netzwerkverkehr wird nur analysiert und „mitgehört“, ohne die Assets aktiv zu attackieren.
Endpoints & IAM (Eine SPS ist kein Büro-PC)
Moderne EDR-Software oder strenge Least Privilege-Konzepte scheitern oft an historischen OT-Komponenten, die keine Nutzerverwaltung kennen oder ressourcenschwach sind. Weil sich das einzelne Asset oft nicht aufrüsten lässt, muss die Architektur die Schwächen kompensieren – etwa durch Jump Hosts oder dedizierte Engineering-Stationen. Wie sich sichere OT-Komponenten schon bei der Beschaffung erkennen lassen, zeigen die CISA-Empfehlungen zur Auswahl sicherer OT-Produkte.
Netzwerksegmentierung (Nach Prozess, nicht nach IP)
Während die klassische IT ihre Netze nach organisatorischen Grenzen trennt (Gäste, Entwicklung, HR), muss die Segmentierung in der OT dem industriellen Prozess folgen. Die einzige Frage, die zählt: Welche Systeme müssen zwingend miteinander kommunizieren, damit die Produktionslinie läuft?
Die Konsequenz: Architektur schlägt Einzelmaßnahme
IT-Prinzipien verlieren in der OT nicht ihre Gültigkeit, aber sie stoßen an technische und physikalische Grenzen. Cybersecurity darf hier deshalb nie vom Schutz eines einzelnen Geräts abhängen. Und genau an diesem Punkt entfaltet die Normenreihe IEC 62443 ihre größte Stärke: Sie beschreibt nicht nur isolierte Kontrollen, sondern liefert den methodischen Rahmen, um Anlagen systematisch abzusichern.
Der IEC 62443-Ansatz: Vom Prozess zum passgenauen Schutz
Wie entscheidet man, wie viel Security eine jahrzehntealtes IACS wirklich braucht? Die IEC 62443 beantwortet diese Frage mit einem klaren Schnitt. Anstatt alle Best Practices aus der Unternehmens-IT zu kopieren, strukturiert die Norm das Problem völlig neu: Das benötigte Schutzniveau wird konsequent aus den physikalischen Risiken, Funktionen und Abhängigkeiten der realen Anlage abgeleitet.
Der Paradigmenwechsel zeigt sich bereits in der Leitfrage. Sie lautet nicht mehr: „Welche Kontrollen müssen wir flächendeckend einsetzen?“ Sondern: „Welche Risiken bedrohen diesen spezifischen Prozess, und welches Schutzniveau fordern die beteiligten Systeme?“
Um diese Frage zu beantworten, muss das Security-Team den Prozess im Kern verstehen: Welche Anlagen sind wirklich kritisch? Welche Kommunikationswege sind zwingend notwendig? Und vor allem: Was passiert mit Mensch, Maschine und Umwelt, wenn eine Steuerung ausfällt oder manipuliert wird?
Security als Teamsport: Die geteilte Verantwortung
Ein Betreiber kann eine unsicher entwickelte SPS (Speicherprogrammierbare Steuerung) nicht im Nachhinein flicken und ein Hersteller kann nicht kontrollieren, wie seine Komponente im Werkzeugmaschinenbau vernetzt wird. Daher betrachtet die IEC 62443 den gesamten Lebenszyklus und verteilt die Verantwortung auf drei Säulen:
- IEC 62443-2-x (Betreiber): Richtet sich an die Organisation, Security-Prozesse und das Risikomanagement im laufenden Betrieb. Welche organisatorischen Pflichten sich hier zusätzlich aus der Regulierung ergeben, erläutert der Beitrag Vom Gesetz zur Praxis: Was NIS-2 für Unternehmen bedeutet; einen vertiefenden Überblick liefert die Themenseite IT-Regulierung: Gesetze (NIS-2, DORA) & Pflichten.
- IEC 62443-3-x (Systemintegrator): Fokussiert sich auf die sichere Integration und Systemarchitektur durch die verantwortlichen Integratoren (hier greifen Zonen & Conduits).
-
IEC 62443-4-x (Hersteller): Fordert „Security by Design“ und sichere Entwicklungsprozesse direkt auf der Komponenten-Ebene.
Risikobasiert statt „Security um jeden Preis“
In der Industrie gilt: Maximale Sicherheit ist nicht automatisch die beste Sicherheit. Besonders dann nicht, wenn sie Echtzeitanforderungen oder die Verfügbarkeit sabotiert. Ein Display, das lediglich Produktionsdaten anzeigt, erfordert ein grundlegend anderes Schutzniveau als eine Steuerung, deren Ausfall einen gefährlichen Überdruck im Kessel erzeugt. Der Ansatz stellt sicher, dass Schutzmaßnahmen und Budgets genau dort greifen, wo das betriebliche und physische Risiko am höchsten ist.
Von der Risikoanalyse zur Architektur
Die IEC 62443 belässt es nicht bei der abstrakten Risikoanalyse, sondern übersetzt diese direkt in die Systemarchitektur. Die Logik dahinter ist strikt sequenziell:
Risiko → Security-Anforderung → Zone → Conduit → Technische Maßnahme
Zurück zu unserem Szenario aus der Einleitung: Die Engineering-Workstation, deren Patch die Anlage lahmlegte, ist nicht nur „ein weiterer PC“. Die Norm erfordert, ihren Kontext zu bewerten: In welcher Zone befindet sich die Workstation? Über welche Conduits (Kommunikationswege) ist sie mit den Steuerungssystemen verbunden?
Damit verlagert die IEC 62443 den Fokus von isolierten Security-Tools hin zu einer belastbaren Architektur. Und das bringt uns zum mächtigsten und zentralsten Konzept der gesamten Norm: Zones & Conduits.
Zones & Conduits: Das architektonische Herzstück der IEC 62443
Zurück zu unserer Engineering-Workstation: Die Schwachstelle ist bekannt, der Patch steht bereit. Doch bevor gehandelt werden kann, muss klar sein, welche Rolle dieses System in der Gesamtarchitektur spielt. Genau hier greift das zentrale Strukturierungsmodell der IEC 62443: Zones & Conduits.
Die Norm betrachtet ein industrielles Netzwerk nicht als homogenen Block, sondern zerlegt es in kontrollierbare Segmente. Das Prinzip ist simpel, die strategischen Auswirkungen für die Cyberresilienz sind gewaltig:
Zones (Zonen) – nach Risiko gruppieren, nicht nach IT-Topologie
Eine Zone fasst Assets mit vergleichbaren Sicherheitsanforderungen zusammen (z. B. alle Steuerungen einer bestimmten Produktionslinie). In der klassischen IT fragen wir: „Welche Geräte stecken im selben VLAN?“ In der OT nach IEC 62443 lautet die Leitfrage: „Welche Assets haben das gleiche Risikoprofil und welche physischen Auswirkungen hat es, wenn genau diese Gruppe kompromittiert wird?
Conduits (Übergänge) – Der Flaschenhals der Kommunikation:
Zonen arbeiten selten isoliert. Die Kommunikationswege dazwischen sind die Conduits. Ein Conduit ist nicht einfach eine Firewall, sondern die logische Klammer für alle zulässigen Datenströme. Hier gilt es zu hinterfragen: Welche Systeme müssen für den industriellen Prozess zwingend miteinander sprechen? Mit welchen Protokollen? In welche Richtung?
Der Gedanke ähnelt dabei dem Zero-Trust-Prinzip aus der klassischen IT – nur konsequent auf physische Prozesse übertragen. Mehr dazu im Beitrag Zero Trust in der Praxis.
Containment statt Perimeterschutz
Eine Firewall am Übergang zwischen Office- und Produktionsnetz (Perimeterschutz) ist wichtig, beantwortet aber eine kritische Frage nicht: Was passiert, wenn der Angreifer bereits drinnen ist?
Betrachten wir den potenziellen Angriffspfad: Office-Netzwerk → Engineering-Workstation → Conduit → Steuerungszone → SPS. Ohne saubere Zonierung kann sich ein Angreifer, der die Workstation übernommen hat, ungehindert lateral in die Steuerungsebene vorarbeiten. Das Zones & Conduits-Modell etabliert hier eine Defense-in-Depth-Strategie. Das Ziel ist Schadensbegrenzung (Containment): Selbst wenn ein einzelnes Asset fällt, sollen klare Grenzen und streng limitierte Kommunikationswege verhindern, dass die nächste Zone infiziert wird.
Die Kette der Erkenntnis: Vom Asset zur Maßnahme
Eine Zone ist per Definition noch nicht „sicher“. Sie liefert lediglich das strukturierte Fundament für die Risikoanalyse. Für jede Zone und jeden Conduit wird ein Ziel-Sicherheitsniveau definiert, das sogenannte Target Security Level (SL-T). Erst daraus leiten sich die technischen Anforderungen (nach IEC 62443-3-3) ab. Damit entsteht eine klare Architektur-Kette, die reinen Aktionismus oder blinden Tool-Kauf verhindert:
Assets → Zonen & Conduits → Risikoanalyse → Target Security Level (SL-T) → Technische & Organisatorische Maßnahmen
Für unsere Workstation heißt das: Wir definieren ihre Zone, limitieren ihre Conduits, bewerten das Risiko und bestimmen so das notwendige Schutzniveau. Das führt uns unweigerlich zur wichtigsten Frage für Entscheider und Security-Teams: Wie viel Security ist in der Produktion eigentlich genug? Die Antwort darauf liefern die vier Security Level.
Security Level in der Praxis: Wie viel Schutz braucht eine Anlage?
Mit Zones & Conduits steht die Architektur. Nun folgt die Praxisfrage: Wie viel Security braucht ein bestimmtes Segment eigentlich?
Genau dafür liefert die IEC 62443 das Konzept der Security Level (SL). Wichtig vorab: Security Levels sind keine einfachen Schulnoten nach dem Motto „SL 4 ist sicher, SL 1 ist unsicher“. Sie beschreiben stattdessen, gegen welches Angreiferprofil und welche Ressourcen ein System bestehen muss.
| Security Level | Das Schutzziel: Schutz gegen... |
|---|---|
| SL 0 | Keine spezifischen Sicherheitsanforderungen |
| SL 1 | Zufällige oder unbeabsichtigte Fehler (z.B. der unbedarfte Mitarbeiter) |
| SL 2 | Gezielte Angriffe mit einfachen Mitteln (z.B. Standard-Malware, Gelegenheitshacker) |
| SL 3 | Gezielte Angriffe mit fortgeschrittenen Mitteln und OT-Know-how |
| SL 4 | Hochkomplexe Angriffe durch staatliche Akteure (APTs) mit massiven Ressourcen |
Die entscheidende Frage ist daher: „Welches Level ist für das spezifische Risiko dieser konkreten Zone angemessen?“.
Mehr Sicherheit ist nicht automatisch bessere Sicherheit
Das Ziel einer OT-Security-Strategie lautet nicht, jede Zone auf SL 4 zu panzern. Ein maximaler Schutz bringt enorme technische und organisatorische Hürden mit sich. Wenn diese Maßnahmen die Verfügbarkeit drosseln oder Echtzeitprozesse stören, ohne dass das Risiko dies rechtfertigt, schadet die Security-Maßnahme dem Geschäft. Eine Produktionsanlage braucht nicht überall dasselbe Level.
Das Dreigestirn der Security Level: SL-T, SL-C und SL-A
Um diese Risikoabwägung in der Praxis steuern zu können, trennt die IEC 62443 den Begriff „Security Level“ in drei essenzielle Perspektiven:
- SL-T (Target Security Level): Das Ziel. Wie viel Security benötigen wir für diese Zone basierend auf der Risikoanalyse?
- SL-C (Capability Security Level): Die Hardware-Fähigkeit. Welches Security-Niveau bringt eine eingekaufte Komponente (z.B. eine SPS) von Haus aus technisch mit?
- SL-A (Achieved Security Level): Die Realität. Welches Level erreicht die Zone im tatsächlichen Betrieb der Gesamtanlage
Diese Unterscheidung ist in der Praxis der größte Hebel. Ein Beispiel: Die Risikoanalyse fordert für eine kritische Zone ein SL-T von 3. Die verbaute Steuerung schafft technisch aber nur ein SL-C von 2.
Das bedeutet nicht, dass die Anlage unsicher bleiben muss. Es bedeutet lediglich, dass die Komponente allein das Ziel nicht erreicht. Die Gesamtarchitektur muss den Mangel kompensieren, etwa durch strengere Netzwerksegmentierung oder vorgeschaltete Firewalls, um am Ende ein SL-A von 3 für die gesamte Zone zu erreichen. Das Security Level der Einzelkomponente ist nicht das Security Level des Gesamtsystems.
Was bedeutet das für unsere ungepatchte Workstation? Zurück zu unserem Ausgangsszenario: Die Workstation hat eine Schwachstelle, aber der Patch lässt sich nicht einspielen, ohne die Anlage zu gefährden. Ohne IEC 62443 würde es sehr kompliziert werden. Mit der Methodik der Norm stellen wir jetzt völlig andere Fragen:
- In welcher Zone steht die Workstation?
- Welches Ziel-Level (SL-T) gilt hier?
- Fällt unser erreichtes Level (SL-A) durch die Schwachstelle unter das Ziel?
- Wenn wir den Patch nicht einspielen können: Wie können wir das System stattdessen „von außen“ abschirmen (z. B. durch strengere Firewalls oder Netzwerk-Trennung), um diese Schwäche auszugleichen und die Anlage trotzdem sicher zu halten?
Damit wird die IEC 62443 von einem theoretischen Regelwerk zu einem handfesten Werkzeug. Sie verhindert blinden Aktionismus und hilft dabei, Budgets und Maßnahmen exakt dort zu priorisieren, wo ein Angriff den größten physischen und wirtschaftlichen Schaden anrichten würde.
Von der Theorie zur Praxis: IEC 62443 im Bestand umsetzen
Eine historisch gewachsene Produktionsanlage nach IEC 62443 abzusichern, beginnt nicht mit dem blinden Kauf von Sicherheitslösungen. Der erste Schritt ist deutlich unspektakulärer, aber essenziell: Transparenz schaffen.
So gelingt die methodische Umsetzung in der Praxis, ohne den laufenden Betrieb zu gefährden:
1. Sichtbarkeit herstellen (Das Asset Inventory)
Man kann nur schützen, was man kennt. Eine Liste von IP-Adressen reicht dafür nicht aus. Es muss lückenlos erfasst werden: Welche Steuerungen, HMIs und Feldgeräte existieren? Welche Firmware läuft? Wie sehen die Kommunikationswege und Fernwartungszugänge aus? Da aktive Netzwerk-Scans alte Anlagen oft zum Absturz bringen, sind passive Discovery-Verfahren hier das Mittel der Wahl. Erst verstehen, dann absichern.
2. Risiken bewerten, nicht nur Schwachstellen jagen
Ein roter CVSS-Score (Schwachstellen-Bewertung) auf einer isolierten Workstation ist oft weniger kritisch als eine „kleine“ Lücke an einem Asset, das den Kernprozess steuert. Die entscheidende Metrik in der OT ist immer die Auswirkung auf den physischen Prozess: Was passiert bei Ausfall oder Manipulation mit der Produktion, der Umwelt und der Sicherheit (Safety) der Mitarbeiter?
3. Zonen, Conduits und Ziel-Level (SL-T) definieren
Ein historisch gewachsenes VLAN (Virtual Local Area Network) ist keine Security-Zone. Die Architektur muss stattdessen entlang der funktionalen Prozessgrenzen neu strukturiert werden. Für jede definierte Zone und jeden Conduit wird anschließend risikobasiert das benötigte Target Security Level (SL-T) festgelegt. Die Devise lautet: Passgenaues Schutzniveau statt Gießkannenprinzip.
4. Architektonische Hebel nutzen (Gap-Analyse)
Jetzt folgt der Abgleich: Erreicht die Zone das geforderte Ziel-Level? Wenn eine alte Komponente sich nicht patchen lässt, muss das Risiko architektonisch kompensiert werden – etwa durch strikte Netzwerksegmentierung, Allowlisting oder strenges Monitoring am Conduit. Nicht jedes Problem muss direkt auf dem Endgerät gelöst werden. Die Lücke zwischen Ziel und Realität wird durch ein smartes Defense-in-Depth-Konzept geschlossen.
5. IT und OT vereinen: Evolution statt „Big Bang“
Für den IT-Security-Spezialisten ist ein ungepatchtes System ein sofortiges Risiko; für den OT-Verantwortlichen ist das Einspielen eines Patches in einen validierten Prozess das eigentliche Risiko. Beide haben recht. Echte Cyberresilienz erfordert daher gemeinsame Prozesse und Verantwortlichkeiten.
Wie Unternehmen diesen Spagat zwischen Regulierung und Resilienz in der Praxis meistern, zeigt die Aufzeichnung Cyberresilienz von morgen: Proaktiv statt reaktiv der it-sa Expo&Congress 2025. Jetzt Aufzeichnung ansehen!
Der pragmatische Start: Ein kompletter Umbau der Anlage über Nacht ist illusorisch. Ein pragmatischer Startpunkt liegt dort, wo das Risiko am höchsten ist: an den Übergängen zwischen Office- und Produktionsnetz oder bei externen Fernwartungszugängen. Das Ziel von IEC 62443 ist keine perfekte, einmalige Momentaufnahme, sondern ein kontinuierlicher Prozess, in dem Risiken strukturiert bewertet und schrittweise reduziert werden.
Sie wollen mit OT-Security-Verantwortlichen und IEC-62443-Experten direkt ins Gespräch kommen? Auf der it-sa EXPO & Congress erwarten Sie Live-Vorträge, praxisnahe Use Cases und den direkten Austausch mit Ausstellern zu industrieller Cybersicherheit. Jetzt als Besucher anmelden!
Fazit: OT-Security beginnt bei der Architektur, nicht beim Patch
Zurück zu unserer Engineering-Workstation vom Anfang: Die Schwachstelle ist da, der Patch lässt sich nicht einspielen. Was für die klassische IT ein unlösbarer Konflikt ist, markiert in der Welt der IEC 62443 lediglich den Startpunkt der Security-Betrachtung.
Die Leitfrage lautet nicht dogmatisch: „Wie zwingen wir diesen Patch auf das System?“. Sie lautet pragmatisch: „Welches Risiko entsteht für den industriellen Prozess und wie können wir es durch architektonische Maßnahmen (Defense in Depth) abfangen?“.
Diese Perspektive macht den entscheidenden Unterschied. Die IEC 62443 fordert keine „IT-Security light“. Sie hilft vielmehr dabei, bewährte Security-Prinzipien in einen Kontext zu übersetzen, in dem Verfügbarkeit und physische Sicherheit (Safety) an erster Stelle stehen.
Der Perspektivwechsel für Security-Teams
Ausgehend von einer echten Risikoanalyse werden Zonen gezogen, Kommunikationswege (Conduits) definiert und passgenaue Security Level abgeleitet. Das erfordert ein Umdenken:
- Nicht jede Schwachstelle muss zwingend auf dem betroffenen Endgerät gelöst werden.
- Nicht jedes System benötigt das maximale Schutzniveau.
- Entscheidend ist, dass die Gesamtarchitektur das Risiko beherrscht.
Damit ist die IEC 62443 auch das perfekte Puzzleteil für Unternehmen, die auf Management-Ebene bereits mit Frameworks wie der ISO 27001 arbeiten. Sie schlägt die Brücke vom abstrakten Security-Management hinunter auf den Shopfloor, bis in die Systemarchitektur und den Betrieb.
Die wichtigste Erkenntnis: OT-Security bedeutet nicht, IT-Sicherheit weniger konsequent umzusetzen. Es bedeutet, sie konsequent an der physikalischen Realität des Produktionsprozesses auszurichten. Wer diese Denkweise verinnerlicht, betrachtet eine Fabrik nicht mehr als eine bloße Sammlung von Rechnern, die gepatcht werden müssen. Er begreift sie als vernetztes, physisches Automatisierungssystem, in dem Security keine nachträglich aufgesetzte Last ist, sondern das Fundament für einen resilienten Betrieb.
