Creando herramientas efectivas para la detección de seguridad
Examinamos dos escenarios para desarrollar herramientas de seguridad contra ataques.
Samuele Pasini, Jinhan Kim, Tommaso Aiello, Rocio Cabrera Lozoya, Antonino Sabetta, Paolo Tonella
― 7 minilectura
Tabla de contenidos
- Los Dos Escenarios
- Sin Conjunto de datos de entrenamiento (NTD)
- Conjunto de Datos de Entrenamiento Disponible (TDA)
- Preguntas de Investigación
- RQ1: ¿Qué tan útil es RAG para generar mejores herramientas de seguridad?
- RQ2: ¿Es la Auto-Ranking una buena estrategia?
- RQ3: ¿Cómo se comparan nuestras funciones generadas por LLM con modelos de última generación?
- RQ4: ¿Podemos usar las mejores prácticas de una tarea en otra?
- Los Modelos que Usamos
- Cómo Configuramos el Experimento
- Generación de Funciones
- Generación de Conjuntos de Datos
- Selección de las Mejores Funciones
- Evaluación de los Resultados
- Métricas para la Evaluación
- Resultados del Escenario NTD
- Resultados del Escenario TDA
- El Desafío de la Transferibilidad
- Conclusión
- Fuente original
- Enlaces de referencia
¡Bienvenido al mundo de la detección de seguridad! Imagina un lugar donde las computadoras están constantemente atacadas por molestos hackers. Nuestra misión es encontrar formas ingeniosas de crear herramientas que ayuden a atrapar a estos villanos digitales. Tenemos dos escenarios para investigar: uno donde los desarrolladores no tienen datos previos de los que aprender (lo llamamos escenario NTD) y otro donde sí (lo llamamos escenario TDA).
Aquí, vamos a explorar cómo podemos crear herramientas para identificar ataques de seguridad, averiguar qué métodos son los mejores y ver qué tan bien funcionan estas herramientas. Así que, agarra un snack y ¡vamos a sumergirnos en el mundo de la detección de seguridad!
Los Dos Escenarios
Conjunto de datos de entrenamiento (NTD)
SinEn este primer escenario, los desarrolladores son como chefs sin ingredientes. Quieren preparar un platillo delicioso (en este caso, una herramienta de seguridad) pero no tienen los materiales adecuados (el conjunto de datos de entrenamiento). No pueden evaluar ni comparar diferentes modelos o configuraciones porque están empezando desde cero. No pueden decir qué modelo, temperatura o tipo de indicación produce los mejores resultados.
Entonces, ¿qué hacen? Solo ven cómo se desempeña la herramienta contra ataques del mundo real y promedian los resultados de diferentes elecciones. ¡Es un poco como lanzar espagueti a la pared a ver qué se queda pegado! Checan qué tan bien las herramientas de seguridad pueden atrapar ataques cuando no pueden entrenarlas con datos previos.
Conjunto de Datos de Entrenamiento Disponible (TDA)
Ahora, echemos un vistazo a nuestro segundo escenario donde los desarrolladores son como chefs con una despensa completamente llena. Tienen un conjunto de datos de entrenamiento etiquetado, lo que significa que realmente pueden entrenar sus modelos de seguridad para detectar ataques. Pueden dividir este conjunto de datos en partes de entrenamiento y validación, permitiéndoles probar y comparar diferentes herramientas de manera efectiva.
En este escenario, pueden ver qué herramienta funciona mejor, ajustar la configuración y sentirse como pros en una competencia de cocina. ¡Incluso pueden elegir comparar el rendimiento de su propia herramienta contra los mejores métodos existentes!
Preguntas de Investigación
Ahora que tenemos nuestros dos escenarios de cocina listos, vamos a plantear algunas preguntas que queremos explorar:
RAG para generar mejores herramientas de seguridad?
RQ1: ¿Qué tan útil esEsta pregunta trata sobre si el método RAG es un ingrediente mágico en nuestra caja de herramientas de seguridad. Queremos ver cómo se desempeña, especialmente cuando se combina con ejemplos para guiar el proceso.
RQ2: ¿Es la Auto-Ranking una buena estrategia?
Esta pregunta pregunta si elegir las mejores funciones usando Auto-Ranking hace que nuestras herramientas sean más confiables. Es como preguntar si el chef debería probar cada platillo y luego elegir sus favoritos.
RQ3: ¿Cómo se comparan nuestras funciones generadas por LLM con modelos de última generación?
Aquí, nos da curiosidad si nuestras herramientas de seguridad caseras pueden estar a la par con los mejores modelos que ya existen.
RQ4: ¿Podemos usar las mejores prácticas de una tarea en otra?
Finalmente, esta pregunta profundiza en si podemos tomar las mejores técnicas de cocina aprendidas de un platillo para ayudarnos a preparar otro completamente diferente.
Los Modelos que Usamos
¡Un buen chef necesita una variedad de herramientas! Probamos nueve modelos diferentes en nuestros experimentos. Cada modelo tiene sus propias fortalezas y debilidades, así que nos aseguramos de evaluar su Desempeño cuidadosamente. Algunos modelos son viejos favoritos, mientras que otros son nuevos y relucientes, listos para impresionar.
Cómo Configuramos el Experimento
Para comenzar en nuestra cocina, tuvimos que establecer algunas reglas y reunir nuestros ingredientes:
-
Configuraciones del Modelo: Piensa en estas como diferentes recetas, donde cada receta tiene un modelo específico y una configuración de temperatura.
-
Configuraciones de Indicación: También jugamos con el número de ejemplos que proporcionamos y si usamos RAG para hacer nuestras indicaciones más elegantes.
-
Generación de Datos: Para cada experimento, generamos múltiples funciones y conjuntos de datos para mantener las cosas frescas e interesantes. Después de todo, un buen chef no se apega a un solo estilo de cocina.
Generación de Funciones
En nuestra búsqueda, generamos funciones que nos ayudarían a atrapar esos molestos ataques. Alimentamos a los modelos con una serie de indicaciones, instándolos a encontrar soluciones. Este proceso se repitió múltiples veces para asegurar variedad en nuestros resultados, así como un chef experimenta con diferentes sabores.
Generación de Conjuntos de Datos
La siguiente parte de nuestra aventura culinaria involucró la creación de conjuntos de datos sintéticos. Esto se hizo alimentando a los modelos con indicaciones especialmente diseñadas que les pedían producir ejemplos de ataques. Nos aseguramos de equilibrar los buenos y malos ejemplos; después de todo, ¡no podemos tener un platillo desbalanceado!
Selección de las Mejores Funciones
Una vez que creamos nuestras funciones, era hora de elegir las mejores de entre las mejores. Esto se hizo usando métricas de rendimiento basadas en nuestros resultados de pruebas anteriores. Clasificamos nuestras funciones generadas y seleccionamos a las mejores como un chef que muestra sus platillos insignia.
Evaluación de los Resultados
Ahora que teníamos nuestros platillos favoritos (funciones y conjuntos de datos), ¡era hora de probarlos! Tuvimos dos métodos principales para probar:
-
Sin Clasificación: Verificamos qué tan bien se desempeñaron las funciones generadas por su cuenta.
-
Con Clasificación: Comparamos esas funciones basado en nuestro conjunto de datos de validación para ver cuáles se destacaban.
Al evaluar la calidad de nuestras funciones, pudimos determinar cuáles eran realmente la crème de la crème.
Métricas para la Evaluación
En nuestro viaje culinario, pusimos un énfasis extra en no perder ningún ataque. Así que usamos el F2 Score, que da más peso a atrapar ataques, como nuestra métrica principal. ¡Queríamos asegurarnos de que nuestras herramientas pudieran encontrar a los villanos escondidos en las sombras!
También nos aseguramos de probar nuestras funciones desde diferentes ángulos, verificando métricas como precisión y F1 Score para confirmar nuestros resultados.
Resultados del Escenario NTD
Cuando pusimos a prueba nuestros modelos en el escenario NTD, vimos algunos resultados interesantes. Queríamos saber si RAG era realmente útil para generar mejores herramientas. Después de un análisis cuidadoso, los datos mostraron que RAG le dio efectivamente un poco de magia a nuestras funciones.
Resultados del Escenario TDA
En el escenario TDA, comparamos el rendimiento de nuestros modelos contra métodos de seguridad de primera clase. ¡Los resultados fueron prometedores! Nuestras funciones generadas por LLM eran contendientes sólidos y demostraron que las herramientas caseras podían competir contra los grandes jugadores.
El Desafío de la Transferibilidad
Finalmente, miramos si podríamos tomar nuestras mejores prácticas aprendidas de una tarea y aplicarlas a otra. Piensa en esto: ¿podría un chef que es bueno en pasteles también preparar un fantástico platillo de pasta? Nuestros hallazgos sugirieron que hay potencial para transferir conocimientos entre tareas, ¡apoyando la intuición del chef!
Conclusión
Al finalizar nuestro experimento, aprendimos mucho sobre cómo crear herramientas efectivas para atrapar ataques de seguridad. Con la configuración correcta, incluso un pequeño equipo de desarrolladores puede cocinar algo genial, sin importar los ingredientes que tengan a mano.
Así que la próxima vez que veas una herramienta de seguridad en acción, recuerda a los chefs detrás de escena-experimentando, probando y perfeccionando hasta crear algo verdaderamente especial. ¡Brindemos por el mundo de la detección de seguridad y el arte culinario involucrado en hacer del espacio digital un lugar más seguro!
Título: Evaluating and Improving the Robustness of Security Attack Detectors Generated by LLMs
Resumen: 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.
Autores: Samuele Pasini, Jinhan Kim, Tommaso Aiello, Rocio Cabrera Lozoya, Antonino Sabetta, Paolo Tonella
Última actualización: 2024-11-27 00:00:00
Idioma: English
Fuente URL: https://arxiv.org/abs/2411.18216
Fuente PDF: https://arxiv.org/pdf/2411.18216
Licencia: https://creativecommons.org/licenses/by/4.0/
Cambios: Este resumen se ha elaborado con la ayuda de AI y puede contener imprecisiones. Para obtener información precisa, consulte los documentos originales enlazados aquí.
Gracias a arxiv por el uso de su interoperabilidad de acceso abierto.
Enlaces de referencia
- 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