Das IT-Grundschutz-Profil für kleine und mittlere Flughäfen

Das Profil versteht sich als „Schablone“ und definiert ein „empfohlenes Mindestschutzniveau“ für die Informationssicherheit bei Flughäfen (Kap. 5.2). Anwenderinnen und Anwender sollen die Besonderheiten ihres Flughafens berücksichtigen; das Profil nennt Eigentumsverhältnisse, Schnittstellen zu Auftraggebern, Partnerunternehmen, Aufsichts- und Polizeibehörden sowie die Art des Flugbetriebs, etwa Abflugmasse der Luftfahrzeuge oder Passagier- und Frachtaufkommen (ebd.). Was einen Flughafen „klein“ oder „mittel“ macht, legt es nicht fest.

Die Prozesse gliedert das Profil in fünf Bereiche (Kap. 8.1, Tab. 4 bis 8). Security (P1, 15 Einzelprozesse) umfasst Ausweis- und Schlüsselverwaltung, Zutrittskontrolle, Überwachung sensibler Bereiche, Bordkarten-, Passagier- und Gepäckkontrolle einschließlich der mehrstufigen Reisegepäckkontrollanlage sowie die Frachtannahme. Safety (P2, 11) reicht von der Befeuerung der Flugbetriebsflächen über Vorfeldkontrolle und Gebäudemanagement bis zum Safety Management System und zur Leitstelle für Feuerwehr und Rettungsdienst. Aviation (P3, 23) enthält Passagier-, Gepäck- und Frachtabfertigung, zehn Bodenverkehrsdienste von der Betankung bis zum Push-Back und die Verkehrsleitstelle. Dazu kommen Non-Aviation (P4, 7) mit Parken, Immobilien und Einzelhandel und die Unterstützungsprozesse (P7, 38) von Asset- und Identitätsmanagement bis Verkehrsabrechnung. Die Gliederung lehnt sich an den Anhang der Durchführungsverordnung (EU) 2015/1998 an: P1 entspricht dessen Abschnitt 1 und enthält originäre Flughafenprozesse, P3 dessen Abschnitt 3 und betrifft Prozesse in der originären Verantwortung eines Luftfahrtunternehmens; P2, P4 und P7 sind dort nicht abgebildet (Kap. 8.1). Die Nummern P5 und P6 kommen im Profil nicht vor.

Warum Prozesse der Luftfahrtunternehmen im Profil stehen, erklärt Kapitel 8: An kleinen und mittleren Flughäfen ist der Betreiber häufig selbst mit der Abfertigung beauftragt und führt diese Prozesse als Auftragnehmer aus. Wer das nicht tut, kürzt die Liste; das Profil verlangt ausdrücklich, die Prozesse auf ihre Verwendbarkeit im eigenen Informationsverbund zu prüfen.

Zu den Prozessen kommen 32 Anwendungen, von der Airport Operational Database (A1) als zentraler Flugdatenverwaltung über Ausweis-, Zutrittskontroll- und Videoüberwachungssystem, Gebäudeleittechnik mit Brandmeldeanlage, Common Use Terminal Equipment, Baggage Handling System und Baggage Reconciliation System bis zu Befeuerung, Einsatzleitsystem und Fluglärmüberwachung (Tab. 9). Die IT-Systeme und Netze (Tab. 10) enthalten neben Servern, Netzkomponenten und Clients flughafentypische Einträge wie einen SITATEX-Server für den automatischen Nachrichtenaustausch zwischen Flughäfen und Airlines und einen Bordkartenkontroll-Server. Die 27 Bereiche und Räume (Tab. 11) reichen von Verkehrszentrale und Sicherheitszentrale über Tower, Airport Surveillance Radar und Notstromversorgung der Flugsicherung bis zu Vorfeld, Start- und Landebahn, Hangar, Werkstätten und den Flughafenfahrzeugen mit ihren mobilen Geräten.

Der vereinfachte Netzplan (Kap. 8.4, Abb. 1) zeigt einen fiktiven Flughafen mit internem Netz, DMZ und Internet; alle dargestellten Objekte „sollten mindestens im Netzplan des Anwendenden dieses Profils vorhanden sein“. Über das Internet angebunden sind dort Fernwartung, Flugsicherung, Luftfahrtunternehmen, Luftsicherheitsbehörde, Bodenabfertigung, Beteiligte an der sicheren Lieferkette, entfernte Arbeitsplätze und das Leitungsorgan des Flughafens.

Nicht berücksichtigt sind (Kap. 7.2): Prozesse von Unternehmen, die am Flughafen Dienstleistungen anbieten, die der Flughafen gewöhnlich nicht selbst wahrnimmt; die Aufgaben der Stellen und Betreiber nach §§ 5, 9 und 9a Luftsicherheitsgesetz, die das Profil nur als Schnittstellen betrachtet, sofern der Flughafen sie nicht als Dienstleister übernimmt; der BOS-Digitalfunk nach TETRA-Standard, der nicht vollständig berücksichtigt wird; und die Daten- und Telefonanschlüsse, solange der Flughafen nicht selbst Netzbetreiber ist. Weicht Ihr Flughafen von der Referenzarchitektur ab, sind zusätzliche oder fehlende Objekte zu dokumentieren und passenden Bausteinen zuzuordnen (Kap. 8.6).

Hoher Schutzbedarf in der Breite: Das Profil begründet, die Schutzziele müssten an Flughäfen „über das übliche Maß hinaus erreicht werden“ (Kap. 6.3). Entsprechend fällt die Schutzbedarfsfeststellung der Prozesse aus (Tab. 13). Nach dem jeweils höchsten Schutzziel gezählt sind von 94 Einzelprozessen 29 sehr hoch, 30 hoch und 35 normal. In der Security sind es 9 von 15 Prozessen mit sehr hohem Schutzbedarf, fast immer wegen der Integrität, etwa weil gefährliche Gegenstände unerkannt in den Sicherheitsbereich gelangen könnten. In der Safety sind es 8 von 11, darunter die Befeuerung bei Integrität und Verfügbarkeit. Betrieb und Wartung der Anwendungs-, Kommunikations-, Informations- und Sicherheitssysteme, Betrieb und Wartung der technischen Anlagen sowie Identity and Access Management stuft das Profil in allen drei Schutzzielen als sehr hoch ein. Die Non-Aviation-Prozesse bleiben durchgehend normal.

Vererbung nur bis zur Anwendung: Das Profil stellt die Vererbung „ausschließlich aus den Prozessen in die Anwendungen“ dar; die Betrachtung für IT-Systeme und andere Objekte überlässt es den Anwendenden, weil sich die IT-Infrastruktur der Flughäfen stark unterscheide (Kap. 9.1). Von 32 Anwendungen sind 17 sehr hoch, 9 hoch und 6 normal (Tab. 14). Die Bürokommunikation (A31) unterstützt laut Tabelle 9 „alle Prozesse“ und ist deshalb in allen drei Schutzzielen sehr hoch. Da Clients, Netzkomponenten, DNS, Firewall und VPN in Tabelle 10 die Bürokommunikation unterstützen, landet bei konsequenter Vererbung der Großteil der Infrastruktur ebenfalls bei sehr hoch; diese Folgerung zieht das Profil nicht selbst.

Bausteinauswahl nach Maximalprinzip: „Es werden alle Bausteine modelliert, die grundsätzlich für kleine und mittlere Flughäfen bedeutend sein könnten“ (Kap. 9.2). Wir haben Tabelle 15 und 16 gegen das Kompendium 2023 abgeglichen: Alle 111 Bausteine sind aufgeführt, 108 als relevant markiert; ausgeschlossen sind nur der Geheimschutz VS-NfD (CON.11.1), die Revision nach dem Leitfaden IS-Revision (DER.3.2) und IBM Z (SYS.1.7). Viele Einträge haben Zusätze wie „wenn vorhanden“. Die eigentliche Auswahl treffen damit Sie, indem Sie streichen, was es bei Ihnen nicht gibt.

Flughafentechnik als Industrielle IT: Anders als manche Profile modelliert dieses die IND-Bausteine. Gebäudeleittechnik, Brandmeldeanlage, Baggage Handling System, Befeuerung, Baggage Reconciliation System, Parkmanagement und Fluglärmüberwachung ordnet es Prozessleit- und Automatisierungstechnik, allgemeinen ICS-Komponenten, Sensoren und Aktoren und der Fernwartung im industriellen Umfeld zu; für das Baggage Handling System kommen speicherprogrammierbare Steuerung, Maschine und Safety Instrumented Systems hinzu (Tab. 16). Die Vorfeldfahrzeuge laufen über den Baustein Allgemeines Fahrzeug (INF.11). Kapitel 9.5 nennt gerade das Baggage Handling System als Beispiel für ein Objekt, das mit den vorhandenen Bausteinen nicht hinreichend abgebildet werden kann, und das Vorwort kündigt flughafenspezifische Bausteine als Ergänzung an. In den von uns ausgewerteten Quellen haben wir solche Bausteine nicht gefunden.

Kein Eingriff auf Anforderungsebene: Kapitel 9 erklärt, ein Profil könne Anforderungen auswählen, konkretisieren und neue hinzufügen. Dieses Profil bleibt auf Bausteinebene; es wählt keine einzelnen Anforderungen aus und nennt keine bestimmten Anforderungen für erhöhten Schutzbedarf, obwohl es deren Umsetzung allgemein empfiehlt (Kap. 6.3). Die Hinweise stehen als kurze Anmerkungen an den Bausteinen, etwa dass das WLAN von den kritischen Systemen zu trennen ist (NET.2.1), dass Dienstleister und Hersteller von Flughafensystemen Fernwartung nutzen (OPS.2.3), dass Flughäfen selbst ausgelagerte Dienstleistungen für andere Unternehmen erbringen (OPS.3.2) oder dass Microsoft Entra mangels eigenem Baustein über Active Directory und Cloud-Nutzung abzubilden sei (APP.2.2). Als Erstes umzusetzen sind nach Kapitel 11 das Sicherheitsmanagement, ORP.1 bis ORP.4, das Datensicherungskonzept (CON.3), Löschen und Vernichten (CON.6) und alle Bausteine aus OPS.1.1.

Für die Leitungsebene empfiehlt das Profil, externe Dienstleister bei einem Outsourcing von IT oder Prozessen zu verpflichten, eine Mindestabsicherung nachzuweisen, zum Beispiel auf Grundlage dieses Profils (Kap. 5.3). Das ist eine der wenigen Stellen, an denen das Profil eine konkrete organisatorische Maßnahme vorschlägt.

Wo das Profil sich selbst widerspricht: Sechzehn Prozesse, darunter die Sicherheitskontrollen, die mehrstufige Reisegepäckkontrollanlage, die Fracht und die Betankung von Luftfahrzeugen, haben in Tabelle 9 keine Fachanwendung; die Prüfliste weiter unten behandelt sie. Der Netzplan zeigt Systeme, die in Tabelle 9 fehlen: ein Identity- und Access-Management-System, Metalldetektor-Schleusen sowie Durchleuchtungs- und Spürsysteme mit dem Vermerk „evtl. in Zuständigkeit der §5 LuftSiG Behörde“, ein Flughafen-Dispositionssystem, das die Förder- und Sortieranlage steuert, und ein Ortungs- und Leitsystem für mobile Objekte. Tabelle 9 verweist beim BCMS (A20) auf „A23 / ISMS“ und beim ISMS (A21) auf „A22 / BCMS“, obwohl A23 das Personalmanagement und A22 das ERP-System ist; gemeint sind nach unserer Lesart A21 und A20. Tabelle 14 begründet die hohe Vertraulichkeit des Zutrittskontrollsystems unter anderem mit P1.1.8, der laut Tabelle 13 normale Vertraulichkeit hat. Kapitel 11 spricht von einem Schutzbedarf „der Kategorie ‚Standard‘“, die es in Tabelle 12 nicht gibt. Und 14 der 27 Bereiche und Räume, darunter Tower, Radar, Sicherheitszentrale, Feuerwehrzentrale, Vorfeld sowie Start- und Landebahn, sind in Tabelle 16 keinem eigenen Baustein zugeordnet; für sie bleibt nur Allgemeines Gebäude (INF.1).

Tabelle 9 ordnet jeder Anwendung die Prozesse zu, die sie unterstützt. Sechzehn der 94 Prozesse kommen dort nur über die Bürokommunikation (A31, „alle Prozesse“) vor, keiner Fachanwendung. Für sie gibt es im Profil keine Kette vom Prozess zur Anwendung und damit auch keine Vererbung des Schutzbedarfs. Dreizehn von ihnen haben bei mindestens einem Schutzziel hohen oder sehr hohen Schutzbedarf.

Gehen Sie die Liste durch und tragen Sie für jeden Prozess ein, welches System ihn bei Ihnen unterstützt und wer es betreibt. Betreiben Sie das System selbst, erfassen Sie es als Asset des Prozesses (in Grundschutz++ nach BSI-Standard 300-1 Anhang 1, meist als Anwendung und IT-System). Liegt es bei einem Luftfahrtunternehmen, einer Behörde oder einem anderen Unternehmen, dokumentieren Sie die Schnittstelle, wie es Kapitel 3.1 von 300-1 für die technische Zuordnung und die Outsourcing-Abgrenzung verlangt. Gibt es den Prozess bei Ihnen nicht, streichen Sie ihn mit Begründung. Für jeden Prozess mit hohem Schutzbedarf ist in Grundschutz++ eine explizite Risikobetrachtung erforderlich (300-1 Kap. 2.11).

Für einen Flughafen ändert der Wechsel nach Grundschutz++ drei Dinge: 59 der 94 Prozesse landen in der Kategorie hoch und brauchen je eine explizite Risikobetrachtung, für Gepäckförderanlage, Befeuerung und Gebäudeleittechnik gibt es in Anhang 1 von 300-1 keine eigene Zielobjektkategorie, und von den 1.759 gültigen Anforderungen der 108 markierten Bausteine haben 496 einen Eintrag im Mapping-Entwurf. Eine Fassung des Flughafenprofils für Grundschutz++ haben wir am 02.11.2026 nicht gefunden.

Erstens der Schutzbedarf. Die drei Stufen des Profils bilden Sie auf die zwei Kategorien von Grundschutz++ ab (300-1 Kap. 2.6): Aus 29 Prozessen mit sehr hohem und 30 mit hohem Schutzbedarf werden 59 Prozesse der Kategorie hoch. Für jeden Geschäftsprozess, der bei mindestens einem Schutzziel hohen Schutzbedarf hat, verlangt 300-1 eine explizite Risikobetrachtung (Kap. 2.11). Das ist der größte Aufwandstreiber beim Übertrag. Prüfen Sie deshalb zuerst, welche Prozesse es bei Ihnen gibt, und folgen Sie der Empfehlung aus 300-1, mit dem wichtigsten Prozess der höchsten Kategorie zu beginnen (Kap. 2.6). Die Begründungen aus Tabelle 13 können Sie für Ihre eigene Einstufung weiterverwenden; die Vererbung auf Anwendungen ersetzen Sie durch die Zuordnung der Assets zu Prozessen (Kap. 3.1, 3.4.2).

Zweitens die Flughafentechnik. Anhang 1 von 300-1 kennt keine eigene Zielobjektkategorie für Steuerungstechnik oder Fahrzeuge. Gepäckförderanlage, Befeuerung und Gebäudeleittechnik fassen Sie als Anwendungen, die nach der Definition auch der „Steuerung, Konfiguration, Überwachung oder Administration von Hardware, technischen Anlagen“ dienen, und als IT-Systeme. Wo das nicht ausreicht, sieht 300-1 eine explizite Risikobetrachtung vor, wenn ein relevantes Asset durch die bestehenden Zielobjektkategorien nicht hinreichend abgedeckt wird (Kap. 2.11), und ergänzende Anforderungen (Kap. 3.4.3). Das ist dieselbe Lücke, die das Profil in Kapitel 9.5 für das Baggage Handling System beschreibt.

Drittens die Bausteine. Weil das Profil 108 von 111 Bausteinen als relevant markiert, zählt eine Gesamtzählung fast das ganze Kompendium; aussagekräftiger sind die Teilmengen, die das Profil selbst hervorhebt: die zuerst umzusetzenden Bausteine aus Kapitel 11 und die sieben IND-Bausteine für die Flughafentechnik. Grundlage ist der Mapping-Entwurf (Status „draft“, Stand 21.07.2026), aufgelöst im Anwenderkatalog Build 2026-10-29. Das Ergebnis ist ein Entwurf und keine amtliche Zuordnung.

Das Profil nennt eine Reihe von Rechtsquellen: die Durchführungsverordnung (EU) 2015/1998 mit Kapitel 1.7 ihres Anhangs, die Verordnung (EG) 300/2008, die Verordnung (EU) 1254/2009, die Verordnung (EU) 139/2014, die Durchführungsverordnung (EU) 2022/1645 (nach Angabe des Profils gültig ab dem 16. Oktober 2025), das Luftsicherheitsgesetz, § 45 LuftVZO, Anlage I des Nationalen Luftsicherheitsprogramms sowie NIS- und NIS2-Richtlinie (Kap. 6.3, 6.6). Diese Vorgaben legen wir nicht aus. Ob und wie sie für Ihren Flughafen gelten, welche Mindestabsicherung sie verlangen und wer nach §§ 5, 9 und 9a Luftsicherheitsgesetz wofür zuständig ist, ergibt sich aus dem jeweiligen Recht und Ihrer Zulassung; das klären Sie mit den zuständigen Stellen.

Die Verweise des Profils auf § 8a und § 8f BSI-Gesetz sowie auf KRITIS- und UBI-Verordnung beziehen sich auf die Rechtslage bei Erscheinen im November 2024 und sind insoweit historisch. Das BSI-Gesetz ist seitdem neu gefasst worden. Ob und mit welchen Pflichten das heutige BSI-Gesetz für Ihren Flughafen gilt, entscheidet diese Seite nicht.

Wer das Flughafenprofil umsetzt, hat damit weder einen Nachweis gegenüber einer Aufsicht noch eine Zertifizierung. Das Profil selbst beschreibt sich als „Empfehlung und Handreichung“ (Vorwort); die tatsächliche Anwendung der empfohlenen Anforderungen hat jeder Flughafen selbst zu überprüfen (Kap. 5.2). Dass das BSI das Profil veröffentlicht und an ihm mitgearbeitet hat, macht es nicht zu einer Vorgabe für Ihren Flughafen.