Funktionale Sicherheit vs. IT-Sicherheit

Technische Vertiefung

Sicherheitsfunktion und erwartete Reaktion

Eine technische Einordnung von „Funktionale Sicherheit vs. IT-Sicherheit“ beginnt mit dem vorgesehenen Zweck und dem überprüfbaren Ergebnis. Safety schützt Menschen und Umwelt vor gefährlichem Anlagenverhalten. Gleichzeitig gilt: Ein Security-Vorfall kann eine Safety-Funktion beeinflussen. Erst wenn diese Aussagen zusammenpassen, lässt sich beurteilen, ob die vorgesehene sichere Reaktion vollständig, prüfbar und nachvollziehbar umgesetzt ist.

Teilfunktionen, Zustände und Grenzen

Eine sichere Steuerung kann korrekt auf einen echten Sensorfehler reagieren. Wird jedoch ihre Konfiguration unbefugt verändert, entsteht ein Security-Problem mit möglicher Safety-Auswirkung. Das Beispiel zeigt, dass Gefährdung, Erkennung, Sicherheitslogik, Reaktion und Nachweis als vollständige Funktion betrachtet werden müssen. Security schützt Systeme und Informationen vor unbefugter oder schädlicher Einwirkung. Außerdem ist zu beachten: Beide Disziplinen benötigen abgestimmte, aber unterschiedliche Nachweise. Safety-Themen beginnen bei einer Gefährdung und einer definierten sicheren Reaktion, nicht bei einem einzelnen Bauteil. Sensorik, Logik, Aktorik, Diagnose, Testabstände und organisatorische Maßnahmen müssen als zusammenhängende Sicherheitsfunktion betrachtet werden.

Prüfung, Nachweis und Änderungsdisziplin

Fehlersuche darf eine Schutzfunktion nicht umgehen oder unbemerkt schwächen. Prüfungen, Änderungen und Wiederanlauf benötigen dokumentierte Zuständigkeiten, geeignete Testverfahren und die jeweils geltenden normativen Nachweise. Typische Fehlansätze bei diesem Thema sind: Safety-Zertifizierung als Schutz vor Cyberangriffen interpretieren; Security-Patches ohne Safety- und Verfügbarkeitsbewertung einspielen; Verantwortung vollständig an nur eine Disziplin übertragen. Diese Punkte sollten nicht nur als Checkliste abgearbeitet, sondern mit Risikobeurteilung, Prüfprotokollen, Versionsständen, Rücksetzbedingungen, Änderungsnachweisen und freigegebenen Verantwortlichkeiten belegt werden. Nützliche Leitfragen sind „Welche unerwünschte physische Wirkung ist möglich?“ „Welche Manipulation oder Fehlkonfiguration könnte sie auslösen?“ „Wie werden Änderungen autorisiert, getestet und nachgewiesen?“ Die Antworten bilden eine bessere Grundlage für Übergabe, Lernen, Wartung oder spätere Entscheidungen als eine bloße Aussage, beim ersten Versuch habe alles funktioniert.