AbwehrKI verteidigt und greift an.
KI ist Werkzeug der Verteidigung und der Angreifer zugleich. Der Leitfaden zeigt, wo KI im SOC und im Schwachstellenmanagement hilft, nach welchen Kriterien sie eingeführt wird, welche KI-gestützten Angriffe einzuplanen sind und was gegen Deepfake-Betrug wirkt.
Rechtsstand: 12. Oktober 2026. Die Bewertungskriterien sind fachliche Empfehlungen von STOP.LI, keine Vorgabe eines Regelwerks.
Wo KI in der
Abwehr hilft.
KI unterstützt Analysten, sie ersetzt keine Entscheide. Der Nutzen liegt dort, wo viel Text oder viele Ereignisse verdichtet werden müssen und ein Mensch das Ergebnis prüfen kann. Die Tabelle ordnet typische Einsatzfelder nach Wirkung und Risiko.
| Einsatzfeld | Nutzen | Hauptrisiko | Empfohlener Betrieb |
|---|---|---|---|
| Triage von Alarmen im SIEM | Gruppieren, Anreichern, Priorisieren | Echte Alarme werden fälschlich als harmlos eingestuft | KI schlägt vor; Stichproben der als harmlos eingestuften Alarme |
| Zusammenfassen von Vorfällen und Protokollen | Schnellerer Überblick, Übergaben, Berichte | Erfundene oder weggelassene Details | Zusammenfassung mit Verweis auf Rohdaten; Analyst prüft vor Weitergabe |
| Erstellen von Suchabfragen und Detection-Regeln | Schnellere Jagd und Regelentwurf | Fehlerhafte Abfragen, zu breite Regeln | Entwurf, Test an Referenzdaten, Freigabe im Änderungsprozess |
| Analyse von Schadcode und Skripten | Erste Einordnung unbekannter Dateien | Falsche Einordnung; Abfluss von Proben an Dritte | Nur in freigegebener Umgebung; Ergebnis als Hinweis, nicht als Befund |
| Priorisierung im Schwachstellenmanagement | Einordnen nach Ausnutzbarkeit und Systemrolle | Intransparente Gewichtung; blinde Flecken | KI-Wert neben nachvollziehbaren Kriterien führen, nicht an deren Stelle |
| Vorschläge für Gegenmassnahmen und Playbooks im SOAR | Kürzere Reaktionszeit | Fehlentscheid mit Wirkung auf Produktion | Automatisch nur reversible Schritte mit kleinem Schaden; sonst Freigabe |
| Erkennung von Anomalien und Phishing, Security Analytics, E-Mail Security | Muster, die Regeln nicht abdecken | Falschalarme; Umgehung durch Angreifer | Kennzahlen zu Treffer- und Fehlerquote; regelmässig mit Tests prüfen |
Setzt das SOC einen KI-Assistenten ein, ist er ein KI-System wie jedes andere: Er gehört ins Inventar, unter die Nutzungsrichtlinie und in die Risikobeurteilung.
Vier Kriterien
vor dem Einsatz.
Ein Assistent im SOC sieht die sensibelsten Daten der Organisation: Protokolle, Zugangsdaten, Vorfälle, Kundendaten. Vor der Einführung müssen vier Kriterien erfüllt sein.
Welche Daten gehen an das Modell, wo werden sie verarbeitet, wie lange gespeichert, werden sie zum Training verwendet? Sicherheitsdaten enthalten oft Personendaten und Geheimnisse. Daten vor der Übergabe maskieren, Verarbeitungsort und Aufbewahrung vertraglich regeln, siehe Datenkontrollen und Lieferanten und Modelle.
Modelle können überzeugend formulierte, falsche Inhalte erzeugen. Das NIST Generative AI Profile (AI 600-1) führt dies als Risiko «Confabulation»; die OWASP-Liste 2026 für LLM-Anwendungen nennt es «Misinformation». Folge für die Abwehr: Jede Aussage über Vorfall, Ursache oder Betroffene braucht einen Beleg in den Rohdaten.
Der Analyst muss sehen, auf welche Quellen sich eine Antwort stützt, und sie wiederholen können. Eingaben, Ausgaben, Modell- und Promptversion protokollieren, damit Entscheide später prüfbar sind, etwa im Post-Incident Review. Ohne Belege ist ein Befund kein Befund.
Ein Assistent mit Schreibzugriff auf Firewall, Identitätsverwaltung oder Endgeräte ist ein Angriffsziel. OWASP führt übermässige Handlungsbefugnis als «Excessive Agency». Eigene Identität, minimale Rechte, Freigabe vor jeder nicht umkehrbaren Aktion; Details in Agenten und MCP.
Ein weiteres Risiko liegt im Inhalt, den der Assistent liest. Protokolle, E-Mails und Webseiten können Anweisungen enthalten, die das Modell befolgt (indirekte Prompt Injection, ATLAS AML.T0051.001). Ein Angreifer kann so den Assistenten gegen das SOC wenden. Lesende und handelnde Funktionen deshalb trennen.
| Stufe | Was der Assistent darf | Bedingung |
|---|---|---|
| 1 Vorschlag | Lesen, zusammenfassen, Hypothesen nennen | Nur freigegebene Datenquellen; Belege sichtbar |
| 2 Entwurf | Regeln, Abfragen, Tickets, Berichte vorbereiten | Mensch gibt jede Übernahme frei |
| 3 Aktion mit Freigabe | Massnahmen ausführen, nachdem ein Mensch bestätigt hat | Rollback möglich; Protokoll der Freigabe |
| 4 Autonome Aktion | Reversible Schritte mit kleinem Schaden, etwa ein Konto vorübergehend sperren | Schwellen schriftlich, Abschaltschalter, laufende Stichproben |
Die Stufen sind eine Empfehlung von STOP.LI. Ein Einsatz beginnt auf Stufe 1 und steigt nur mit gemessener Fehlerquote.
KI-gestützte
Angriffe einplanen.
Das britische NCSC hielt im Januar 2024 fest, dass KI Umfang und Wirkung von Cyberangriffen in den folgenden zwei Jahren mit an Sicherheit grenzender Wahrscheinlichkeit erhöht. KI bringe für Aufklärung und Social Engineering einen Fähigkeitsgewinn und senke die Einstiegshürde für unerfahrene Täter. Die Lagebeurteilung vom Mai 2025 erwartet die bedeutsamste Entwicklung sehr wahrscheinlich bei KI-gestützter Schwachstellensuche und Exploit-Entwicklung und rechnet bis 2027 mehr Angriffe auf ungepatchte Systeme. Die ENISA hält in ihrer Lagebeurteilung 2025 fest, dass Angreifer Sprachmodelle einsetzen, um Phishing zu verbessern und Social Engineering zu automatisieren.
| Angriff | Was sich ändert | ATLAS | Abwehr |
|---|---|---|---|
| Phishing und Spearphishing | Fehlerfreie, auf das Opfer zugeschnittene Texte in jeder Sprache; Rechtschreibfehler taugen nicht mehr als Merkmal | AML.T0052.000 | Authentisierung, die nicht auf Wachsamkeit beruht (Phishing-resistente Verfahren); Mailfilter; Meldeweg |
| Deepfake-Betrug | Gefälschte Stimme oder gefälschtes Video von Vorgesetzten, Lieferanten, Kunden | AML.T0052.001, AML.T0088 | Rückruf, Vier-Augen-Prinzip, Codewort; siehe unten |
| Aufklärung | Schnelles Auswerten öffentlicher Daten und erbeuteter Dokumente | AML.T0116 | Kleine Angriffsfläche, Datensparsamkeit, Überwachung von Zugriffen |
| Automatisierte Angriffsketten | Agenten kombinieren Aufklärung, Zugang und Datenabfluss in kürzerer Zeit | AML.T0124 | Segmentierung, Rechte nach Minimalprinzip, schnelle Eindämmung |
| Ausnutzen bekannter Schwachstellen | Zeit zwischen Offenlegung und Ausnutzung wird kürzer | – | Patch- und Notfallprozess nach Risiko, nicht nach Zyklus |
Die ATLAS-Technik-IDs stammen aus dem Datenstand v2026.09. Die vollständige Zuordnung steht in der Bedrohungslandschaft. NCSC und ENISA beschreiben Tendenzen; sie liefern keine Zahlen für einzelne Organisationen. Die Einschätzung der Eintrittswahrscheinlichkeit gehört in die Risikobeurteilung.
Schneller
eindämmen.
Wenn Aufklärung, Zugang und Ausnutzung schneller aufeinander folgen, schrumpft das Zeitfenster für die Abwehr. Der SIGNAL-Beitrag Sechs Stunden: Wann Incident Response zu langsam ist beschreibt eine agentengestützte Kampagne, die nach der Kompromittierung einer Cloud-Ressource in weniger als sechs Stunden geplant, gebaut und ausgeführt wurde. Ein Einzelfall belegt keinen Trend, zeigt aber, welche Zeiten ein Plan prüfen sollte.
- Zeiten messen: von der Entdeckung bis zur Eindämmung, nicht nur bis zum Ticket.
- Vorab freigeben: Konten sperren, Sitzungen beenden, Systeme isolieren, ohne Rückfrage bei klar definierten Auslösern, aber mit Schutzgrenzen (siehe nächster Abschnitt).
- Erreichbarkeit: Entscheidungsträger ausserhalb der Bürozeiten bestimmen.
- Patchen nach Risiko: öffentlich bekannte, ausgenutzte Schwachstellen mit Vorrang und eigener Frist.
- Üben: Szenarien mit hoher Geschwindigkeit in Übungen aufnehmen; Playbooks siehe Monitoring und Incident Response.
Die Abwehr als
Angriffsziel.
Automatisierte Abwehr hat eine Schwäche: Wer ihre Eingaben kontrolliert, kontrolliert ihre Reaktion. Erzeugt ein Angreifer gezielt Signale, kann die Abwehr legitime Dienste, Konten, Adressen oder Netzsegmente selbst sperren oder isolieren. Das ist ein selbst verursachter Denial of Service: Der Schaden entsteht durch die Reaktion, nicht durch den Angriff. Dazu kommt die Überlastung der KI-Analyse durch Alarmflut und Kosten. Die Szenarien unten leiten sich aus den genannten Quellen ab. Dokumentierte Vorfälle dieser Art behauptet diese Seite nicht.
| Angriff auf die Abwehr | Mögliche Folge | Beleg |
|---|---|---|
| Gefälschte Indikatoren, manipulierte Telemetrie, vergiftete Threat-Intel-Feeds | Legitime Adressen, Konten oder Dienste gelten als bösartig; automatische Sperre | OWASP Agentic Top 10 (ASI08, Szenario 8): eingeschleuster Fehlalarm führt zu Abschaltungen, Sperren und Netztrennungen. ATLAS AML.T0059 Erode Dataset Integrity. NIST AI 100-2 E2025, Abschn. 2.3.1: Vergiftung von Spam-Klassifikatoren erhöhte die Rate falsch-positiver Treffer |
| Adversariale Eingaben gegen Klassifikatoren | Fehlklassifikation: Schadhaftes wird übersehen, Harmloses wird blockiert | ATLAS AML.T0015 Evade AI Model, AML.T0043 Craft Adversarial Data (Fehlklassifikation, übersehene Erkennungen) |
| Alarmflut mit Füllmaterial | Analysten und Freigabeschleifen werden überlastet; echte Befunde gehen unter | ATLAS AML.T0046 Spamming AI System with Chaff Data (mehr Erkennungen und Prüfaufwand; bei Agenten viele Aktionen mit menschlicher Freigabe) |
| Anweisungen in Log-, Ticket- oder Mailinhalt | Ein KI-Assistent im SOC verzögert Antworten, verliert Fähigkeiten, blendet Quellen aus oder liefert leere Ausgaben | NIST AI 100-2 E2025, Abschn. 3.4.1 Availability Attacks (eingeschleuste Prompts: zeitraubende Hintergrundaufgaben, gesperrte Fähigkeiten oder Schnittstellen, störende Formatierung bis zur leeren Ausgabe) und Abschn. 3.4.2 Integrity Attacks (Informationsquellen unterdrücken oder verbergen) |
| Überlastung und Kostentreiber | Verzögerte Analyse, Ausfall des Dienstes, hohe Betriebskosten | ATLAS AML.T0029 Denial of AI Service, AML.T0034 Cost Harvesting inkl. AML.T0034.002 Agentic Resource Consumption; NIST AI 100-2 E2025, Abschn. 2.1.2 Availability Breakdown |
Die Richtung «Harmloses wird blockiert» folgt aus den Fehlklassifikationen und Fehlalarmen der Quellen; ATLAS beschreibt bei AML.T0015 vor allem das Umgehen der Erkennung. Das ist eine fachliche Einordnung von STOP.LI.
| Schutzgrenze | Umsetzung |
|---|---|
| Allowlist kritischer Dienste | Domain-Controller, Zahlungs- und Notfallsysteme, Dienstkonten und Kundenzugänge sind von automatischen Sperren ausgenommen. Eine Sperre dort braucht immer eine menschliche Freigabe. |
| Blast-Radius-Limits | Höchstzahl gesperrter Konten, isolierter Hosts oder Segmente je Zeitfenster. Wird die Grenze erreicht, stoppt die Automatik und eskaliert. OWASP nennt Quoten, Fortschrittsgrenzen und Sicherungen zwischen Planer und Ausführer (ASI08, Massnahme 7). |
| Rate Limits für Sperren | Sperren pro Minute und pro Quelle begrenzen; Massenwirkung ist ein Warnsignal. Ebenso Anfragen an die KI-Analyse begrenzen (ATLAS AML.M0004, AML.M0036). |
| Mensch in der Schleife ab Schwelle | Unterhalb der Schwelle handelt die Automatik, oberhalb entscheidet ein Mensch (ASI08, Massnahme 5; ATLAS AML.M0029). Die Schwelle richtet sich nach der Kritikalität des Ziels. Eine Freigabeflut ist selbst ein Angriffsweg: Freigaben bündeln und priorisieren. |
| Rücknahme und Kill-Switch | Jede automatische Aktion ist umkehrbar und protokolliert. Ein Schalter setzt die Automatik auf «nur melden» zurück. Das NIST AI RMF sieht Mechanismen zum Abschalten von Systemen mit abweichendem Verhalten vor (MANAGE 2.4). |
| Vertrauensbewertung der Eingangsdaten | Quelle, Alter und Bestätigung eines Indikators bewerten. Ein einzelner, unbestätigter Indikator löst keine Sperre mit grosser Wirkung aus. Leistungskennzahlen der Modelle überwachen: Vergiftung mit grosser Wirkung zeigt sich meist in einem Einbruch von Präzision und Trefferquote (NIST AI 100-2 E2025, Abschn. 2.3.1). |
| Erkennung adversarialer Eingaben | Eingaben vor der Inferenz prüfen und auf auffällige Anfragemuster achten (ATLAS AML.M0015). |
| Übungen | Szenario «Fehlalarm löst Massensperre aus» einmal jährlich üben: Wer erkennt es, wer schaltet ab, wie schnell ist der Normalzustand wieder hergestellt? Methoden: Testing und Red Teaming. |
Die Umsetzungsvorschläge sind fachliche Empfehlungen von STOP.LI. Die Quellen belegen Angriffsarten und Gegenmassnahmen nach Art, nicht die Schwellenwerte. Agentische Aktionen im Allgemeinen: Agenten und MCP.
Gegen Deepfake-
Betrug schulen.
Bei Deepfake-Betrug zählt das Verfahren, nicht das Auge. Mitarbeitende sollen nicht beurteilen müssen, ob eine Stimme echt klingt. Sie brauchen Regeln, die auch bei einer perfekten Fälschung greifen. Das NCSC erwartet, dass Menschen echte Nachrichten immer schlechter von Phishing unterscheiden können; Schulung auf Erkennungsmerkmale allein reicht deshalb nicht.
- Rückruf über bekannte Nummer: bei Zahlungs-, Konto- und Zugangswünschen immer über einen Kanal zurückrufen, den die Organisation selbst hinterlegt hat, nie über die Nummer aus der Anfrage.
- Vier-Augen-Prinzip: Zahlungen, Änderungen von Bankdaten und Rechtevergaben erst nach unabhängiger zweiter Freigabe.
- Codewort für Führungspersonen: vorab vereinbart, nicht per E-Mail oder Chat verteilt, regelmässig gewechselt.
- Dringlichkeit als Warnzeichen: Druck, Geheimhaltung und Umgehen des Prozesses lösen die Prüfung aus, nicht überspringen sie.
- Meldeweg ohne Schuldzuweisung: wer einen Versuch meldet, hilft; wer zahlt und schweigt, schadet.
- Übung: Anrufe und Nachrichten in Simulationen aufnehmen (Phishing Simulation, Awareness), Ziel ist das richtige Verhalten, nicht die Klickrate.
Die Kennzeichnungspflicht für Deepfakes nach Art. 50 Abs. 4 AI Act trifft Betreiber von KI-Systemen, die Deepfakes erzeugen. Sie ist kein Schutz gegen Betrüger, die sich nicht daran halten. Zur Einordnung siehe Vertrauen und Aufsicht. Messgrössen für Wirksamkeit: Kennzahlen und Reporting.
Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt bei der Beurteilung und Einführung von KI-Werkzeugen im SOC und bei Awareness-Programmen gegen Deepfake-Betrug. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.
- The near-term impact of AI on the cyber threat (NCSC UK, 24.01.2024)
- Impact of AI on cyber threat from now to 2027 (NCSC UK, 07.05.2025)
- ENISA Threat Landscape 2025 (ENISA, 01.10.2025)
- MITRE ATLAS (MITRE, Datenstand v2026.09, Apache 2.0)
- NIST AI 600-1, Generative AI Profile (NIST, Juli 2024)
- OWASP Top 10 for LLM Applications 2026 (OWASP GenAI Security Project, 2026)
- Verordnung (EU) 2024/1689 (AI Act), Art. 50 Abs. 4 (konsolidierte Fassung 27.07.2026)
Zitierte Fremdinhalte unterliegen der Lizenz ihrer Herausgeber. Die Seite ist eine Orientierung, keine Rechtsberatung.
© 2026 4T2 Solutions GmbH. Text und eigene Diagramme stehen unter CC BY 4.0.