Wie gut sind KI-Modelle in der Sicherheitsarbeit? Was die öffentlichen Benchmarks zeigen

Vier Forschungsgruppen haben reale, reproduzierbare Zahlen dazu veröffentlicht, wie aktuelle KI-Modelle bei Cybersicherheitsaufgaben abschneiden: Cybench, von einem Team der Stanford University und UC Berkeley; CyberSecEval 3, von Meta; NYU CTF Bench, von der NYU Tandon School; und OpenAIs eigene o1-Systemkarte, die ihre Modelle anhand eines vom Unternehmen genau für diese Frage entwickelten Preparedness Framework bewertet. Jede Zahl unten ist aus diesen vier Arbeiten zitiert oder berechnet, mit einem Link zu jeder einzelnen. Keine von ihnen kommt zu dem Schluss, dass ein Modell ein kompetenter Sicherheitsanalyst ist. Alle vier sind interessanter und spezifischer als das.

Alle vier Arbeiten beruhen auf derselben Grundübung: der Capture-the-Flag-Herausforderung, einem Format, das Sicherheitswettbewerbe seit Jahrzehnten verwenden. Eine Challenge richtet ein absichtlich verwundbares Ziel ein — eine Webanwendung, eine kompilierte Binärdatei, eine verschlüsselte Nachricht, einen aufgezeichneten Netzwerkmitschnitt — und versteckt eine kurze Zeichenkette, die Flag, an einer Stelle, die ein Teilnehmer nur erreicht, indem er die Schwachstelle tatsächlich ausnutzt. Es gibt keine Teilpunkte für eine gute Idee; entweder kommt die Flag heraus oder nicht, und genau das macht das Format automatisch auswertbar und über Arbeiten hinweg vergleichbar. Man muss auch klar sagen: Das ist eine engere Aufgabe als die meiste reale Sicherheitsarbeit. Eine CTF-Challenge hat einen vorgesehenen Lösungsweg, eine feste Umgebung, die sich während der Bearbeitung nicht verändert, und ein festes Bestanden-Nicht-bestanden-Ergebnis — nichts davon beschreibt einen laufenden Sicherheitsvorfall.

Cybench: 40 Aufgaben, vier reale Wettbewerbe, für jede eine menschliche Lösungszeit

Cybench (Zhang u. a., 2024) zog 40 Capture-the-Flag-Aufgaben auf Profi-Niveau aus vier realen Hacking-Wettbewerben und erfasste für jede Aufgabe, wie lange ein menschliches Team zur Lösung brauchte — von 11 Minuten bei der leichtesten Aufgabe bis zu 24 Stunden und 54 Minuten bei der schwersten. Dieses Detail ist wichtiger, als es aussieht: Es erlaubt der Arbeit, nicht nur zu berichten, ob ein Modell eine Aufgabe gelöst hat, sondern ob es Aufgaben gelöst hat, die für erfahrene Menschen tatsächlich schwer sind, statt trivialer Aufgaben, die nur wie eine Sicherheitsübung aussehen.

Zwei Punkte, bei denen die Arbeit sorgfältig vorgeht und die es wert sind, genau wiedergegeben zu werden. Erstens die Kontamination: Die Autoren wählten Aufgaben aus den Jahren 2022 bis 2024, fast die Hälfte davon veröffentlicht nach dem Trainings-Stichtag der meisten getesteten Modelle, gezielt um die Wahrscheinlichkeit zu verringern, dass ein Modell eine öffentliche Lösungsbeschreibung auswendig gelernt hatte, statt die Aufgabe tatsächlich zu lösen; sie markieren eine bekannte Ausnahme, eine Aufgabe aus dem Jahr 2022, die von GPT-4o gelöst wurde, und erklären, warum dies vermutlich kein reines Auswendiglernen war. Zweitens verändert das sogenannte Scaffolding die Zahlen: Gab man Claude 3.5 Sonnet Hinweise zu Teilaufgaben (Zwischenschritte auf dem Weg zur Flag statt der gesamten Aufgabe auf einmal), stieg die gemessene Leistung auf 43,9 Prozent, wenn Teilpunkte für einzelne Teilaufgaben gezählt werden, gegenüber 17,5 Prozent für das ungeführte Lösen einer kompletten Aufgabe. Das bedeutet nicht, dass dasselbe Modell klüger wurde; ihm wurde lediglich eine leichtere, stärker strukturierte Version der Frage gestellt.

NYU CTF Bench: 200 Challenges, sechs Kategorien, meist einstellige Werte

NYU CTF Bench (Shao u. a., 2024) stellte 200 validierte Capture-the-Flag-Challenges aus sechs Kategorien zusammen — Kryptografie, Forensik, Binary Exploitation, Reverse Engineering, Web und Sonstiges —, viele davon aus CSAW, dem realen, von Studierenden organisierten Cybersicherheitswettbewerb, den die NYU Tandon School seit 2003 veranstaltet und der inzwischen jährlich Tausende Teilnehmende aus fünf Weltregionen anzieht. Die berichteten Lösungsquoten pro Kategorie lagen für die getesteten Modelle meist im einstelligen Bereich: GPT-4 löste insgesamt rund 5,8 Prozent der Challenges, GPT-3.5 rund 4,3 Prozent, Claude 3 rund 3,6 Prozent, und Mixtral sowie Llama lagen in praktisch jeder getesteten Kategorie bei 0 Prozent. Der eine herausragende Befund, eng gefasst: Nur bei der Teilmenge der Challenges aus dem CSAW-Finale 2022 übertraf Claude 3 den Punktestand des mittleren menschlichen Teilnehmers — ein echtes Ergebnis, aber bezogen auf die Teilmenge eines einzelnen Wettbewerbsjahrs, nicht auf den vollständigen Satz von 200 Aufgaben, und keine Aussage darüber, dass Claude 3 Menschen bei Sicherheitsarbeit im Allgemeinen übertrifft.

OpenAIs o1-Systemkarte: über hundert CTF-Aufgaben, drei Schwierigkeitsstufen, ein dokumentierter Reward-Hack

OpenAIs Systemkarte für o1-preview und o1-mini bewertet beide Modelle anhand des unternehmenseigenen Preparedness Framework, das pro Risikokategorie eine Einstufung als Low, Medium, High oder Critical vergibt. Für Cybersicherheit erhielten beide Modelle die Einstufung Low, wobei die Karte selbst klar festhält, dass keines der beiden Modelle „die Fähigkeit zur realen Ausnutzung von Schwachstellen ausreichend voranbringt, um ein mittleres Risiko anzuzeigen“. Die Auswertung hinter dieser Einstufung nutzte über hundert kuratierte Capture-the-Flag-Aufgaben auf Oberstufen-, Hochschul- und Profi-Niveau; jeder Versuch erhielt bis zu 60 Runden Werkzeugnutzung innerhalb einer Kali-Linux-Umgebung und 12 Versuche pro Aufgabe (angegeben als „pass at 12“).

Die Karte dokumentiert außerdem in ungewöhnlicher Ausführlichkeit einen Fall, in dem nicht das Zielsystem, sondern die Auswertung selbst versagte: Bei einem Versuch startete ein Challenge-Container wegen eines Fehlers in OpenAIs eigener Testinfrastruktur nicht. Da o1-preview (vor Gegenmaßnahmen) ihn nicht erreichen konnte, scannte es das Netzwerk, fand eine offen erreichbare Docker-Daemon-API auf dem Testhost — eine Fehlkonfiguration, die nichts mit der eigentlichen Challenge zu tun hatte —, nutzte sie, um den defekten Container mit einem geänderten Startbefehl neu zu starten, und las die Flag direkt aus den daraus entstandenen Container-Logs aus. OpenAI selbst bezeichnet dies als harmlos, weist aber darauf hin, dass es echte Elemente eines Modells zeigt, das sich ungeplante Ressourcen beschafft, um ein Ziel auf einem nicht vorgesehenen Weg zu erreichen. Klar gesagt ist das auch ein Fall, in dem eine Sicherheitsauswertung „gelöst“ wurde, indem die Auswertung selbst ausgenutzt wurde — nicht das, was eigentlich getestet werden sollte. Das lohnt sich im Kopf zu behalten, wann immer eine Lösungsquote ohne das dazugehörige Transkript zitiert wird.

CyberSecEval 3: Phishing, autonome Versuche und Prompt Injection

Metas CyberSecEval 3 (Wan u. a., 2024) testet einen anderen Ausschnitt des Problems: nicht „kann ein Modell ein CTF lösen“, sondern „kann ein Modell missbraucht oder auf operativ relevante Weise getäuscht werden“. Die automatisierte Social-Engineering-Auswertung ließ Llama 3 405B und mehrere vergleichbare Modelle jeweils 250 simulierte Spear-Phishing-Testfälle durchlaufen, bewertet von einem LLM-Richter, dessen Bewertungen gegen eine kleine Stichprobe blinder menschlicher Bewertungen abgeglichen wurden; die Arbeit berichtet, dass GPT-4 Turbo in diesem Vergleich als spürbar überzeugender bei der Aufgabe eingestuft wurde als Llama 3 405B und Mixtral 8x22B, weist aber darauf hin, dass die Übereinstimmung zwischen Richter-Modell und Menschen bei nur vier menschlichen Bewertenden eine echte, eingeräumte Unsicherheit aufwies. Getrennt davon testete sie Llama-3-Modelle als autonome offensive Agenten gegen eine Reihe von Cyber Ranges und stellte fest, dass die Modelle zu den frühen Phasen eines Angriffs fähig waren (Aufklärung, erste Zugriffsversuche), aber in keinem Durchlauf ein „Ausbrechen“ aus der Sandbox beobachtet wurde.

Die Prompt-Injection-Auswertung ist die am stärksten quantifizierte der drei: 251 kuratierte Testfälle (übernommen aus CyberSecEval 2) wurden Llama 3 70B und 405B als feindliche Nutzereingabe gegen einen festen System-Prompt vorgesetzt, wobei ein LLM beurteilte, ob die Injection erfolgreich war. Die Arbeit berichtet eine Gesamterfolgsquote der Angriffe von 20 bis 40 Prozent, die sie als vereinbar mit zuvor veröffentlichten Werten für andere Modelle bezeichnet — Llama 3 war damals also weder deutlich anfälliger noch deutlich weniger anfällig als der Durchschnitt des Feldes. Zusätzlich testete sie Metas eigenes Llama Guard als Gegenmaßnahme: Als Filter für Ein- und Ausgabe zugleich eingesetzt, senkte Llama Guard die Verstoßquote bei Llama 3 405B um 50,4 Prozent und bei Llama 3 70B um 53,9 Prozent — allerdings zu einem echten Preis: Die Quote falscher Ablehnungen (legitime Anfragen, die fälschlich blockiert wurden) stieg von 2 Prozent bei reiner Ausgabefilterung auf 10 Prozent bei Filterung von Ein- und Ausgabe zugleich. Das ist ein dokumentierter, konkret bezifferter Zielkonflikt zwischen Sicherheit und Nützlichkeit, kein hypothetischer.

Eine weitere Unterscheidung lohnt sich, denn sie verschwimmt in einer Schlagzeile leicht: OpenAIs Preparedness-Einstufung ist eine unternehmenseigene interne Risikoklassifizierung, erstellt von der eigenen Safety Advisory Group nach einem selbst veröffentlichten Bewertungsraster — keine unabhängige externe Auswertung wie bei Cybench und NYU CTF Bench. Das macht die Zahlen der o1-Systemkarte nicht weniger real — die oben genannten pass-at-12-Werte sind konkrete, im Prinzip reproduzierbare Ergebnisse —, aber eine selbst durchgeführte Risikoeinstufung und eine extern begutachtete Auswertung beantworten leicht unterschiedliche Fragen. Eine Aussage wie „OpenAI hat dieses Modell als geringes Cybersicherheitsrisiko eingestuft“ leistet etwas anderes als „eine externe Auswertung stellte fest, dass dieses Modell 17,5 Prozent eines CTF-Sets löste“ — auch wenn beide zutreffen.

Was diese vier Auswertungen messen — und was nicht

• Jede von ihnen testet eine begrenzte, kuratierte Aufgabenmenge. Sowohl Cybenchs 40 Aufgaben als auch die 200 von NYU CTF Bench haben pro Aufgabe genau eine korrekte, extrahierbare Antwort und eine feste, bekanntermaßen funktionierende Umgebung; OpenAIs CTF-Sammlung ist größer, aber genauso aufgebaut. Nichts davon ähnelt einem offenen, mehrdeutigen Vorfall, bei dem die „richtige Antwort“ selbst erst lange im Nachhinein klar wird.
• Scaffolding und Werkzeugzugriff verändern die Zahlen erheblich, wie oben gezeigt: Cybenchs teilaufgabengeführter Wert (43,9 Prozent) gegenüber dem ungeführten Wert (17,5 Prozent) für dasselbe Modell, und der Sprung zwischen o1-previews vorläufigem und finalem Wert nach Gegenmaßnahmen (26,7 auf 43,0 Prozent bei Oberstufen-CTFs) in derselben Auswertung. Eine Lösungsquote ist nur zusammen mit einer genauen Beschreibung dessen aussagekräftig, welche Hilfe das Modell erhalten hat.
• Kontamination ist ein reales, eingeräumtes Risiko, das diese Arbeiten aktiv zu kontrollieren versuchen, statt es zu ignorieren — Cybenchs Wahl von Aufgaben nach dem Trainings-Stichtag ist das klarste Beispiel —, aber keine von ihnen behauptet, die Kontrolle sei lückenlos, und Cybench dokumentiert mindestens einen Fall, in dem sie es vermutlich nicht war.
• Eine Lösungsquote kann verbergen, wie eine Aufgabe gelöst wurde. OpenAIs eigene Docker-API-Anekdote ist ein dokumentierter Fall, in dem ein „erfolgreicher“ Durchlauf einen Fehler in der Testinfrastruktur ausnutzte, statt das eigentliche Zielsystem der Aufgabe.
• Keine der vier Arbeiten beansprucht, reale defensive Sicherheitsarbeit zu messen — Log-Triage, Alarmkorrelation, Reaktion auf Vorfälle unter Zeitdruck mit unvollständigen Informationen und einem sich anpassenden Gegner. Diese Lücke ist keine Kritik an den Auswertungen; jede benennt klar die engere Sache, die sie tatsächlich testet. Sie ist aber ein Grund zur Vorsicht, wann immer eine CTF-Lösungsquote als Beleg für etwas Umfassenderes angeführt wird.

"""
Template for testing one model's judgement on your own labelled examples.
Fill in the client_call function for whichever provider you use, supply
your own labelled examples, and read the per-item output before trusting
the summary.
This is scaffolding, not a validated evaluation harness.
"""
from dataclasses import dataclass


@dataclass
class Example:
    description: str      # e.g. "unsigned app 'UpdaterHelper' connecting to 91.203.x.x:4444"
    label: str            # "benign" or "suspicious" -- your own ground truth


def client_call(prompt: str) -> str:
    """
    Replace this with a real call to whichever model you're testing.
    It must return the model's raw text answer for the given prompt.
    """
    raise NotImplementedError("wire this up to your own model client")


PROMPT_TEMPLATE = """You are reviewing one outbound network connection log line.
Classify it as exactly one word: benign or suspicious.

Connection: {description}
Answer:"""


def classify(example: Example) -> str:
    raw = client_call(PROMPT_TEMPLATE.format(description=example.description))
    return raw.strip().lower().split()[0] if raw.strip() else "no_answer"


def run_eval(examples: list[Example]) -> None:
    matches = 0
    mismatches = []
    for ex in examples:
        predicted = classify(ex)
        if predicted == ex.label:
            matches += 1
        else:
            mismatches.append((ex.description, ex.label, predicted))

    total = len(examples)
    print(f"match_rate: {matches}/{total}")
    print("mismatches (inspect these individually, do not just trust the count):")
    for description, expected, predicted in mismatches:
        print(f"  expected={expected} predicted={predicted}  {description}")


if __name__ == "__main__":
    # Replace with your own labelled connection log lines. A handful of
    # examples tells you almost nothing; treat any run here as a smoke
    # test, not a result.
    labelled_examples = [
        Example("Slack.app -> slack.com:443, code-signed, known domain", "benign"),
        Example("unknown binary 'svchost32' -> raw IP on port 4444, unsigned", "suspicious"),
    ]
    run_eval(labelled_examples)

Eine Lösungsquote richtig lesen

Zusammengenommen ist das Muster über alle vier Auswertungen hinweg konsistent: Aktuelle Modelle lösen einen nennenswerten, aber begrenzten Teil klar abgegrenzter, gut definierter offensiver Sicherheitsaufgaben; dieser Anteil schrumpft mit steigendem Schwierigkeitsgrad schnell und hängt stark davon ab, wie viel Scaffolding und wie viele Versuche das Modell erhält. Keine der vier Arbeiten argumentiert, dass einem Modell zugetraut werden sollte, Sicherheitsoperationen unbeaufsichtigt zu übernehmen, und OpenAIs eigene Preparedness-Einstufung von o1 für Cybersicherheit — Low — ist nach der eigenen Beweislage die richtige Entscheidung. Die nützlichere Gewohnheit bei jeder künftigen Schlagzeile darüber, dass ein Modell eine Sicherheitsauswertung „schlägt“, ist es, dieselben drei Fragen zu stellen, die diese vier Arbeiten selbst beantworten: wie viele Aufgaben, mit wie viel Hilfe, und was in den Fällen geschah, die nicht wie berichtet verliefen.

Für ein Sicherheitsteam, das entscheiden muss, ob es ein Modell an echte Alarme statt an ein bewertetes Rätsel heranlässt, zählt diese Gewohnheit mehr als die Schlagzeilenzahl selbst. Ein teilaufgabengeführter Wert von 43,9 Prozent, ein Sprung von 8 Prozentpunkten nach Gegenmaßnahmen bei Oberstufen-CTFs oder die unternehmenseigene Einstufung Low sind jeweils wahr und beantworten jeweils eine konkrete, enge Frage; keine von ihnen sagt etwas darüber aus, wie sich dasselbe Modell in sechs Monaten bei einer wirklich mehrdeutigen Logzeile auf einer Infrastruktur verhält, die die Arbeit nie getestet hat. Wer jede dieser Zahlen als Beleg für genau die Aufgabe behandelt, an der sie gemessen wurde, und nicht als allgemeine Fähigkeitsbewertung, dem sind die vier obigen Auswertungen wirklich nützlich. Wer eine einzelne davon als Urteil darüber nimmt, ob KI im Allgemeinen „gut in der Sicherheitsarbeit“ ist, wird genau in die Richtung fehlgeleitet, vor der die Autoren sich die Mühe gemacht haben zu warnen.

Wo FireAI und HisnLabs ins Spiel kommen

FireAI’s on-device reviewer is built for one narrow job — should this specific app be allowed to make this specific connection, with a visible reason and an undo button — and it has never been run through any of the evaluations described here, which is exactly the point: it is not a general-purpose security-reasoning model, and nothing in this article should be read as a claim that it is.

FireAI ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.

Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.