Definition
Standard zur Cybersicherheit in der Luftfahrt. Verlangt einen strukturierten Security-Prozess parallel zum klassischen Safety-Prozess — Threat Modeling, Schwachstellenbewertung, Security Risk Assessment und Maßnahmen-Verifikation über den gesamten Lebenszyklus des Flugzeugs. Mit ED-202A das europäische Pendant. Von EASA und FAA als anerkanntes Mittel (Acceptable Means of Compliance, bei der EASA über AMC 20-42) für die Security-Bewertung neuer Produkte, STCs und wesentlicher Änderungen referenziert.
In der Praxis
DO-326A stellt Bestandsorganisationen vor ein Strukturproblem: Security und Safety leben in den meisten Häusern in getrennten Silos — die Safety-Ingenieure denken in Ausfallwahrscheinlichkeiten, die IT-Security-Leute in Angriffsvektoren, und beide reden selten miteinander. Der Standard verlangt genau diese Verzahnung, weil in einer vernetzten Luftfahrt ein Security-Ereignis zum Safety-Problem werden kann: Ein kompromittiertes Wartungsdaten-Interface ist kein IT-Incident, sondern ein Lufttüchtigkeitsrisiko. Zweiter Praxispunkt: Weil die Behörden den Security-Prozess für neue Zulassungsvorhaben inzwischen erwarten — bei der EASA über AMC 20-42, das ED-202A beziehungsweise DO-326A referenziert —, stehen viele Unternehmen vor dem Aufbau eines Prozesses, den es im Haus nie gab. Da hilft kein Kopieren aus der ISO-27001-Welt allein: Der lufttüchtigkeitsbezogene Security-Prozess hat eigene Artefakte, von der Bedrohungsanalyse über den Lebenszyklus bis zur Verknüpfung mit der Safety Assessment. Mein Rat: Starten Sie mit einem Pilotprojekt, bilden Sie Security- und Safety-Personal gemeinsam aus und verankern Sie die Schnittstellen schriftlich — im Audit zählt die gelebte Verzahnung, nicht die Folie.
Verwandte Begriffe
Häufige Fragen zu DO-326A
Wir haben ein ISMS nach ISO 27001 — deckt das DO-326A ab?
Nein, das sind komplementäre, aber verschiedene Schutzobjekte. ISO 27001 zertifiziert Ihr Informationssicherheits-Managementsystem auf Unternehmensebene: Vertraulichkeit, Integrität und Verfügbarkeit Ihrer Informationen und IT-Systeme. DO-326A adressiert dagegen die Airworthiness Security — die Frage, ob ein Cyberangriff auf das Produkt Luftfahrzeug dessen Lufttüchtigkeit beeinträchtigen kann. Der Standard verlangt einen produktbezogenen Security-Prozess über den gesamten Lebenszyklus, der eng mit der Safety Assessment verzahnt ist: Bedrohungsmodellierung, Security-Risikobewertung und Maßnahmenverifikation am konkreten Flugzeugsystem. Ihr ISMS ist dafür eine gute organisatorische Basis — etwa für Schwachstellenmanagement und Incident Response —, ersetzt aber die produktbezogene Security-Entwicklung nicht. Ähnlich verhält es sich mit IEC 62443 und ISO/SAE 21434: verwandte Logik aus OT und Automotive, aber keine luftfahrtrechtliche Anerkennung.
Müssen wir bei neuen Zulassungsprojekten zwingend nach DO-326A arbeiten?
Zwingend im Gesetzessinn ist der Standard nicht — aber die Erwartungslage der Behörden ist eindeutig. Die EASA referenziert über AMC 20-42 die ED-202A beziehungsweise DO-326A als anerkanntes Mittel, die Security-Bewertung für neue Produkte, Supplemental Type Certificates und wesentliche Änderungen durchzuführen. Wie bei allen Acceptable Means of Compliance gilt: Sie dürfen einen alternativen Weg vorschlagen, müssen dann aber dessen Gleichwertigkeit gegenüber der Behörde begründen — ein Aufwand, den praktisch niemand wählt. Für Zulieferer kommt die Anforderung zusätzlich über die Vertragskette: Die Flugzeughersteller fordern den Security-Prozess von ihren Systemlieferanten ein, weil sie die produktbezogene Security-Bewertung an der Spitze nur mit belastbaren Beiträgen der Zulieferkette zusammenbekommen. Rechnen Sie also fest damit, dass neue Programme Security-Artefakte nach diesem Standard einfordern.
Wie bauen wir den Security-Prozess auf, wenn Safety und IT-Security bei uns getrennte Welten sind?
Beginnen Sie mit der organisatorischen Verzahnung, nicht mit Werkzeugen. Definieren Sie eine gemeinsame Schnittstelle zwischen Safety- und Security-Prozess: Die Security-Risikobewertung liefert Bedrohungsszenarien, die in die Safety Assessment einfließen, und umgekehrt zeigt die Safety-Sicht, welche Funktionen schützenswert sind — diese Wechselbeziehung schriftlich zu fixieren, ist der erste Prozessbaustein. Richten Sie eine funktionsübergreifende Arbeitsgruppe ein, in der Safety-Ingenieure, Security-Experten und Systemarchitekten an denselben Analysen arbeiten; Schulungen in beide Richtungen sind dabei kein Luxus, sondern Voraussetzung, weil beide Disziplinen unterschiedliche Denkmodelle haben. Pilotieren Sie den Prozess an einem überschaubaren Produkt oder einer Änderung, bevor Sie ihn hausweit ausrollen. Und dokumentieren Sie die Artefakte — Bedrohungsmodell, Security-Anforderungen, Verifikationsnachweise — so, dass sie in die bestehende Konfigurations- und Nachweisstruktur passen. Was im Zulassungsgespräch nicht nachweisbar ist, existiert nicht.