KI in der Security | STOP.LI

STOP.LI · AI Security · Technik und Betrieb

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.

Einsatzfelder

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.

Einführung

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.

1 Datenabfluss

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.

2 Halluzination

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.

3 Nachvollziehbarkeit

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.

4 Rechte des Assistenten

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.

Angreifer

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.

Reaktionszeit

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.
Selbstausfall

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.

Awareness

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.

Unterstützung

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.