Die indische Computer-Notfallreaktionseinheit (CERT-In) hat das 38-seitige Leitdokument CISG-2026-02 veröffentlicht, das strikte Fristen für die Behebung von Schwachstellen festlegt: Bekannt ausgenutzte Schwachstellen in Systemen mit Internetzugang müssen, wo dies umsetzbar ist, innerhalb von 12 Stunden geschlossen werden. Das Dokument ist direkt motiviert durch die zunehmenden Bedrohungen infolge der Nutzung von KI-Werkzeugen und großen Sprachmodellen durch Angreifer, um das Auffinden und Ausnutzen von Schwachstellen zu automatisieren. Die Leitlinie betrifft alle Organisationen, die von Cloud-Infrastruktur, Software-Lieferketten, Operational Technology und KI-basierten Plattformen abhängig sind.
Schlüsselanforderungen zu Behebungsfristen
CERT-In führt ein gestuftes System von Patch-Fristen ein, das auf einer Risikobewertung basiert. Es gehört zu den aggressivsten Modellen für Schwachstellenmanagement unter den nationalen CERT-Teams:
- Bekannt ausgenutzte Schwachstellen in Systemen mit Internetzugang und in kritischen Systemen – 12 Stunden (wo umsetzbar)
- Kritische Schwachstellen in externen Systemen – 1 Tag
- Bekannt ausgenutzte Schwachstellen in internen Systemen – 1 Tag (sofern keine alternativen Minderungsmaßnahmen dokumentiert sind)
- Kritische interne Schwachstellen in besonders schützenswerten Systemen – 3 Tage
- Schwachstellen mit hohem Schweregrad – 5 Tage auf Basis einer risikoorientierten Priorisierung
Wenn kein Patch verfügbar ist, empfiehlt CERT-In den Einsatz temporärer Maßnahmen: Isolierung betroffener Systeme, Zugriffsbeschränkungen, Absicherung über WAF und API-Gateways, verstärktes Monitoring oder Deaktivierung der verwundbaren Funktionalität bis zur Bereitstellung eines Fixes.
Warum genau 12 Stunden: der KI-Beschleunigungsfaktor bei Angriffen
Die Begründung für derart knappe Fristen ist eine direkte Folge der Einschätzung von CERT-In zur Auswirkung von KI auf die Bedrohungslandschaft. Laut Leitlinie „verkürzen KI-gestützte Cyberangriffe die Zeit, die Angreifer benötigen, um Schwachstellen, offene Dienste, schwache Zugangsdaten, unsichere APIs und fehlerhaft konfigurierte Systeme zu entdecken, zu bewaffnen und auszunutzen“.
CERT-In hebt mehrere Einsatzfelder von KI durch Angreifer hervor: Aufklärung der Angriffsoberfläche, Exploit-Analyse, Generierung überzeugender Phishing-Inhalte und Erstellung von Malware. Diese Fähigkeiten verkürzen Berichten zufolge die Vorbereitungszeit für Angriffe erheblich und erleichtern die Umgehung traditioneller Schutzmechanismen. Konkrete quantitative Daten zum Umfang einer solchen Nutzung werden in der Leitlinie nicht genannt – es geht um einen Trend, den CERT-In als ausreichend ausgereift für eine regulatorische Antwort einstuft.
Ein eigener Abschnitt der Leitlinie ist den Risiken für die KI-Systeme selbst gewidmet. CERT-In warnt vor Bedrohungen durch Prompt-Injection, Datenabflüsse, Jailbreaks von Modellen, Manipulation von Modellen, Vergiftung von Trainingsdaten, Diebstahl von Modellen und Kompromittierung von Orchestrierungs-Pipelines.
Schutzprinzipien und architektonische Anforderungen
Die Leitlinie formuliert eine umfassende Schutzstrategie, die weit über reines Patch-Management hinausgeht:
- Ausgehen von Kompromittierung (assume breach) – Vorbereitung auf schnelle Erkennung, Eindämmung und Wiederherstellung
- Zero-Trust-Architektur (Zero Trust) – kontinuierliche Verifikation und minimale Privilegien
- Mehrschichtige Verteidigung (defense-in-depth) – mehrstufige Kontrollen zur Vermeidung einzelner Ausfallpunkte
- Security by Design (secure-by-design) – Einbettung von Sicherheit in Systeme, Anwendungen und KI-Workflows
- Risikomanagement in der Lieferkette – über SBOM, Validierung der Herkunft von Komponenten und Bewertung von Abhängigkeiten, einschließlich KI-Modellen
- Formale Governance von KI-Systemen – Etablierung von Kontrollmechanismen für den Einsatz von KI und Sicherstellung der Transparenz ihrer Integrationen und ihres Verhaltens
CERT-In drängt außerdem auf eine regelmäßige Überprüfung der Wirksamkeit der Schutzmaßnahmen durch Penetrationstests, Schwachstellenbewertungen, Red-Team-Übungen und unabhängige Audits.
Kontext: Vorangegangene Warnung zu Frontier-KI-Modellen
Die Leitlinie erschien einen Monat, nachdem CERT-In eine separate Warnung CIAD-2026-0020 zu den Cyberfähigkeiten von Frontier-KI-Modellen von Anthropic und OpenAI veröffentlicht hatte. In diesem Dokument wurde betont, dass die „doppelte Natur“ dieser Modelle die Einstiegshürde für Angreifer senken und „zur Beschleunigung der Durchführung von Angriffen, zur Automatisierung von Exploit-Workflows und zur Skalierung von Cyberkampagnen“ genutzt werden kann. Die neue Leitlinie ist somit eine logische Fortsetzung der systematischen Arbeit von CERT-In, den regulatorischen Rahmen an die Realität KI-gestützter Bedrohungen anzupassen.
Praktische Empfehlungen
Für Organisationen, die unter die Leitlinie von CERT-In fallen, sind die folgenden Schritte prioritär:
- Audit von Systemen mit Internetzugang durchführen und diese mit Katalogen bekannt ausgenutzter Schwachstellen abgleichen. Sicherstellen, dass Notfall-Patching innerhalb von 12 Stunden möglich ist.
- Kontinuierliches Schwachstellenmanagement einführen, das nicht nur Softwarefehler, sondern auch Konfigurationsfehler, unsichere APIs, öffentlich erreichbare Dienste und schwache Zugangsdaten abdeckt.
- Verfahren für temporäre Minderung entwickeln für Situationen, in denen kein Patch verfügbar ist: WAF-Regelvorlagen, Isolationsszenarien, Verfahren zur Deaktivierung von Funktionalität.
- KI-spezifische Risiken bewerten – eingesetzte Modelle inventarisieren, Schutz vor Prompt-Injection und Datenabflüssen prüfen, Kontrolle der Lieferkette von KI-Komponenten sicherstellen.
- KI-Governance formalisieren – Richtlinien für die Nutzung von KI-Systemen dokumentieren und das Monitoring ihrer Integrationen gewährleisten.
Die Leitlinie von CERT-In setzt einen Maßstab, der voraussichtlich auch die regulatorischen Erwartungen in anderen Jurisdiktionen beeinflussen wird. Organisationen sollten bereits jetzt ihre Fähigkeit bewerten, einen 12-Stunden-Patch-Zyklus für kritische Schwachstellen einzuhalten – und, falls dies mit den aktuellen Prozessen nicht möglich ist, mit der Automatisierung der Schwachstellenerkennung und der Verteilung von Fixes auf Systeme mit externem Zugriff beginnen.
