In Projektgesprächen taucht regelmäßig die gleiche Gleichsetzung auf: Ein Produkt erreiche SIL 2, also brauche es auch SL-C 2, und beides sei ungefähr dasselbe Anspruchsniveau. Die Zahl stimmt, die Logik dahinter nicht. Security Level lassen sich nicht auf Komponentenebene abhaken und anschließend zu einem sicheren Gesamtsystem addieren.
Der Safety Integrity Level (SIL) nach IEC 61508 beschreibt, wie zuverlässig eine Sicherheitsfunktion zufälligen Ausfällen standhält. Er beruht auf Ausfallwahrscheinlichkeiten. Security Level nach IEC 62443 beschreiben, gegen welche Art von Angreifer ein System bestehen soll, also gegen Vorsatz statt gegen Zufall. Aus diesem Unterschied folgt, ob sich Level zusammenrechnen lassen oder nicht.
Der Performance Level (PL) nach ISO 13849-1 und der Automotive Safety Integrity Level (ASIL) nach ISO 26262 sind eigenständige Kenngrößen mit eigenen Berechnungswegen, folgen aber derselben Grundlogik. Was im Folgenden über den SIL gesagt wird, gilt für beide sinngemäß.
Warum lassen sich Safety Integrity Level kombinieren?
IEC 61508 beschreibt eine Sicherheitsfunktion über die Wahrscheinlichkeit eines gefährlichen Ausfalls, ausgedrückt als PFD oder PFH. Diese Werte lassen sich über die Teilsysteme einer Sicherheitskette aufaddieren: Sensor, Logikeinheit und Aktor liefern jeweils ihren Beitrag zum Gesamtwert. Liegt die Summe im Zielband, ist der geforderte SIL erreicht.
ISO 13849-1 rechnet anders, aber nach demselben Prinzip. Der Performance Level ergibt sich aus MTTFd, Diagnosedeckungsgrad, Ausfällen infolge gemeinsamer Ursache und der gewählten Kategorie. ISO 26262 erlaubt mit der ASIL-Dekomposition sogar, eine Anforderung gezielt auf mehrere unabhängige Elemente aufzuteilen. In allen drei Fällen ergibt die Kombination von Teilsystemen mit bekannten Kenngrößen eine berechenbare Aussage über das Ganze.
Deshalb funktioniert im Safety-Umfeld das Safety Element out of Context: Ein Zulieferer entwickelt ein Element ohne konkretes Zielsystem, dokumentiert seine Annahmen und liefert prüfbare Kennwerte mit. Der Integrator rechnet damit weiter. Die Annahmen bleiben überschaubar, weil physikalische Ausfallmechanismen sich nicht an das Einsatzszenario anpassen. Ein Relais altert im Verpackungsautomaten nach den gleichen Gesetzen wie in der Wasseraufbereitung.
Warum funktioniert dieses Prinzip bei Security nicht?
Ein Angreifer wählt Ziel, Werkzeug und Zeitpunkt. Er nutzt die Stelle, an der Annahmen nicht eingehalten wurden. Eine Ausfallrate gibt es dafür nicht.
Nehmen Sie eine Maschinensteuerung, deren Komponenten alle eine Security Level Capability von SL-C 2 mitbringen. Jede beherrscht rollenbasierte Zugriffssteuerung, Passwortrichtlinien und verschlüsselte Kommunikation. Bei der Inbetriebnahme bleibt das Servicekonto auf dem Auslieferungspasswort, weil die Instandhaltung einen gemeinsamen Zugang braucht. Die Komponenten erfüllen ihre Anforderungen weiterhin vollständig, das System ist trotzdem angreifbar.
Eine Fähigkeit muss konfiguriert, betrieben und gepflegt werden, sonst verpufft sie. Zwischen PFH-Wert und Wirkung klafft diese Lücke nicht. Daraus folgt: Ein Security Element out of Context kann es nicht geben. Ohne Zweckbestimmung, Umgebung, Bedrohungslage und Annahmen über den Betreiber ist die Angabe eines Security Levels ohne Aussagekraft.
Was besagt der Security Level nach IEC 62443?
Ein Security Level ist dort kein Skalar, sondern ein Vektor über die sieben Foundational Requirements, von der Identifikations- und Authentifizierungssteuerung bis zur Verfügbarkeit der Ressourcen. Ein Produkt kann bei der Zugriffssteuerung SL 3 erreichen und bei der Verfügbarkeit SL 1. Die Kurzform “das Gerät hat SL 2” verliert diese Information.
Die Norm unterscheidet zudem den Ziel-Level SL-T aus der Risikobewertung der Zone, die Fähigkeit SL-C des Produkts und den im Betrieb erreichten SL-A.
Für Hersteller ist IEC 62443-4-1 die entscheidende Norm. Sie beschreibt den sicheren Entwicklungsprozess und verlangt an dessen Anfang zweierlei: SR-1 fordert einen dokumentierten Product Security Context, also die Festlegung, in welcher Umgebung, für welchen Zweck und unter welchen Annahmen das Produkt eingesetzt wird. SR-2 fordert darauf aufbauend ein Bedrohungsmodell. Erst daraus lässt sich ableiten, welche Anforderungen aus IEC 62443-4-2 relevant sind und welche Security Level Capability ein Produkt beanspruchen kann. Die Reihenfolge ist normativ vorgegeben: Kontext, Bedrohungen, Maßnahmen, Level.
Warum fordert der CRA einen risikobasierten Ansatz?
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verankert dieselbe Logik im Recht. Anhang I Teil I Nummer 1 verlangt, dass Produkte mit digitalen Elementen auf der Grundlage der Risiken ein angemessenes Cybersicherheitsniveau gewährleisten. Die Produktanforderungen in Nummer 2 stehen jeweils unter dem Vorbehalt, dass sie den Risiken angemessen sein müssen. Artikel 13 Absatz 2 und 3 verpflichten Hersteller, eine Cybersicherheitsrisikobewertung durchzuführen und in der technischen Dokumentation nach Anhang VII festzuhalten.
Maßgeblich sind die bestimmungsgemäße und die vernünftigerweise vorhersehbare Verwendung. Ein pauschal gesetztes SL-C 2 beantwortet diese Frage nicht: Bei einem sicherheitskritischen Anlagenteil ist es zu wenig, bei einem isoliert betriebenen Gerät zu viel. Wie sich die Anforderungen des CRA und die Prozesse der IEC 62443 ineinander übersetzen lassen, betrifft diese Schnittstelle.
Was bedeutet das für Hersteller generischer Komponenten?
Am schwierigsten ist die Lage, wenn Produkte in sehr unterschiedlichen Anlagen landen. Ein Embedded Controller mit Webinterface und Feldbus kann in einer Verpackungsmaschine hinter einer Firewall sitzen, in einer dezentralen Pumpstation am Mobilfunknetz hängen oder in einer Prüfanlage mit wechselnden Servicezugängen laufen. Bedrohungslage und sinnvolle Maßnahmen unterscheiden sich erheblich.
Die Antwort darauf ist nicht ein möglichst hoch angesetztes Level, sondern eine überschaubare Zahl typischer Einsatzszenarien: jeweils bewertet und dokumentiert, welche Annahmen über die Umgebung gelten, welche Schutzmaßnahmen das Produkt mitbringt, welche der Integrator oder Betreiber stellen muss und welche Security Level Capability unter welchen Bedingungen gilt. IEC 62443-4-2 sieht ausdrücklich vor, dass Anforderungen auch durch kompensierende Maßnahmen auf Systemebene erfüllt werden können, sofern das dokumentiert ist.
Integratoren und Betreiber brauchen ohnehin diese Dokumentation. Eine Zahl im Datenblatt hilft ihnen bei der eigenen Risikobewertung nach IEC 62443-3-2 nicht weiter, eine belastbare Liste von Annahmen und Restrisiken schon.
Fazit
SIL 2 und SL-C 2 klingen ähnlich und meinen Verschiedenes. Der Safety Integrity Level beschreibt eine berechenbare Eigenschaft, die sich über Teilsysteme zusammenführen lässt, und für Performance Level und ASIL gilt das gleichermaßen. Der Security Level beschreibt eine Fähigkeit, die erst im definierten Kontext und durch korrekten Betrieb zu Sicherheit wird. Security muss deshalb vom Einsatzszenario und vom Betreiber her gedacht werden, nicht vom Bauteil.
Kommentar hinzufügen