← Zurück zum Sicherheitsblog

Leitlinien für Security by Design bei 6G veröffentlicht, internes AI-Risiko erreicht kritisches Niveau, Zero-Days in Unternehmenssoftware auf Allzeithoch — Überblick zur Sicherheitsregulierung

Sieben westliche Staaten veröffentlichen Grundsätze für Security by Design in 6G-Netzen, noch bevor die Standards endgültig festgelegt sind. Mimecast berichtet, dass AI-gestützte interne Bedrohungen zu einer „kritischen Geschäftsbedrohung“ geworden sind — 42 % der Unternehmen verzeichneten sowohl bei böswilligen als auch bei fahrlässigen internen Vorfällen einen Anstieg. Googles Threat Intelligence Group erfasste 2025 insgesamt 90 Zero-Days, wobei Unternehmenssoftware inzwischen das Hauptziel darstellt. Microsoft reagiert mit neuen DLP-Kontrollen auf Bedenken hinsichtlich Datenlecks durch Copilot. Und eine Gemini-AI-Schwachstelle mit hohem Schweregrad in Chrome wirft neue Fragen zur AI-Sicherheit im Rahmen des EU AI Act auf. Hier erfahren Sie, worauf Regulierungs- und Compliance-Teams diese Woche reagieren müssen.

---

📡 GCOT veröffentlicht Grundsätze für Security by Design bei 6G

Warum dies wichtig ist, bevor 6G überhaupt existiert

Da kommerzielle 6G-Einführungen nicht vor 2029–2030 erwartet werden, handelt es sich hierbei um einen der frühesten Fälle, in denen Regulierung nach dem Prinzip Security by Design der von ihr geregelten Technologie vorausgeht. Die Koalition kam zu dem Schluss, dass 6G stärker virtualisierte Netzwerkfunktionen, disaggregierte Architekturen mit standardisierten Schnittstellen und eine native AI-Integration mit sich bringen wird — all dies schafft neue Angriffsflächen, die auf Standardebene berücksichtigt werden müssen, anstatt sie erst nach der Bereitstellung nachzurüsten.

Die acht Grundsätze

GCOT definierte vier Sicherheits- und vier Resilienzziele:

Kategorie	Grundsatz	Zentrale Anforderung
Sicherheit	Eindämmung	Ausbreitung böswilliger Akteure im Netzwerk begrenzen
Sicherheit	Vertraulichkeit	Datenschutz durch Technikgestaltung für Nutzerdaten und Schutz vor Abhören
Sicherheit	Integrität	Gewährleistung der Datenintegrität bei der Übertragung im Netzwerk und innerhalb der Infrastruktur
Sicherheit	Zugriffskontrolle	Authentifizierung und Autorisierung für alle Netzwerkkomponenten
Resilienz	Dienstkontinuität	Verfügbarkeit auch unter schwierigen Bedingungen aufrechterhalten
Resilienz	Lieferkette	Sicherheit in Umgebungen mit mehreren Anbietern und Gewährleistung vertrauenswürdiger Lieferanten
Resilienz	Physische Sicherheit	Widerstandsfähigkeit gegen physische und umweltbedingte Bedrohungen
Resilienz	Wiederherstellung	Schnelle Wiederherstellung nach Sicherheitsvorfällen oder Störungen

Übereinstimmung mit regulatorischen Vorgaben

Diese Grundsätze lassen sich direkt bestehenden und kommenden EU-Vorschriften zuordnen:

• NIS2 Artikel 21: Die Sicherheitsgrundsätze entsprechen den NIS2-Maßnahmen zum Risikomanagement für wesentliche Einrichtungen im Telekommunikationssektor — Eindämmung, Integrität und Zugriffskontrolle gehören zu den zentralen NIS2-Anforderungen
• EU Cyber Resilience Act (CRA): Die Grundsätze zur Lieferkette und zu Security by Design entsprechen den Produktsicherheitsanforderungen des CRA, die nach der Markteinführung für 6G-Netzwerkausrüstung gelten werden
• Europäischer Kodex für die elektronische Kommunikation (EECC): Die Resilienzgrundsätze von GCOT ergänzen die Artikel 40–41 des EECC zur Sicherheit und Integrität von Netzen
• EU AI Act: Da AI nativ in 6G-Netze integriert wird, gelten die AI-Governance-Anforderungen der Artikel 6–49 für AI-Komponenten in 6G-Infrastrukturen, die als hochriskant eingestuft werden

---

🤖 AI-gestütztes internes Risiko: eine „kritische Geschäftsbedrohung“

Wichtigste Erkenntnisse

• Anstieg böswilliger interner Vorfälle um 42 %: Beschäftigte stehlen, manipulieren oder zerstören vorsätzlich Daten — häufig mithilfe von AI-Werkzeugen, um vertrauliche Informationen in großem Umfang zu finden und auszuschleusen
• Anstieg fahrlässiger Vorfälle um 42 %: Beschäftigte nutzen private Cloud-Konten oder schwache Passwörter oder fallen auf AI-optimiertes Phishing herein — wobei die Sorglosigkeit durch das falsche Sicherheitsgefühl verstärkt wird, das AI-Produktivitätswerkzeuge vermitteln
• Anstieg der Sorge von CISOs vor böswilligen Insidern um 10 % gegenüber dem Vorjahr, wobei Sicherheitsverantwortliche inzwischen mit durchschnittlich sechs durch Insider verursachten Bedrohungen pro Monat rechnen
• AI als Waffe und Schwachstelle zugleich: Angreifer nutzen AI, um überzeugendere Phishing-Köder zu erstellen, während Insider AI einsetzen, um vertrauliche Daten effizienter zu suchen und zu extrahieren

Auswirkungen des EU AI Act

Das risikobasierte Rahmenwerk des EU AI Act ist für AI-gestützte interne Bedrohungen unmittelbar relevant:

• Artikel 9 (Risikomanagement): Hochrisiko-AI-Systeme, die in Arbeitsumgebungen eingesetzt werden, müssen Risikomanagementsysteme umfassen, die Missbrauchsszenarien berücksichtigen — einschließlich des vorsätzlichen Missbrauchs durch autorisierte Nutzer
• Artikel 14 (Menschliche Aufsicht): In Unternehmensumgebungen eingesetzte AI-Werkzeuge müssen Möglichkeiten zur menschlichen Aufsicht bieten, einschließlich der Fähigkeit, Muster der Datenausschleusung zu erkennen und zu verhindern
• Artikel 13 (Transparenz): Unternehmen, die AI-Produktivitätswerkzeuge einsetzen, müssen Nutzer über die Fähigkeiten und Grenzen des Systems informieren — Beschäftigte müssen verstehen, auf welche Daten AI-Werkzeuge zugreifen können
• Artikel 52 (Besondere Transparenz): AI-Systeme, die Inhalte erzeugen oder mit Menschen interagieren, müssen als AI erkennbar sein — dies gilt auch für AI-erstellte Phishing-E-Mails, die sich gegen Beschäftigte richten

Anforderungen aus NIS2 und DORA

Interne Bedrohungen fallen ausdrücklich in den Geltungsbereich beider Rahmenwerke:

• NIS2 Artikel 21(2)(i): Verlangt Maßnahmen zur „Sicherheit des Personals“, darunter Hintergrundüberprüfungen, Sicherheitsbewusstsein und Zugriffsverwaltung — die Governance von AI-Werkzeugen muss nun ein Bestandteil davon sein
• NIS2 Artikel 21(2)(a): Risikoanalysen und Sicherheitsrichtlinien für Informationssysteme müssen durch AI verstärkte interne Risikoszenarien berücksichtigen
• DORA Artikel 5: Finanzunternehmen müssen Szenarien interner Bedrohungen in ihre Rahmenwerke für das ICT-Risikomanagement aufnehmen, wobei AI-gestützte Bedrohungen spezifische Erkennungs- und Reaktionsfähigkeiten erfordern
• DORA Artikel 13: Die Anforderungen an Lernen und Weiterentwicklung bedeuten, dass Finanzunternehmen ihre Bedrohungsinformationen um AI-gestützte interne Angriffsmuster ergänzen müssen

---

🎯 Zero-Days in Unternehmenssoftware erreichen Allzeithoch: 90 im Jahr 2025

Die Verlagerung auf Unternehmenssysteme

Googles Analyse zeigt einen strukturellen Wandel der Bedrohungslandschaft:

• 43 Zero-Days richteten sich gegen Unternehmensprodukte — Sicherheits-Appliances, Netzwerkausrüstung, Virtualisierungsplattformen und Unternehmensanwendungen
• 21 davon (fast die Hälfte) richteten sich gegen Sicherheits- und Netzwerklösungen — Firewalls, VPNs, Router und Sicherheits-Gateways am Netzwerkrand
• Edge-Geräte sind blinde Flecken: Sicherheits-Appliances verfügen häufig nicht über eine Abdeckung durch Endpunkterkennung und -reaktion (EDR), wodurch die Ausnutzung von Zero-Days schwerer zu erkennen ist
• Angreifer nisten sich tief in kritischen Unternehmensinfrastrukturen ein und nutzen kompromittierte Unternehmenswerkzeuge zur Ausweitung von Berechtigungen und zur lateralen Bewegung

Weitere Erkenntnisse von GTIG

• Windows bleibt das am häufigsten angegriffene Betriebssystem: Von den 47 Zero-Days für Endnutzer richteten sich 24 (27 % der Gesamtzahl) gegen Betriebssysteme, allen voran Microsoft Windows
• Starker Anstieg mobiler Zero-Days: 15 Zero-Days in mobilen Betriebssystemen im Jahr 2025, gegenüber 9 im Jahr 2024 — ein Anstieg um 67 %
• Browser-Zero-Days erreichen historischen Tiefstand: Da sich die Browser-Sandboxing-Verfahren verbessern, verlagern Angreifer ihren Fokus auf weniger gehärtete Ziele
• CVE-2026-0628 (Gemini AI in Chrome): Eine Schwachstelle zur Ausweitung von Berechtigungen mit hohem Schweregrad (CVSS 8.8), durch die bösartige Erweiterungen Gemini Live im Seitenpanel des Chrome-Browsers übernehmen können

Regulatorische Auswirkungen

Rahmenwerk	Anforderung	Auswirkung des Zero-Day-Anstiegs
NIS2	Art. 21(2)(e) — Behandlung von Schwachstellen	Wesentliche Einrichtungen müssen über Prozesse zur Erkennung, Triage und Notfallbehebung von Zero-Days in Unternehmensinfrastrukturen verfügen
DORA	Art. 9 — ICT-Risikomanagement	Finanzunternehmen müssen Zero-Day-Szenarien für Unternehmenssysteme in Risikobewertungen aufnehmen und Verfahren für Notfallkorrekturen aufrechterhalten
CRA	Art. 11 — Meldung von Schwachstellen	Für Produkthersteller gilt ab September 2026 eine verpflichtende Meldung aktiv ausgenutzter Schwachstellen innerhalb von 24 Stunden
EU AI Act	Art. 15 — Genauigkeit, Robustheit, Sicherheit	AI-Systeme müssen widerstandsfähig gegen Ausnutzung sein — die Gemini-Chrome-CVE zeigt, dass AI-Komponenten neue Schwachstellenklassen schaffen

---

🛡️ Microsoft Copilot-Datenschutz: AI-Governance in der Praxis

Was sich geändert hat

Das Kernproblem: Der AI-Assistent Microsoft 365 Copilot konnte auf lokal auf den Geräten der Nutzer gespeicherte Dateien zugreifen und diese verarbeiten, selbst wenn DLP-Richtlinien dieselben Dateien in OneDrive und SharePoint einschränkten. Diese Lücke führte dazu, dass vertrauliche Dokumente — die durch DLP-Regeln als sensibel gekennzeichnet waren — ohne jegliche Schutzmaßnahmen in von Copilot generierten Berichten zusammengefasst, zitiert oder erwähnt werden konnten.

• Neues Standardverhalten (April 2026): DLP-Richtlinien gelten für alle Dateien, auf die Copilot zugreift, unabhängig vom Speicherort
• Standardmäßig aktiviert: Unternehmen müssen sich nicht anmelden — der Schutz wird automatisch aktiviert
• Rückwirkende Durchsetzung: Bestehende DLP-Richtlinien werden auf den lokalen Dateizugriff von Copilot ausgeweitet

Regulatorische Bedeutung

Dieser Vorfall verdeutlicht ein regulatorisches Muster, das Compliance-Teams verinnerlichen müssen:

• GDPR Artikel 25 (Datenschutz durch Technikgestaltung): Das ursprüngliche Verhalten von Copilot — die Verarbeitung vertraulicher Daten ohne Anwendung bestehender DLP-Regeln — verstieß möglicherweise gegen den Grundsatz des Datenschutzes durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Unternehmen, die Copilot ohne Überprüfung der DLP-Abdeckung eingesetzt haben, könnten als Verantwortliche haftbar sein
• EU AI Act Artikel 9 (Risikomanagement): AI-Systeme, die personenbezogene oder vertrauliche Daten verarbeiten, müssen Kontrollen zur Verhinderung unbefugter Datenoffenlegung umfassen. Die DLP-Lücke von Copilot ist genau die Art von Risiko, die Risikomanagementsysteme gemäß Artikel 9 erkennen und mindern müssen
• DORA Artikel 28 (ICT-Drittparteienrisiko): Finanzunternehmen, die Microsoft 365 Copilot verwenden, müssen diese DLP-Lücke als wesentliches ICT-Risikoereignis behandeln. Dokumentieren Sie die Lücke, den Zeitplan für ihre Behebung (April 2026) und alle zwischenzeitlichen kompensierenden Kontrollen in Ihrem Drittparteien-Risikoregister
• NIS2 Artikel 21(2)(d) — Sicherheit der Lieferkette: Copilot ist eine AI-Komponente eines Drittanbieters in Ihrer ICT-Umgebung. Sein Verhalten bei der Datenverarbeitung stellt ein Lieferkettenrisiko dar, das kontinuierlich bewertet werden muss

---

⚠️ Gefälschte AI-Browsererweiterungen: Lücke im Verbraucherschutz

Die regulatorische Lücke

Dieser Trend offenbart kritische Lücken in bestehenden regulatorischen Rahmenwerken:

• EU AI Act Artikel 52 (Transparenz): AI-Systeme, die mit Nutzern interagieren, müssen als AI erkennbar sein und ihren Zweck offenlegen. Gefälschte AI-Erweiterungen verstoßen sowohl gegen die Transparenz- als auch gegen die Zweckbindungsanforderungen, doch die Durchsetzungsmechanismen für den Vertrieb über App-Stores sind nicht definiert
• Gesetz über digitale Dienste (DSA): App-Stores gelten gemäß DSA als „Online-Plattformen“ und müssen Maßnahmen ergreifen, um die Verbreitung bösartiger Erweiterungen zu verhindern. Dazu gehören für sehr große Online-Plattformen (VLOPs) Pflichten zur proaktiven Sicherheitsprüfung
• GDPR Artikel 5(1)(b) — Zweckbindung: Erweiterungen, die über ihre angegebene AI-Funktionalität hinaus Daten erheben, verstoßen gegen den Grundsatz der Zweckbindung. Datenschutzbehörden sollten die Durchsetzung gegenüber diesen Akteuren priorisieren
• CRA-Produktsicherheit: Wenn die Meldepflichten des CRA im September 2026 in Kraft treten, könnten App-Stores verpflichtet sein, aktiv ausgenutzte Schwachstellen in vertriebener Software zu melden, einschließlich bösartiger Erweiterungen

---

📅 Regulierungskalender: wichtige bevorstehende Termine

Datum	Rahmenwerk	Meilenstein
11. März 2026	Patch-Dienstag	Microsoft-Veröffentlichung vom März 2026 — nach 90 Zero-Days im Jahr 2025 ist mit bedeutenden Patches zu rechnen
April 2026	Microsoft	Lokaler DLP-Dateischutz für Copilot wird standardmäßig angewendet — überprüfen Sie, ob Ihre DLP-Richtlinien alle Datenkategorien abdecken
2. Mai 2026	EU AI Act	Transparenzpflichten für GPAI-Modelle treten in Kraft — AI-Anbieter müssen Zusammenfassungen ihrer Trainingsdaten veröffentlichen
2. August 2026	EU AI Act	Anforderungen an Hochrisiko-AI-Systeme werden durchsetzbar (Artikel 6–49) — vollständige Compliance-Struktur erforderlich
11. September 2026	CRA	Die verpflichtende Meldung aktiv ausgenutzter Schwachstellen beginnt — Benachrichtigung innerhalb von 24 Stunden erforderlich
17. Oktober 2026	NIS2	Frist für die Umsetzung durch die Mitgliedstaaten — alle 27 EU-Länder müssen NIS2 in nationales Recht umgesetzt haben
2029–2030	GCOT/6G	Voraussichtlicher Beginn der kommerziellen Einführung von 6G — Grundsätze für Security-by-Design müssen bis dahin in den Standards verankert sein

---

🔑 Wichtigste Erkenntnisse für Compliance-Teams

1. Die 6G-Sicherheitsstandards werden jetzt gestaltet. Die acht Grundsätze von GCOT definieren Erwartungen, die zu verbindlichen Anforderungen werden. Telekommunikationsbetreiber und Gerätehersteller sollten ihre Security-by-Design-Prozesse bereits heute an diesen Grundsätzen ausrichten — wer auf die endgültigen Standards wartet, gerät ins Hintertreffen.
2. AI-bedingte Insider-Risiken sind eine Compliance-Verpflichtung und kein Personalthema. Da 42 % der Unternehmen einen Anstieg AI-gestützter Insider-Bedrohungen melden, müssen NIS2- und DORA-Compliance-Programme spezifische Kontrollen für die Governance von AI-Werkzeugen umfassen — Audits nicht autorisierter AI-Nutzung, DLP für AI-gestützte Zugriffe und Ausgangswerte für Insider-Bedrohungen, die AI-Fähigkeiten berücksichtigen.
3. Ihre Sicherheitsinfrastruktur ist das Ziel. Googles Erkenntnis zu 90 Zero-Days, von denen fast die Hälfte auf Sicherheits- und Netzwerkgeräte von Unternehmen abzielte, bedeutet, dass Programme für das Schwachstellenmanagement genau den Werkzeugen Priorität einräumen müssen, die Sie schützen sollen. Gehen Sie von einer Kompromittierung der Edge-Geräte aus und implementieren Sie eine Out-of-Band-Überwachung.
4. Die DLP-Lücke von Microsoft Copilot ist ein Vorgeschmack auf das Scheitern der AI-Governance. Unternehmen, die AI-Produktivitätswerkzeuge einsetzen, ohne deren Kontrollen zur Datenverarbeitung zu überprüfen, riskieren eine Haftung nach GDPR, EU AI Act und NIS2. Prüfen Sie den Datenzugriff von AI-Werkzeugen, bevor die Aufsichtsbehörden Fragen stellen.
5. Gefälschte AI-Erweiterungen sind eine Krise für den Verbraucherschutz. Bis die Durchsetzung von DSA und CRA aufholt, ist eine Positivliste für Browsererweiterungen im Unternehmen Ihre einzige zuverlässige Verteidigung. Implementieren Sie sie jetzt.
6. Die Vorbereitung auf den Patch-Dienstag ist nicht optional. Nach einem Rekordjahr bei Zero-Days in Unternehmen weisen DORA- und NIS2-Organisationen ohne dokumentierte und getestete Verfahren für Notfall-Patches ein Compliance-Defizit auf, das die Aufsichtsbehörden erkennen werden.