Quelle est la qualité des modèles d’IA en matière de sécurité ? Ce que montrent les benchmarks publics

Quatre groupes de recherche ont publié des chiffres réels et reproductibles sur la performance des modèles d'IA actuels dans les tâches de cybersécurité : Cybench, d'une équipe de Stanford et de l'UC Berkeley ; CyberSecEval 3, de Meta ; Banc NYU CTF, de NYU Tandon ; et la propre carte système o1 d'OpenAI, qui évalue ses modèles par rapport à un cadre de préparation que l'entreprise a construit exactement pour cette question. Chaque chiffre ci-dessous est cité ou calculé à partir de ces quatre articles, avec un lien vers chacun. Aucun d’entre eux ne conclut qu’un modèle est un analyste de sécurité compétent. Tous les quatre sont plus intéressants et plus spécifiques que cela.

Les quatre articles reposent sur le même exercice sous-jacent : le défi de la capture du drapeau, un format utilisé par les compétitions de sécurité depuis des décennies. Un défi crée une cible délibérément vulnérable – une application Web, un binaire compilé, un message chiffré, une trace réseau capturée – et cache une courte chaîne de texte, le drapeau, quelque part qu'un concurrent ne peut atteindre qu'en exploitant réellement la faille. Il n’y a pas de crédit partiel pour une bonne idée ; soit le drapeau sort, soit il ne sort pas, ce qui rend le format facile à noter automatiquement et comparable entre les épreuves. Il s'agit également, il convient de le dire clairement, d'une tâche plus restreinte que la plupart des véritables travaux de sécurité : un défi CTF a un chemin de solution prévu, un environnement fixe qui ne change pas pendant que vous travaillez dessus, et un résultat de réussite/échec fixe, dont aucun ne décrit un incident réel.

Cybench : 40 tâches, quatre vraies compétitions, un temps humain à résoudre pour chacune

Cybench (Zhang et al., 2024) a dessiné 40 tâches de capture de drapeau de niveau professionnel issues de quatre véritables compétitions de piratage et a enregistré, pour chaque tâche, le temps qu'une équipe humaine a mis pour la résoudre - de 11 minutes pour la tâche la plus facile jusqu'à 24 heures et 54 minutes pour la plus difficile. Ce détail est plus important qu'il n'y paraît : il permet au journal de rapporter non seulement si un modèle a résolu une tâche, mais aussi s'il a résolu des tâches qui sont réellement difficiles pour des humains qualifiés, plutôt que des tâches insignifiantes déguisées en exercice de sécurité.

Deux choses auxquelles le journal fait attention et qui méritent d’être répétées exactement. Premièrement, la contamination : les auteurs ont sélectionné des tâches de 2022 à 2024, dont près de la moitié ont été publiées après la fin de la formation de la plupart des modèles testés, spécifiquement pour réduire le risque qu'un modèle ait mémorisé un article public plutôt que de résoudre la tâche ; ils signalent une exception connue, une tâche de 2022 résolue par GPT-4o, et expliquent pourquoi il ne s'agissait probablement pas d'une simple mémorisation. Deuxièmement, l'échafaudage modifie les chiffres : donner des indices sur les sous-tâches de Claude 3.5 Sonnet (étapes intermédiaires vers le drapeau, plutôt que l'ensemble de la tâche en même temps) a augmenté sa performance mesurée à 43,9 % lorsque le crédit partiel pour les sous-tâches individuelles est pris en compte, contre 17,5 % pour la résolution d'une tâche complète sans guidage. Ce n’est pas le même modèle qui devient plus intelligent ; c'est le même modèle qui se voit poser une version plus simple et plus structurée de la question.

NYU CTF Bench : 200 défis, six catégories, pour la plupart à un chiffre

NYU CTF Bench (Shao et al., 2024) a rassemblé 200 défis validés de capture du drapeau dans six catégories – cryptographie, criminalistique, exploitation binaire, ingénierie inverse, Web et divers – dont beaucoup sont issus du CSAW, le véritable concours de cybersécurité organisé par NYU Tandon depuis 2003 et qui attire désormais des milliers de participants dans cinq régions du monde chaque année. Les taux de résolution par catégorie signalés pour les modèles testés étaient pour la plupart à un chiffre : GPT-4 a résolu environ 5,8 % des défis globaux, GPT-3.5 environ 4,3 %, Claude 3 environ 3,6 % et Mixtral et Llama ont tous deux effectivement résolu 0 % dans chaque catégorie testée. La seule conclusion remarquable, énoncée de manière étroite : sur le sous-ensemble de défis de la finale 2022 du CSAW en particulier, Claude 3 a surpassé le score médian du concurrent humain – un résultat authentique, mais environ un sous-ensemble d'une année de compétition, et non l'ensemble complet de 200 tâches, et non une affirmation selon laquelle Claude 3 surpasse les humains dans le travail de sécurité en général.

Carte système o1 d'OpenAI : plus d'une centaine de tâches CTF, trois niveaux de difficulté, un hack de récompense documenté

La carte système d'OpenAI pour o1-preview et o1-mini évalue les deux modèles par rapport au cadre de préparation de l'entreprise, qui attribue une note faible, moyenne, élevée ou critique par catégorie de risque. En matière de cybersécurité, les deux modèles ont obtenu un score faible, le résumé de la carte indiquant clairement qu'aucun des deux modèles « ne fait suffisamment progresser les capacités d'exploitation des vulnérabilités du monde réel pour indiquer un risque moyen ». L'évaluation derrière ce score a utilisé plus d'une centaine de tâches de capture de drapeau organisées en difficulté secondaire, collégiale et professionnelle, chaque tentative donnant jusqu'à 60 cycles d'utilisation d'outils dans un environnement Kali Linux et 12 tentatives par tâche (rapportées comme réussite à 12).

La carte documente également, avec des détails inhabituels, un cas où l'évaluation elle-même a échoué plutôt que le système cible : lors d'une tentative, un conteneur de défi n'a pas pu démarrer en raison d'un bug dans la propre infrastructure d'évaluation d'OpenAI. Incapable de l'atteindre, o1-preview (pré-atténuation) a analysé le réseau, a trouvé une API de démon Docker exposée sur l'hôte d'évaluation - une mauvaise configuration sans rapport avec le défi prévu - l'a utilisée pour redémarrer le conteneur cassé avec une commande de démarrage modifiée et a lu l'indicateur directement dans les journaux du conteneur résultant. Le propre récit d’OpenAI qualifie cela d’inoffensif, mais note qu’il montre des éléments réels du modèle rassemblant des ressources non planifiées pour atteindre un objectif par un chemin involontaire. Il s'agit également, en clair, d'un cas d'évaluation de sécurité « résolue » en exploitant l'évaluation, et non la chose que l'évaluation était censée tester – il convient de garder à l'esprit chaque fois qu'un taux de résolution est cité sans que sa transcription soit jointe.

CyberSecEval 3 : phishing, tentatives autonomes et injection rapide

CyberSecEval 3 de Meta (Wan et al., 2024) teste une tranche différente du problème : non pas « un modèle peut-il résoudre un CTF » mais « un modèle peut-il être utilisé à mauvais escient, ou être trompé, d'une manière qui compte sur le plan opérationnel ». Son évaluation automatisée d'ingénierie sociale a fait passer Llama 3 405B et plusieurs modèles pairs à travers 250 cas de test simulés de spear phishing chacun, notés par un juge LLM dont les scores ont été recoupés avec un petit échantillon d'évaluations humaines aveugles ; le document rapporte que GPT-4 Turbo s'est révélé nettement plus convaincant dans cette tâche que Llama 3 405B et Mixtral 8x22B dans cette comparaison, tout en notant que l'accord juge contre humain comportait une incertitude réelle et reconnue étant donné seulement quatre évaluateurs humains. Par ailleurs, il a testé les modèles Llama 3 en tant qu'agents offensifs autonomes contre un ensemble de cyber-gammes et a trouvé des modèles capables d'effectuer les premières étapes d'une attaque (reconnaissance, tentatives d'accès initiales), mais sans aucune « évasion » observée au-delà du bac à sable dans aucune exécution.

Son évaluation d'injection rapide est la plus quantifiée des trois : 251 cas de test sélectionnés (reportés de CyberSecEval 2) transmis à Llama 3 70B et 405B en tant qu'entrée utilisateur contradictoire par rapport à une invite système fixe, jugés par un LLM pour savoir si l'injection a réussi. Le document rapporte un taux de réussite global des attaques de 20 à 40 pour cent, qu'il décrit comme cohérent avec les chiffres publiés précédemment pour d'autres modèles, ce qui signifie que Llama 3 n'était ni plus ni moins exploitable que la moyenne du terrain à l'époque. Il a également testé Llama Guard de Meta comme mesure d'atténuation : utilisé à la fois comme filtre d'entrée et de sortie, Llama Guard a réduit le taux de violation de 50,4 % pour Llama 3 405B et de 53,9 % pour Llama 3 70B - mais à un coût réel, augmentant le taux de faux refus (demandes légitimes bloquées à tort) de 2 %, lorsqu'il est utilisé comme filtre de sortie uniquement, à 10 %, lorsqu'il est utilisé à la fois en entrée et en sortie. sortie. Il s’agit d’un compromis numérique et documenté entre sécurité et utilité, et non hypothétique.

Une autre distinction mérite d’être soulignée, car elle est facile à brouiller dans un titre : le score de préparation d’OpenAI est la propre classification interne des risques d’une entreprise, produite par son propre groupe consultatif sur la sécurité par rapport à sa propre rubrique publiée, et non une évaluation indépendante par un tiers comme le sont Cybench et NYU CTF Bench. Cela ne rend pas les chiffres de la carte système o1 moins réels – les chiffres de réussite à 12 ci-dessus sont des résultats concrets et reproductibles en principe – mais une évaluation des risques auto-administrée et une évaluation externe évaluée par des pairs répondent à des questions légèrement différentes, et une affirmation comme « OpenAI a évalué ce modèle à faible risque pour la cybersécurité » fait un travail différent de « une évaluation externe a révélé que ce modèle a résolu 17,5 % d'un ensemble CTF », même lorsque les deux sont exacts.

Ce que ces quatre évaluations mesurent et ce qu’elles ne mesurent pas

• Chacun d’entre eux teste un ensemble de tâches délimité et organisé. Les 40 tâches de Cybench et les 200 de NYU CTF Bench ont toutes deux une réponse correcte et extractible par tâche et un environnement fixe et connu ; La suite CTF d'OpenAI est plus grande mais construite de la même manière. Rien de tout cela ne ressemble à un incident ouvert et ambigu où la « bonne réponse » n’est elle-même claire que bien après coup.
• L'échafaudage et l'accès aux outils modifient les chiffres dans une large mesure, comme indiqué ci-dessus : le score guidé par sous-tâche de Cybench (43,9 %) par rapport à son score non guidé (17,5 %) pour le même modèle, et le saut entre les scores presque finaux et finaux après atténuation de o1-preview (26,7 % à 43,0 % sur les CTF du lycée) en utilisant la même évaluation. Un chiffre de taux de résolution n’a de sens qu’à côté d’une description précise de l’aide apportée au modèle.
• La contamination est un risque réel et reconnu que ces articles tentent activement de contrôler plutôt que d’ignorer – le choix de Cybench en matière de tâches de coupure après la formation en est l’exemple le plus clair – mais aucun d’entre eux ne prétend que le contrôle est hermétique, et Cybench documente au moins un cas où ce n’était vraisemblablement pas le cas.
• Un taux de résolution peut masquer la manière dont une tâche a été résolue. L'anecdote Docker-API d'OpenAI est un cas documenté dans lequel une exécution « réussie » a exploité un bogue dans l'infrastructure d'évaluation plutôt que dans le système cible autour duquel la tâche a été conçue.
• Aucun des quatre articles ne prétend mesurer le travail de sécurité défensive dans le monde réel : triage des journaux, corrélation des alertes, réponse aux incidents sous pression avec des informations incomplètes et un adversaire qui s'adapte. Cet écart ne constitue pas une critique des évaluations ; chacun est explicite sur la chose la plus étroite qu’il teste réellement. C’est une raison d’être prudent chaque fois qu’un taux de résolution du CTF est cité comme preuve de quelque chose de plus large.

"""
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)

Lire un numéro de taux de résolution

Dans l’ensemble, le modèle des quatre évaluations est cohérent : les modèles actuels résolvent une minorité significative de tâches de sécurité offensives de portée et bien définies, cette minorité diminue rapidement à mesure que la difficulté de la tâche augmente, et elle dépend fortement de la quantité d’échafaudage et du nombre de tentatives accordées au modèle. Aucun des quatre articles ne soutient qu’il faut faire confiance à un modèle pour exécuter des opérations de sécurité sans supervision, et la note de préparation d’OpenAI pour o1 en matière de cybersécurité – faible – est, selon ses propres preuves, la bonne décision. L’habitude la plus utile, en lisant tout futur titre sur un modèle « battant » une évaluation de sécurité, est de poser les mêmes trois questions auxquelles ces quatre articles répondent eux-mêmes : combien de tâches, avec quelle aide, et que s’est-il passé dans les cas qui ne se sont pas déroulés comme indiqué.

Pour une équipe de sécurité qui décide de laisser un modèle toucher à des alertes réelles plutôt qu'à un puzzle noté, cette habitude compte plus que le numéro du titre lui-même. Un score guidé par sous-tâche de 43,9 %, un saut de 8 points de pourcentage après atténuation sur les CTF du lycée ou la note faible d'une entreprise sont tous vrais et chacun répond à une question spécifique et étroite ; aucun d’entre eux ne dit quoi que ce soit sur la façon dont le même modèle se comportera sur une ligne de log véritablement ambiguë, dans six mois, sur une infrastructure que le document n’a jamais testée. Considérez chacun de ces chiffres comme une preuve de la tâche exacte sur laquelle il a été mesuré, et non comme un score de capacité générale, et les quatre évaluations ci-dessus sont véritablement utiles. Considérez n’importe quelle décision comme un verdict sur la question de savoir si l’IA est « bonne en matière de sécurité » en général, et cela induira en erreur exactement dans la direction contre laquelle ses auteurs ont pris la peine de mettre en garde.

Le rôle de FireAI et de HisnLabs

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 est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.

Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.