TL; DR: por extraño que parezca, ver algunos falsos positivos informados por un escáner de seguridad es probablemente una buena señal y ciertamente mejor que no ver ninguno. Expliquemos por qué.
Introducción
Los falsos positivos han hecho una aparición un tanto inesperada en nuestras vidas en los últimos años. Me refiero, por supuesto, a la pandemia de COVID-19, que requirió campañas de pruebas masivas para controlar la propagación del virus. Para que conste, un falso positivo es un resultado que parece positivo (para COVID-19 en nuestro caso), cuando en realidad es negativo (la persona no está infectada). Más comúnmente, hablamos de falsas alarmas.
En seguridad informática, también nos enfrentamos a menudo a falsos positivos. Pregúntele al equipo de seguridad detrás de cualquier SIEM cuál es su mayor desafío operativo, y es probable que se mencionen falsos positivos. Un reciente reporte estima que hasta un 20% de todas las alertas que reciben los profesionales de seguridad son falsos positivos, lo que lo convierte en una gran fuente de fatiga.
Sin embargo, la historia detrás de los falsos positivos no es tan simple como podría parecer al principio. En este artículo, defenderemos que al evaluar una herramienta de análisis, ver una tasa moderada de falsos positivos es una buena señal de eficiencia.
¿De qué estamos hablando exactamente?
Con análisis estático en la seguridad de las aplicaciones, nuestra principal preocupación es captar todos los verdadero vulnerabilidades mediante el análisis del código fuente.
Aquí hay una visualización para comprender mejor la distinción entre dos conceptos fundamentales del análisis estático: precisión y recuperación. La lupa representa la muestra que fue identificada o seleccionada por la herramienta de detección. Puede obtener más información sobre cómo evaluar el rendimiento de un proceso estadístico aquí.
Veamos qué significa eso desde el punto de vista de la ingeniería:
- al reducir los falsos positivos, mejoramos la precisión (todas las vulnerabilidades detectadas en realidad representan un problema de seguridad).
- al reducir los falsos negativos, mejoramos el recuerdo (todas las vulnerabilidades presentes se identifican correctamente).
- con una recuperación del 100 %, la herramienta de detección nunca perdería una vulnerabilidad.
- con una precisión del 100 %, la herramienta de detección nunca generaría una alerta falsa.
Dicho de otra manera, el objetivo de un escáner de vulnerabilidades es ajustar el círculo (en la lupa) lo más cerca posible del rectángulo izquierdo (elementos relevantes).
El problema es que la respuesta rara vez es clara, lo que significa que se deben hacer concesiones.
Entonces, ¿qué es más deseable: maximizar la precisión o recordar?
¿Cuál es peor, demasiados falsos positivos o demasiados falsos negativos?
Para entender por qué, llevémoslo a ambos extremos: imagina que una herramienta de detección solo alerta a sus usuarios cuando la probabilidad de que un determinado código contenga una vulnerabilidad es superior al 99,999%. Con un umbral tan alto, puede estar casi seguro de que una alerta es realmente positiva. Pero, ¿cuántos problemas de seguridad van a pasar desapercibidos debido a la selectividad del escáner? Mucho.
Ahora, por el contrario, ¿qué sucedería si la herramienta se ajustara para no perder nunca una vulnerabilidad (maximizar la recuperación)? Lo has adivinado: pronto te enfrentarás a cientos o incluso miles de alertas falsas. Y ahí yace un peligro mayor.
Como nos advirtió Esopo en su fábula El niño que gritaba lobo, cualquiera que se limite a repetir afirmaciones falsas terminará sin ser escuchado. En nuestro mundo moderno, la incredulidad se materializaría con un simple clic para desactivar las notificaciones de seguridad y restaurar la tranquilidad, o simplemente ignorarlas si no se permite la desactivación. Pero las consecuencias podrían ser al menos tan dramáticas como las de la fábula.
Es justo decir que la fatiga de alerta es probablemente la principal razón por la que el análisis estático falla con tanta frecuencia. Las falsas alarmas no solo son la fuente de fallas de los programas de seguridad de aplicaciones completas, sino que también causan daños mucho más graves, como el agotamiento y la participación.
Y sin embargo, a pesar de todos los males que se les atribuyen, sería un error pensar que si una herramienta no lleva ningún falso positivo, entonces debe traer la respuesta definitiva a este problema.
Cómo aprender a aceptar falsos positivos
Para aceptar falsos positivos, tenemos que ir en contra de ese instinto básico que muchas veces nos empuja a conclusiones tempranas. Otro experimento mental puede ayudarnos a ilustrar esto.
Imagine que tiene la tarea de comparar el rendimiento de dos escáneres de seguridad A y B.
Después de ejecutar ambas herramientas en su punto de referencia, los resultados son los siguientes: el escáner A solo detectó vulnerabilidades válidas, mientras que el escáner B informó tanto vulnerabilidades válidas como no válidas. Llegados a este punto, ¿quién no se sentiría tentado a sacar una conclusión anticipada? Tendrías que ser un observador lo suficientemente sabio como para pedir más datos antes de decidir. Lo más probable es que los datos revelen que algunos secretos válidos informados por B habían sido silenciosamente ignorados por A.
Ahora puede ver la idea básica detrás de este artículo: cualquier herramienta, proceso o empresa que afirme ser completamente libre de falsos positivos debería sonar sospechoso. Si ese fuera realmente el caso, sería muy probable que algunos elementos relevantes se omitan silenciosamente.
Encontrar el equilibrio entre la precisión y la recuperación es un asunto sutil y requiere muchos esfuerzos de ajuste (puede leer cómo los ingenieros de GitGuardian están mejorando la modelo de precisión). No solo eso, sino que también es absolutamente normal verlo fallar ocasionalmente. Es por eso que debería estar más preocupado por no tener falsos positivos que por ver pocos.
Pero también hay otra razón por la que los falsos positivos también podrían ser una señal interesante: la seguridad nunca es “totalmente blanca o totalmente negra”. Siempre hay un margen donde “no sabemos”, y
donde el escrutinio humano y el triaje se vuelven esenciales.
“Debido a la naturaleza del software que escribimos, a veces obtenemos falsos positivos. Cuando eso sucede, nuestros desarrolladores pueden completar un formulario y decir: “Oye, esto es un falso positivo”. Esto es parte de un caso de prueba. Puedes ignorar esto”. — Fuente.
Ahí reside una verdad más profunda: la seguridad nunca es “totalmente blanca o totalmente negra”. Siempre hay un margen en el que “no sabemos”, y en el que el escrutinio y la clasificación humanos se vuelven esenciales. En otras palabras, no se trata solo de números en bruto, también se trata de cómo se utilizarán. Los falsos positivos son útiles desde esa perspectiva: ayudan a mejorar las herramientas y refinan los algoritmos para que el contexto se entienda y se considere mejor. Pero como una asíntota, nunca se puede alcanzar el 0 absoluto.
Sin embargo, hay una condición necesaria para transformar lo que parece una maldición en un círculo virtuoso. Debe asegurarse de que los falsos positivos se puedan marcar e incorporar en el algoritmo de detección lo más fácilmente posible para los usuarios finales. Una de las formas más comunes de lograrlo es simplemente ofrecer la posibilidad de excluir archivos, directorios o repositorios del perímetro escaneado.
En GitGuardian, estamos especializados en detección de secretos. Impulsamos la idea de mejorar cualquier hallazgo con la mayor cantidad de contexto posible, lo que lleva a ciclos de retroalimentación mucho más rápidos y alivia la mayor cantidad de trabajo posible.
Si un desarrollador intenta confirmar un secreto con el lado del cliente Escudo instalado como un enlace previo a la confirmación, la confirmación se detendrá a menos que el desarrollador lo marca como un secreto para ignorar. A partir de ahí, el secreto se considera un falso positivo y ya no activará una alerta, sino solo en su estación de trabajo local. Solo un miembro del equipo de seguridad con acceso al panel de control de GitGuardian puede marcar un falso positivo para todo el equipo (ignorar globalmente).
Si se informa un secreto filtrado, proporcionamos herramientas para ayudar al equipo de seguridad a despacharlo rápidamente. por ejemplo, el manual de recuperación automática envía automáticamente un correo electrónico al desarrollador que confió el secreto. Dependiendo de la configuración del libro de jugadas, se puede permitir que los desarrolladores resuelvan o ignoren el incidente por sí mismos, aligerando la cantidad de trabajo que le queda al equipo de seguridad.
Estos son solo algunos ejemplos de cómo aprendimos a adaptar los procesos de detección y remediación en torno a los falsos positivos, en lugar de obsesionarnos con eliminarlos. En estadística, esta obsesión incluso tiene un nombre: se llama sobreajuste y significa que su modelo depende demasiado de un conjunto particular de datos. Al carecer de entradas del mundo real, el modelo no sería útil en un entorno de producción.
Conclusión
Los falsos positivos causan fatiga de alertas y descarrilan los programas de seguridad con tanta frecuencia que ahora se los considera pura maldad. Es cierto que al considerar una herramienta de detección, desea la mejor precisión posible, y tener demasiados falsos positivos causa más problemas que no usar ninguna herramienta en primer lugar. Dicho esto, nunca pase por alto la tasa de recuperación.
En GitGuardian, diseñamos un amplio arsenal de genérico filtros de detección para mejorar la tasa de recuperación de nuestro motor de detección de secretos.
Desde una perspectiva puramente estadística, tener una baja tasa de falsos positivos es una buena señal, lo que significa que pocos defectos pasan por la red.
cuando tiene el controllos falsos positivos no son que malo. Incluso se pueden utilizar a su favor, ya que indican dónde se pueden realizar mejoras, tanto en el lado del análisis como en el lado de la remediación.
Comprender por qué el sistema consideró algo “válido” y tener una forma de adaptarse a él es clave para mejorar la seguridad de su aplicación. También estamos convencidos de que es una de las áreas donde realmente brilla la colaboración entre los equipos de seguridad y desarrollo.
Como nota final, recuerde: si una herramienta de detección no informa ningún falsos positivos, corre. Estás en un gran problema.
Nota: este artículo está escrito y contribuido por Thomas Segura, escritor de contenido técnico en GitGuardian.