Por qué nos equivocamos en la gestión de vulnerabilidades


A veces, demasiada información es una bendición mixta. Los equipos de seguridad utilizan múltiples escáneres de vulnerabilidades en un intento de hacer frente a un aumento significativo tanto en la diversidad de la superficie de ataque como en las vulnerabilidades del program.

Pero pronto se ven abrumados por los resultados, lo que lleva a una creciente acumulación de errores que deben corregirse. Este retraso tiene múltiples impactos negativos. Ralentiza el proceso de desarrollo porque las fallas tardan en repararse, e ignorarlas conduce a una cantidad excesiva de deuda tecnológica.

Muchos equipos están utilizando prácticas obsoletas y datos limitados, que según los estudios no conducen a una reducción del riesgo para la superficie de ataque de una organización. En realidad, un análisis reciente de RAND Company no encontró una reducción noteworthy de las infracciones en organizaciones con programas maduros de gestión de vulnerabilidades.

Tiene que haber una mejor manera de manejar la gestión de vulnerabilidades. Propongo un replanteamiento de la gestión de vulnerabilidades.

Demasiado ruido, muy pocas señales
El nuevo camino a seguir en la gestión de vulnerabilidades requiere cambiar la percepción de que la gestión de vulnerabilidades se trata simplemente de escanear su program en busca de amenazas. ¿Por qué? Debido a que los escáneres de información le brindan una falta de contexto para los siguientes pasos significativos que reducen el riesgo.

propio de Rezilion análisis de investigación en tiempo de ejecución encuentra que, en promedio, solo el 15% de las vulnerabilidades descubiertas se cargan en la memoria, lo que las hace explotables. Eso significa que, en promedio, solo el 15% de las fallas requieren parches prioritarios, o parches en absoluto. Se puede obtener más valor al aplicar el contexto de riesgo. Los equipos de seguridad deben poder deducir cómo se pueden explotar esas brechas y las consecuencias que podrían ocurrir si no se abordan.

Lo más importante es que las vulnerabilidades deben priorizarse en función de su gravedad. Pero no me refiero a la gravedad basada en el sistema común de puntuación de vulnerabilidades (CVSS). Con los enfoques tradicionales, los equipos de seguridad a menudo giran sus ruedas escaneando y luego reparando las vulnerabilidades que pueden no representar una amenaza grave o inmediata simplemente porque el sistema de puntuación las considera críticas.

Esta falta de comprensión sobre la criticidad también puede causar fricción adicional entre los equipos de seguridad y DevOps, que generalmente discuten sobre la necesidad de velocidad y agilidad comercial mientras se mantiene la seguridad.

Parche lo que importa
Rezilión llevó a cabo un análisis de 20 de las imágenes de contenedores más populares en DockerHub junto con varias imágenes del sistema operativo base de los tres principales proveedores de la nube: Amazon Internet Expert services (AWS), Microsoft Azure y Google Cloud Platform (GCP). La thought era evaluar cuántas vulnerabilidades no son relevantes y cuáles representan un riesgo authentic.

Los hallazgos mostraron más de 4.347 vulnerabilidades conocidas. De ellos, el 75% de los calificados como críticos o de alta gravedad no se cargaron en la memoria y no representaron ningún riesgo. Por supuesto, llevaría mucho tiempo y sería casi imposible parchearlos todos a la vez. La conclusión es que las organizaciones pueden usar el análisis de tiempo de ejecución para priorizar la corrección de vulnerabilidades y no dejarse intimidar por el creciente retraso. Un atacante no puede aprovechar una vulnerabilidad en un paquete que no se está cargando en la memoria.

Con este nuevo enfoque, las organizaciones pueden utilizar sus recursos limitados para remediar las vulnerabilidades que Realmente representar una amenaza genuine de explotación y parchearlos en consecuencia. Este nivel de conocimiento y priorización también ahorra tiempo de desarrollo y evita retrasos en el tiempo de comercialización.

Cuando se implementa un enfoque basado en el riesgo para priorizar la reparación de vulnerabilidades, el trabajo pasa a contener las amenazas que representan una amenaza significativa. Eso, a su vez, lessen los gastos generales y la acumulación de vulnerabilidades. También decrease la superficie de ataque del program, lo que facilita la aplicación de parches de forma adecuada.

Es hora de un cambio en la gestión de vulnerabilidades

Es hora de una nueva estrategia de gestión de vulnerabilidades y es apropiado reiterar algunas cosas en las que pensar mientras lo hace. En lugar de aplicar decisiones de permitir o bloquear estáticas, basadas en puntajes o basadas en políticas manuales, use más contexto y visibilidad en tiempo de ejecución para tomar decisiones basadas en riesgos que sean continuas y adaptables.

Estamos abogando por un replanteamiento en el que los equipos de seguridad no solo prioricen la remediación de vulnerabilidades mediante el uso exclusivo de puntajes de gravedad CVSS. En su lugar, busque herramientas que le permitan concentrarse en las vulnerabilidades que representan el mayor riesgo para su organización. Rezilión proporciona herramientas para ver su entorno de software y determinar qué vulnerabilidades representan un riesgo y cuáles no requieren parches. Los equipos de seguridad deben utilizar controles de seguridad contextualizados en tiempo true para comprender su verdadera superficie de ataque de software program. Pero para aplicar el contexto, necesita datos que ayuden a identificar los puntos débiles para reenfocar los esfuerzos de remediación en los riesgos más críticos. De lo contrario, solo está perdiendo un tiempo valioso encontrando señales en el ruido.

Sobre el Autor

Liran Tancman


Liran Tancman, director ejecutivo y cofundador de Rezilion, es uno de los fundadores del comando cibernético israelí y pasó una década en el cuerpo de inteligencia de Israel. En 2013, Liran cofundó CyActive, una empresa que creó una tecnología capaz de predecir cómo podrían evolucionar las ciberamenazas y ofrecer seguridad preparada para el futuro. Liran se desempeñó como director ejecutivo de CyActive y lo dirigió desde sus inicios hasta su adquisición por parte de PayPal en 2015. Luego de la adquisición, Liran dirigió el Centro de productos de seguridad world wide de PayPal, responsable del desarrollo de tecnologías de vanguardia para proteger a los clientes de PayPal.



Enlace a la noticia first