Cybersicherheit funktioniert jetzt wie Proof of Work

• Anthropics LLM „Mythos“ arbeitet in komplexen Simulationen von Netzwerkangriffen schneller und präziser als Menschen und ist nur für einen begrenzten Kreis zentraler Entwickler zugänglich
• In Tests des AI Security Institute gelang Mythos in einer 32-stufigen Simulation eines Unternehmensnetzwerk-Angriffs in 3 von 10 Durchläufen ein vollständiger Erfolg, wobei sich die Leistung mit steigendem Token-Budget verbessert
• Das Ergebnis zeigt, dass Sicherheit sich zu einer Struktur wandelt, in der Verteidiger mehr Tokens einsetzen müssen als Angreifer, also zu einem Wettbewerb nach dem Prinzip Proof of Work
• Nach den Supply-Chain-Angriffen auf LiteLLM und Axios verbreiten sich Versuche, Open-Source-Abhängigkeiten durch LLMs zu ersetzen oder durch Token-Einsatz die Sicherheit zu stärken
• Sicherheit wird damit weniger durch technische Kreativität als durch den Umfang des Ressourceneinsatzes bestimmt, was zu einem Trend führt, dem Entwicklungsprozess eine „Hardening“-Phase hinzuzufügen

---

Die Struktur, in der Sicherheit wie „Proof of Work“ funktioniert

• Anthropics LLM „Mythos“ zeigt bei Computer-Sicherheitsaufgaben herausragende Leistungen und ist deshalb nicht allgemein verfügbar, sondern nur für zentrale Softwareentwickler zugänglich
  • Mythos führt komplexe Simulationen von Netzwerkangriffen deutlich schneller aus als Menschen
  • Auch in der Bewertung des AI Security Institute (AISI) wies es im Vergleich zu früheren Modellen eine um eine Stufe höhere Fähigkeit zur Durchführung von Cyberangriffen nach
• In „The Last Ones“, einer 32-stufigen Simulation eines Unternehmensnetzwerk-Angriffs, erzielte Mythos in 3 von 10 Versuchen einen vollständigen Erfolg
  • AISI verwendete pro Versuch 100 Millionen Tokens (etwa 12.500 US-Dollar)
  • Unter den getesteten Modellen war Mythos das einzige, das den gesamten Angriff abschloss, und die Leistung verbesserte sich weiter, je höher das Token-Budget war
• Diese Ergebnisse führen die Ökonomie der Sicherheit auf eine einfache Formel zurück: „Um sich zu verteidigen, muss man mehr Tokens einsetzen als der Angreifer.“
  • Sicherheitsverstärkung wird eher durch den Umfang des Ressourceneinsatzes als durch Kreativität bestimmt
  • Das ähnelt dem Proof-of-Work-Mechanismus von Kryptowährungen, bei dem die Seite gewinnt, die mehr Rechenressourcen einsetzt

Implikationen der neuen Sicherheitsökonomie

• Wachsende Bedeutung von Open-Source-Software

  • Nach den jüngsten Supply-Chain-Angriffen auf LiteLLM und Axios wurde teils vorgeschlagen, Abhängigkeitscode mit AI-Agenten neu zu implementieren
  • Andrej Karpathy sagte, „Abhängigkeiten sollten neu bewertet werden, und einfache Funktionen lassen sich besser direkt mit LLMs implementieren“
  • Wenn Sicherheit proportional zum Token-Einsatz ist, könnten Unternehmen sicherer werden, je mehr Tokens sie in Open-Source-Bibliotheken investieren, um deren Sicherheit zu stärken
  • Gleichzeitig haben weit verbreitete OSS-Projekte einen hohen Angriffsreiz, sodass auch Angreifer einen Anreiz haben, mehr Ressourcen einzusetzen

• Hinzufügen einer „Hardening“-Phase zum Entwicklungsprozess

  • Derzeit folgen Entwickler einem zweistufigen Prozess aus Entwicklung → Code-Review und nutzen für jede Phase unterschiedliche Modelle
  • Anthropic bietet mit Code Review einen dedizierten Dienst für Code-Reviews an, zu Kosten von etwa 15 bis 20 US-Dollar pro Review
  • Künftig könnte sich ein dreistufiger Zyklus aus Entwicklung → Review → Hardening als Standard etablieren
    1. Entwicklung: Funktionsimplementierung und Iteration auf Basis von Nutzerfeedback
    2. Review: Dokumentation, Refactoring und Qualitätsverbesserung
    3. Hardening: Automatisierte Schwachstellensuche im Rahmen des verfügbaren Budgets
  • In der ersten Phase ist menschliche Zeit der limitierende Faktor, in der letzten Phase sind es die Kosten

Kostenstruktur und Grenzen der Sicherheit

• Das Schreiben von Code selbst bleibt weiterhin günstig, doch um Sicherheit zu gewährleisten, muss man mehr Tokens kaufen als der Angreifer
• Selbst wenn sich die Inferenz-Effizienz von Modellen verbessert, sind die Kosten der Sicherheitsverstärkung durch den Angriffswert bestimmt, sodass vollständige Kostensenkungen schwer erreichbar sind
• Infolgedessen wandelt sich Sicherheit von technischer Kreativität hin zu einem marktbasierten Wettbewerb um Ressourcen

[GN⁺]

Hacker-News-Kommentare

• Der Zugriff auf die Codebasis ist der Schlüssel. Das heutige LLM-basierte Security-Scanning ist im Grunde kaum mehr als ein einfaches Bash-Skript, das alle Dateien durchläuft und Prompts wie „Finde Schwachstellen“ absetzt
  Wenn der Verteidiger jedoch die gesamte Source kontrolliert, kann er deutlich effizienter arbeiten. Er kann zum Beispiel nur die in einem PR geänderten Dateien scannen oder sicherheitsrelevantem Code mehr Tokens zuweisen. Der Angreifer muss jedes Mal neu scannen, während der Verteidiger mit einem einzigen Scan alle potenziellen Schwachstellen proaktiv finden kann
  Letztlich gibt es also eine Kostenasymmetrie, und die Verteidigerseite ist bei der Effizienz im Vorteil. Der Angreifer muss eine mehrstufige Exploit-Kette vollständig aufbauen, während der Verteidiger nur ein einziges schwächstes Glied blockieren muss

  • Es gibt viele Angreifer und nur einen Verteidiger; daher ist die Behauptung schwer nachzuvollziehen, dass Skaleneffekte den Verteidigern helfen. Davon auszugehen, dass kein Codezugriff möglich ist, ist aus Security-Sicht keine gute Annahme. Jedes Security-Review setzt Zugriff auf den Source voraus
  • Trotzdem erhöht ein solcher Ansatz die Kosten der Softwareentwicklung. Eine sorglose Haltung nach dem Motto „Wer sollte es schon ausgerechnet auf uns abgesehen haben?“ funktioniert nicht mehr
  • Wie kürzlich im Podcast Security Cryptography Whatever erwähnt, fand ich interessant, dass es derzeit effizienter zu sein scheint, auf „die nächste Modellgeneration zu warten“, als die Harnesses zu verbessern
  • Das Problem ist, dass dieser Ansatz einen Vorfall auf dem Niveau „Supply-Chain-Angriff über den kompromittierten PC eines einzelnen Entwicklers“ zu „vollständigem Source-Code-Leak und automatisiertem Audit“ eskalieren lassen kann. So eine Welt dürfte für Startups wie ein dunkler Wald wirken
  • Der Verteidiger muss alles absichern, der Angreifer dagegen nur eine einzige Schwachstelle finden

• Das im Artikel erwähnte AI Security Institute (AISI) fand ich interessant und habe es mir angesehen. Es ist offenbar eine Organisation, an der vor allem Leute von DeepMind oder OpenAI beteiligt sind. Personen aus der Security-Branche gibt es kaum. Deshalb klingt das Fazit „Um Systeme zu härten, muss man mehr Tokens einsetzen“ etwas nach einer AI-industriezentrierten Logik. Ich frage mich auch, warum Alternativen wie formal verification nicht erwähnt werden. NVIDIA könnte so eine Argumentation womöglich gut für den GPU-Verkauf nutzen

  • Ich frage mich, welche bekannten Security-Forscher hier wohl eine Gegenposition einnehmen würden. Tatsächlich scheinen viele Forscher dieser These zuzustimmen. Der Fokus der aktuellen Debatte liegt offenbar darauf, ob LLMs eine Innovation auf dem Niveau von Fuzzing sind oder darüber hinausgehen
  • Der Vollständigkeit halber: AISI ist eine dem britischen Staat unterstellte Einrichtung und gehört zum Department for Science, Innovation and Technology (DSTI). Die Analyse wirkte aber etwas schwach, etwa weil die Graphen als einfache lineare Kurven dargestellt wurden

• Das Zitat von Tony Hoare ist eindrucksvoll: „Es gibt zwei Wege, Software zu entwerfen: entweder so einfach, dass sie offensichtlich keine Fehler hat, oder so kompliziert, dass sie keine offensichtlichen Fehler hat“

  • Selbst völlige Einfachheit kann nicht jeden Angriff verhindern, aber die Reduktion der Angriffsfläche ist sehr wirksam. Wenn man etwa ein System so entwirft, dass vor der Verarbeitung von Netzwerknachrichten zwingend eine Signaturprüfung erfolgt, wird es schwer, unsignierte Nachrichten überhaupt zu akzeptieren. Viele heutige Systeme haben ein deutlich breiteres Threat Model als nötig
  • Allerdings ist „Komplexität“ für Menschen und für LLMs nicht dasselbe. Was für Menschen komplex wirkt, kann für ein LLM einfach sein. Deshalb ist fraglich, wie wirksam dieser Ansatz tatsächlich ist

• Security war schon immer ein Spiel darum, wie viel Geld die Gegenseite ausgibt. Dass es jetzt LLMs gibt, ändert nichts am Grundprinzip. Auch Karpathys Philosophie „kopieren statt Abhängigkeiten“ existierte im Kern schon als Sprichwort in der Go-Welt. Und auch der Grundsatz „Security entsteht nicht durch Geheimhaltung“ ist alles andere als neu

  • Trotzdem ist obscurity nicht völlig wertlos. Als eine von mehreren Verteidigungsschichten kann sie helfen. Ideal ist es, ein System zunächst unter der Annahme vollständiger Transparenz zu härten und darüber dann noch etwas zusätzliche Undurchsichtigkeit zu legen
  • Die Aussage „Zur Verteidigung muss man mehr Tokens einsetzen als der Angreifer“ ist ebenfalls nicht neu. In der physischen Sicherheit war es schon immer so. Am Ende gilt auch im AI-Zeitalter: AI muss mit AI verteidigt werden. Zuerst sollte man sich die Prompts der Code-Generierungsmodelle ansehen, die Entwickler verwenden

• Ich stimme dem Artikel weitgehend zu. Die Formulierung „Es geht nicht darum, mit Cleverness Punkte zu machen“ ist allerdings etwas gefährlich. Das Wesen der Cybersicherheit ist weiterhin ein menschliches System. Viel GPU-Zeit einzusetzen ist wichtig, aber letztlich entscheiden Security-Kultur und Disziplin einer Organisation über Sieg oder Niederlage. Nötig ist ein Niveau an Disziplin, wie es in der Nuklear- oder Luftfahrtindustrie oft erst nach Unfällen entsteht.
  In diesem Zusammenhang beschreibt dieser Text von vor einem Jahr die aktuelle Lage fast schon prophetisch

• Zur Behauptung „Um ein System zu härten, muss man mehr Tokens als der Angreifer einsetzen“: Ich habe in der Vergangenheit selbst Skripte für Ticketmaster-API-Automatisierung gebaut. Sie hatten ihre Verteidigung mit PerimeterX verstärkt, aber ich habe sie in drei Tagen umgangen. Vor Kurzem habe ich auf ähnliche Weise auch eine Methode umgesetzt, um Cloudflare Turnstile von ChatGPT zu umgehen.
  Das war ein Beispiel dafür, dass Security-Produkte, in die zig Millionen Dollar geflossen sind, in der Praxis nutzlos sein können
  Zugehöriger HN-Post

• Ich frage mich, ob die von LLMs gefundenen Security-Vorfälle wirklich neue Schwachstellen sind oder nur eine Fortsetzung bereits bekannten Security-Wissens. Falls Letzteres zutrifft, stellt sich die Frage, warum wir sie nicht selbst systematisch finden

• Dass diese Forschung wie Proof of Work wirkt, liegt daran, dass AISI sagt, „mit mehr Tokens steigen die Ergebnisse weiter“. Dahinter steht also die Annahme, dass die Erfolgsquote eines Angriffs proportional zum Token-Verbrauch wächst. Das Experiment war jedoch ein 32-stufiges Szenario zur Netzwerkkompromittierung, und das einzige Modell, das es abschließen konnte, war Mythos. Bei einer einfachen Codebibliothek könnte der Punkt abnehmender Erträge sehr viel früher erreicht sein
  Bei Open-Source-Projekten könnten sowohl Verteidiger als auch Angreifer mehr Tokens verbrauchen und dadurch diesen Grenzpunkt schneller erreichen

  • Mythos war nicht bei jedem Versuch erfolgreich, und das Testnetzwerk verfügte auch nicht über echte Verteidigungsmechanismen. Trotzdem gibt es keinen Grund, AI zu unterschätzen. Die Modelle in drei Monaten werden wieder auf einem anderen Niveau sein
  • Ich kenne mich mit Cybersicherheit nicht gut aus, aber entscheidend scheint mir die Wachstumsrate der Token-Kosten zu sein, um von 32 auf 33 Stufen zu kommen. Wenn Verteidigung pro Stufe unabhängig wirkt, fällt die Erfolgswahrscheinlichkeit eines Angriffs als p^N sehr schnell ab

• Am Ende ist die eigentliche Frage diese: Ist es billiger, eine von Menschen geschriebene Codebasis zu schützen, oder von einer Armee von Agenten erzeugten Code?

• Modelle wie heute einfach blind auf die gesamte Codebasis loszulassen, ist ineffizient. Nach meinen Experimenten sinken die Kosten stark, wenn man das Modell so steuert, dass es source-to-sink trace strukturiert erkundet.
  Wir sind jetzt in einer Phase, in der Systeme den Kontext einer gesamten Codebasis visualisieren und Bruchstellen präzise aufzeigen können. Das wird ein großer Wendepunkt für die Softwarequalität sein