KI
Eben erst haben wir über „Tokenomics“ und „Denial-of-Wallet“-Angriffe berichtet – neuartige DDoS-Angriffe, die darauf abzielen, KI-Token massenhaft zu verplempern. Bevor Sicherheitsexperten sich jedoch um die KI-Prozesse in anderen Abteilungen kümmern, sollten sie überlegen, wie die Abteilung für Informationssicherheit vor solchen Angriffen geschützt werden kann. KI-basierte Automatisierung wird derzeit in vielerlei Varianten aktiv von Sicherheitsteams getestet und implementiert. Dabei sind externe Eingriffe, die das Abwehrsystem lahmlegen könnten, eine Bedrohung, die auch für interne Prozesse und Technologien im Sicherheitsbereich relevant ist.
Nach Schätzungen des Sicherheitslabors Elastic kann schon die Überprüfung eines einzigen Alarms von einem Host relativ teuer werden. Ein wichtiger Faktor ist die „agentenbasierte SOC“-Architektur. Mögliche Kosten für eine Triage: 0,69 US-Dollar für ein Ensemble hoch spezialisierter Agenten oder 3,42 US-Dollar für einen universellen Agenten mit 14 verschiedenen Fähigkeiten.
Diese Durchschnittswerte können in der Praxis noch weiter in die Höhe schnellen. Die elementare Verarbeitung einer einfachen Warnung (z. B. tausend Token) kann sich jederzeit in eine kaskadierende Untersuchung verwandeln, an der Millionen von Protokolleinträgen, API-Aufrufen und damit verbundenen Daten beteiligt sind. Dann sind innerhalb weniger Minuten schnell Millionen von Token verbraucht.
Elastic hat erklärt, dass es Claude Sonnet 4.6 in seinem SOC einsetzt. Naheliegende Frage: Was passiert, wenn das Budget erschöpft ist oder die Sicherheitsfilter des Modells ausgelöst werden? Schlimmstes Szenario: Es werden verdächtige Ereignisse gemeldet, die auf die Ausweitung eines Angriffs in der Infrastruktur hinweisen könnten. Zur Untersuchung startet das KI-gestützte SOC ein „Orchester von Agenten“. Ein Agent ruft die Anthropic-API auf, aber das Monatsbudget der Abteilung ist aufgebraucht und die API gibt Fehler zurück. Die Ermittlungen kommen zum Erliegen. Das Team erfährt allerdings erst einen halben Tag später davon. Da die „Sicherheitsfilter“ bei großen KI-Anbietern ständig geändert werden, könnten die Anfragen des SOC als bösartig eingeordnet werden. Der Effekt wäre ähnlich, auch wenn in diesem Fall das Budget noch gar nicht erschöpft wäre. Diese traurige Erfahrung machte Hugging Face, als der Angriff auf seine Infrastruktur durch OpenAI analysiert wurde.
Angreifern kommen solche Szenarien natürlich sehr gelegen. Sie haben damit direkten Einfluss auf die Sicherheitskosten, die einem Unternehmen entstehen. Dazu fügen sie einfach schädliche Prompts in die verfügbaren Daten (DNS-TXT-Datensätze, HTTP-Header, Code-Kommentare, Dateinamen usw.) ein und verlassen sich darauf, dass Informationssicherheitssysteme auf diese Prompts hereinfallen. Im Fall des GhostJacking-Angriffs dienen beispielsweise WAF-Protokolle als Vektor für die Prompt-Injektion. In einer Studie wurde eine weitere Methode getestet: Forschern gelang ein erfolgreicher Angriff auf die LLM-Sicherheitsfilter. Als Folge erhöhte sich die Verzögerung von Anfragen um das 148-fache und die Anzahl der verbrauchten Token um das 63-fache. Mit anderen Worten: Das System funktioniert scheinbar weiterhin ordnungsgemäß. In Wirklichkeit steigen aber die Latenz bei der Verarbeitung von Warnungen und die damit verbundenen Kosten ins Unermessliche.
Gefahr durch geräuschlosen Ausfall
In agentenbasierten Szenarien zeigt sich die Erschöpfung des Budgets nicht unbedingt als expliziter Fehler mit der Meldung „Anforderungslimit überschritten“ und einer umgehenden Benachrichtigung der Verantwortlichen. Je nach Konfiguration sind auch „Guerilla“-Szenarien denkbar: Wenn bei einer Anfrage an das Modell das Zeitlimit überschritten wird, wechselt das System automatisch zu einem billigeren Modell. Dadurch sinkt die Qualität der Ausgaben und die Ausführung von Subagenten und periodischen Aufgaben wird eingestellt. Das Sicherheitsteam glaubt möglicherweise stundenlang, dass alles wie vorgesehen funktioniert.
So kontrollierst du die KI-Kosten für Cybersicherheit
Beim Kostenmanagement darf es natürlich nicht nur um die „Vermeidung von Mehrausgaben“ gehen. In diese Falle sind viele Unternehmen bereits bei der SIEM-Implementierung getappt: Als die Abrechnung nach der Menge der gesammelten Telemetriedaten eingeführt wurde, begannen Unternehmen, die Protokollierung selektiv (aber nicht immer effektiv) einzuschränken. Daraus ergab sich eine lückenhafte Erkennung. Die gleiche Situation könnte bei Token eintreten, nur noch rasanter und in größerem Umfang. Eine unausgereifte Richtlinie, die auf Kostensenkung fixiert ist, könnte die Genauigkeit von Untersuchungen und die Qualität der Antworten beeinträchtigen. Doch was passiert, wenn eine solche Richtlinie überhaupt fehlt? Wer entscheidet dann über Einsparungen? Leider nicht der Systemarchitekt oder CISO, während das System entwickelt wird, sondern ein diensthabender, übermüdeter Analyst um 3 Uhr nachts. Oder der Systemhersteller hat einen Grenzwert vorgegeben, der die Sache automatisch regelt.
Es gibt ein paar einfache Prinzipien, um vorhersehbare Kostenüberschreitungen zu vermeiden und unvorhersehbare Situationen besser zu bewältigen.
Aufgaben, die mit einer Standardabfrage erledigt werden können, sollten nicht an das KI-Modell gehen. Alles, was sich wiederholt und im Voraus bekannt ist, sollte auf traditionelle Weise mit Regeln und Datenabfragen abgearbeitet werden. Diese Abfragen können zwar mithilfe von KI entwickelt werden, müssen jedoch festgelegten Abläufen folgen. Ein KI-Modell sollte nur dort verwendet werden, wenn es wirklich um die Bewertung einer mehrdeutigen Situation geht.
Verwende strenge Grenzwerte und warne die Nutzer offensiv, wenn diese Werte überschritten werden. Limits sollten kombiniert werden: ein Limit pro Aufgabe, ein Limit pro Tag und so weiter. Sobald Grenzwerte überschritten werden, müssen sowohl die diensthabenden Analysten als auch die Systemadministratoren gewarnt werden. Und zwar sofort!
Entscheide im Voraus, was passiert, wenn ein Limit erreicht wird. Egal, ob du das KI-Modell in solchen Fällen anhalten und Kosten sparen willst – und dadurch die Kontrolle verlierst – oder ob das Modell weiterlaufen soll und du dafür extra bezahlen musst. Diese Entscheidung muss getroffen werden, bevor ein Vorfall eintritt.
Beschränke die Berechtigungen und die Tools, die die Agenten nutzen können. Je weniger Aktionen dem System zur Verfügung stehen, desto effektiver arbeitet es an einer konkreten Aufgabe, desto weniger Möglichkeiten hat es, die Kosten in die Höhe zu treiben, und desto geringer ist die Wahrscheinlichkeit, dass es von Außenstehenden „ausgenutzt“ wird.
Unterziehe externe, nicht vertrauenswürdige Daten einer strengen Untersuchung. Externe Daten können nicht nur zu Prompt-Injektionen führen, sondern auch die Auslastung bewusst erhöhen. Zu diesen Daten zählen eingehende Anfragen, Aufforderungen, Nachrichten und Kommentare sowie verschiedene technische Felder mit beliebigen Textinhalten (DNS-Einträge, HTTP-Header, Dateinamen). Begrenze ihre Größe und überwache die von ihnen erzeugte Last.
Bereite dich darauf vor, Ausfälle bei externen Anbietern abzufangen. Auch in solchen Situationen solltest du die volle Kontrolle über die Daten deines Unternehmens behalten. Ein vielversprechender Ansatz sind lokale Modelle, die „on-premises“ bereitgestellt werden – zumindest für den Bereich Informationssicherheit. Selbst wenn diese Modelle nicht dem neuesten Stand der Technik entsprechen, sorgen die enge Spezialisierung und das gezielte Training mit Unternehmensdaten für Effizienz und Betriebssicherheit.
In einer komplexeren Architektur kann die Verwendung von LLMs in mehrere Ebenen unterteilt werden. Die erste Abwehrlinie (Routing, Rauschfilterung, Datenanreicherung) wird von kompakten lokalen Modellen übernommen. Dadurch werden die Budgetschwankungen erheblich reduziert. Die zweite Ebene bildet ein großes lokales Modell, das die inhaltliche Arbeit erledigt: Es verknüpft Ereignisse, testet Hypothesen und erstellt ein Gesamtbild des Vorfalls. Dieses Modell wird nicht nach Anzahl der Anfragen abgerechnet, sondern sein Durchsatz ist begrenzt. Daher kann es anstelle von Budgetüberschreitungen zu Überlastungen und Ereigniswarteschlangen kommen. Nur konkrete, wirklich schwierige Fälle werden an führende cloudbasierte Modelle weitergeleitet, möglichst mit ausdrücklicher Genehmigung eines menschlichen Analysten. Auch in diesem Schema gibt es variable Kosten. Sie betreffen jedoch eine überschaubare Anzahl von „harten Nüssen“, bei denen die Weiterleitung auf einer bewussten Entscheidung beruht und kein zufälliger Nebeneffekt ist.
Eigentlich entspricht das gesamte Vorgehen dem klassischen mehrstufigen SOC-Modell: Auf der ersten Ebene wird gefiltert und auf der dritten Ebene wird analysiert. Nur werden diese Rollen inzwischen von Modellen übernommen, nicht mehr von Menschen.
Tipps