- Terence Tao souligne l’importance logique de la distinction entre blue team et red team dans le domaine de la cybersécurité
- La constructive logic (logique constructive) représente les principes de la blue team, tandis que la co-constructive logic (logique co-constructive) représente ceux de la red team
- Mike Shulman mène des recherches sur une nouvelle logique combinant ces deux cadres
- L’interprétation de Brouwer–Heyting–Kolmogorov (BHK) est centrée sur la preuve, mais met aussi en lumière l’importance de la réfutation
- Ces recherches pourraient s’appliquer à divers domaines, notamment la sécurité de l’IA
Discussion sur la distinction et la combinaison des logiques blue team et red team pour les LLM
- Terence Tao a récemment indiqué que les logiciens réfléchissent plus en profondeur à la distinction entre blue team (défense) et red team (attaque) dans les domaines de la sécurité et des algorithmes
- La constructive logic (logique constructive) se concentre sur le processus de vérification, c’est-à-dire la manière de prouver une affirmation, et définit les principes de la blue team
- À l’inverse, la co-constructive logic (logique co-constructive) porte sur le processus de réfutation, c’est-à-dire la logique de la contestation ou de l’attaque, et attire récemment l’attention comme cadre des principes de la red team
Les recherches de Mike Shulman sur la combinaison des logiques
- Mike Shulman étudie une forme de logique qui combine ces deux systèmes logiques
- Selon une citation tirée de son article, l’interprétation de Brouwer–Heyting–Kolmogorov (BHK) existante tend à ne mettre l’accent que sur les critères de preuve, alors que les mathématiciens praticiens estiment tout aussi important de disposer de critères de réfutation, c’est-à-dire permettant d’identifier qu’une proposition est fausse
- Cela met en évidence les limites d’une approche de l’interprétation logique centrée uniquement sur la preuve
Nécessité d’élargir l’interprétation logique
- Il devient nécessaire d’expliquer, pour les connecteurs logiques, ce que signifient à la fois la preuve et la réfutation, depuis les deux points de vue
- Les recherches en cours de Mike Shulman explorent la structure que pourrait prendre concrètement une telle interprétation élargie
Implications et possibilités d’application
- Si ce type de recherche sur une logique combinée progresse, il pourrait avoir des usages concrets dans la conception de la sécurité de l’IA ainsi que dans le développement de systèmes de vérification et de réfutation d’algorithmes en cybersécurité
- Les détails de l’article concerné peuvent être consultés via le lien arXiv
1 commentaires
Avis Hacker News
J’ai quelques réflexions
(a) l’IA est utile à la fois dans les équipes « rouge » et « bleue »
l’équipe bleue joue en quelque sorte un rôle de brainstorming
(b) AlphaEvolve est, en ce sens, un exemple clair d’application de l’approche « red/blue team ». Ils n’emploient simplement pas cette terminologie
Terence Tao a d’ailleurs été conseiller sur cet article
(c) cela rappelle aussi la répartition des rôles « vérificateur/réfutateur » en sémantique des jeux
Tao lui-même a publiquement évoqué cette façon de penser, donc il voit probablement vraiment les choses sous cet angle
l’expression « bleu/rouge » est sans doute un habillage destiné aux programmeurs
(d) pour ajouter un point, on ne peut pas toujours dire qu’un système de sécurité n’est fort qu’à hauteur de son maillon le plus faible
cela dépend de l’architecture : en couches ou en parallèle
si c’est un couloir avec plusieurs portes solides et fragiles alignées, la résistance globale est déterminée par la porte la plus solide
et si l’on combine plusieurs classifieurs faibles pour construire un algorithme de détection de fraude, on peut obtenir quelque chose de bien plus puissant que le plus faible des classifieurs
Article AlphaEvolve
Q&R sur la manière de penser de Tao
là, le LLM ne fait que générer du nouveau code à partir d’exemples, et n’évalue pas lui-même le code
J’ai trouvé que le concept red team vs blue team est un bon cadre pour comprendre jusqu’où les LLM sont utiles pour les experts
pour ajouter des tests, je les confierais presque sans hésiter à un LLM
parce que les tests sont en général peu coûteux, faciles à supprimer ou corriger s’ils sont mauvais, et utiles s’ils sont bons
en revanche, comme les LLM testent rarement les fonctionnalités centrales, les tests les plus importants doivent être écrits à la main pour être fiables
à l’inverse, corriger des bugs ou ajouter des fonctionnalités avec un LLM est plus risqué
parce qu’un LLM peut tricher, ou écrire du code qui passe juste les tests sans résoudre le vrai problème
En travaillant sur une base de code legacy, j’ai fortement ressenti à quel point l’idée « ce n’est pas grave si les tests sont faux, on les corrigera plus tard » est dangereuse
les tests servent parfois de référence plus proche de la vérité que le code lui-même, donc de mauvais tests peuvent être plus graves que du mauvais code
surtout quand on mélange des tests inutiles ou ambigus, il devient extrêmement difficile de distinguer ceux qui garantissent réellement une fonctionnalité importante
Je pense que l’IA ressemble à une calculatrice
de même qu’une calculatrice effectue très bien des calculs que la plupart des gens ne peuvent pas faire, l’IA est un nouvel outil d’intelligence qui augmente les capacités humaines
beaucoup pensent que « l’IA remplace les humains », mais sa vraie valeur est en réalité de compléter le travail humain
Je suis en désaccord
je pense qu’il faut écrire soi-même les tests et les comprendre entièrement pour établir une vraie référence, puis seulement ensuite pouvoir laisser l’IA modifier le code en étant serein
si les tests ont eux aussi été produits par un LLM, cela augmente au contraire mon inquiétude à l’idée de confier le reste du code à l’IA
J’ai essayé de faire générer des tests sur du code Rust par un LLM, et dans les faits cela a fait plus de mal que de bien
il y avait beaucoup de tests, mais les zones importantes étaient facilement oubliées
comme la quantité de code était trop grande, il était difficile de voir ce qui n’était pas couvert
et quand il fallait modifier la logique du code plus tard, j’ai dû retoucher tous les nombreux tests générés
Il y a cette idée que « personne ne vérifie les tests, donc on suppose qu’ils sont corrects »
c’est pour cela qu’existe le modèle Arrange-Act-Assert
mes tests unitaires préférés en ce moment consistent à stocker les valeurs d’entrée et les sorties attendues, puis à valider le résultat du code avec ça
cela permet de vérifier facilement même les cas limites et de confirmer que le comportement est bien celui voulu
D’après ce que j’ai compris, l’algorithme RSA aurait aussi été conçu ainsi
selon The Code Book de Simon Singh (je l’ai rangé quelque part et je ne le retrouve plus), Rivest et Shamir proposaient les idées et Adleman jouait le rôle de celui qui trouvait les failles
Voir l’article Wikipédia sur RSA
c’est aussi un exemple de collaboration blue/red team en mathématiques
l’un a beaucoup d’idées, parle beaucoup et manque de structure
l’autre est logique et précis, donc quand l’un rédige une première version d’article, l’autre supprime tout ce qui est inutile
Dans les grandes lignes je suis d’accord, mais le cadrage via l’infosec me semble un peu étrange
la vision selon laquelle « la sécurité vaut son point le plus faible » est trop simpliste et dangereuse
une stratégie de sécurité doit être multicouche
comme on ne peut pas attendre la perfection d’une seule couche, il en faut plusieurs
attaque et défense ne diffèrent pas tant que ça, sauf que beaucoup d’attaquants ont peu de comptes à rendre en cas d’erreur, alors que les défenseurs, surtout dans les grandes entreprises, portent une lourde responsabilité sur les conséquences
mais les défenseurs ont l’avantage de jouer à domicile. L’oublier peut mener à de sérieux problèmes
L’exemple disant que verrouiller la porte ne sert à rien si la fenêtre est ouverte est une bonne analogie
la défense en profondeur a du sens quand plusieurs couches doivent être franchies pour atteindre la cible
mais si porte et fenêtre sont au même niveau, c’est bien l’élément le plus faible qui détermine l’ensemble
dans le web, par exemple, si l’authentification principale est parfaite mais qu’un vieux endpoint comme
/v1/legacy/external_backofficepermet un accès au réseau interne sans aucune authentification, alors toute la défense s’effondrecela dit, s’il existe d’autres mécanismes internes de blocage, les dégâts peuvent être limités, donc les couches défensives restent importantes
J’utilisais simplement l’expression « la défense est aussi forte que son maillon le plus faible » dans un sens plus large
j’ai dépassé la formulation du message d’origine en y ajoutant l’idée d’« effort défensif global », mais en réalité les deux points de vue se défendent
comme le dit Terence, le maillon le plus faible peut réellement être exploité, d’où la nécessité de plusieurs couches de défense
un exemple récent a été celui d’un agent de helpdesk qui réinitialisait les mots de passe clients sans vérification
même avec des technologies de sécurité solides comme un VPN ou la 2FA, ce seul maillon faible, la « récupération de compte », a suffi à tout faire tomber
des couches internes supplémentaires ont ensuite détecté et bloqué l’intrus en trois heures, mais cela relève de la « limitation des dégâts », pas de la « prévention »
au final, il faut plusieurs couches pour contenir les dommages
récemment, l’industrie de l’infosec est elle-même passée d’un objectif de « prévention à 100 % » à un objectif de « réduction d’impact »
comme il est difficile de prévenir tous les risques, la stratégie consiste davantage à réduire le risque, minimiser la surface exposée et abaisser le niveau de confiance
Je ne suis pas du tout expert en sécurité, mais j’ai entendu dire que « une surface d’attaque extrêmement réduite et l’utilisation de protocoles open source éprouvés » constituent la meilleure défense
je me demande en quoi cela diffère de ce dont on parle ici
C’est simplement que l’analogie choisie n’était pas très adaptée
l’expression « maillon le plus faible » est juste quand il faut franchir plusieurs étapes successives
mais s’il y a plusieurs couches ou éléments sur un même niveau, il est logique de viser le plus faible d’entre eux
comme vous le craigniez, cela laisse effectivement place à une interprétation ambiguë
On peut aussi considérer l’attaque comme une autre couche de défense
un peu comme dans l’expression « la meilleure attaque, c’est la meilleure défense »
En cybersécurité, les red teams et blue teams sont deux équipes de force équivalente
mais dans le développement logiciel, je trouve que l’analogie est un peu exagérée
les tests aussi sont du code, et ils gardent des bugs
cela crée un paradoxe du type « Who polices the police? »
Phrase anglaise répétitive et ambiguë, à la manière de Buffalo buffalo
Cela me fait penser à l’idée mentale de John Cleese sur le « mode ouvert vs mode fermé »
on génère d’abord un maximum d’idées dans une posture très ouverte
puis on passe plus tard en mode fermé pour éliminer les mauvaises idées et ne développer que les bonnes
les écrivains de tous les domaines ont généralement aussi des éditeurs
la conception des cartes de Magic: the Gathering fonctionne de façon similaire : l’équipe de design crée une première version du set, puis la transmet à une équipe de développement totalement distincte pour validation
s’il y a d’autres exemples de ce type de collaboration, je serais curieux de les entendre
En pratique, je dirais plutôt l’inverse de ce billet
les LLM excellent pour produire rapidement un premier jet, tandis qu’un humain bien entraîné est plus adapté pour examiner de manière critique le résultat du LLM
donc le LLM convient mieux à l’équipe bleue, et l’humain à l’équipe rouge
Tao semble d’ailleurs faire référence à ce genre de situation extrême
C’est un ressenti que j’ai eu récemment en utilisant des modèles et workflows à base d’agents
ces agents brillent quand on les utilise non seulement pour écrire du code, mais aussi pour les tests, l’administration et même le management
le développeur devient une sorte de manager, c’est-à-dire de superviseur
il se place au-dessus de l’ensemble du processus : planification de la tâche (rédaction des prompts, cadrage du périmètre), écriture des tests et écriture du code
il y a énormément plus de revue, mais comme je joue moi-même le rôle de red team pour vérifier que tout casse moins facilement, j’ai au contraire l’impression d’avoir davantage de contrôle
Je trouve cette perspective frappante
on peut aussi distinguer dans le business une « équipe bleue » (industries d’infrastructure sociale : électricité, pétrole, télécoms, logiciel, finance, etc.) et une « équipe rouge » (industries à valeur ajoutée : restauration, commerce spécialisé, luxe, tourisme, etc.)
économiquement, le camp bleu est bien plus important, parce que ces secteurs servent de base à l’ensemble de l’économie, génèrent une forte demande et doivent minimiser leurs erreurs
à l’inverse, les secteurs rouges ne sont pas indispensables au fonctionnement de l’économie, mais plus ils se développent, plus ils améliorent la qualité globale
dans l’exemple de Tao aussi, le fait qu’un ingénieur logiciel soit mieux payé qu’un QA, ou qu’écrire une preuve soit jugé plus précieux économiquement que la vérifier, relève de la même structure
quand Sam Altman cherche à financer l’entraînement des LLM, il doit insister sur le fait que « nous sommes utiles comme une équipe bleue » pour convaincre les investisseurs, et cela influence tout le récit médiatique
en réalité, les LLM sont plus adaptés à des usages de type red team, mais comme il faut promettre un retour sur investissement, les entreprises continueront à les pousser pour des usages blue team
Google Glasses, la VR et les appareils wearables suivent un schéma similaire
ce sont des technologies de red team utiles dans des niches, mais incapables de créer un énorme écosystème ou une forte rentabilité, donc le capital les ignore
(Je travaille chez Microsoft)
j’exploite directement de la validation automatisée de red team sur des exemples RAG avec le SDK
azure-ai-evaluationici, un LLM adversarial qui sort des rails est combiné au package
pyrit, qui génère automatiquement des questions bizarres à soumettre à l’application, puis transforme aussi les questions elles-mêmes via base64, chiffrement de César, urldecode, etc.les résultats réels sont intéressants, et je suis d’accord pour dire que les LLM sont assez utiles pour les activités de red team
Démo vidéo YouTube
(désolé si le ton de la voix est fort, cela a été filmé dans un endroit un peu particulier)