TL; DR: por extra\u00f1o que parezca, ver algunos falsos positivos informados por un esc\u00e1ner de seguridad es probablemente una buena se\u00f1al y ciertamente mejor que no ver ninguno. Expliquemos por qu\u00e9.<\/p>\n
Introducci\u00f3n<\/h2>\n
Los falsos positivos han hecho una aparici\u00f3n un tanto inesperada en nuestras vidas en los \u00faltimos a\u00f1os. Me refiero, por supuesto, a la pandemia de COVID-19, que requiri\u00f3 campa\u00f1as de pruebas masivas para controlar la propagaci\u00f3n 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\u00e1 infectada). M\u00e1s com\u00fanmente, hablamos de falsas alarmas.<\/p>\n
En seguridad inform\u00e1tica, tambi\u00e9n nos enfrentamos a menudo a falsos positivos. Preg\u00fantele al equipo de seguridad detr\u00e1s de cualquier SIEM cu\u00e1l es su mayor desaf\u00edo operativo, y es probable que se mencionen falsos positivos. Un reciente reporte<\/a> 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.<\/p>\n Sin embargo, la historia detr\u00e1s de los falsos positivos no es tan simple como podr\u00eda parecer al principio. En este art\u00edculo, defenderemos que al evaluar una herramienta de an\u00e1lisis, ver una tasa moderada de falsos positivos es una buena se\u00f1al de eficiencia. <\/p>\n Con an\u00e1lisis est\u00e1tico<\/a> en la seguridad de las aplicaciones, nuestra principal preocupaci\u00f3n es captar todos los verdadero<\/em> vulnerabilidades mediante el an\u00e1lisis del c\u00f3digo fuente.<\/p>\n Aqu\u00ed hay una visualizaci\u00f3n para comprender mejor la distinci\u00f3n entre dos conceptos fundamentales del an\u00e1lisis est\u00e1tico: precisi\u00f3n y recuperaci\u00f3n. La lupa representa la muestra que fue identificada o seleccionada por la herramienta de detecci\u00f3n. Puede obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo evaluar el rendimiento de un proceso estad\u00edstico aqu\u00ed<\/a>.<\/p>\n Veamos qu\u00e9 significa eso desde el punto de vista de la ingenier\u00eda: <\/p>\n Dicho de otra manera, el objetivo de un esc\u00e1ner de vulnerabilidades es ajustar el c\u00edrculo (en la lupa) lo m\u00e1s cerca posible del rect\u00e1ngulo izquierdo (elementos relevantes).<\/p>\n El problema es que la respuesta rara vez es clara, lo que significa que se deben hacer concesiones. <\/p>\n Entonces, \u00bfqu\u00e9 es m\u00e1s deseable: maximizar la precisi\u00f3n o recordar? <\/p>\n Para entender por qu\u00e9, llev\u00e9moslo a ambos extremos: imagina que una herramienta de detecci\u00f3n solo alerta a sus usuarios cuando la probabilidad de que un determinado c\u00f3digo 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, \u00bfcu\u00e1ntos problemas de seguridad van a pasar desapercibidos debido a la selectividad del esc\u00e1ner? Mucho. <\/p>\n Ahora, por el contrario, \u00bfqu\u00e9 suceder\u00eda si la herramienta se ajustara para no perder nunca una vulnerabilidad (maximizar la recuperaci\u00f3n)? Lo has adivinado: pronto te enfrentar\u00e1s a cientos o incluso miles de alertas falsas. Y ah\u00ed yace un peligro mayor. <\/p>\n Como nos advirti\u00f3 Esopo en su f\u00e1bula El ni\u00f1o que gritaba lobo<\/em><\/a>, cualquiera que se limite a repetir afirmaciones falsas terminar\u00e1 sin ser escuchado. En nuestro mundo moderno, la incredulidad se materializar\u00eda con un simple clic para desactivar las notificaciones de seguridad y restaurar la tranquilidad, o simplemente ignorarlas si no se permite la desactivaci\u00f3n. Pero las consecuencias podr\u00edan ser al menos tan dram\u00e1ticas como las de la f\u00e1bula. <\/p>\n Es justo decir que la fatiga de alerta es probablemente la principal raz\u00f3n por la que el an\u00e1lisis est\u00e1tico 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\u00e9n causan da\u00f1os mucho m\u00e1s graves, como el agotamiento y la participaci\u00f3n.<\/p>\n Y sin embargo, a pesar de todos los males que se les atribuyen, ser\u00eda un error pensar que si una herramienta no lleva ning\u00fan falso positivo, entonces debe traer la respuesta definitiva a este problema.<\/p>\n Para aceptar falsos positivos, tenemos que ir en contra de ese instinto b\u00e1sico que muchas veces nos empuja a conclusiones tempranas. Otro experimento mental puede ayudarnos a ilustrar esto. <\/p>\n Imagine que tiene la tarea de comparar el rendimiento de dos esc\u00e1neres de seguridad A y B. <\/p>\n Despu\u00e9s de ejecutar ambas herramientas en su punto de referencia, los resultados son los siguientes: el esc\u00e1ner A solo detect\u00f3 vulnerabilidades v\u00e1lidas, mientras que el esc\u00e1ner B inform\u00f3 tanto vulnerabilidades v\u00e1lidas como no v\u00e1lidas.<\/strong> Llegados a este punto, \u00bfqui\u00e9n no se sentir\u00eda tentado a sacar una conclusi\u00f3n anticipada? Tendr\u00edas que ser un observador lo suficientemente sabio como para pedir m\u00e1s datos antes de decidir. Lo m\u00e1s probable es que los datos revelen que algunos secretos v\u00e1lidos informados por B hab\u00edan sido silenciosamente ignorados por A.<\/strong><\/p>\n Ahora puede ver la idea b\u00e1sica detr\u00e1s de este art\u00edculo: cualquier herramienta, proceso o empresa que afirme ser completamente libre<\/em> de falsos positivos deber\u00eda sonar sospechoso. Si ese fuera realmente el caso, ser\u00eda muy probable que algunos elementos relevantes se omitan silenciosamente. <\/p>\n Encontrar el equilibrio entre la precisi\u00f3n y la recuperaci\u00f3n es un asunto sutil y requiere muchos esfuerzos de ajuste (puede leer c\u00f3mo los ingenieros de GitGuardian est\u00e1n mejorando la modelo de precisi\u00f3n<\/a>). No solo eso, sino que tambi\u00e9n es absolutamente normal verlo fallar ocasionalmente. Es por eso que deber\u00eda estar m\u00e1s preocupado por no tener falsos positivos que por ver pocos.<\/p>\n Pero tambi\u00e9n hay otra raz\u00f3n por la que los falsos positivos tambi\u00e9n podr\u00edan ser una se\u00f1al interesante: la seguridad nunca es “totalmente blanca o totalmente negra”. Siempre hay un margen donde “no sabemos”, y<\/p>\n donde el escrutinio humano y el triaje se vuelven esenciales.<\/p>\n “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”. <\/em>\u2014 <\/i>Fuente<\/a>.<\/p>\n Ah\u00ed reside una verdad m\u00e1s 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\u00f3n humanos se vuelven esenciales. En otras palabras, no se trata solo de n\u00fameros en bruto, tambi\u00e9n se trata de c\u00f3mo<\/em> se utilizar\u00e1n. Los falsos positivos son \u00fatiles 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\u00edntota, nunca se puede alcanzar el 0 absoluto.<\/p>\n Sin embargo, hay una condici\u00f3n necesaria para transformar lo que parece una maldici\u00f3n en un c\u00edrculo virtuoso. Debe asegurarse de que los falsos positivos se puedan marcar e incorporar en el algoritmo de detecci\u00f3n lo m\u00e1s f\u00e1cilmente posible para los usuarios finales. Una de las formas m\u00e1s comunes de lograrlo es simplemente ofrecer la posibilidad de excluir archivos, directorios o repositorios del per\u00edmetro escaneado. <\/p>\n En GitGuardian, estamos especializados en detecci\u00f3n de secretos<\/a>. Impulsamos la idea de mejorar cualquier hallazgo con la mayor cantidad de contexto posible, lo que lleva a ciclos de retroalimentaci\u00f3n mucho m\u00e1s r\u00e1pidos y alivia la mayor cantidad de trabajo posible.<\/p>\n Si un desarrollador intenta confirmar un secreto con el lado del cliente Escudo<\/a> instalado como un enlace previo a la confirmaci\u00f3n, la confirmaci\u00f3n se detendr\u00e1 a menos que el desarrollador lo marca como un secreto para ignorar<\/a>. A partir de ah\u00ed, el secreto se considera un falso positivo y ya no activar\u00e1 una alerta, sino solo en su estaci\u00f3n 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).<\/p>\n Si se informa un secreto filtrado, proporcionamos herramientas para ayudar al equipo de seguridad a despacharlo r\u00e1pidamente. por ejemplo, el manual de recuperaci\u00f3n autom\u00e1tica<\/a> env\u00eda autom\u00e1ticamente un correo electr\u00f3nico al desarrollador que confi\u00f3 el secreto. Dependiendo de la configuraci\u00f3n del libro de jugadas, se puede permitir que los desarrolladores resuelvan o ignoren el incidente por s\u00ed mismos, aligerando la cantidad de trabajo que le queda al equipo de seguridad.<\/p>\n Estos son solo algunos ejemplos de c\u00f3mo aprendimos a adaptar los procesos de detecci\u00f3n y remediaci\u00f3n en torno a los falsos positivos, en lugar de obsesionarnos con eliminarlos. En estad\u00edstica, esta obsesi\u00f3n 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\u00eda \u00fatil en un entorno de producci\u00f3n.<\/p>\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\u00f3n, desea la mejor precisi\u00f3n posible, y tener demasiados falsos positivos causa m\u00e1s problemas que no usar ninguna herramienta en primer lugar. Dicho esto, nunca pase por alto la tasa de recuperaci\u00f3n. <\/p>\n\u00bfDe qu\u00e9 estamos hablando exactamente?<\/h2>\n
![\"Falsos](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2022\/08\/1660074443_438_La-verdad-sobre-los-falsos-positivos-en-seguridad.jpg\" "\\"Falsos")
<\/div>\n![\"Falsos](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2022\/08\/1660074443_862_La-verdad-sobre-los-falsos-positivos-en-seguridad.jpg\" "\\"Falsos")
<\/div>\n\n
\u00bfCu\u00e1l es peor, demasiados falsos positivos o demasiados falsos negativos?<\/h2>\n
![\"Falsos](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2022\/08\/1660074443_629_La-verdad-sobre-los-falsos-positivos-en-seguridad.jpg\" "\\"Falsos")
<\/div>\nC\u00f3mo aprender a aceptar falsos positivos<\/h2>\n
Conclusi\u00f3n<\/h2>\n