KI-Agenten machen Berechtigungsgrenzen zur Sicherheitsfrage

Der Sicherheitsvorfall beim US-amerikanischen KI-Dienstleister Hugging Face im Juli 2026 zeigt, warum KI-Agenten nicht allein über Modellschutz abgesichert werden können. Während einer internen Cyber-Evaluation identifizierten und kombinierten OpenAI-Modelle Schwachstellen in der Testumgebung. Sie erlangten darüber Internetzugang und drangen anschließend bis in die Produktionsinfrastruktur von Hugging Face vor.

https://openai.com/index/hugging-face-model-evaluation-security-incident/

Betroffen waren interne Datensätze sowie Zugangsdaten von Diensten. Öffentliche Modelle, Datensätze, Spaces und die Software-Lieferkette waren nach Angaben von Hugging Face nicht manipuliert.

https://huggingface.co/blog/security-incident-july-2026

Der Vorfall fand in einer Evaluation mit reduzierten Schutzmechanismen statt. Er ist deshalb nicht mit dem Einsatz eines Standardprodukts gleichzusetzen. Seine Relevanz liegt an anderer Stelle. Ein Agent kann bekannte Angriffstechniken über viele Einzelschritte hinweg verbinden, wenn seine Umgebung zu weitreichende Zugriffe ermöglicht. Sicherheit entsteht damit nicht nur durch Vorgaben im Modell, sondern auch durch technisch durchgesetzte Grenzen für Identitäten, Zugriffe und Aktionen.

https://openai.com/index/hugging-face-incident-and-the-road-ahead/

Auch aktuelle Erkenntnisse zu Ransomware stützen diese Einordnung. Der Sicherheitsdienstleister CloudSEK dokumentierte in einem Fall den Einsatz des KI-Agenten Cursor zur Planung von Angriffsschritten. Das ist kein Beleg für eigenständig operierende KI. Es zeigt aber, dass Angreifer KI-Assistenten bereits in bestehende Angriffsketten einbinden, um technische Aufgaben schneller vorzubereiten und umzusetzen.

https://www.cloudsek.com/blog/aurora-ransomware-affiliate-ai-attack-planning-crypto-payments

Prompt Injection verschärft das Risiko. Inhalte aus Dokumenten, Websites oder Repositories können dabei von einem Agenten als Handlungsanweisung verarbeitet werden. Modellseitige Schutzmechanismen können problematische Antworten mit einiger Wahrscheinlichkeit erkennen und unterdrücken. Sie verhindern jedoch nicht zuverlässig, dass ein manipulierter Agent mit einer gültigen Berechtigung auf Daten zugreift oder eine Aktion ausführt. Die entscheidende Sicherheitsfrage lautet daher (wie beim Hugging-Face-Fall), welche Rechte ein Agent technisch besitzt, und welche Aktionen ohne menschliche Freigabe möglich sind.

Die gemeinsame Leitlinie der Five-Eyes-Behörden vom 1. Mai 2026 und die vorläufigen Hinweise des britischen NCSC vom 20. August 2026 weisen in dieselbe Richtung. Agentische Systeme benötigen eng begrenzte Berechtigungen und eine stetige Überwachung. Für kritische Fälle müssen Eingriffsmöglichkeiten erprobt sein.

https://ncsc.govt.nz/protect-your-organisation/careful-adoption-of-agentic-ai-services/

https://ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai

In dieselbe Richtung gehen auch die Überlegungen der NSA zum Sicherheitsdesign des Model Context Protocol. Das MCP verbindet Agenten mit Datenquellen und Funktionen anderer Systeme. Das Protokoll schreibt jedoch weder eine eindeutige Zuordnung von Sitzungen zu Identitäten noch eine rollenbasierte Zugriffskontrolle verbindlich vor. Auch der Umgang mit Zugangsdaten, Freigaben und Protokollierung hängt wesentlich von der jeweiligen Umsetzung ab. Das Dokument der NSA beschreibt zentrale Risiken bei der Integration von KI-Agenten mit externen Tools und Datenquellen und gibt Empfehlungen für einen sicheren, Zero-Trust-orientierten Betrieb.

https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF

Für CISO, IT-Leitung und KI-Governance folgt daraus eine konkrete Priorität. Jeder eingesetzte Agent braucht eine nachvollziehbare Identität. Seine Berechtigungen müssen auf den jeweiligen Zweck begrenzt sein. Besonders risikoreiche Aktionen benötigen eine menschliche Freigabe. Erst auf dieser Grundlage lassen sich Risiken realistisch bewerten und Zugriffe wirksam begrenzen.

Signiert und trotzdem bösartig

Der Angriff auf die Softwarebibliotheken keyv und cacheable vom 4. August 2026 zeigt eine oft übersehene Grenze. Die sogenannte Provenance, also der Nachweis, wo und über welchen Prozess ein Artefakt gebaut wurde, bestätigt die Herkunft eines Builds. Sie bestätigt nicht, dass der zugrunde liegende Quellcode legitim oder unverändert war.

Bei keyv@6.0.0 waren npm-Provenance und SLSA-Attestation (ein Beleg, dass die Software in einer sicheren, nachvollziehbaren Umgebung gebaut wurde) gültig. Dennoch enthielt das veröffentlichte Paket Schadcode, weil dieser bereits vor dem Build in das Repository eingebracht worden war. Der reguläre Prozess baute und signierte damit korrekt einen kompromittierten Stand.

https://socket.dev/supply-chain-attacks/keyv-and-cacheable-compromise

Provenance schützt den Veröffentlichungsweg, nicht automatisch die Integrität des Quellcodes. Wer eine gültige Attestation als vollständigen Sicherheitsnachweis bewertet, verwechselt Build-Herkunft mit Code-Integrität.

Das kompromittierte Paket enthielt einen preinstall-Hook, der bereits bei der Installation lief. Damit konnte Schadcode auf Entwicklerrechnern oder CI-Runnern auf Tokens, Cloud-Zugänge und weitere sensible Daten zugreifen. Die Gefahr beginnt also nicht erst in der Produktivumgebung, sondern beim Auflösen und Installieren von Abhängigkeiten.

https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks/

Hinzu kamen Projektkonfigurationen für Claude Code und VS Code, die beim Öffnen eines Repositorys Code ausführen konnten. Solche Dateien gehören inzwischen ebenso in Sicherheitsreviews wie Build-Skripte und CI-Konfigurationen. Ein reiner Dependency-Scan reicht dafür nicht aus.

https://safedep.io/keyv-npm-supply-chain-compromise/

Die gemeldete Reichweite unterstreicht das Risiko, auch wenn sie keine Zahl tatsächlich kompromittierter Systeme beschreibt. keyv kam laut Aikido zum Zeitpunkt der Analyse auf rund 127 Millionen wöchentliche Downloads. Entscheidend für die eigene Bewertung sind jedoch nicht globale Summen, sondern die konkret verwendeten Versionen in Lockfiles, Artefakt-Proxys und Build-Caches.

https://aikido.dev/blog/keyv-and-friends-compromised-in-npm-supply-chain-attack

Für Security- und Plattformteams folgt daraus eine klare Priorität. Lifecycle-Skripte sollten nur dort laufen, wo sie erforderlich sind, und dabei möglichst geringe Rechte erhalten. Installationsprozesse dürfen keinen Zugriff auf weitreichende Publishing-Tokens oder produktive Cloud-Zugänge bekommen. Neu veröffentlichte Abhängigkeiten können zudem vor der Übernahme in zentrale Builds eine Wartezeit durchlaufen.

Auch die Incident Response muss diesen Fall abdecken. Nach einer potenziell bösartigen Installation muss schnell erkennbar sein, welche Zugangsdaten auf dem betroffenen System verfügbar waren. Host-Isolierung und die Suche nach Persistenz sollten vor der Token-Rotation erfolgen, weil eine vorschnelle Sperrung Angreifer warnen kann.

https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks

Provenance bleibt wichtig. Sie ist jedoch ein Herkunftsnachweis, kein vollständiger Integritätsnachweis. Sicherheit entsteht erst dann, wenn auch die Ausführung fremden Codes, seine Berechtigungen sowie ausführbare Editor- und Agentenkonfigurationen kontrolliert werden.

Der Vorfall sollte für jeden Anlass sein, die Ausführung fremden Codes als eigenständiges Risiko zu behandeln. Besonders gilt dies bei Installationsprozessen und Build-Runnern mit weitreichenden Zugängen, da dort ein kompromittiertes Paket unmittelbar Tokens oder Cloud-Zugriffe abgreifen kann. Editor- und Agentenkonfigurationen gehören deshalb verbindlich in Repository-Reviews.

Der G7 drängt, die EU-Uhr läuft: Post-Quanten-Migration ist ein Inventarproblem

Die G7-Arbeitsgruppe für Cybersicherheit hat am 3. September 2026 öffentliche und private Organisationen in einem gemeinsamen Aufruf dazu aufgefordert, den Übergang zu Post-Quanten-Kryptografie jetzt vorzubereiten. Wann kryptografisch relevante Quantencomputer verfügbar sein werden, ist offen. Das Risiko besteht dennoch bereits heute. Angreifer können verschlüsselte Daten schon jetzt abgreifen und so speichern, um sie später zu entschlüsseln, wenn die technische Fähigkeit dafür vorhanden ist. Besonders betroffen sind Informationen, die über viele Jahre vertraulich bleiben müssen.

https://cyber.gouv.fr/en/news/post-quantum-cryptography-transition-anssi-and-its-g7-partners-rally-public-and-private-sectors-with-urgent-call-to-action/

Auch die europäische Roadmap wird häufig missverstanden. Ende 2026 ist kein Endtermin für die Migration. Bis dahin sollen alle EU-Mitgliedstaaten erste Schritte umgesetzt und nationale Post-Quantum-Computing-Strategien (PQC) angestoßen haben. Hochrisikofälle, etwa in kritischen Infrastrukturen, sollen so früh wie möglich und spätestens bis Ende 2030 auf quantenresistente Verfahren umgestellt sein. Die Roadmap empfiehlt für den Übergang standardisierte hybride Verfahren. Krypto-Agilität gehört ebenfalls dazu.

https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

Ab 2027 will Frankreich PQC bei der Qualifizierung von Sicherheitsprodukten berücksichtigen. Für Organisationen bedeutet das vor allem eines. Sie sollten neue Produkte und Ersatzbeschaffungen nicht mehr ohne eine belastbare Aussage des Herstellers zu PQC und Krypto-Agilität bewerten.

https://cyber.gouv.fr/enjeux-technologiques/cryptographie-post-quantique/faq-pqc/

Die entscheidende Frage zu Beginn einer Migration lautet nicht, welches PQC-Verfahren eingesetzt werden soll, sondern, ob die Organisation ihre heutige Kryptografie kennt. Wo werden RSA, ECC oder Diffie-Hellman eingesetzt? Welche Zertifikate, VPN-Verbindungen, HSM, Signaturprozesse und Geräteflotten hängen daran? Welche Abhängigkeiten bestehen zu Herstellern oder Dienstleistern?

Wer PQC als reines Update behandelt, übersieht das eigentliche Risiko. Die Erfassung scheitert selten an fehlender Technik. Häufig fehlen klare Verantwortlichkeiten und ein sinnvoll abgegrenzter Startbereich.

Statt sofort das gesamte Unternehmen zu erfassen, sollte zunächst ein Pilot in einem geschäftskritischen, aber überschaubaren Bereich starten. Eine verantwortliche Rolle sollte den Umfang festlegen und die eingesetzten Verfahren dokumentieren. Parallel sollten Beschaffungsvorgaben ergänzt werden. Hersteller müssen darlegen, wie sie Krypto-Agilität ermöglichen und wann sie PQC unterstützen.

Diese Maßnahmen lohnen sich unabhängig davon, wann der Q-Day eintritt. Sie schaffen die Grundlage, um Risiken priorisiert zu bewerten und die Migration kontrolliert zu steuern.

Die Perimeter-Schmelze

Warum VPN-Gateways und Legacy-Altlasten uns im Sommer 2026 einholen

Während Check Point und Palo Alto kritische bzw. hochriskante Authentifizierungsumgehungen offenlegten, zeigte FortiBleed eine parallele Schwächeklasse: massenhafte Kompromittierung durch wiederverwendete oder aus Konfigurationen extrahierte Zugangsdaten, begünstigt durch Legacy-Credential-Handling und exponierte Management-/VPN-Oberflächen. Das Perimeter-Modell erodiert strukturell. Check Point selbst beobachtete, dass dieselbe Bedrohungsakteur-Infrastruktur parallel auch Schwachstellen bei Palo Alto, Fortinet und F5 ausnutzt. Ein koordinierter Angriff auf die gesamte Gateway-Kategorie.

CVE-2026-50751 (CVSS 9.3) erlaubt unauthentifizierten Angreifern, eine VPN-Sitzung ohne gültiges Passwort aufzubauen. Entscheidend ist die Bedingung: Die Schwachstelle betrifft ausschließlich Deployments, die das veraltete IKEv1-Schlüsselaustauschprotokoll nutzen, bei denen Gateways Legacy-Remote-Access-Clients akzeptieren und kein Maschinenzertifikat verlangen. Die Ausnutzung begann bereits am 7. Mai, verstärkte sich Anfang Juni, und Check Point bewertet mit mittlerer Konfidenz, dass der Akteur finanziell motiviert ist und Qilin-Ransomware einsetzt. Das „Zero-Day“-Fenster ohne verfügbaren Patch dauerte rund einen Monat.

CVE-2026-0257 wirkt zunächst harmloser – ursprünglich nur mit CVSS 4,7 bewertet –, doch die Eskalation war dramatisch. Verwundbare PAN-OS-Versionen vertrauten jedem entschlüsselbaren Authentication-Override-Cookie, ohne zu prüfen, ob es legitim vom Gerät erzeugt wurde. Wird dasselbe Zertifikat für den HTTPS-Dienst und die Cookie-Verschlüsselung verwendet, kann ein Angreifer die öffentliche Zertifikatskette abrufen und gültige Cookies für beliebige Nutzer fälschen – inklusive Administratoren. Nach Rapid7s Proof-of-Concept und bestätigter Ausnutzung hob Palo Alto den Schweregrad auf 7,8 an; CISA nahm die Lücke am 29. Mai in den Known-Exploited-Vulnerabilities-Katalog (KEV-Katalog) auf. Bei acht von zehn betroffenen Rapid7-MDR-Kunden blieb es bei reinen Authentifizierungs-Sonden ohne vollständige VPN-Sitzung – ein Hinweis, dass die Angriffswelle noch breiter angelegt war als bislang sichtbar.

Was im Juni als Leak von rund 74.000 Fortinet-Zugangsdaten begann, hat sich zu einem der gravierendsten Vorfälle des Jahres entwickelt. Aktuelle SOCRadar-Recherchen beziffern die Kampagne auf über 430.000 angegriffene FortiGate-Firewalls weltweit mit mehr als 110 Millionen erbeuteten Zugangsdaten. Der technische Kern bleibt das Legacy-Data-Debt-Problem: Ältere Passwort-Hashes verbleiben nach einem Firmware-Update auf PBKDF2 so lange als schwächere SHA-256-Hashes gespeichert, bis sich ein Administrator nach dem Upgrade manuell neu anmeldet.

Die eigentliche Eskalation kam jedoch erst Anfang Juli: SOCRadars Threat Research Unit fand einen Operator, der gleichzeitig in den Verhandlungspanels von INC Ransom und Lynx eingeloggt war – der belastbare Beweis, dass FortiBleed direkt in die Ransomware-Ökonomie einspeist. Konkret bedeutet das: Scanning-Aktivität gegen rund 11.250 FortiGate-Portale, bestätigter Admin-Zugriff auf 409 Ziele, vollständiger Angriffsketten-Abschluss bei 354 davon, mit mindestens 12 bestätigten Ransomware-Deployments und hunderten verschlüsselten Endpunkten. Zusätzlich identifizierten die Forscher Hinweise auf einen Nextcloud-Zero-Day sowie Citrix-bezogene Artefakte, die auf eine Ausweitung über Fortinet hinaus deuten.

Drei unterschiedliche technische Ursachen – Protokoll-Legacy, Logikfehler, Krypto-Schulden – führen zum selben Ergebnis: kompromittierter Perimeter, Ransomware-Zugang. Patch-Management allein greift zu kurz. Notwendig sind die konsequente Deaktivierung von IKEv1, die Trennung von Zertifikatsverwendung pro Funktion, verpflichtende Passwort-Rotation nach jeder Krypto-Migration sowie der überfällige Umstieg von Perimeter-VPN auf identitätsbasierte Zero-Trust-Architekturen.

Quellen:

Check Point Blog: Hotfix für CVE-2026-50751
https://blog.checkpoint.com/security/check-point-releases-important-hotfix-for-vulnerabilities-in-deprecated-ikev1-vpn-protocol/

Rapid7: rapid7.com – CVE-2026-50751 & CVE-2026-0257 Threat Reports
https://www.rapid7.com/db/vulnerabilities/check-point-gaia-cve-2026-50751/
https://www.rapid7.com/blog/post/etr-rapid7-observed-exploitation-of-pan-os-globalprotect-authentication-bypass-vulnerability-cve-2026-0257/

BleepingComputer: Qilin-Attribution & FortiBleed-Berichterstattung
https://www.bleepingcomputer.com/news/security/fortibleed-credential-theft-campaign-linked-to-lynx-ransomware/

Palo Alto Networks Security Advisory
https://security.paloaltonetworks.com/CVE-2026-0257

Arctic Wolf: CVE-2026-0257 Analyse
https://arcticwolf.com/resources/blog/cve-2026-0257-pan-os-globalprotect-authentication-bypass/

SOCRadar: „FortiBleed — 86,644 Fortinet Firewalls Compromised“ https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised/

Hudson Rock: „FortiBleed 75,000 Fortinet Firewalls Compromised“ https://www.hudsonrock.com/blog/fortibleed-75000-fortinet-firewalls-compromised-global-enterprises-exposed-claim-your-ethical-disclosure

The Hacker News: FortiBleed-Ransomware-Link
https://thehackernews.com/2026/07/fortibleed-credential-theft-linked-to.html

SecurityWeek: FortiBleed & Check Point Berichterstattung
https://www.securityweek.com/fortibleed-86000-fortinet-device-credentials-compromised/

Klue/Salesforce: Wenn OAuth-Tokens zum Datenabfluss werden

Nicht jeder Perimeter sieht aus wie ein VPN-Gateway. Im SaaS-Zeitalter besteht er aus OAuth-Tokens, Connected Apps und API-Berechtigungen, die oft weniger streng überwacht werden als menschliche Admin-Konten. Genau dieses Muster zeigte sich im Juni bei der Kompromittierung der Klue-Battlecards-Integration für Salesforce.

Klue ist eine Competitive-Intelligence-Plattform, die sich mit Salesforce verbindet, um Battlecards, Win/Loss-Daten und CRM-Kontext in Vertriebsprozesse einzubetten. Laut ReliaQuest wurde eine kompromittierte Klue-Integration genutzt, um über OAuth-Tokens und automatisierte REST-API-Abfragen Salesforce-CRM-Daten zu exfiltrieren. Eine Salesforce-Schwachstelle stand dabei nicht im Mittelpunkt; missbraucht wurde eine bereits vertrauenswürdige Drittanbieter-Verbindung. Salesforce deaktivierte die Klue-Battlecards-Verbindungen vorübergehend und erklärte, es gebe keinen Hinweis auf eine Schwachstelle in der eigenen Plattform.

Technisch lief der Angriff weitgehend innerhalb legitimer SaaS-Mechanismen: OAuth-Tokens, Objekt-Enumeration, Query- und QueryMore-Aufrufe über die Salesforce REST API. ReliaQuest beobachtete in einer Umgebung eine Abfragekette über fast 24 Stunden; in einem anderen Fall fast tausend API-Queries innerhalb von 15 Minuten. Damit wird der persistente OAuth-Refresh-Token zur modernen Variante des gestohlenen VPN-Zugangs — nur oft schlechter überwacht.

Der Vorfall ist Teil eines größeren SaaS-Supply-Chain-Problems: Drittanbieter-Apps besitzen dauerhaft Zugriff auf CRM-, Vertriebs- und Kundendaten, während ihre Berechtigungen selten regelmäßig überprüft werden. Cybersecurity Dive berichtete, dass unter anderem LastPass, Recorded Future und Tanium Zugriffe auf bestimmte CRM- bzw. Geschäftskontaktdaten bestätigten; ihre Kernprodukte seien nach bisherigem Stand nicht betroffen gewesen.

SaaS-Integrationen sind privilegierte Maschinenidentitäten. Jede Connected App mit Zugriff auf Salesforce, Microsoft 365, ServiceNow, GitHub oder Slack braucht Inventarisierung, Least-Privilege-Scopes, regelmäßige Token-Rotation, IP-Allowlisting, Monitoring auf ungewöhnliche API-Volumina und einen sauberen Offboarding-Prozess.

Der eigentliche Blind Spot liegt nicht in einem einzelnen Anbieter, sondern in der Annahme, dass eine einmal genehmigte Integration dauerhaft vertrauenswürdig bleibt.

ReliaQuest: „Klue Integration Abused in Salesforce Data Theft“
https://reliaquest.com/blog/threat-spotlight-integration-abused-in-crm-data-theft/

Cybersecurity Dive: „Klue investigating supply chain attack that targeted Salesforce integrations“
https://www.cybersecuritydive.com/news/klue-investigating-supply-chain-attack-salesforce-integrations/823532/

Krypto-Agilität: Der Weg von der Bedrohung zur Handlungsfähigkeit

Quantencomputer bedrohen die Grundlagen unserer digitalen Sicherheit. Holger von Rhein hat in seinem Beitrag die Hintergründe beleuchtet: Harvest Now, Decrypt Later, Moscas Theorem und die historische Einordnung kryptografisch relevanter Quantencomputer zeichnen ein klares Bild – wir müssen handeln. Dieser Artikel widmet sich dem „Wie“.

Die unbequeme Wahrheit: Kryptografie ist kein „Set and Forget“. Wer Holgers Artikel gelesen hat, kennt die Ausgangslage: Die Frage ist nicht mehr ob, sondern wann ein kryptografisch relevanter Quantencomputer Realität wird. Die NIST hat mit FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) bereits 2024 die ersten Post-Quantum-Standards finalisiert. Das BSI positioniert sich klar an der Seite der EU und empfiehlt, die Migration zeitnah einzuleiten. Die Werkzeuge liegen auf dem Tisch.

Und trotzdem wird das Thema in vielen Organisationen nicht mit der gebotenen Dringlichkeit behandelt, ähnlich wie in den frühen Tagen der DSGVO oder aktuell mit der NIS-2-Einführung. Man hat vielleicht davon gehört, aber unterschätzt, wie groß der Berg tatsächlich ist. In der Konsequenz bleibt der erste Schritt aus. Dabei offenbart die Post-Quanten-Herausforderung ein weit tieferliegendes, strukturelles Problem: Die meisten Organisationen wissen schlicht nicht, wo und wie sie Kryptografie einsetzen. Keine Inventare, keine zentrale Governance, keine Agilität. Kryptografie wurde über Jahrzehnte als unsichtbare Selbstverständlichkeit behandelt – eingebettet in Bibliotheken, Protokolle und Appliances, über die niemand eine Gesamtübersicht hat.

Genau hier setzt Krypto-Agilität an. Und nein, das ist kein bloßes Buzzword. Es beschreibt die Fähigkeit einer Organisation, kryptografische Algorithmen, Protokolle und Schlüssel systematisch, zeitnah und möglichst unterbrechungsfrei austauschen zu können – nicht nur einmal, sondern kontinuierlich. Denn selbst Post-Quanten-Algorithmen sind nicht für die Ewigkeit gemacht. Wer heute eine starre PQC-Migration durchführt, ohne dabei Agilität als Designprinzip zu verankern, schafft die nächste Altlast.

Bin ich überhaupt betroffen? Die kurze Antwort: Ja. Wenn eine Organisation digitale Kommunikation betreibt, Daten speichert oder Software entwickelt, nutzt sie Kryptografie. TLS, VPN, PKI, Festplattenverschlüsselung, Signaturverfahren, API-Authentifizierung: All das basiert auf kryptografischen Bausteinen, den sogenannten Primitiven,, die durch Quantencomputer bedroht sind.

Die differenziertere Antwort ergibt sich aus zwei Aspekten – dem Zeitdruck und der Komplexität der eigenen kryptografischen Landschaft. Dabei stehen Organisationen mit langfristig schützenswerten Daten unter dem höchsten Zeitdruck. Moscas Theorem gibt uns die entscheidende Formel an die Hand: Wenn die Summe aus der Geheimhaltungsdauer der Daten und der benötigten Migrationszeit größer ist als die Zeit bis zur Verfügbarkeit eines kryptografisch relevanten Quantencomputers, dann sind die Daten bereits jetzt im Risiko.

Für Organisationen, deren Daten über Jahrzehnte hinweg vertraulich bleiben müssen (etwa in der Verteidigung, der Forschung oder dem Gesundheitswesen), hätte die Migration bereits beginnen müssen. Doch mittlerweile geht die Gleichung für „normale“ Betriebe nicht mehr auf. Schon gesetzliche Aufbewahrungsfristen von zehn Jahren, etwa beim Handels- und Steuerrecht, reichen in Kombination mit realistischen Migrationszeiten aus, um das Zeitfenster von Moscas Theorem zu sprengen. Wenn ein Angreifender heute verschlüsselten Datenverkehr abfängt (Harvest Now, Decrypt Later), ist der Schaden bei der Verfügbarkeit eines kryptografisch relevanten Quantencomputers bereits eingetreten – unabhängig davon, wann das sein wird.

Das betrifft zum Beispiel:

  • Behörden und Verteidigung: Staatliche Kommunikation, die über Dekaden geheim bleiben muss.
  • Gesundheitswesen: Patientendaten unterliegen strengstem Schutz – und zwar dauerhaft.
  • Forschung und geistiges Eigentum: Forschungsergebnisse, deren wirtschaftlicher Wert auf Jahre hinaus kritisch ist.
  • Finanzsektor: Langfristige Vertragsdaten, Transaktionshistorien, strategische Planungen
  • Konzerne: Hochkomplexe IT-Landschaften, Patente, Firmengeheimnisse und strategische Planungen

Regulatorische Rahmenwerke verschärfen den Druck zusätzlich. Wer unter NIS-2, den Cyber Resilience Act (CRA), ISO 27001, IT-Grundschutz oder branchenspezifische Regelungen wie DORA oder TISAX fällt, wird sich bald mit der Frage konfrontiert sehen, ob die eigene kryptografische Praxis den Anforderungen noch genügt. Diese Regularien fordern üblicherweise bereits heute explizit den Einsatz „dem Stand der Technik entsprechender“ Kryptografie. Das BSI empfiehlt explizit klassisch eingesetzte Kryptografie für hohe Schutzbedarfe nur bis Ende 2030 und für die restlichen Anwendungen bis Ende 2031. Demnach ist die Definition vom „Stand der Technik“ klar: Die Nutzung von quantensicheren Verfahren.

Organisationen mit komplexen, historisch gewachsenen IT-Landschaften – typischerweise im Mittelstand und in Konzernen – stehen vor einer besonderen Herausforderung: Kryptografie steckt nicht nur in den offensichtlichen Punkten (TLS-Zertifikate, VPN-Gateways), sondern tief in der Lieferkette, in eingebetteten Systemen, in OT-Umgebungen und in selbst entwickelter Software. Die Migrationszeit kann hier besonders groß sein, was das von Mosca beschriebene Zeitfenster weiter verengt.

Selbst wenn ihre Daten keine jahrzehntelange Geheimhaltung erfordern und sie keiner strikten Regulatorik unterliegen: Krypto-Agilität ist eine architektonische Eigenschaft, die sich nicht über Nacht herstellen lässt. Wer heute beginnt, verschafft sich strategischen Spielraum. Wer wartet, wird irgendwann unter Zeitdruck und einem erhöhten Risiko sowie höheren Kosten migrieren müssen.

Der Weg zur Krypto-Agilität

Krypto-Agilität entsteht nicht durch ein einzelnes Projekt, sondern durch einen strategischen Aufbauprozess, der sich in klar abgrenzbare Phasen gliedern lässt. Im Folgenden skizzieren wir unseren erprobten Ansatz, der sich an der Realität mittelständischer und großer Organisationen orientiert.

Phase 1: Standortbestimmung – Wo stehen wir?

Bevor man irgendetwas migriert, muss man verstehen, was es zu migrieren gilt. Und genau hier liegt bei den meisten Organisationen die größte Lücke.

Unser Crypto-Basis-Check ist der erste, entscheidende Schritt. Er umfasst die Sichtung der kryptografischen Landschaft. Das bedeutet eine systematische Erfassung über alle relevanten Domänen hinweg, von der Zusammenarbeit, Vendor- & Supply-Chain-Readiness bis zum internen Wissen. Dabei betrachten wir alle kryptografischen Kategorien:

  • Operative Kryptografie: PKI-Infrastrukturen, Schlüsselmanagement, Konfigurationen, At-Rest-Verschlüsselung, OT-Umgebungen, …
  • Software-Kryptografie: Kryptografische Bibliotheken, Abhängigkeiten, hartcodierte Schlüssel oder Algorithmen …
  • Netzwerk-Kryptografie: Protokolle, Cipher Suites, In-Transit-Verschlüsselung, Firewall- und VPN-Konfigurationen, …
  • Managed und Hardware-basierte Kryptografie: Verwaltete Schlüssel, HSMs, …

Außerdem gilt klar: Nicht jede Kryptografie ist gleich kritisch. Die zentrale Frage lautet daher:

„Wie lange müssen welche Daten vertraulich, integer oder authentisch bleiben?“

Diese Frage speist direkt in Moscas Theorem ein und liefert die Grundlage für jede sinnvolle Priorisierung. Aus alldem entsteht ein Lagebild, das sich in einem Krypto-Reifegrad-Modell verdichten lässt – von Ad hoc (keine Sichtbarkeit, keine Strategie) bis Optimierend (automatisierte Inventarisierung, abgeschlossener PQC-Rollout für Hochrisikosysteme, kontinuierliche Verbesserung). Dieses Modell dient als KPI-Framework: messbar, nachvollziehbar und steuerungsrelevant. Ein solcher Basis-Check ist – je nach Größe der Organisation – in wenigen Tagen bis zu wenigen Wochen durchführbar und liefert die Entscheidungsgrundlage für alles Weitere.

Phase 2: Inventarisierung und Risikoanalyse – Was haben wir und was davon ist kritisch?

Auf dem Crypto-Basis-Check aufbauend folgt die systematische, unternehmensweite Inventarisierung kryptografischer Assets. Hier gelten einige Grundprinzipien, die wir aus der Praxis ableiten:

  • Vollständigkeit: Das Inventar wird nie vollständig sein – und das ist in Ordnung. Wer auf Vollständigkeit wartet, wird nie fertig. Wichtiger als Perfektion ist ein belastbarer Prozess, der kontinuierlich verbessert wird. Dennoch muss die Erfassung ambitioniert sein.
  • Automatisierung: Netzwerk-Scans, TLS-Checks, Dependency-Analysen in CI/CD-Pipelines – vieles lässt sich toolgestützt erfassen. Wo Scanner nicht hinkommen (OT, Legacy, Blackbox-Appliances), braucht es halbautomatisierte oder manuelle Erfassung.
  • Standardisierung durch CBOM: Die Cryptographic Bill of Materials (CBOM) hat sich als Standardformat für kryptografische Inventare etabliert. Wer sein Inventar heute auf dem CBOM-Standard aufbaut, schafft Anschlussfähigkeit für zukünftige Automatisierung und Tool-Ökosysteme.
  • Erweiterung des bestehenden Asset-Managements: In vielen Organisationen existieren bereits CMDB- oder Asset-Management-Systeme. Die Frage ist nicht, ob man ein neues System braucht, sondern wie sich das bestehende um kryptografische Attribute erweitern lässt.
  • Dokumentation: Was nicht erfasst werden kann, muss dokumentiert werden. Wenn ein System sich einer kryptografischen Inventarisierung entzieht – etwa eine proprietäre Appliance ohne Einsicht in die verwendete Kryptografie – ist das kein Grund, es zu ignorieren. Es ist ein Grund, es als Risiko zu behandeln und den Hersteller in die Pflicht zu nehmen.

Auf Grundlage des Inventars erfolgt die Risikoanalyse. Hierbei empfiehlt sich eine Dreistufung:

KategorieBeschreibung
Akutes Risikobereits heute unsichere Kryptografie (z.B. TLS 1.0, SHA-1, RSA < 2048 Bit)sofortiger Handlungsbedarf, unabhängig von der Quantenbedrohung
Quantum-Risikoheute noch sichere Kryptografie, in Zukunft durch Quantencomputer knackbarPriorisierung über Moscas Theorem
Kein (akutes) Risikokurzlebige Daten mit niedrigem Schutzbedarf und geringer Migrationszeit

Die Ergebnisse lassen sich in einer Risiko-Heatmap verdichten, die sowohl dem operativen Team als auch dem Management als Steuerungsinstrument dient. Assets, die sich der Inventarisierung entzogen haben, sollten mindestens als PQC-Risiko eingestuft werden, denn wo Unklarheit herrscht, muss das Vorsichtsprinzip gelten.

Ein nicht zu unterschätzender Nebeneffekt: Die kryptografische Risikoanalyse fördert häufig akute Schwachstellen zutage, die mit der Quanten-Bedrohung gar nichts zu tun haben. Veraltete Protokolle, abgelaufene Zertifikate, unsichere Konfigurationen – die „Krypto-Hygiene“ ist oft der erste sogenannte No-Regret-Move.

Phase 3: Governance – Richtlinien, Prozesse, Verantwortlichkeiten

Technische Migration ohne organisatorische Verankerung ist Sisyphusarbeit. Deshalb ist die Etablierung einer kryptografischen Governance ein essenzieller Baustein – und einer, der oft unterschätzt wird. Viele Organisationen verfügen über eine Krypto-Richtlinie und seltener über ein Krypto-Konzept. Für die vorhandene Richtlinie gilt allerdings oft, dass sie seit Jahren nicht aktualisiert wurde, ausschließlich auf die ungelesene TR-02102 des BSI für Details verweist und PQC nur indirekt berücksichtigt. Eine zeitgemäße Krypto-Richtlinie muss folgende Aspekte abdecken:

  • Zuverlässige Verfahren: Klare Vorgaben für zulässige Algorithmen, Schlüssellängen und Protokolle, inklusive einer Positionierung zu PQC und hybriden Verfahren
  • Regulatorischer Bezug: Ausrichtung an einschlägigen Standards und Vorgaben (BSI TR-02102, NIST SP 800-131A, branchenspezifische Regelwerke)
  • Reaktionsfähigkeit: Finden von Antworten auf die Fragen: Was passiert, wenn morgen ein Algorithmus gebrochen wird? Wer entscheidet? In welcher Zeit? Über welche Meldewege?

Kryptografie betrifft nicht nur die IT-Abteilung. Einkaufsprozesse müssen kryptografische Anforderungen an Produkte und Dienstleister stellen. Softwareentwicklungsprozesse müssen kryptografische Prüfungen einschließen. Und im Lieferantenmanagement müssen PQC-Roadmaps eingefordert und bewertet werden, denn Ihre Krypto-Agilität ist immer nur so gut wie die Ihrer schwächsten Abhängigkeit. Wenn Ihr VPN-Anbieter, Ihr Cloud-Dienstleister oder Ihr HSM-Hersteller keine PQC-Roadmap hat, wird Ihre eigene Migration an genau dieser Stelle blockiert. Der Dialog mit dritten Parteien muss frühzeitig und strukturiert geführt werden.

Phase 4: Proof of Concept und Pilotprojekte – Kontrolliertes Lernen

Bevor eine unternehmensweite Migration beginnt, braucht es kontrollierte Erfahrungsräume. PoC- und Pilotprojekte sind keine optionale Kür, sondern eine notwendige Risikominderung.

Warum Pilotprojekte unverzichtbar sind:

  • Wissensaufbau: PQC-Algorithmen verhalten sich anders als ihre klassischen Vorgänger. Signaturgrößen von ML-DSA oder SLH-DSA sind zum Teil erheblich größer als bei RSA oder ECDSA. Schlüsselgrößen bei ML-KEM unterscheiden sich von ECDH. Dieses Wissen muss in der Organisation ankommen. Nicht nur theoretisch, sondern durch praktische Erfahrung.
  • Interoperabilitätstests: Legacy-Systeme und Middleware kommen mit größeren Schlüsseln und Signaturen nicht immer zurecht. Paketgrößen können MTU-Grenzen überschreiten, Zertifikatsketten können Parser überfordern, Handshakes können Timeouts auslösen. All das will vor dem Produktiv-Rollout entdeckt werden.
  • Hybride Verfahren validieren: Der empfohlene Migrationspfad führt über hybride Kryptografie – also die Kombination klassischer und PQC-Algorithmen. Damit bleibt die Sicherheit auch dann gewährleistet, wenn sich einer der beiden Algorithmen als schwächer herausstellt als erwartet.

Phase 5: Migration und kontinuierliche Verbesserung

Die eigentliche Migration ist kein Sprint, sondern ein priorisierter, phasenweiser Marathon. Dabei müssen Abhängigkeiten der Assets untereinander, technische Einschränkungen und Work-Arounds sowie Kritikalität berücksichtigt werden. Außerdem können PQC-Algorithmen – je nach Parametersatz – signifikant größere Schlüssel, Signaturen und Ciphertexte erzeugen. Das hat Auswirkungen auf Netzwerkbandbreite, Speicher, CPU-Last und Latenz. Eine vorgelagerte Kapazitätsplanung verhindert böse Überraschungen im Produktivbetrieb.

PQC ist komplex. Entwickelnde und Administrierende müssen verstehen, was sich ändert, warum es sich ändert und wie die neuen Algorithmen korrekt eingesetzt werden. Falsch konfigurierte PQC-Kryptografie ist nicht besser als gar keine. Schulungen sind also zu Beginn von Migrationsbestrebungen besonders sinnvoll.

Nach Abschluss der Migrationsschritte sollte der Krypto-Reifegrad erneut erhoben werden. Das macht Fortschritte sichtbar, identifiziert verbleibende Baustellen und gibt dem Management eine belastbare Grundlage für weitere Investitionsentscheidungen.

Krypto-Reifegrad: Wo stehen Sie?

Um die eigene Position auf dem Weg zur Krypto-Agilität greifbar zu machen, hat sich ein fünfstufiges Reifegradmodell bewährt:

StufeBezeichnungCharakteristik
1Ad hocKeine Sichtbarkeit über die eigene kryptografische Landschaft. Kryptografie wird reaktiv und ohne zentralen Plan implementiert. Kein Bewusstsein für PQC-Risiken.
2SensibilisiertWichtige Stakeholder sind informiert. Erste isolierte Assessments finden statt. Pläne werden entwickelt, um Erwartungen und Erkenntnisse mit relevanten Stakeholdern zu teilen.
3StrukturiertUnternehmensweite Krypto-Inventare sind erstellt. Risiko-Heatmaps und Strategiedokumente liegen vor. Tools und Ressourcen für die Migration sind identifiziert und zugewiesen.
4OperativPrinzipien der Krypto-Agilität sind in der Architektur verankert. PQC-Piloten laufen. Kryptografische Metriken werden überwacht (z. B. Alerts bei Richtlinienverstößen, Certificate-Lifecycle-Monitoring, Anomalie-Erkennung in hybriden Prozessen).
5OptimierendVollständig automatisierte Inventarisierung und Krypto-Überwachung. PQC-Rollout für Hochrisikosysteme ist abgeschlossen. Prozesse zur kontinuierlichen Verbesserung sind etabliert. Die Organisation kann schnell auf neue Standards oder Bedrohungen reagieren.

Die meisten Organisationen, mit denen wir sprechen, befinden sich derzeit irgendwo zwischen Stufe 1 und 2. Das ist keine Schande – es ist der Normalzustand. Entscheidend ist, dass der Weg nach oben jetzt beginnt.

Der nächste Schritt

Die Post-Quanten-Migration ist aktuell eine der größten Herausforderungen für die IT-Sicherheit. Sie betrifft jede Schicht des Technologie-Stacks, jede Branche und jede Organisationsgröße. Aber sie kann bewältigt werden, wenn man sie strukturiert angeht. Der beste Zeitpunkt, mit Krypto-Agilität zu beginnen, war gestern. Der zweitbeste ist heute.

Meta-Fehler bei KI-Support: Angreifer kapern Instagram-Konten über automatisierte Kontowiederherstellung

Mehrere Quellen zeichnen ein konsistentes Bild: Angreifer nutzten Ende Mai und Anfang Juni 2026 eine Schwachstelle in Metas KI-gestütztem Account-Recovery- und Support-System für Instagram aus. Im Zentrum stand das interne bzw. erweiterte Support-Werkzeug „High Touch Support“ (HTS), das laut Meta als AI-assisted account recovery system fungierte. Statt eine klassische Sicherheitslücke in der Instagram-App selbst auszunutzen, zweckentfremdeten die Täter also den automatisierten Account-Wiederherstellungsprozess des KI-Chatbots.

Laut TechCrunch und 404 Media ließen sich die Angriffe offenbar dadurch durchführen, dass Metas AI-Support-Chatbot dazu gebracht wurde, eine neue E-Mail-Adresse zu einem Zielkonto hinzuzufügen beziehungsweise den Reset-Prozess anzustoßen. BleepingComputer berichtet ergänzend, dass HTS dabei unzureichend prüfte, ob die angegebene E-Mail-Adresse tatsächlich mit dem betroffenen Instagram-Konto verknüpft war. Das Problem lag also nicht nur in fehlender Verifikation, sondern in der Automatisierung einer hochsensiblen Entscheidung, die traditionell stärker abgesichert oder menschlich geprüft würde.

Der Vorfall fällt deshalb aus der Reihe, weil er weniger ein klassischer „Exploit“ als ein Beispiel für prozessuale Sicherheitsrisiken durch KI-gestützte Support-Automation ist. Wenn ein KI-System nicht nur informiert, sondern aktiv sicherheitsrelevante Kontofunktionen wie E-Mail-Änderungen oder Passwort-Resets anstoßen kann, wird der Support-Workflow selbst zur Angriffsfläche. Genau darin liegt die eigentliche sicherheitstechnische Relevanz des Falls: Nicht die KI „hackt“ das Konto, sondern sie wird zum fehlbaren Gatekeeper in einem Identity-Recovery-Prozess. Diese letzte Einordnung ist eine Schlussfolgerung aus den berichteten Abläufen. Ein schönes Bespiel für „Excessive Agency“ aus den „OWASP Top 10 LLM“.

Die Auswirkungen waren erheblich. Laut Meta wurden mehr als 20.000 Instagram-Konten kompromittiert; erste Berichte betrafen auch prominente oder begehrte Handles. BleepingComputer beschreibt zudem, dass betroffene Nutzer teils in automatisierten Recovery-Schleifen festhingen, weil auch die Wiedererlangung des Kontos stark auf automatisierte- und KI-gestützte Prozesse setzte. Meta erklärte, das Problem sei inzwischen behoben und betroffene Konten würden abgesichert.

Der Meta/Instagram-Fall ist vor allem deshalb bemerkenswert, weil er zeigt, dass KI-unterstützte Support- und Recovery-Systeme selbst zu einem sicherheitskritischen Vertrauensanker werden können. Für IT- und Security-Teams ist das ein Warnsignal: Sobald automatisierte Assistenten in Identitäts- oder Recovery-Prozesse eingebunden werden, müssen deren Prüfmechanismen genauso streng modelliert, getestet und abgesichert werden wie klassische Authentifizierungs- und Helpdesk-Prozesse.

https://www.bleepingcomputer.com/news/security/meta-ai-support-data-breach-affects-20-000-instagram-accounts/amp

https://www.404media.co/hackers-are-using-meta-ai-to-hijack-instagram-accounts

Claude Mythos / Project Glasswing: Anthropic erweitert stark eingeschränktes Cyber-Modell auf kritische Infrastrukturen

Anthropic hat Claude Mythos Preview im April 2026 als besonders leistungsfähiges, aber nicht allgemein freigegebenes Modell für cybersicherheitsbezogene Aufgaben vorgestellt. Der Zugang erfolgt über Project Glasswing, ein Programm, in dem ausgewählte Partner das Modell für defensive Sicherheitsarbeit wie Schwachstellenanalyse und Absicherung kritischer Software einsetzen. Anthropic begründet die restriktive Freigabe ausdrücklich mit dem Missbrauchsrisiko solcher Cyber-Fähigkeiten.

Anfang Juni 2026 hat Anthropic Project Glasswing deutlich ausgeweitet: Nach Angaben des Unternehmens erhalten rund 150 weitere Organisationen in mehr als 15 Ländern Zugang, darunter Akteure aus Bereichen wie Energie, Wasser, Gesundheitswesen, Kommunikation und Hardware. Anthropic gibt an, dass jede neue Organisation vor dem Zugang zu Claude Mythos Preview interne Sicherheitsanforderungen erfüllen muss. Worin diese konkret bestehen, legt das Unternehmen jedoch nicht offen.

Für die Einordnung ist vor allem die strategische Bedeutung relevant: Anthropic beschreibt Mythos nicht als gewöhnliches Produkt-Update, sondern als Modellklasse, die die bestehenden Annahmen in der Cybersicherheit verändert. Das Unternehmen betont, dass die eigentliche Herausforderung nicht nur im Auffinden zusätzlicher Schwachstellen liegt, sondern zunehmend auch in deren Verifikation, Offenlegung und Behebung, also in den nachgelagerten Prozessen des Sicherheitsökosystems.

Die bisher kommunizierten Ergebnisse unterstreichen diesen Anspruch: Anthropic berichtet, dass die ersten Project‑Glasswing‑Partner bereits mehr als 10.000 hoch- oder kritisch eingestufte Sicherheitslücken identifiziert hätten. Fachmedien nennen dazu Beispiele einzelner Partner, bei denen die Zahl gefundener Schwachstellen deutlich gestiegen sei; diese Angaben stammen jedoch im Kern aus Unternehmens- und Partnerberichten und sind daher eher als starke Indikation denn als unabhängig auditierte Gesamtbilanz zu lesen.

Der Fall ist damit weniger wegen einer einzelnen CVE relevant als wegen der Governance-Frage, die er aufwirft: Wenn KI-Modelle sicherheitsrelevante Analyse- und Patch-Prozesse spürbar beschleunigen, werden Zugangskontrolle, Schutzmaßnahmen und verantwortliche Bereitstellung selbst zu einem sicherheitspolitischen Thema. Anthropic stellt dabei die kontrollierte Freigabe und den defensiven Einsatzzweck in den Mittelpunkt – das ist die offizielle Begründung. Aus Sicherheitssicht entsteht so aber auch ein abgestuftes Zugangsmodell: Mit dem am 9. Juni 2026 veröffentlichten Claude Fable 5 brachte Anthropic erstmals ein öffentlich verfügbares Modell seiner Mythos-Klasse auf den Markt, dessen Leitplanken Antworten in Hochrisikobereichen wie Cybersicherheit und Biologie blockieren. Konkret werden bei Fable Anfragen zu Cybersicherheit, Biologie und Chemie sowie Distillation automatisch vom schwächeren Claude Opus 4.8 beantwortet. Die ungebremste Variante ist hingegen nicht allgemein zugänglich: Dasselbe Modell ohne diese Beschränkungen ist Claude Mythos 5, das nur einer kleinen Gruppe geprüfter Kunden zur Verfügung steht – im Rahmen von Project Glasswing. Hinzu kommen Preis und Datenauflagen: Fable 5 und Mythos 5 kosten das Doppelte von Claude Opus 4.8. Anthropic koppelte an beide Modelle eine verpflichtende 30-tägige Datenspeicherung, die bestehende Zero-Retention-Vereinbarungen außer Kraft setzt. Damit verschiebt sich „Sicherheit“ tendenziell von einer Grundeigenschaft hin zu einem gestuften Leistungsmerkmal – eine Entwicklung, vor der auch Beobachter warnen: Die Vorgabe könnte einen Branchenpräzedenzfall schaffen, bei dem der Zugang zu Frontier-Modellen an eine als Sicherheitsmaßnahme gerahmte Pflichtspeicherung gekoppelt wird. Ob Anthropics gestaffeltes Modell langfristig der erklärten Mission – dem Nutzen für die Allgemeinheit – dient oder vor allem eine Gatekeeper-Position absichert, wird sich daran messen lassen müssen, wie schnell und breit die Schutzfähigkeiten tatsächlich verfügbar werden.

https://www.anthropic.com/news/expanding-project-glasswing

https://www-cdn.anthropic.com/8b8380204f74670be75e81c820ca8dda846ab289.pdf

https://www.anthropic.com/system-cards

https://coursiv.io/blog/claude-fable-5

https://yellow.com/news/claude-fable-5-free-until-june-22

https://www.cfr.org/articles/six-reasons-claude-mythos-is-an-inflection-point-for-ai-and-global-security

https://www.techradar.com/pro/security/anthropic-to-present-exposed-mythos-flaws-to-global-watchdog-claims-critical-vulnerabilities-found-in-every-major-operating-system-and-web-browser

https://www.tomshardware.com/tech-industry/artificial-intelligence/nsa-using-clause-mythos-for-offensive-cyber-operations-report-claims-says-half-a-dozen-anthropic-engineers-embedded-inside-the-agency

https://www.theneuron.ai/explainer-articles/everything-to-know-about-claude-fable-5-anthropics-new-and-first-public-release-of-its-mythos-model

Die Uhr läuft: Warum die Post-Quanten-Migration jetzt beginnen muss

Be liberal in what you accept – don’t trust anything. Das Thema Vertrauen in Netzwerken hat einen radikalen Wandel vollzogen. Wo es in den Anfangszeiten der modernen IT noch mit einer guten Portion Vertrauensvorschuss voranging, ist heute große Skepsis angebracht. Und mit Quantencomputern steht bereits der nächste Paradigmenwechsel bevor.

Vertrauen im Wandel – eine kurze Geschichte der Netzwerksicherheit

In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.” Diesen Satz formulierte Jon Postel in den Anfangstagen des Internets. Mit diesem Satz in seinem RFC 760 zum Internet-Protokoll im Jahr 1980 sollte er die Netzwerkentwicklung nachhaltig prägen. Nur ein Jahr später, im RFC 793 zur Spezifikation des TCP, erhob er diesen Gedanken explizit zum Robustheitsprinzip: „Be conservative in what you do, be liberal in what you accept from others.

Zum damaligen Zeitpunkt galt dies als pragmatische Ingenieursweisheit. Es entsprach dem Geist einer Zeit, in der das Netz eine überschaubare Gemeinschaft von Universitäten und Forschungseinrichtungen verband. Man kannte sich. Man vertraute sich. Und genau dieses Grundvertrauen wurde zum Fundament eines Netzwerks, das nie für das gebaut wurde, was es heute ist: Ein globales Netzwerk, wo die nächste Gefahr fürs eigene Netzwerksegment nur einen Hop entfernt ist.

Als das Internet in den 1990er-Jahren seinen Weg in Unternehmen fand, wurde schnell klar, dass Postels großzügiges Prinzip allein nicht ausreichen würde. Nicht jeder Teilnehmende im Netz hatte gute Absichten. Die Antwort der IT-Sicherheit folgte einer Logik, die so alt ist wie die Zivilisation selbst: Man baute eine Mauer. Das Modell des Perimeterschutzes war geboren – eine klare Grenze zwischen Innen und Außen. Firewalls filterten den Datenverkehr an den Toren. Was innerhalb der Mauern lag, galt als vertrauenswürdig. Postels Prinzip der Großzügigkeit lebte dort weiter – aber nur noch im geschützten Inneren.

Doch Mauern haben ein grundsätzliches Problem: Sie schützen nur, solange niemand sie überwindet. Wer einmal drinnen ist – ob berechtigt oder nicht – genießt volles Vertrauen. Und die Welt jenseits der Mauern wurde größer, feindseliger, unübersichtlicher.

Parallel dazu reiften kryptografische Verfahren heran, die eine fundamental andere Art von Vertrauen ermöglichten: nicht mehr Vertrauen durch Zugehörigkeit zu einem Netzwerk, sondern Vertrauen durch mathematisch überprüfbare Identität. SSL und sein Nachfolger TLS sicherten die Kommunikation zwischen Endpunkten. VPNs schufen verschlüsselte Tunnel zwischen perimetergeschützten Umgebungen über unsicheres Terrain. Public-Key-Infrastrukturen etablierten Vertrauensketten, die an keine physische Netzwerkgrenze gebunden waren. Was als Ergänzung zum Perimeterschutz begann, wurde zunehmend zu einer eigenständigen Sicherheitsschicht – und schließlich zu einer Alternative.

Nach der Jahrtausendwende formulierte John Kindervag bei Forrester Research im Jahr 2010 den konsequenten Schluss aus dieser Entwicklung: Zero Trust. Das Prinzip ist in seiner Radikalität bemerkenswert einfach: Vertraue niemandem. Verifiziere immer alles.  Kein Netzwerkstandort, keine IP-Adresse, keine Firewall-Regel gewährt Vertrauen – nur die kryptografisch gesicherte, kontinuierlich überprüfte Identität eines Akteurs und der Kontext seiner Anfrage.

Zero Trust ist damit nicht nur eine technische Architektur. Es ist die konsequente Umkehrung von Postels Erbe. Wo das Robustheitsprinzip noch sagte “Sei großzügig in dem, was du akzeptierst”, antwortet Zero Trust “Akzeptiere nichts, was sich nicht zweifelsfrei ausweisen kann”. Aus implizitem Vertrauen wurde explizite Verifikation. Was einst als Tugend galt – Offenheit, Toleranz gegenüber dem Unbekannten – wurde in einer feindlichen Umgebung zur Schwachstelle.

Die Geschichte der Netzwerksicherheit ist damit auch eine Geschichte darüber, wie sich der Begriff des Vertrauens selbst gewandelt hat: vom sozialen Grundkonsens einer akademischen Gemeinschaft über die territoriale Logik befestigter Grenzen hin zu einem System, in dem Vertrauen nicht vorausgesetzt, sondern in jedem einzelnen Moment mathematisch bewiesen werden muss. Postel entwarf sein Prinzip für eine Welt, in der guter Wille die Regel war. Zero Trust wurde für eine Welt gebaut, in der man sich diesen guten Willen nicht mehr leisten kann.

Die vier Bedrohungsachsen der Kryptografie

Heute ist die Netzwerksicherheit fundamental von der Sicherheit der eingesetzten kryptografischen Verfahren abhängig. Diese Verfahren sehen sich vier zentralen Bedrohungsachsen ausgesetzt:

  1. Kontinuierliche Steigerung der Rechenleistung – was heute als sicher parametrisiert gilt, kann morgen durch brute-force-fähige Hardware fallen.
  2. Protokoll- und Implementierungsfehler – von Heartbleed (CVE-2014-0160) über ROBOT (CVE-2017-17382, CVE-2017-6168) bis hin zu Timing-Seitenkanalangriffen. Die Lücke liegt oft nicht im Algorithmus, sondern im Code.
  3. Mathematische Fortschritte – neue analytische Methoden können die effektive Sicherheit eines Verfahrens über Nacht reduzieren, wie zuletzt die Diskussionen um Angriffe auf gitterbasierte Verfahren zeigten.
  4. Quantencomputer – ein kryptografisch relevanter Quantencomputer (CRQC) würde RSA, ECDSA und Diffie-Hellman mittels Shors Algorithmus in polynomialer Zeit brechen.

Die strategische Antwort auf diese Bedrohungen trägt einen Namen: Kryptoagilität – die architektonische Fähigkeit, kryptografische Verfahren in bestehenden Systemen zügig und ohne disruptive Umbaumaßnahmen austauschen zu können (vgl. Fraunhofer SIT: Kryptoagilität). Kryptoagilität ist keine Option mehr. Sie ist eine Überlebensfähigkeit.

Die Quantenbedrohung: Näher als viele glauben

Lange Zeit galt ein kryptografisch relevanter Quantencomputer (CRQC) als akademische Spekulation. Doch die Faktenlage hat sich verdichtet:

  • 2015 veröffentlichte Prof. Michele Mosca, Mitgründer des Institute for Quantum Computing an der University of Waterloo, eine vielbeachtete Risikoabschätzung: Die Wahrscheinlichkeit, dass die heute eingesetzte Public-Key-Kryptografie durch einen Quantencomputer gebrochen wird, liege bei ca. 14 % bis 2026 und bei 50 % bis 2031 (Mosca 2015, eprint.iacr.org/2015/1075).
  • 2016 rief das NIST den Standardisierungsprozess für Post-Quantum Cryptography (PQC) ins Leben. In der Begründung (NIST IR 8105) hieß es unmissverständlich: Ein CRQC könne innerhalb von ein bis zwei Jahrzehnten zur realen Bedrohung werden.
  • August 2024 veröffentlichte das NIST die finalen PQC-Standards: FIPS 203 (ML-KEM, basierend auf CRYSTALS-Kyber), FIPS 204 (ML-DSA, basierend auf CRYSTALS-Dilithium) und FIPS 205 (SLH-DSA, basierend auf SPHINCS+). Der Werkzeugkasten für die Post-Quanten-Ära existiert. Die Standards sind da.
  • 2025 und darüber hinaus setzt sich die Standardisierungsdynamik fort: Mit FIPS 206 (FN-DSA, basierend auf FALCON) steht ein weiterer NIST-Standard für digitale Signaturen kurz vor der Veröffentlichung – ein Verfahren, das insbesondere durch kompakte Signaturen bei gleichzeitig moderaten Schlüsselgrößen besticht. Parallel dazu treibt die ISO die Standardisierung zweier Verfahren voran, die bewusst auf konservativere – und damit besser verstandene – mathematische Grundlagen setzen: FrodoKEM, dessen Sicherheit auf dem allgemeinen Learning-with-Errors-Problem (LWE) ohne Gitterstruktur basiert, sowie Classic McEliece, ein codebasiertes Verfahren mit über 40 Jahren kryptoanalytischer Resistenz (vgl. BSI TR-02102-1, Kryptografische Verfahren: Empfehlungen und Schlüssellängen, Version 2026-01, Abschnitte 2.4.1 & 2.4.2). Damit zeichnet sich ein diversifiziertes PQC-Ökosystem ab – eines, das nicht von einer einzelnen mathematischen Annahme abhängt und der Forderung nach Kryptoagilität auch auf Verfahrensebene Rechnung trägt.

Ein bemerkenswertes Detail verdient besondere Aufmerksamkeit: Anders als bei der Kernfusion, die stets „in 50 Jahren“ einsatzbereit sein soll – egal, wann man fragt –, hat sich die Einschätzung der Krypto-Community zum Zeithorizont eines CRQC über das letzte Jahrzehnt nicht nach hinten verschoben. Die Prognosen konvergieren beständig auf den Zeitraum 2030 bis 2035. Das ist keine vage Zukunft. Das ist dieses Jahrzehnt.

Harvest Now, Decrypt Later – die Bedrohung von heute

Die Quantenbedrohung ist keine Zukunftsmusik – sie materialisiert sich bereits. Unter dem Paradigma „Harvest now, decrypt later“ (HNDL) werden heute verschlüsselt übertragene Daten von staatlichen Akteuren und nachrichtendienstlichen Einheiten systematisch abgefangen und gespeichert, um sie zu einem späteren Zeitpunkt mit einem CRQC zu entschlüsseln.

Betroffen sind alle Daten, deren Vertraulichkeit über den Zeitpunkt der Übertragung hinaus Bestand haben muss: Staatsgeheimnisse, medizinische Daten, Geschäftsgeheimnisse, Verhandlungspositionen, Quellenschutz. Wer heute verschlüsselt kommuniziert, aber klassische Verfahren nutzt, gewährt retrospektive Einsicht, sobald ein CRQC verfügbar ist.

Die Bedrohung durch Quantencomputer ist daher nicht erst in zehn Jahren relevant. Sie ist es bereits jetzt.

Moscas Ungleichung: Warum die Schere bereits aufgegangen ist

Die eigentliche Eskalation liegt nicht im Quantencomputer selbst – sie liegt in der Asymmetrie zwischen Angriffs- und Verteidigungstempo.

Filippo Valsorda, einer der profiliertesten Stimmen im Bereich angewandter Kryptografie, hat diese Dynamik in einer vielbeachteten Analyse (words.filippo.io/crqc-timeline) auf den Punkt gebracht: Mit jedem Durchbruch in der Quantenfehlerkorrektur komprimiert sich die prognostizierte Zeitlinie für einen CRQC, während sich gleichzeitig die für eine vollständige kryptografische Migration benötigte Zeit als erschreckend lang erweist.

Das formalisiert Moscas Ungleichung:

x + y < z

x = benötigte Migrationszeit, y = geforderte Schutzfrist der Daten, z = verbleibende Zeit bis zum CRQC

Sobald x + y > z (die Summe aus Migrationszeit und Schutzbedarf die verbleibende Zeit bis zum CRQC übersteigt) ist das Zeitfenster für eine rechtzeitige Absicherung unwiderruflich geschlossen. Jeder Tag ohne begonnene Migration ist ein Tag, an dem die Schere weiter aufgeht. Es gibt keinen Weg, verlorene Zeit zurückzugewinnen.

Die konvergierenden Signale sind eindeutig: Google demonstrierte im Dezember 2024 mit dem Quantenprozessor Willow erstmals eine skalierende Quantenfehlerkorrektur unterhalb der Fehlerschwelle, wie sie seit den 1990er‑Jahren theoretisch vorhergesagt wurde. Die Ergebnisse, veröffentlicht in der wissenschaftlichen Fachzeitschrift Nature, zeigen, dass logische Qubits mit wachsender Größe exponentiell zuverlässiger werden. Ein Durchbruch, der Quantencomputing von einem physikalischen Experiment zu einer ingenieurtechnisch beherrschbaren Technologie und damit das Narrativ „Quantencomputer sind noch Jahrzehnte entfernt“ endgültig obsolet macht.

IBM, Google und Microsoft haben in den Jahren 2024–2025 konsistente Roadmaps veröffentlicht, die jeweils explizit auf fehlerkorrigierte (fault‑tolerante) Quantensysteme abzielen (Roadmap IBM, Roadmap Google, Roadmap Microsoft). Obwohl sie unterschiedliche Hardware‑Ansätze verfolgen, konvergieren ihre Zeitpläne auf die späten 2020er Jahre, mit ersten großskaligen, logisch geschützten Quantensystemen bis zum Ende dieses Jahrzehnts.

Nationale Sicherheitsbehörden gehen heute explizit davon aus, dass staatliche Akteure bereits verschlüsselten Datenverkehr massenhaft erfassen und langfristig speichern, um ihn mit zukünftigen kryptografischen Durchbrüchen – insbesondere durch Quantencomputer – nachträglich zu entschlüsseln. Dieses bereits weiter oben benannte Vorgehen ist als Harvest Now, Decrypt Later (HNDL) bekannt und wird in aktuellen Regierungs‑, Industrie‑ und Aufsichtsberichten als gegenwärtige, operative Realität beschrieben (stateofsurveillance.org, federalreserve.gov).

Damit hat sich die zentrale Frage verschoben: Es geht nicht mehr darum, ob die heutige Public-Key-Kryptografie fällt, sondern ob unsere Infrastrukturen schnell genug umgerüstet sein werden, wenn es so weit ist.

Was jetzt zu tun ist

Das klingt düster, ist aber kein Grund zur Resignation. Es ist ein Grund zum Handeln. Der Werkzeugkasten existiert. Die Standards sind verabschiedet. Die Migrationspfade werden klarer. Was fehlt, ist nicht Technologie. Was fehlt, ist Entschlossenheit und begonnene Arbeit.

Fünf Schritte, die Sie diese Woche anstoßen können:

  1. Kryptografisches Inventar erstellen: Sie können nicht migrieren, was Sie nicht kennen. Erfassen Sie systematisch, wo in Ihrer Infrastruktur welche kryptografischen Verfahren im Einsatz sind – von TLS-Konfigurationen über VPN-Tunnel bis hin zu Signaturverfahren in CI/CD-Pipelines und Firmware-Updates. Das BSI bezeichnet diesen Schritt als unverzichtbare Grundlage jeder Migrationsstrategie.
  2. Daten nach Schutzfrist klassifizieren: Nicht alle Daten sind gleich betroffen. Identifizieren Sie Assets, deren Vertraulichkeit oder Integrität über 2030 hinaus gewährleistet sein muss. Diese Daten stehen unter akuter HNDL-Bedrohung und erfordern priorisierte Migration.
  3. Kryptoagilität architektonisch verankern: Kryptografische Verfahren dürfen nicht hart in Anwendungen und Protokolle eingebrannt sein. Abstraktionsschichten, konfigurierbare Cipher-Suites und modulare Kryptobibliotheken sind die Voraussetzung dafür, dass die PQC-Migration nicht zum Großprojekt mit Zeithorizont 2035 wird.
  4. Hybride Ansätze jetzt evaluieren und pilotieren: Die NIST-Standards (ML-KEM, ML-DSA, SLH-DSA) sind final. Große Anbieter wie Cloudflare, Google und Signal setzen bereits hybride Verfahren (klassisch + PQC) in Produktion ein. Pilotieren Sie hybride TLS-Konfigurationen und Key-Encapsulation in Ihren kritischsten Kommunikationskanälen.
  5. Migration als strategisches Programm aufsetzen – nicht als Technikprojekt: Selbst bei guter Kryptoagilität bleibt die PQC-Migration mehr als ein Algorithmentausch. Sie betrifft Procurement-Anforderungen, Compliance-Nachweise, Partnerkommunikation, Zertifikats-Lifecycles und Legacy-Systeme, die sich nicht per Konfigurationsänderung umstellen lassen. Diese organisatorische Breite erfordert ein Mandat auf Leitungsebene, ein dediziertes Budget und einen realistischen, aber ambitionierten Zeitplan. Kryptoagilität verkürzt die technische Migrationszeit erheblich. Aber nur ein strategisches Programm stellt sicher, dass auch alles drumherum rechtzeitig mitkommt.

Moscas Ungleichung ist keine Abstraktion. Sie ist eine Stoppuhr – und sie läuft. Jeder Tag, an dem Ihre Organisation die Post-Quanten-Migration nicht aktiv vorantreibt, ist ein Tag, an dem sich das Zeitfenster für eine geordnete Transition weiter schließt. Die gute Nachricht: Wer heute beginnt, hat noch die Chance, vor der Kurve zu sein statt hinter ihr. Die Standards stehen. Die Werkzeuge reifen. Die Early Movers haben angefangen.

Die Frage ist nicht mehr, ob Sie migrieren müssen. Die Frage ist, ob Sie es rechtzeitig tun.

Fangen Sie an. Heute.

Copy Fail, Dirty Frag, Dirty Pipe – Warum SELinux Ihr bester Schutz gegen Local Privilege Escalation ist

Copy Fail, Dirty Frag, Dirty Pipe: Unterschiedliche Exploits mit dem gleichen Ziel: Local Privilege Escalation (LPE). Diese Klasse von Verwundbarkeiten ist häufig anzutreffen. Wenngleich sie nicht so problematisch wie Remote Code Execution (RCE)-Schwachstellen sind, ermöglichen sie Angreifenden durch die Erhöhung der Rechte weitere Möglichkeiten zur Ausbreitung und zur Ausführung von Schadsoftware. Daraus lassen sich nun, je nach Bedarf, unterschiedliche Blickwinkel betrachten. Wir könnten technisch auf die Verwundbarkeiten eingehen und sie beschreiben. Auch spannend ist die Methodik der Sicherheitsforschenden, und ob und wie „künstliche Intelligenz“ dafür eingesetzt wurde. Oder wir könnten Unterschiede zu anderen Schwachstellen dieser Art hervorheben.

Aber in diesem Digest (und in unserer täglichen Arbeit) sind wir pragmatischer und stellen uns die Frage: Wie geht man mit diesen Schwachstellen um? Die Ausnutzung von Schwachstellen ist – außer bei bewusst implementierten Backdoors – auf die Existenz von Defekten angewiesen, sogenannten Bugs. Die Sicherheit eines Systems ist daher darauf angewiesen, dass alle Bestandteile von Hardwarelogik bis Applikation „korrekt“ funktionieren. Eine Möglichkeit, Fehler aufzufangen, ist die Verwendung von Mandatory Access Control (MAC) in Form der SELinux-Erweiterung. Dadurch können Policies festgelegt werden, die den Zugriff auf Dateien und Systemkomponenten festlegen. In dieser Konstellation reicht dann die Korrektheit der eingestellten Policies (und der SELinux-Implementierung), um einen sicheren Betrieb des Systems zu ermöglichen. Ein praktisches Beispiel bietet ein Blick auf Mobil-Betriebssysteme. GrapheneOS hat dazu einige erläuternde Hinweise.

Aus unserer Sicht unterstützen die Lücken unsere in einem vorherigen Digest formulierte Erwartung, dass sich das Security-Modell im Desktop- und Serverbereich sukzessive an das aus dem Mobilbereich anpassen wird. Auch wenn das Thema SELinux eher in den Aufgabenbereich der eingesetzten Distribution fällt, können Sie durch kleine Konfigurationen viel Angriffsoberfläche reduzieren. Sprechen Sie uns gerne an, wenn wir Sie dabei unterstützen können.

https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux

https://en.wikipedia.org/wiki/SELinux

https://copy.fail

https://github.com/V4bel/dirtyfrag

https://infosec.exchange/@jrt/116537982697417546