Créer des outils efficaces pour la détection de sécurité
On a examiné deux scénarios pour développer des outils de sécurité contre les attaques.
Samuele Pasini, Jinhan Kim, Tommaso Aiello, Rocio Cabrera Lozoya, Antonino Sabetta, Paolo Tonella
― 8 min lire
Table des matières
- Les Deux Scénarios
- Pas de Jeu de Données d'Entraînement (NTD)
- Jeu de Données d'Entraînement Disponible (TDA)
- Questions de Recherche
- RQ1 : À quel point RAG aide-t-il à générer de meilleurs outils de sécurité ?
- RQ2 : Le Self-Ranking est-il une bonne stratégie ?
- RQ3 : Comment nos fonctions générées par LLM se comparent-elles aux modèles à la pointe ?
- RQ4 : Peut-on utiliser les meilleures pratiques d'une tâche dans une autre ?
- Les Modèles Qu'on a Utilisés
- Comment On A Mis en Place l'Expérience
- Génération de Fonctions
- Génération d'Ensembles de Données
- Sélection des Meilleures Fonctions
- Évaluation des Résultats
- Métriques d'Évaluation
- Résultats du Scénario NTD
- Résultats du Scénario TDA
- Le Défi de la Transférabilité
- Conclusion
- Source originale
- Liens de référence
Bienvenue dans le monde de la détection de sécurité ! Imagine un endroit où les ordinateurs sont constamment attaqués par des hackers embêtants. Notre mission est de trouver des moyens astucieux de créer des outils qui aident à attraper ces méchants numériques. On a deux scénarios à explorer : un où les développeurs n'ont pas de données précédentes à partir desquelles apprendre (on appelle ça le scénario NTD) et un autre où ils en ont (on l'appelle le scénario TDA).
Ici, on va voir comment on peut créer des outils pour identifier les attaques de sécurité, déterminer les meilleures méthodes à utiliser et voir comment ces outils fonctionnent. Alors, prends un snack et plongeons dans le royaume de la détection de sécurité !
Les Deux Scénarios
Pas de Jeu de Données d'Entraînement (NTD)
Dans ce premier scénario, les développeurs sont comme des chefs sans ingrédients. Ils veulent préparer un plat savoureux (dans ce cas, un outil de sécurité) mais n'ont pas les bons matériaux (le jeu de données d'entraînement). Ils ne peuvent pas évaluer ou comparer différents modèles ou configurations parce qu'ils partent de zéro. Ils ne peuvent pas dire quel modèle, température, ou type de prompt donne les meilleurs résultats.
Alors, que font-ils ? Ils regardent juste comment l'outil fonctionne contre des attaques réelles et moyennent les résultats de différents choix. C'est un peu comme lancer des spaghettis contre le mur pour voir ce qui colle ! Ils vérifient comment les outils de sécurité peuvent attraper les attaques quand ils ne peuvent pas les entraîner avec des données précédentes.
Jeu de Données d'Entraînement Disponible (TDA)
Maintenant, jetons un œil à notre deuxième scénario où les développeurs sont comme des chefs avec un garde-manger bien garni. Ils ont un jeu de données d'entraînement étiqueté, ce qui signifie qu'ils peuvent vraiment entraîner leurs modèles de sécurité pour détecter les attaques ! Ils peuvent diviser ce jeu de données en parties d'entraînement et de validation, ce qui leur permet de tester et de comparer différents outils efficacement.
Dans ce scénario, ils peuvent voir quel outil fonctionne le mieux, ajuster les réglages, et se sentir comme des pros dans une compétition de cuisine. Ils peuvent même choisir de comparer la performance de leur propre outil contre les meilleures méthodes existantes !
Questions de Recherche
Maintenant qu'on a nos deux scénarios de cuisine en place, préparons quelques questions qu'on veut explorer :
RAG aide-t-il à générer de meilleurs outils de sécurité ?
RQ1 : À quel pointCette question porte sur la méthode RAG comme un ingrédient magique dans notre boîte à outils de sécurité. On veut voir comment ça fonctionne, surtout quand c'est associé à des exemples pour guider le processus.
RQ2 : Le Self-Ranking est-il une bonne stratégie ?
Celle-ci demande si choisir les meilleures fonctions en utilisant le Self-Ranking rend nos outils plus fiables. C'est comme demander si le chef doit goûter chaque plat et ensuite choisir ses préférés.
RQ3 : Comment nos fonctions générées par LLM se comparent-elles aux modèles à la pointe ?
Ici, on est curieux de savoir si nos outils de sécurité faits maison peuvent rivaliser avec les meilleurs modèles déjà présents.
RQ4 : Peut-on utiliser les meilleures pratiques d'une tâche dans une autre ?
Enfin, cette question plonge dans l'idée de savoir si on peut emprunter les meilleures techniques de cuisine apprises d'un plat pour nous aider à préparer un autre plat, complètement différent.
Les Modèles Qu'on a Utilisés
Un bon chef a besoin de plusieurs outils ! On a testé neuf modèles différents dans nos expériences. Chaque modèle a ses propres forces et faiblesses, donc on s'est assuré d'évaluer leurs Performances avec soin. Certains modèles sont des vieux favoris, tandis que d'autres sont nouveaux et brillants, prêts à impressionner !
Comment On A Mis en Place l'Expérience
Pour commencer dans notre cuisine, on a dû établir des règles et rassembler nos ingrédients :
-
Configurations de Modèle : Pense à ça comme à différentes recettes, où chaque recette a un modèle précis et un réglage de température.
-
Configurations de Prompt : On a aussi joué avec le nombre d'exemples fournis et si on utilisait RAG pour rendre nos prompts plus stylés.
-
Génération de Données : Pour chaque expérience, on a généré plusieurs fonctions et ensembles de données pour garder les choses fraîches et intéressantes. Après tout, un bon chef ne s'en tient pas à une seule méthode de cuisine !
Génération de Fonctions
Dans notre quête, on a généré des fonctions qui nous aideraient à attraper ces attaques embêtantes. On a donné aux modèles une série de prompts, les incitant à trouver des solutions. Ce processus a été répété plusieurs fois pour garantir la variété dans nos résultats, tout comme un chef qui expérimente avec différentes saveurs.
Génération d'Ensembles de Données
La prochaine partie de notre aventure culinaire impliquait de créer des ensembles de données synthétiques. Ça a été fait en nourrissant les modèles avec des prompts spécialement conçus qui leur demandaient de produire des exemples d'attaques. On a veillé à équilibrer les bons et les mauvais exemples-après tout, on ne peut pas avoir un plat déséquilibré !
Sélection des Meilleures Fonctions
Une fois qu'on a créé nos fonctions, il était temps de choisir le meilleur du meilleur. Ça a été fait en utilisant des métriques de performance basées sur nos précédents résultats de test. On a trié nos fonctions générées et sélectionné les meilleures comme un chef mettant en avant ses plats phares.
Évaluation des Résultats
Maintenant qu'on avait nos plats préférés (fonctions et ensembles de données), il était temps de faire des tests ! On avait deux méthodes principales pour tester :
-
Sans Classement : On a vérifié comment les fonctions générées fonctionnaient toutes seules.
-
Avec Classement : On a comparé ces fonctions en fonction de notre jeu de données de validation pour voir lesquelles se démarquaient.
En évaluant la qualité de nos fonctions, on pouvait déterminer lesquelles étaient vraiment la crème de la crème !
Métriques d'Évaluation
Dans notre aventure culinaire, on a mis un accent particulier sur le fait de ne pas rater d'attaques. Donc, on a utilisé le Score F2, qui donne plus de poids à la détection des attaques, comme notre métrique principale. On voulait s'assurer que nos outils pouvaient trouver les méchants cachés dans l'ombre !
On a aussi veillé à tester nos fonctions sous différents angles, en vérifiant des métriques comme la précision et le Score F1 pour confirmer nos résultats.
Résultats du Scénario NTD
Quand on a testé nos modèles dans le scénario NTD, on a vu des résultats intéressants. On voulait savoir si RAG était vraiment utile pour générer de meilleurs outils. Après une analyse soigneuse, les données ont montré que RAG a effectivement apporté une petite touche de magie à nos fonctions !
Résultats du Scénario TDA
Dans le scénario TDA, on a comparé la performance de nos modèles avec des méthodes de sécurité de haut niveau. Les résultats étaient prometteurs ! Nos fonctions générées par LLM étaient de solides concurrentes et ont montré que des outils faits maison pouvaient rivaliser avec les grands noms !
Le Défi de la Transférabilité
Enfin, on a regardé si on pouvait emprunter nos meilleures pratiques apprises d'une tâche et les appliquer à une autre. Réfléchis-y : un chef qui est bon en pâtisserie peut-il aussi préparer un plat de pâtes fantastique ? Nos résultats ont suggéré qu'il y a du potentiel pour transférer des connaissances entre les tâches, soutenant l'intuition du chef !
Conclusion
En résumé de notre expérience, on a beaucoup appris sur la création d'outils efficaces pour attraper les attaques de sécurité. Avec la bonne configuration, même une petite équipe de développeurs peut concocter quelque chose de génial, peu importe les ingrédients à disposition.
Donc la prochaine fois que tu vois un outil de sécurité en action, souviens-toi des chefs derrière les coulisses-expérimentant, goûtant et peaufiner jusqu'à ce qu'ils créent quelque chose de vraiment spécial ! Voici à l'univers de la détection de sécurité et à l'art culinaire impliqué dans la création d'un espace numérique plus sûr !
Titre: Evaluating and Improving the Robustness of Security Attack Detectors Generated by LLMs
Résumé: Large Language Models (LLMs) are increasingly used in software development to generate functions, such as attack detectors, that implement security requirements. However, LLMs struggle to generate accurate code, resulting, e.g., in attack detectors that miss well-known attacks when used in practice. This is most likely due to the LLM lacking knowledge about some existing attacks and to the generated code being not evaluated in real usage scenarios. We propose a novel approach integrating Retrieval Augmented Generation (RAG) and Self-Ranking into the LLM pipeline. RAG enhances the robustness of the output by incorporating external knowledge sources, while the Self-Ranking technique, inspired to the concept of Self-Consistency, generates multiple reasoning paths and creates ranks to select the most robust detector. Our extensive empirical study targets code generated by LLMs to detect two prevalent injection attacks in web security: Cross-Site Scripting (XSS) and SQL injection (SQLi). Results show a significant improvement in detection performance compared to baselines, with an increase of up to 71%pt and 37%pt in the F2-Score for XSS and SQLi detection, respectively.
Auteurs: Samuele Pasini, Jinhan Kim, Tommaso Aiello, Rocio Cabrera Lozoya, Antonino Sabetta, Paolo Tonella
Dernière mise à jour: 2024-11-27 00:00:00
Langue: English
Source URL: https://arxiv.org/abs/2411.18216
Source PDF: https://arxiv.org/pdf/2411.18216
Licence: https://creativecommons.org/licenses/by/4.0/
Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.
Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.
Liens de référence
- https://anonymised-site/moderate-social-media&t=1396533765893&n=1129109&k=mainentity
- https://anonymised-site/guestbook/index.php?lang="><script>alert
- https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html
- https://websec.wordpress.com/2010/12/04/sqli-filter-evasion-cheat-sheet-mysql/
- https://github.com/fmereani/Cross-Site-Scripting-XSS/blob/master/XSSDataSets/Payloads.csv
- https://www.langchain.com/
- https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
- https://github.com/PasiniSamuele/Robust-Attack-Detectors-LLM