UAE Information Assurance Regulation 1.1 und Dubai ISR: wer umsetzen muss, wie Anwendbarkeit und Prioritäten wirken, und was offen bleibt

Problem in der Praxis

Der erste Fehler ist ein Analogieschluss aus Europa. Wer NIS-2 kennt, sucht nach Sektorlisten und Schwellenwerten im Dokument selbst. Die IA Regulation verweist für Sektoren und für das Verfahren zur Identifizierung kritischer Stellen auf die UAE CIIP Policy, die nicht als Snapshot vorliegt. Ob eine Stelle verpflichtet ist, folgt bei kritischen Stellen aus einer Bestimmung durch die TRA, nicht aus einer Selbsteinschätzung anhand von Kennzahlen.

Der zweite Fehler ist, "risikobasiert" als "frei wählbar" zu lesen. Die Regulation lässt Ausschlüsse nur auf Grundlage einer Risikobewertung zu und verlangt dafür eine Begründung gegenüber der TRA; die Always-Applicable-Controls und alle ihre Subcontrols sind nie ausschließbar, und wer keine Risikobewertung hat, muss alle Controls umsetzen.

Der dritte Fehler betrifft den Stand. Teams übernehmen aus Sekundärquellen Versionsangaben oder Nachfolgedokumente, die sich an den vorliegenden Quellen nicht prüfen lassen. Die Version 1.1 trägt selbst keine Aussage über einen Nachfolger, beruft sich in ihren Grundlagen auf Normausgaben wie ISO/IEC 27001:2005 und kündigt sektorspezifische Anhänge an, die im vorliegenden Dokument fehlen. Wer mit ihr arbeitet, sollte den aktuellen Stand bei der zuständigen Stelle erfragen, statt eine Versionsnummer anzunehmen.

CISO-Einordnung

Herausgeberin, Stand und Einbettung. Das Dokument trägt den Titel UAE Information Assurance Regulation, Version 1.1, März 2020, und nennt als zuständige Behörde durchgehend die TRA. Bezogen wurde es von der Website der TDRA; das amtliche Portal u.ae führt die Behörde als Telecommunications and Digital Government Regulatory Authority (TDRA). Einen Rechtsakt zum Übergang von Zuständigkeiten enthalten die Snapshots nicht. Die Regulation versteht sich als Bestandteil des National Information Assurance Framework (NIAF) und als wesentliches Element der National Cyber Security Strategy (NCSS); sie stützt sich auf die UAE CIIP Policy, das National Cyber Risk Management Framework und die National Cyber Information Sharing Policy. Keines dieser Dokumente liegt als Snapshot vor. Die Begriffsbestimmungen nennen zusätzlich eine Stelle mit der Abkürzung NCSA, die das Dokument nicht ausschreibt. Eine Aussage über eine Nachfolgefassung enthält die Version 1.1 nicht; der Abu Dhabi Healthcare Information and Cyber Security Standard von 2024 führt die Regulation mit der Jahreszahl 2020 unter seinen Referenzdokumenten und ordnet seine Controls ihr zu (siehe vae-004).

Adressaten und wie sie bestimmt werden. Die Einleitung verpflichtet alle staatlichen Stellen der VAE und weitere Stellen, die die TRA als kritisch identifiziert. Der Abschnitt zum Geltungsbereich regelt, wie die zusätzlichen kritischen Stellen bestimmt werden: Die TRA bestimmt sie nach der UAE CIIP Policy. Die Pflicht der staatlichen Stellen aus der Einleitung macht er nicht von einer solchen Bestimmung abhängig. Die Liste der Sektoren und das Identifizierungsverfahren legt nach der Regulation die CIIP Policy fest. Eine kritische Stelle ist nach den Begriffsbestimmungen eine Stelle, die für Investitionen in eine bestimmte kritische Informationsinfrastruktur oder deren täglichen Betrieb verantwortlich ist. Erfasst sind Informationen und Daten in physischer oder elektronischer Form und die Systeme und Prozesse für ihre Nutzung, Verarbeitung, Speicherung und Übermittlung, gleich ob sie der Stelle gehören, geleast sind oder sich sonst in ihrem Besitz, Gewahrsam oder ihrer Kontrolle befinden. Allen übrigen Stellen in den VAE empfiehlt die TRA nachdrücklich die freiwillige Übernahme, soweit anwendbar. Als "implementing entity" bezeichnet die Regulation jede Stelle, die sie umsetzt, verpflichtet oder freiwillig.

Verbindlichkeit. Die Regulation bezeichnet sich als nationale Regelung, deren Einhaltung umsetzende Stellen nachweisen müssen, und als alleinigen Bezugspunkt für die Compliance mit ihren Anforderungen, gemessen an den Kriterien der einzelnen Controls. Sie soll bestehende Programme der Stellen ergänzen. Verbindlich sind die Controls und Subcontrols; Umsetzungshinweise, Automatisierungshinweise und Bedrohungsbeschreibungen dienen nach eigener Aussage nur der Information. Leistungskennzahlen sind für den Compliance-Nachweis zu verwenden; eine Stelle darf von den vorgeschlagenen Kennzahlen abweichen, muss dann aber den Grund angeben und eigene Kennzahlen festlegen.

Aufbau auf Familienebene. Die Controls sind in sechs Management-Familien und neun technische Familien gegliedert. Die Management-Familien sind Strategy and Planning, Information Security Risk Management, Awareness and Training, Human Resources Security, Compliance sowie Performance Evaluation and Improvement. Die technischen Familien sind Asset Management, Physical and Environmental Security, Operations Management, Communications, Access Control, Third-Party Security, Information Systems Acquisition, Development and Maintenance, Information Security Incident Management sowie Information Systems Continuity Management. Unter jeder Familie stehen Unterfamilien und Controls, jeweils mit Ziel, Leistungskennzahl, Priorität, Anwendbarkeit, Control-Aussage, Subcontrols und Umsetzungshinweisen. Anhänge fassen die Always-Applicable-Controls, die Prioritäten, eine Zuordnung zu anderen Standards, eine Zuordnung zu Bedrohungen und 15 Controls mit Sektor- und nationalem Bezug zusammen. Die angekündigten sektorspezifischen Anhänge für die kritischen Sektoren der CIIP Policy enthält das vorliegende Dokument nicht; die Sektorregulatoren sollen die Regulation nach ihrer Rollenbeschreibung um sektorspezifische Anforderungen ergänzen.

Anwendbarkeit. Vor der Risikobewertung gelten alle Controls als anwendbar. Eine Stelle darf einzelne Controls auf Grundlage des Ergebnisses ihrer Risikobewertung ausschließen, wenn sie der TRA eine angemessene Begründung vorlegt; im Compliance-Kapitel verlangt die Regulation für jeden Ausschluss zusätzlich Nachweise, dass verantwortliche Personen oder autorisierende Stellen die Risiken akzeptiert haben. Always-Applicable-Controls sind von jeder betroffenen Stelle unabhängig vom Ergebnis der Risikobewertung umzusetzen, einschließlich aller ihrer Subcontrols; ihr Fehlen ist eine Nichtkonformität. Nach Anhang A sind das 34 Management-Controls. Bei Controls, die aufgrund der Risikobewertung anwendbar sind, darf die Stelle begründet einzelne Subcontrols weglassen oder anders umsetzen, wieder mit Nachweis der Risikoakzeptanz. Fehlt eine Risikobewertung, gelten alle Controls als anwendbar und verpflichtend.

Prioritäten und Umsetzungsstufen. Die Controls sind vier Prioritätsstufen zugeordnet, P1 bis P4 in absteigender Wichtigkeit; nach Anhang B entfallen 39 Controls auf P1, 69 auf P2, 35 auf P3 und 45 auf P4. Für verpflichtete kritische Stellen sind alle anwendbaren Controls aller vier Stufen verpflichtend; sie beginnen die Umsetzung mit P1. Sie dürfen die vorgeschlagene Priorität auf Grundlage ihrer Risikobewertung anheben oder absenken, mit Ausnahme der P1-Controls, die, soweit anwendbar, ergänzt, aber nie herabgestuft werden dürfen. Eine Frist für die Umsetzung einer Stufe nennt die Regulation nicht.

Compliance und Berichtswege. Die Stellen melden ihren Sektorregulatoren den Stand der Umsetzung, Ergebnisse der Risikobewertung sowie Informationen zu Cyberbedrohungen, Risiken und Vorfällen. Die Sektorregulatoren verdichten diese Informationen zu einer Sektorsicht und berichten an die TRA; die TRA bildet daraus eine nationale Sicht und gibt Risiko- und Umsetzungserkenntnisse an die Sektorregulatoren zurück, diese an die Stellen. Nach der Rollenbeschreibung aktualisiert jede umsetzende Stelle regelmäßig den zuständigen Regulator, oder die TRA, wo es keinen Sektorregulator gibt, über ihren Umsetzungsfortschritt und unterstützt Audits und Tests, wenn die TRA sie verlangt. Die TRA prüft die über die Sektorregulatoren eingehenden Selbstbewertungsberichte, kann Compliance-Audits und Tests selbst durchführen oder beauftragen, wo sie es für angemessen hält, und kann weiter eskalieren. Das Compliance-Überwachungsschema ist nach der Regulation in der NIAF Governance beschrieben, die nicht vorliegt. Sanktionen nennt die Regulation nicht; das Fehlen von Always-Applicable-Controls oder ihrer Subcontrols bezeichnet sie als Nichtkonformität.

Vorfälle. Die Familie Information Security Incident Management verlangt unter anderem eine Vorfallrichtlinie, ein Computer Security Incident Response Team, eine Vorfallklassifizierung, ein Meldeverfahren für Sicherheitsereignisse über geeignete Kanäle einschließlich der zuständigen Behörde und unter Berücksichtigung der Sektor- und nationalen Kanäle sowie die Teilnahme an Informationsaustausch-Gemeinschaften. Mehrere dieser Controls zählt Anhang E zu den Controls mit Sektor- und nationalem Bezug. Eine Meldefrist gegenüber einer Behörde nennt die Regulation nicht; ihre Leistungskennzahl für Meldungen knüpft an die Fristen an, die die Stelle in ihrer eigenen Vorfallrichtlinie je Kategorie festlegt.

Dritte, Cloud und Lieferkette. Die Familie Third-Party Security verlangt von der umsetzenden Stelle eine Drittparteienrichtlinie, die dem Dritten mitgeteilt und von ihm förmlich bestätigt wird, messbare Sicherheitsanforderungen in den Leistungsverträgen, Berichte der Dritten über deren Erfüllung, die Überwachung und regelmäßige Prüfung der Leistungen und ein Verfahren für Änderungen. Die Unterfamilie Cloud Computing verlangt eine Sorgfaltsprüfung der Anforderungen an Verarbeitung, Speicherung und Aufbewahrung in der Cloud, die Einbeziehung der Cloud-Umgebung in die Risikobewertung, die Unterrichtung über Sicherheitsvorfälle beim Cloud-Anbieter und, wo möglich, ein Prüfrecht. Leistungsverträge mit Cloud-Anbietern sollen regeln, dass die Stelle weiß, wo Informationen mit Beschränkungen gespeichert oder übertragen werden, und wie Daten am Vertragsende migriert werden. Eine eigene Pflicht zur Speicherung in den VAE enthalten diese Controls nicht; die nur informativen Umsetzungshinweise nennen Gesetze, die die Speicherung bestimmter Informationen außerhalb der Landesgrenzen verbieten, als zu prüfende Anforderung. Die Unterfamilie Supply Chain Management verlangt eine Strategie gegen Lieferkettenrisiken, die Pflicht des Lieferanten zur Einhaltung der Sicherheitsrichtlinie der Stelle im Vertrag, die Möglichkeit, die Sicherheitspraktiken des Lieferanten zu prüfen, und eine Lieferantenbewertung vor Vertragsschluss. Diese Controls sind nach ihrer Kennzeichnung auf Grundlage der Risikobewertung anwendbar und überwiegend den Stufen P2 und P4 zugeordnet. Alle diese Anforderungen richten sich an die umsetzende Stelle; Lieferanten erreichen sie über Verträge und Prüfungen.

Dubai ISR: ausgewiesene Lücke. Das Dubai Electronic Security Center (DESC) führt auf seiner Website die Information Security Regulation (ISR) in einer Reihe von Dokumenten, zu denen auch Standards für elektronische Biomedizingeräte, industrielle Steuerungssysteme, das Internet der Dinge und Cloud-Anbieter gehören, und stellt sie auf Anfrage über einen E-Mail-Kontaktlink bereit. Nach der Website richten sich viele der von DESC veröffentlichten Standards und Zertifizierungen an staatliche Stellen und an private Unternehmen, abhängig von deren Größe und Infrastruktur; die Rubrik Standards und Richtlinien beschreibt DESC als Leitfaden für staatliche Stellen zum Schutz des Cyberraums Dubais. Der Text der ISR liegt nicht vor. Adressaten, Verbindlichkeit, Version, Aufbau und Verhältnis zur IA Regulation sind deshalb offen, und dieser Artikel trifft dazu keine Aussage.

Umsetzungsperspektive

1. Pflicht je Rechtseinheit klären. Ist die Einheit eine staatliche Stelle der VAE, oder hat die TRA sie als kritische Stelle bestimmt? Ohne eine solche Grundlage ist die Regulation eine Empfehlung.
2. Kundenseite erheben. Welche Kunden sind staatliche Stellen oder bestimmte kritische Stellen? Deren Drittparteien-, Cloud- und Lieferkettenanforderungen kommen über Verträge, Berichtspflichten und Prüfrechte.
3. Risikobewertung als Pflichtdokument behandeln. Bei verpflichteten Einheiten entscheidet sie über Ausschlüsse und Prioritäten; ohne sie gilt der volle Katalog.
4. P1 zuerst, Always Applicable vollständig. Diese beiden Mengen tragen den Umsetzungsplan und sind nicht verhandelbar.
5. Stand und Sektorvorgaben bei der zuständigen Stelle erfragen. Aktuelle Fassung, sektorspezifische Anforderungen und, für Dubai, die ISR über DESC anfordern, statt sie aus Sekundärquellen zu übernehmen.

Typische Fehler

1. Aus fehlenden Schwellenwerten wird geschlossen, die Regulation betreffe niemanden außer Behörden, obwohl die TRA weitere Stellen als kritisch bestimmen kann.
2. Die Empfehlung an alle übrigen Stellen wird als Pflicht dargestellt.
3. Always-Applicable-Controls werden über die Risikobewertung ausgeschlossen, obwohl das nicht zulässig ist.
4. Ausschlüsse werden intern beschlossen, ohne Begründung gegenüber der TRA und ohne Nachweis der Risikoakzeptanz.
5. P1-Controls werden nach einer Risikobewertung herabgestuft.
6. Fristen, Sanktionen, eine "Version 2" oder ein Nachfolgedokument werden genannt, die die vorliegenden Quellen nicht tragen.
7. Die IA Regulation wird mit NIS-2 gleichgesetzt, oder die Dubai ISR wird ohne Text inhaltlich beschrieben.

Risiken und Trade-offs

Eine freiwillige Ausrichtung an der IA Regulation kostet Aufwand, erleichtert aber den Vertrieb an staatliche und kritische Kunden, weil deren Anforderungen ohnehin über Verträge kommen. Weil das Dokument auf Normausgaben von 2005 und 2012 aufbaut, kann ein bestehendes ISO-27001-Programm als Ausgangspunkt dienen; eine Gleichwertigkeit folgt daraus nicht, und die Zuordnung je Control bleibt eigene Arbeit.

Das größte Risiko ist ein falscher Stand: Wer die Version 1.1 umsetzt, obwohl die zuständige Stelle eine andere Fassung oder Sektorvorgaben erwartet, oder wer umgekehrt eine nicht belegte neuere Fassung zugrunde legt, steht im Audit mit dem falschen Bezugsdokument da.

Entscheidungspunkte

• Welche unserer Einheiten könnten staatliche Stellen sein oder von der TRA als kritisch bestimmt werden, und wer klärt das?
• Richten wir uns ohne Pflicht freiwillig an der IA Regulation aus, um staatliche und kritische Kunden zu bedienen?
• Wer beschafft den aktuellen Stand der IA Regulation, die einschlägigen Sektorvorgaben und, für Dubai, die ISR?
• Wie bilden wir in Angeboten die Drittparteien-, Cloud- und Lieferkettenanforderungen verpflichteter Kunden ab?

Praktische Empfehlungen

• Je Rechtseinheit eine Anwendbarkeitsnotiz führen: staatliche Stelle ja oder nein, Bestimmung als kritische Stelle ja oder nein, Kundenbezug zu verpflichteten Stellen ja oder nein.
• In Angeboten an verpflichtete Kunden die Fassung der Regulation ausdrücklich nennen und den Kunden bestätigen lassen, welche Fassung und welche Sektorvorgaben gelten.
• Ausschlüsse und Prioritätsänderungen mit Risikobewertung, Begründung und Risikoakzeptanz dokumentieren.
• Meldewege und Fristen aus der eigenen Vorfallrichtlinie mit den Kanälen der Kunden und Regulatoren abstimmen.
• Die Dubai ISR bei DESC anfordern, bevor Aussagen zu Dubai getroffen werden.

Relevante Normreferenzen

• UAE Information Assurance Regulation, Version 1.1, März 2020: Kapitel 1 (Hintergrund, Zweck, Aufbau), Kapitel 2 (Geltungsbereich, verbundene Dokumente, Entity-, Sektor- und nationaler Kontext), Kapitel 3 (Risikobasierter Ansatz, Anwendbarkeit, Priorisierung, Rollen), Kapitel 4 (Compliance), Kapitel 5 (Control-Struktur und Familien), Anhänge A, B und E, Begriffsbestimmungen in Anhang F.
• Dubai Information Security Regulation (ISR) des DESC: nur als Gegenstand genannt, Text nicht beschafft.
• Abgrenzung: NIS-2 und deutsches KRITIS-Recht stehen in den Tracks nis2 und kritis und werden mit der IA Regulation oder der ISR nicht gleichgesetzt; ISO 27001 nur als Verweis im Track core-iso27001; die saudischen NCA-Controls stehen im Track saudi-arabien und werden hier nicht übertragen; ADHICS und Gesundheitsdaten in vae-004, die Finanzaufsicht in vae-005, die Gesamtsicht für den Markteintritt in vae-001.