Ohne Cybersecurity keine Safety: Warum autonome Systeme ein neues Sicherheitsdenken brauchen

Autonome Systeme sind eine Schlüsseltechnologie für die zukunftsorientierte Mobilität und Industrie. Doch ihre größte Stärke, die intelligente Vernetzung, ist gleichzeitig ihre größte Schwachstelle. In einer Welt, in der Software über die physische Sicherheit entscheidet, müssen Security und Safety von Anfang an gemeinsam gedacht und integriert ineinandergreifen. In diesem Blogbeitrag beleuchten wir, warum die klassische Trennung zwischen funktionaler Sicherheit und IT-Sicherheit in der Softwareentwicklung heute ein kritisches Risiko darstellt. Erfahren Sie, warum moderne Standards wie die VDE AR 28461 auf eine ganzheitliche Vertrauenswürdigkeit setzen und wie ein modellbasiertes Safety und Security Co-Engineering dabei hilft, komplexe Anforderungen effizient und rechtssicher zu meistern. Wir zeigen Ihnen, wie Sie die Lücke zwischen regulatorischen Anforderungen und technischer Umsetzung schließen, um Ihre Systeme robust für die Zukunft aufzustellen.

Stellen Sie sich ein autonomes Shuttle vor, das Fahrgäste sicher durch die Innenstadt befördert. Die Sensoren arbeiten perfekt, die Algorithmen erkennen jedes Hindernis. Die Safety (funktionale Sicherheit) ist dabei nach allen Regeln der Technik zertifiziert. Doch was passiert, wenn sich ein Angreifer über eine Wartungsschnittstelle Zugriff auf das Lenksystem verschafft? In diesem Moment wird aus einem Cybersecurity-Problem unmittelbar eine tödliche Gefahr für Leib und Leben.

Lange Zeit konnten Ingenieure Safety und Security als getrennte Disziplinen behandeln. Es gab jeweils Expertise für funktionale Sicherheit (Safety) und für Cybersecurity. Doch mit der wachsenden Vernetzung autonomer Systeme verschwimmen diese Grenzen.

Warum die Trennung von Safety & Security heute nicht mehr funktioniert

Viele Unternehmen halten in ihren Entwicklungsprozessen noch immer an einer strikten Trennung von Safety und Security fest. Oft sind die Gründe dafür historisch oder organisatorisch bedingt, doch in der Praxis greifen diese herkömmlichen Modelle längst zu kurz. Auf der KI-Standardisierungskonferenz der Bundesnetzagentur (Dezember 2025) wurde deutlich, dass nach wie vor große Unsicherheit herrscht: Wie kann eine echte methodische Integration von Safety und Security gelingen? Ein Blick in die Wissenschaft zeigt, warum die alten Leitplanken nicht mehr halten.

Schutzziele sind nicht mehr trennscharf

Im wissenschaftlichen Modell wie der Taxonomie von Laprie [1][2] werden Safety und Security klar unterschiedlich definiert. Safety wird wie Vertraulichkeit, Integrität und Verfügbarkeit als unterschiedliches Attribut der Verlässlichkeit gesehen und Security als die Kombination aus Vertraulichkeit, Integrität und Verfügbarkeit. In der Praxis moderner, vernetzter Systeme verschwimmt diese Trennung jedoch. Im Security-Engineering betrachten wir heute alle Konsequenzen eines Angriffs – inklusive Personenschäden.

Beispiel: Wenn etwa ein Hacker das Bremssystem eines Lkw manipuliert, ist das Ziel des Angriffs zwar technischer Natur, die Konsequenz ist jedoch ein klassisches Safety-Ereignis (Personenschaden). Eine Trennung allein über das Schutzziel funktioniert in der Praxis also nicht mehr.

Ursachen von Sicherheitsproblemen verschmelzen

Laprie unterscheidet außerdem zwischen »böswilligen Fehlern« (malicious faults = absichtliche Manipulationen) und »nicht-böswilligen Fehlern«. In der herkömmlichen Softwareentwicklung wurde »Security für Safety« daher oft darauf reduziert, böswillige Angriffe wie Hackerattacken als Ursache von Safety-Problemen auszuschließen. Diese isolierte Betrachtung greift zu kurz. Modernes Security Engineering berücksichtigt längst auch nicht-böswillige Ursachen, wie Naturkatastrophen, die physische Auswirkungen auf Rechenzentren oder Kommunikationsinfrastruktur haben können.

Beispiel: Bei einer Adversarial Attack verschmelzen die Ursachen endgültig. Manipuliert ein Angreifer ein Stoppschild durch minimale, für Menschen kaum sichtbare Sticker so, dass die KI es als Geschwindigkeitsbegrenzung missinterpretiert, ist die Ursache böswillig (Security). Die Auswirkung, etwa dass das Fahrzeug nicht bremst, ist jedoch ein klassisches Safety-Versagen.

Systemgrenzen lösen sich auf

Ebenso unterscheidet die Taxonomie von Laprie zwischen internen und externen Fehlern. Bei Security denken viele zunächst an »externe Fehler« und daran, dass die Umgebung keine negativen Auswirkungen auf das System haben soll. Bei Safety liegt der Fokus traditionell darauf, dass das System keine Personenschäden verursacht. »Security für Safety« wird daher häufig so interpretiert, dass kein schädlicher Einfluss der Umgebung auf das System zu einem Safety-Problem führen darf. In der Praxis vernetzter, autonomer Systeme ist diese Trennung jedoch nicht mehr eindeutig. Safety Engineering betrachtet durchaus externe Fehler.

Beispiel: Vernetzte autonome Systeme operieren heute in einem »System-of-Systems«. Sie beziehen permanent Informationen von außen, etwa über Cloud-Dienste oder Infrastrukturdaten. Dadurch verschwimmen die Systemgrenzen physisch und digital. Ein autonomes Fahrzeug muss Fußgänger auch bei schwierigen Sichtverhältnissen oder ungewöhnlicher Kleidung verlässlich erkennen, um sicher agieren zu können. Wenn ein Fußgänger aufgrund besonderer Kleidung nicht erkannt wird, handelt es sich um eine klassische Fragestellung des Safety Engineerings. Das Beispiel zeigt: Die Umgebung ist sowohl für die Safety als auch für die Security entscheidend. Eine isolierte Betrachtung von Fehlerquellen entlang starrer Systemgrenzen ist in modernen, KI-basierten Systemen kaum noch möglich.

Die Lücke im herkömmlichen Engineering

Die logische Konsequenz: Vertrauenswürdigkeit als ganzheitliches Ziel

Neben Normen und technischen Standards rücken zunehmend auch gesetzliche Regelungen und Haftungsfragen in den Fokus. Europäische Initiativen wie der AI Act oder der Cyber Resilience Act verschärfen die Anforderungen an Hersteller und Betreiber. Sie müssen nicht nur nachweisen, dass ihre Produkte sicher entwickelt wurden, sondern auch, dass Risiken über den gesamten Lebenszyklus hinweg angemessen beherrscht und dokumentiert werden.

Integrative Perspektive auf Verlässlichkeit und Vertrauenswürdigkeit

Die bisherigen Ausführungen machen deutlich, dass Safety und Security nicht isoliert betrachtet werden können. Maßnahmen zur Erhöhung der Safety haben jedoch Auswirkungen auf andere Qualitätsattribute. Eine Notabschaltung erhöht zum Beispiel die Sicherheit von Personen, wirkt sich aber negativ auf die Verfügbarkeit des Systems aus.

In der Bahntechnik wird dieser Zusammenhang bereits seit Längerem berücksichtigt.
Der Standard EN 50126 betrachtet die vier RAMS-Eigenschaften gemeinsam:

• Reliability (Zuverlässigkeit)
• Availability (Verfügbarkeit)
• Maintainability (Instandhaltbarkeit)
• Safety (Sicherheit)

Für autonome und kognitive Systeme reicht dieser Rahmen nicht mehr aus. Die Anwendungsregel VDE AR 28461 erweitert den RAMS-Scope der EN 50126 um zusätzliche Qualitätsattribute wie Privatsphäre. Gleichzeitig berücksichtigt sie verschiedene Fehlertypen als Ursachen und nimmt damit eine integrative Perspektive ein, in der Safety und Security nicht mehr getrennt behandelt werden. In der VDE AR 28461 wird somit nicht nur die Verlässlichkeit eines Systems betrachtet, sondern seine Vertrauenswürdigkeit insgesamt. Dies umfasst technische, organisatorische und normative Aspekte und bietet einen holistischen Bezugsrahmen für moderne autonome Systeme.

Folgende Abbildung skizziert diese holistische Perspektive auf Vertrauenswürdigkeit:

In der Entwicklung dieser integrativen Sichtweise spielt die angewandte Forschung eine wichtige Rolle. Das Fraunhofer IESE bringt seine Erfahrungen aus Industrieprojekten in die Normungsarbeit ein und unterstützt so die Ausgestaltung von Regeln wie der VDE AR 28461. Auf diese Weise fließen praktische Erkenntnisse aus konkreten Safety- und Security- Anwendungen direkt in die Definition von Vertrauenswürdigkeit autonomer Systeme ein.

Der Normen-Dschungel: Safety- und Security-Standards im Überblick

Im Bereich Automotive liefert die ISO 26262 die Grundlage für funktionale Sicherheit und die ISO/SAE 21434 die Grundlage für den Schutz vor Cyberangriffen. ISO/TS 5083 adressiert Safety beim automatisierten Fahren und berücksichtigt Security Aspekte in diesem Kontext.

Bei Agrarmaschinen kommen hauptsächlich die ISO 25119 für die funktionale Sicherheit und die ISO 24882 für den Schutz vor Cyberangriffen zum Einsatz.

In der Industrieautomatisierung bilden die IEC 61508 und die ISO 13849 die Grundlage für funktionale Sicherheit und die IEC 62443 die Grundlage für Cybersecurity.

Es gibt viele weitere Anwendungsbereiche mit spezifischen Normen für Safety und Security. Viele der anwendungsspezifischen Normen für funktionale Sicherheit sind von der IEC 61508 abgeleitet. Entsprechend kommt dieser Norm eine besondere Bedeutung zu. Die IEC 62443 hat ebenfalls einen recht breiten Anwendungsbereich, da sie alle Industriebereiche und die kritischen Infrastrukturen (KRITIS) abdeckt.

Um diese beiden Welten zusammenzuführen, arbeitet der gemeinsame Arbeitskreis DKE/GAK 931.1.3 »Funktionale und IT-Sicherheit« an der Schnittstelle zwischen IEC 61508 und IEC 62443. Er analysiert Unterschiede und Gemeinsamkeiten, insbesondere im Lebenszyklus, und benennt Defizite der IEC 62443 aus Sicht der funktionalen Sicherheit. Diese Erkenntnisse fließen wiederum in die Weiterentwicklung der Normen ein.

Die Lösung: Modellbasiertes Safety und Security Co-Engineering

Eine effektive Lösung, um Safety und Security in der Praxis zu integrieren, bietet das modellbasierte Safety und Security Co-Engineering. Im Systems- und Software-Engineering werden verschiedene Aspekte der Produktentwicklung über das gemeinsame Arbeiten an einem Modell integriert. Dabei wird den verschiedenen Stakeholdern eine passende Sicht auf das Modell geboten. Die Safety- und die Security-Sicht werden aber bei herkömmlichen Werkzeugen nicht angeboten. Das Modellierungswerkzeug Enterprise Architect bietet dem Safety-Ingenieur beispielsweise keine Sicht, um eine Fehlerpropagation durch das System zu modellieren.

Grundidee des modellbasierten Safety und Security Co-Engineering

• Das modellbasierte Safety und Security Co-Engineering erweitert die bestehende modellbasierte Produktentwicklung gezielt um Safety- und Security-Sichten.
• Safety-Ingenieure sehen in ihrer Sicht relevante Produktentwicklungsaspekte sowie relevante Security-Aspekte.
• Security-Ingenieure sehen in ihrer Sicht relevante Produktentwicklungsaspekte sowie relevante Safety-Aspekte.
• Das gemeinsame zugrunde liegende Modell integriert alle Aspekte auf konsistente Art und Weise.
• Inkonsistenzen werden konstruktiv vermieden oder automatisch identifiziert und mithilfe der Ingenieure aufgelöst.
• Die modellbasierte Formalisierung von Safety- und Security-Aspekten ermöglicht neben automatischen Konsistenzprüfungen auch viel Automatisierungsunterstützung bei der Durchführung von Safety- und Security-Analysen.

Ein integriertes, modellbasiertes Vorgehen schafft außerdem die Grundlage, Sicherheitsanforderungen nicht nur in der Entwicklung, sondern auch in Betrieb und Wartung systematisch zu berücksichtigen. Dies betrifft zum Beispiel die Planung von Monitoring- und Update-Prozessen sowie den Umgang mit Sicherheitsvorfällen im Feldbetrieb.

Das Werkzeug SafeTbox des Fraunhofer IESE bietet für die oben genannten Punkte eine Reihe von praxisbewährten Automatisierungslösungen. Aktuell forscht das Fraunhofer IESE daran, das Automatisierungspotenzial durch generative KI weiter zu steigern und trägt zu relevanten Normen in diesem Bereich bei.

Referenzen

[1] A. Avizienis, J.-C. Laprie, B. Randell and C. Landwehr, „Basic concepts and taxonomy of dependable and secure computing,“ in IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp. 11-33, Jan.-March 2004, doi: 10.1109/TDSC.2004.2.

[2] Wikipedia: Dependability