Jede Industrieanlage basiert auf Vertrauen. Vertrauen darauf, dass sich ein Ventil öffnet, wenn es angewiesen wird, sich zu öffnen, dass eine Steuerung die Logik ausführt, mit der sie programmiert wurde, und dass ein menschlicher Bediener vor einer HMI das sieht, was tatsächlich in der Anlage geschieht. Da die Operational Technology immer stärker mit Unternehmensnetzwerken, Cloud-Plattformen und Remote-Anbietern vernetzt wird, ist dieses Vertrauen immer schwerer zu garantieren. Genau das ist die Lücke, die mit den IEC 62443 Security Levels geschlossen werden soll.

Für CISOs, Betriebsleiter und Steuerungsingenieure taucht der Begriff „Security Level“ häufig in Herstellerdokumentationen, Risikoanalysen und Auditberichten auf, ohne dass genau erklärt wird, was er für den täglichen Betrieb eigentlich bedeutet. Dieser Blog schlüsselt das Konzept verständlich auf, stellt den Bezug zu realen Vorfällen in der Industrie her und zeigt auf, wie ein strukturiertes IEC 62443 Gap Assessment einen abstrakten Standard in ein funktionierendes Sicherheitsprogramm verwandeln kann.

Was ist IEC 62443 und warum ist es jetzt wichtig?

Die IEC 62443 ist eine international anerkannte Normenreihe für die IT-Sicherheit in der Industrieautomatisierung (IACS). Im Gegensatz zu klassischen IT-Sicherheits-Frameworks wurde sie speziell für die Realitäten der Operational Technology (OT) entwickelt: lange Lebenszyklen von Anlagen, sicherheitskritische Prozesse, Legacy-Protokolle und Umgebungen, in denen ein Sicherheitspatch nicht einfach über Nacht eingespielt werden kann, ohne Ausfallzeiten oder ein Sicherheitsrisiko einzugehen.

Im Mittelpunkt der Norm steht das Konzept der Security Levels – eine strukturierte Methode, um zu beschreiben, wie viel Schutz ein System, eine Zone oder eine Komponente benötigt und wie viel Schutz tatsächlich vorhanden ist. Anstatt Cybersicherheit als einfaches „Bestanden oder Nicht bestanden“ zu betrachten, berücksichtigt die IEC 62443, dass eine Wasseraufbereitungsanlage, eine pharmazeutische Produktionslinie und ein Umspannwerk jeweils unterschiedliche Risikoprofile aufweisen und daher eine unterschiedliche Schutztiefe erfordern.

Diese Unterscheidung ist heute wichtiger denn je. In den Sektoren Fertigung, Energie, Wasser und Transport ist in den letzten Jahren ein starker Anstieg gezielter Angriffe zu verzeichnen. Zudem verweisen Regulierungsbehörden in verschiedenen Regionen im Rahmen von Compliance-Vorgaben (wie den KRITIS-Standards), Versicherungsanforderungen und Beschaffungsverträgen immer häufiger auf die IEC 62443. Das Verständnis von Security Levels ist keine rein technische Formsache mehr, sondern längst ein Thema für die Geschäftsführung.

Die fünf IEC 62443 Security Levels im Detail

Die IEC 62443 definiert fünf Sicherheitsstufen, nummeriert von SL 0 bis SL 4. Jedes Level entspricht der Raffinesse, den Ressourcen und der Absicht des Angreifers, dem ein System standhalten soll. Die Stufen sind kumulativ: Bei einem System mit der Einstufung SL 3 wird davon ausgegangen, dass es auch die Anforderungen von SL 1 und SL 2 erfüllt.

Abbildung 1: Übersicht über die IEC 62443 Security Levels (SL 0 bis SL 4)

Visuelle Darstellung der steigenden Schutzanforderungen über die fünf Security Levels hinweg

Es ist wichtig zu betonen, was diese Stufen tatsächlich messen. Sie beschreiben nicht, wie „gut“ das Sicherheitsprogramm einer Anlage auf dem Papier aussieht. Sie beschreiben die Widerstandsfähigkeit einer bestimmten Zone oder eines Systems gegenüber einem definierten Angreifertyp. Dies ist eine weitaus nützlichere Messgröße für die operative Praxis bei der Budgetplanung und der Definition von Gegenmaßnahmen.

Target, Capability und Achieved Security Levels: Warum der Unterschied entscheidend ist

Eines der am häufigsten missverstandenen Details der IEC 62443 ist, dass der „Security Level“ kein einzelner, statischer Wert ist. Die Norm definiert tatsächlich drei miteinander verknüpfte Konzepte. Diese zu verwechseln, gehört zu den häufigsten Fehlern bei Audits und Lieferantenverhandlungen.

Target Security Level (SL-T)

Dies ist das Sicherheitsniveau, das eine Organisation auf Basis einer formalen Risikoanalyse für eine Zone oder ein System festlegt. Es beschreibt den Soll-Zustand, nicht den aktuellen Zustand.

Capability Security Level (SL-C)

Dies beschreibt das Sicherheitsniveau, das eine Komponente oder ein System bei korrekter Konfiguration von Natur aus erreichen kann, basierend auf dem Design und der Dokumentation des Herstellers. Eine Firewall oder eine PLC kann ab Werk für SL-C 3 zertifiziert sein, aber diese Einstufung gilt nur, wenn sie auch entsprechend den Vorgaben implementiert und konfiguriert wird.

Achieved Security Level (SL-A)

Dies ist das tatsächliche Sicherheitsniveau, auf dem ein System derzeit in der Praxis betrieben wird – unter Berücksichtigung der aktuellen Konfiguration, des Patch-Status, der Netzwerksegmentierung und der kompensierenden Kontrollen. Das SL-A liegt häufig unter dem SL-T. Genau diese Lücke aufzudecken, ist das Ziel eines professionellen IEC 62443 Gap Assessments.

Sicherheitsprogramme scheitern meist nicht an mangelndem Ehrgeiz auf dem Papier, sondern daran, dass niemand die Diskrepanz zwischen dem Target und dem Achieved Level formal misst. Eine Zone, die vor fünf Jahren für SL 3 ausgelegt wurde, kann durch ungepatchte Systeme, ungesicherten Fernzugriff oder undokumentierte Netzwerkänderungen unbemerkt auf ein effektives SL 1 absinken.

Warum Security Levels wichtig sind: Lehren aus realen Vorfällen in der Industrie

Security Levels können theoretisch wirken, bis man sie mit realen Ereignissen in Werkshallen und Leitständen vergleicht. Einige gut dokumentierte Vorfälle im Bereich der industriellen Cybersicherheit verdeutlichen, warum dieses Framework existiert.

In einem viel beachteten Fall aus dem Energiesektor verschafften sich Angreifer Zugang zum operativen Netzwerk eines Energieversorgers und konnten Leistungsschalter manipulieren. Dies führte zu einem großflächigen Stromausfall, von dem Hunderttausende Kunden über mehrere Stunden betroffen waren. Ermittler stellten später fest, dass die betroffenen Steuerungssysteme über eine unzureichende Netzwerksegmentierung und schwache Zugriffskontrollen zwischen IT- und OT-Umgebungen verfügten – Bedingungen, die trotz der Kritikalität der Anlagen einem niedrigen Achieved Security Level entsprachen.

In einem anderen bemerkenswerten Vorfall, der ein sicherheitsgerichtetes System (SIS) in einer petrochemischen Anlage betraf, wurde Schadsoftware, die speziell für die Interaktion mit Sicherheitssteuerungen entwickelt wurde, nur aufgrund eines nicht damit zusammenhängenden Systemfehlers entdeckt – und nicht etwa durch Sicherheits-Monitoring. Dieser Vorfall zeigte, dass Sicherheitssysteme, von denen man oft annimmt, dass sie durch ein „Air Gap“ isoliert und inhärent sicher sind, ein Achieved Security Level aufweisen können, das weit unter den Anforderungen ihrer Kritikalität liegt.

Ein weiterer Vorfall bei einem Aluminium- und Ökostromproduzenten verdeutlichte die betrieblichen Kosten, die entstehen, wenn Security Levels in IT und OT gleichermaßen unterschätzt werden. Ein Ransomware-Angriff zwang das Unternehmen, große Teile seiner Produktion über Wochen hinweg manuell zu betreiben, was finanzielle Schäden in zweistelliger Millionenhöhe verursachte. Die Reaktion erforderte den kompletten Neuaufbau der Systeme – ein kostspieliger und folgenschwerer Weg, um festzustellen, dass die Achieved Security Levels hinter den Target-Anforderungen zurückgeblieben waren.

Ein kleinerer, aber ebenso lehrreicher Fall betraf eine Wasseraufbereitungsanlage, in der ein Bediener über eine Fernwartungssoftware eine kurze, unbefugte Änderung an den Sollwerten für die Chemikalien-Dosierung bemerkte. Der Vorfall wurde schnell erkannt und verhinderte Schaden, machte jedoch deutlich, wie ein einziger Fernzugriffspunkt ohne Multi-Faktor-Authentisierung (MFA) oder Sitzungsüberwachung eine ansonsten gut konzipierte Sicherheitsarchitektur im Alleingang aushebeln kann.

Keinem dieser Unternehmen mangelte es an Technologie-Budgets oder dem Willen zur Sicherheit. Was in jedem Fall fehlte, war ein klares und kontinuierlich validiertes Verständnis darüber, wo das Achieved Security Level im Verhältnis zum Risiko der jeweiligen Zone tatsächlich stand.

Durchführung eines IEC 62443 Gap Assessments

Ein IEC 62443 Gap Assessment ist der strukturierte Prozess des Abgleichs von Target Security Levels (Soll) mit den Achieved Security Levels (Ist) für jede Zone und jeden Conduit in einer Industrieumgebung, gefolgt von der Identifizierung der spezifischen technischen und organisatorischen Lücken, die geschlossen werden müssen.

Ein gründliches Gap Assessment umfasst in der Regel die folgenden Phasen:

Abbildung 2: Kernphasen eines strukturierten IEC 62443 Gap Assessments

Der Wert dieses Prozesses liegt darin, dass er subjektive Einschätzungen zur Sicherheit durch ein belastbares, evidenzbasiertes Bild ersetzt. Ein Betriebsleiter kann mit einer klaren Aussage in Budgetverhandlungen gehen: „Diese Zone muss auf SL 3 betrieben werden, da eine Kompromittierung hier die Produktion über Wochen lahmlegen könnte – derzeit befinden wir uns aufgrund dieser spezifischen Lücken jedoch nur auf einem realisierten SL 1.“

Häufige Herausforderungen bei der Anwendung von Security Levels

Selbst Unternehmen, welche die Theorie hinter der IEC 62443 verstehen, tun sich oft mit der praktischen Umsetzung schwer. Zu den häufigsten Herausforderungen gehören:

• Legacy-Systeme, die nie unter dem Gesichtspunkt der Cybersicherheit entwickelt wurden und moderne Authentisierungs- oder Verschlüsselungsverfahren nicht ohne kostspielige Anpassungen unterstützen.

• Flache oder unzureichend segmentierte Netzwerke, in denen sich eine Kompromittierung in einer Zone mit geringer Kritikalität lateral in Bereiche mit hohem Gefahrenpotenzial ausbreiten kann.

• Unklare Zuständigkeiten zwischen IT- und OT-Teams, was zu Sicherheitsmaßnahmen führt, die auf einem IT-Dashboard zwar gut aussehen, aber nicht den tatsächlichen Gegebenheiten in der Werkshalle entsprechen.

• Fernzugriffe durch Hersteller und Drittanbieter, die Standard-Sicherheitsrichtlinien umgehen – oft aus Gründen der Bequemlichkeit bei Wartungsarbeiten.

• Ein trügerisches Gefühl der Sicherheit durch physische Isolierung („Air Gap“), obwohl der Zugriff über WLAN, USB oder Engineering-Laptops diese Isolierung de facto aufhebt.

• Die Betrachtung der Security-Level-Bewertung als einmaliges Compliance-Projekt anstatt als kontinuierlicher Prozess, der sich mit der Bedrohungslage und den Veränderungen in der Anlage weiterentwickeln muss.

Jede dieser Herausforderungen vergrößert direkt die Lücke zwischen dem Target und dem Achieved Security Level – oft unbemerkt, bis ein Vorfall, ein Audit oder ein Beinahe-Fehler das Thema auf die Agenda der Geschäftsführung zwingt.

Praktische Empfehlungen zur Erhöhung der Security Levels

Die Schließung der Lücke zwischen Target und Achieved Security Level erfordert kein unbegrenztes Budget. Es erfordert Disziplin, eine strukturierte Reihenfolge und die Bereitschaft, Security Levels als dynamische Kennzahl und nicht als statisches Label zu betrachten. Die folgenden Praktiken führen erfahrungsgemäß zu messbaren Verbesserungen:

1. Konsequenz vor Compliance stellen

Definieren Sie Target Security Levels basierend auf den tatsächlichen Auswirkungen einer Kompromittierung der jeweiligen Zone (einschließlich Auswirkungen auf die funktionale Sicherheit, Umwelt und Produktion), anstatt pauschal ein einheitliches Niveau für die gesamte Anlage anzusetzen. So bleibt der Investitionsfokus dort, wo er den größten Nutzen bringt.

2. Segmentierung vor Absicherung

Die Netzwerksegmentierung mittels Zonen und Conduits gehört zu den effektivsten Sicherheitsmaßnahmen überhaupt. Eine gut segmentierte Umgebung grenzt einen Vorfall auf eine einzelne Zone ein und verhindert, dass er Systeme mit deutlich höherer Kritikalität erreicht.

3. Fernzugriff als explizites Risiko behandeln

Jeder Fernzugriffspfad – ob für Zulieferer, Systemintegratoren oder interne Ingenieure – muss inventarisiert, mittels Multi-Faktor-Authentisierung (MFA) abgesichert, zeitlich begrenzt und lückenlos protokolliert werden. Fernzugriffe waren an einem Großteil der öffentlich dokumentierten OT-Sicherheitsvorfälle maßgeblich beteiligt.

4. Aufbau eines dynamischen Asset-Inventars

Sie können keinem Asset ein Sicherheitsniveau zuweisen oder dieses messen, von dessen Existenz Sie nichts wissen. Eine kontinuierliche, passive Erkennung von Geräten und Kommunikationsmustern hält das Inventar auch bei Veränderungen in der Anlage stets aktuell.

5. Überprüfung in festen Intervallen

Das realisierte Sicherheitsniveau (SL-A) verschlechtert sich im Laufe der Zeit schleichend durch Konfigurationsänderungen, ausstehende Patches und neu hinzugefügte Geräte. Ein regelmäßiges Gap Assessment, mindestens einmal jährlich sowie nach jeder größeren Änderung, sorgt für Transparenz beim SL-A.

6. Zusammenarbeit von Safety- und Security-Teams

Sicherheitsgerichtete Systeme (SIS) weisen in jeder Anlage die höchsten Kritikalitätsstufen auf. Die Security Levels für diese Systeme sollten gemeinsam von Experten für Anlagensicherheit (Safety) und Cybersicherheit (Security) definiert werden, nicht von einer Abteilung isoliert.

Wie Shieldworkz Ihr Unternehmen unterstützt

Shieldworkz unterstützt Industrieunternehmen, Energieversorger und Hersteller dabei, die IEC 62443 Security Levels von einem theoretischen Standard in ein messbares, auditsicheres Sicherheitsprogramm zu überführen. Unser Ansatz orientiert sich an den praktischen Realitäten laufender Betriebsumgebungen, nicht an generischen IT-Konzepten.

• Umfassende IEC 62443 Gap Assessments, die Zonen, Conduits, Target Security Levels und Achieved Security Levels mit klaren Nachweisen abbilden.

• Asset-Discovery und Netzwerk-Sichtbarkeits-Services speziell für OT-Umgebungen, unter Verwendung passiver Methoden, die den laufenden Betrieb nicht stören.

• Risiko- und Konsequenzanalysen, die genau auf die spezifischen Prozesse, Sicherheitssysteme und regulatorischen Anforderungen (z. B. BSIG, K產業-Vorgaben) Ihrer Anlage abgestimmt sind.

• Phasenbasierte, budgetbewusste Roadmaps zur Behebung von Schwachstellen, die diejenigen Lücken priorisieren, welche die größte Risikominderung versprechen.

• Kontinuierliche Überwachung und beratende Unterstützung, um sicherzustellen, dass die Achieved Security Levels auch bei Veränderungen in der Anlage dem Soll-Zustand entsprechen.

• Praxisnahe Unterstützung bei der Ausrichtung von sicherheitsgerichteten Systemen, Fernzugriffsarchitekturen und der Netzwerksegmentierung gemäß den Anforderungen der IEC 62443.

Anstatt nur ein statisches Dokument zu übergeben, begleitet Shieldworkz Ihre Security- und Engineering-Teams bei der gesamten Umsetzung. Wir helfen Ihnen, Analyseergebnisse in dauerhafte Verbesserungen zu übersetzen, die sowohl realen Betriebsbedingungen als auch zukünftigen Audits standhalten.

Fazit

Die IEC 62443 Security Levels bieten Industrieunternehmen eine gemeinsame Sprache zur Risikobewertung, die technische Realität mit geschäftlichen Auswirkungen verbindet. Das Verständnis des Unterschieds zwischen Target, Capability und Achieved Security Levels sowie die kontinuierliche Messung dieser Abweichung unterscheidet Unternehmen, die ihre Sicherheitslücken während eines Audits aufdecken, von denen, die dies erst bei einem Sicherheitsvorfall tun.

Die Bedrohungslage im industriellen Umfeld verschärft sich weiter. Dabei sind am stärksten diejenigen Anlagen gefährdet, die nicht etwa gänzlich ohne Sicherheitskonzept dastehen, sondern jene, bei denen das realisierte Sicherheitsniveau unbemerkt hinter die Zielvorgaben zurückgefallen ist. Ein strukturiertes, fundiert dokumentiertes Gap Assessment ist der direkteste Weg, diese Lücke zu schließen, bevor sie von einem Angreifer ausgenutzt wird.

Möchten Sie wissen, wo Ihre Anlage tatsächlich steht?

Vereinbaren Sie ein kostenloses Erstgespräch mit unseren OT-Sicherheitsexperten und erhalten Sie ein klares Bild Ihres Target- versus Achieved-Sicherheitsniveaus nach IEC 62443, untermauert durch eine praxisnahe, prioritätenbasierte Roadmap.

Buchen Sie jetzt ein kostenloses Erstgespräch mit unseren Experten

Zusätzliche Ressourcen  

Ein detaillierter Bericht zum Stryker-Cybervorfall zum Download finden Sie hier.  
Eine Checkliste zur Bewertung und Auswahl von Lösungen zur Überprüfung von Wechselmedien (Schadsoftware-Scanner) finden Sie hier.  
Eine auf der IEC 62443 basierende OT/ICS-Risikoanalyse-Checkliste für die Lebensmittel- und Getränkeindustrie finden Sie hier.