Sicherheit oder Sicherheit

Die Entwicklung hochkomplexer Systeme, ob autonomes Fahrzeug oder unbemanntes Landsystem, folgt heute strengsten Normen der funktionalen Sicherheit wie der ISO 26262. Doch eine isolierte Safety-Strategie ist in einer vernetzten Welt hinfällig, sobald eine Cyber-Schwachstelle die Kontrolle über das System ermöglicht. Wenn funktionale Sicherheit (Safety) und Informationssicherheit (Security) nicht als integrierte Einheiten betrachtet werden, kollabiert das Sicherheitsversprechen am ersten digitalen Angriffspunkt. Die Herausforderung besteht darin, historisch gewachsene Silos aufzubrechen und eine harmonisierte Architektur zu schaffen, die sowohl zufällige Hardwarefehler als auch intentionale Angriffe von außen beherrscht.

In dieser Expertenrunde begrüßt Moderator Felix Lerche drei profilierte Köpfe der Branche: Dr. Wolfgang Freese blickt als Functional Safety Advisor auf eine jahrzehntelange Erfahrung im Aufbau globaler Safety-Organisationen zurück und betrachtet Sicherheit als komplexes soziotechnisches System jenseits von Checklisten. Dr. Daniel Opitz, Automotive Functional Safety Experte mit über 20 Jahren Erfahrung in der Elektronikentwicklung, schlägt die Brücke zwischen strikter ISO-Konformität und modernen KI-Ansätzen. Komplettiert wird die Runde durch Dr. Alexander Nyßen, Executive Vice President Digital Engineering bei itemis, der als leidenschaftlicher Verfechter von modellbasiertem Systems Engineering (MBSE) zeigt, wie Werkzeuge und Prozesse verzahnt werden müssen, um systemische Komplexität beherrschbar zu machen.

Zentrale Erkenntnisse zur integrierten Sicherheit

• Silos als Sicherheitsrisiko: Isolierte Abteilungen für Safety und Security gefährden die Konsistenz des Gesamtsystems; Integration ist keine Option, sondern eine Voraussetzung für die Marktfähigkeit.
• Compliance als Ergebnis, nicht als Ziel: Ein Fokus auf reines „Papier-Engineering“ führt zu Dokumentationsschlachten ohne Mehrwert; wer das Produkt primär sicher designt, erreicht die Zertifizierung fast automatisch.
• Security als Enabler für Safety: Während Safety auf zufällige Fehler blickt, adressiert Security den „Forcible Misuse“. Ohne Cyber-Härtung ist ein funktional sicheres System im Feld schutzlos.
• Effizienz durch methodisches Frontloading: Interdisziplinäre Zusammenarbeit am Anfang des V-Modells reduziert teure Fehler in späten Projektphasen und steigert den Product Value.

Silos als systemisches Hindernis für die Produktintegrität

Silos in Entwicklungsprojekten sind kein Zufall, sondern ein gewachsener Systemeffekt. Historisch betrachtet hat die Qualitätssicherung die ältesten Wurzeln, gefolgt von der funktionalen Sicherheit und schließlich der Cybersecurity. Diese zeitversetzte Integration führt dazu, dass neue Anforderungen oft als zusätzliche Belastung statt als integraler Bestandteil der Architektur wahrgenommen werden. In klassischen Matrix-Organisationen fördern Linienstrukturen zudem das Denken in fachspezifischen Grenzen – Mechanik, Elektronik und Software agieren oft isoliert, was die ganzheitliche Sicht auf das System verhindert.

Der menschliche Faktor und Change Management

Die Integration von Safety und Security ist maßgeblich eine Frage der Führung und Unternehmenskultur. Ingenieure müssen befähigt werden, über ihre Kernkompetenz hinaus zu denken. Ein moderner Systemarchitekt trägt die Mitverantwortung für alle drei Säulen: Qualität, funktionale Sicherheit und Cyber-Resilienz. Die Angst vor zusätzlicher Verantwortung und der enorme Projektdruck führen oft dazu, dass sicherheitsrelevante Themen nach hinten geschoben werden. Erfolgreiche Organisationen brechen dies auf, indem sie interdisziplinäre Kommunikation erzwingen und Verantwortung auf mehrere Schultern verteilen.

Safety, Security und SOTIF: Die drei Säulen der Produktintegrität

Das moderne Systemdenken muss heute drei verschiedene Fehlerräume gleichzeitig adressieren: zufällige Fehler (Safety), technische Grenzen der Funktion (SOTIF) und intentionale Angriffe von außen (Security). Eine Parallele zwischen SOTIF und Cybersecurity liegt in der Betrachtung von unerwünschtem Systemverhalten, das nicht auf klassischen Hardware-Defekten basiert. Während SOTIF die Grenzen der Sensorik analysiert, blickt Security auf die bewusste Ausnutzung von Schwachstellen durch externe Akteure.

Cybersecurity als dynamischer Faktor im Lebenszyklus

Es ist eine gefährliche Verkürzung, Security lediglich als Zulieferer für Safety zu betrachten. Cybersecurity schützt Daten und geistiges Eigentum auch dort, wo kein direkter Personenschaden droht. Dennoch müssen sicherheitsrelevante Security-Funktionen konsequent in das Sicherheitskonzept integriert werden. Ein wesentlicher Unterschied bleibt jedoch die Zeitachse: Während funktionale Sicherheit oft mit der Produktfreigabe mental abgeschlossen wird, beginnt der kritische Teil der Cybersecurity durch die sich ständig ändernde Bedrohungslage im Feld erst nach dem Produktionsstart (SOP).

Methoden zur Beherrschung der Komplexität: MBSE und KI-Unterstützung

Ein sauberes Requirements Engineering bildet das Rückgrat jeder Sicherheitsstrategie. Es dient nicht nur der Auditierbarkeit, sondern ist das zentrale Werkzeug für den Know-how-Transfer.

KI als Sparringspartner in der Sicherheitsanalyse

KI-gestützte Ansätze können den Prozess der Sicherheitsanalyse wie FMEA oder FTA erheblich beschleunigen. Anstatt auf der „grünen Wiese“ zu starten, dient die KI als Katalysator, um initiale Fehlermöglichkeiten und Szenarien zu generieren. Dies ersetzt nicht die menschliche Expertise, sondern befähigt das Team, sich schneller auf die kritischen, architekturspezifischen Herausforderungen zu konzentrieren und wertfreie Impulse in festgefahrene Diskussionen einzubringen.

Modellbasierte Architekturen statt statischer Dokumentation

Die Komplexität moderner Systeme lässt sich nicht mehr mit Visio-Bildchen oder PowerPoint-Folien beherrschen. Nur durch die Verzahnung von Architekturmodellen mit Sicherheitsanalysen entsteht eine „Single Source of Truth“. Wenn Ergebnisse einer Fehlerbaumanalyse (FTA) direkt als Change Requests in die Architektur zurückfließen, entsteht ein geschlossener Regelkreis. Diese methodische Strenge sorgt dafür, dass Compliance am Ende der Entwicklung kein schmerzhafter Checklisten-Marathon ist, sondern das logische Resultat eines sauberen Engineering-Prozesses.