Hola, mi nombre es Jimmy Graham y soy el director de gestión de productos de Vulnerability Management en Qualys. En este podcast de Help Net Security hablaré sobre la importancia de la inteligencia de amenazas y la priorización de la remediación de vulnerabilidades.

Priorización de remediación de vulnerabilidad

Por lo tanto, las organizaciones a menudo se encuentran en uno de los dos estados, o en una transición entre los dos con respecto a su gestión de vulnerabilidad programa. Ve algunas organizaciones que son más maduras y más proactivas, donde realizan parches de rutina, escaneos de vulnerabilidades de rutina, y ven organizaciones que son un poco menos maduras, un poco más reactivas, donde no hay parches de rutina reales en el tablero. Hay un escaneo intermitente, o un escaneo que es inferior a ese mes o menos de una vez a la semana, y algunos de estos están en transición entre los dos estados. Algunas organizaciones que verá tienen una combinación de estas en sus entornos, puede variar según la unidad de negocio, puede variar según el área de tecnología, puede ver más madurez en el parcheo y remediación de Windows, menos madurez en Linux o viceversa, dependiendo de la organización .

La investigación de Qualys muestra que hay organizaciones de ambos tipos. Vimos muchas organizaciones parcheando tan pronto como el parche estuvo disponible, básicamente dentro de los 30 días posteriores a la publicación de un parche por parte de Microsoft. A otros se les aplicaron parches después de que el exploit fuera público, lo que ocurrió unos 30 días después del lanzamiento del parche de Microsoft. Entonces, basándonos en la disponibilidad de los exploits, vimos algunos parches de aumento. Y luego, otros esperaron hasta que WannaCry se extendiera antes de que comenzaran a parchar y se trataran como un escenario de parche de emergencia, y eso sería exactamente alrededor de los 60 días después de que el parche estuviera disponible.

Mientras que WannaCry era una vulnerabilidad bastante reciente en términos de lanzamiento de vulnerabilidades y lanzamiento de exploits y propagación de malware, las viejas vulnerabilidades aún se explotan. Usted ve vulnerabilidades que pueden haber sido liberadas hace años que tienen un nuevo exploit o simplemente se aprovechan en ataques activos, por lo que no es que solo las nuevas vulnerabilidades deberían ser el foco para este tipo de parcheo y priorización de remediación. Las vulnerabilidades antiguas se deben evaluar en función de los datos de amenaza.

La priorización y la inteligencia y priorización de amenazas son necesarias para ambos tipos de organizaciones y cualquier organización intermedia. Si tiene un programa proactivo de administración de vulnerabilidades y un programa de parches, aún necesita priorizar para establecer SLA y OLA en parches y corrección de vulnerabilidades. Todavía es importante poder utilizar los datos de amenaza para determinar si necesita o no disminuir la cantidad de tiempo que está permitiendo aceptar una cierta cantidad de riesgo en función de una vulnerabilidad o un exploit.

Las organizaciones más reactivas que tienen un programa de gestión vulnerable menos maduro que necesita priorizar para minimizar el riesgo porque puede haber una gran acumulación de vulnerabilidad que debe manejar y abordar. Esas vulnerabilidades deben organizarse y agruparse, y el solo hecho de filtrar la gravedad de su proveedor de gestión de vulnerabilidades o su puntaje CVSS no es suficiente para agruparlas en algo que sea manejable. Una gran cantidad de vulnerabilidades todavía caen dentro de los CVSS 9s y 10s, muchas veces eso sigue siendo un gran esfuerzo para tratar de priorizar y tratar a todos de la misma manera en función de la gravedad de la vulnerabilidad.

Priorización de remediación de vulnerabilidad

Entonces, ¿cómo priorizas? Realmente necesita tres cosas para priorizar realmente su programa de remediación. Necesita información de activos, y la información de activos es como el riesgo de los activos y el tipo de activo, qué tipo de activo es este, y hablaré sobre por qué es importante a continuación, hablamos de inteligencia de amenazas. Esa información de activos a menudo está en una CMDB, si no hay una CMDB, la herramienta de escaneo de vulnerabilidades a menudo es un gran lugar para comenzar. Puede sincronizar su herramienta de vulnerabilidad con su CMDB si tiene una CMDB, por lo que puede hacer la sincronización bidireccional. Bidireccional es importante porque muchas veces su CMDB puede tener lagunas donde el escáner de vulnerabilidad pudo encontrar activos que no están en la CMDB. Puede haber lagunas en la cobertura de exploración de vulnerabilidades, por lo que puede haber situaciones en las que no esté escaneando un segmento específico de la red,

Lo segundo que necesita sobre la información de los activos es la información de vulnerabilidad, y eso incluye cosas como la gravedad de la vulnerabilidad que es importante, pero también necesita visibilidad. Eso significa que necesita escanear a menudo y usar cosas como agentes para poder recopilar esta información de vulnerabilidad. Debido a que la mayoría de las organizaciones no tienen perímetro, por lo que tienen activos físicos, nubes públicas virtuales, nubes privadas, estamos viendo un gran crecimiento en contenedores, activos de roaming, trabajadores móviles que pueden estar trabajando en una cafetería o en casa, así como dispositivos móviles . Y es importante tener una cobertura de escaneo de vulnerabilidad o un agente de administración de vulnerabilidades en esos dispositivos para que pueda recopilar estos datos de vulnerabilidad y obtener una visibilidad completa de todo su entorno y comprender la gravedad de esas vulnerabilidades.

Y la tercera cosa que necesitas es inteligencia de amenazas. Y esa inteligencia de amenaza se puede aplicar de manera diferente según el tipo de activo. Por lo tanto, la inteligencia de amenazas sobre una vulnerabilidad puede indicarle que se está utilizando en algo así como un kit de explotación. Los kits de vulnerabilidades se dirigen a estaciones de trabajo, no se dirigen a servidores de destino, por lo que es importante entender que si priorizamos vulnerabilidades basadas en el hecho de que se está utilizando en un kit de explotación, eso debe centrarse en los activos de tipo estación de trabajo. las vulnerabilidades de denegación de servicio representan un mayor riesgo para los activos externos, pero no tanto para los activos internos. Por lo tanto, los diferentes activos están en riesgo para diferentes tipos de amenazas y es importante hacerlo. Y esto realmente no puede ser manual, necesitas tener algún feed de vulnerabilidad, debe estar integrado en su solución de administración de vulnerabilidades porque no va a rastrear todos estos datos manualmente. Combinar esos tres puntos de datos es realmente lo que se necesita para priorizar adecuadamente. Debería establecer acuerdos de nivel de servicio (SLA) y OLA (OLA) para la corrección en función de estas tres cosas.

Y como dije, no solo la gravedad de la vulnerabilidad, la gravedad de la vulnerabilidad podría establecer un mínimo, lo cual está bien, pero la combinación de los datos de los activos y la inteligencia de amenazas debería aumentar la prioridad de los esfuerzos de remediación y acortar esos SLA. Debería establecer un estándar de corrección de vulnerabilidades, así como un estándar de parches. Muchas veces, el parcheo y la administración de vulnerabilidades son dos grupos separados, necesitan tener sus propios estándares y pueden correlacionarse, pueden tener puntos en común, pero es importante que exista la propiedad de esos estándares y que existan requisitos claros y OLAs.

Priorización de remediación de vulnerabilidad

Tomando esta información una vez que la haya recopilado, es importante poder rastrearla de una manera manejable a través de elementos como paneles y widgets. Esta información no se puede leer realmente solo en hojas de cálculo. Debe poder realizar un seguimiento visual en un tablero, observar las tendencias para mostrar el progreso y llamar a las áreas de atención. Puede dividir esa información entre la unidad de negocio, el grupo técnico, el tipo de software, etc., para ayudarlo a llamar la atención donde necesita enfocarse en su vulnerabilidad o programa de corrección.

Deberíamos ir más allá del concepto de intentar rastrear esta información en hojas de cálculo, descargar CSV grandes y enviarlas por correo electrónico a las diferentes áreas tecnológicas para su corrección. Esto debe ser tan automatizado como sea posible. La automatización es clave para tener un programa de gestión de vulnerabilidades maduro. Los tickets de corrección de vulnerabilidades deben entregarse automáticamente en sus sistemas de seguimiento de tickets. Usted debe ser capaz de realizar un seguimiento de estos visualmente el interior de un panel de control para asegurarse de que lo hace ver tendencias a la baja de estas vulnerabilidades para que pueda realizar un seguimiento de las diferentes áreas, como dije romper hacia abajo por las diferentes áreas de si eso es unidad de negocio o área de la tecnología, es Es importante tener ese tipo de visibilidad y tenerlo en un formato visual para poder llamar la atención sobre estas diferentes tendencias.

Debe informar sobre su adhesión a los OLA. Debería desglosarlo por tipo de software, por sistema operativo, por unidades de negocio o grupos técnicos, lo que tenga sentido en términos de cumplimiento con OLA, debe tener informes de rutina sobre eso. Y no deberías temer mucho rojo. Si se encuentra en una situación en la que se encuentra en un entorno menos maduro, debe trazar una línea razonable. Eso no significa que deba establecer objetivos irrazonables, pero sí necesita trazar una línea que sea razonable para su organización. Siempre puede retirarlo según sea necesario, pero si se encuentra en una situación en la que tiene una gran cantidad de vulnerabilidades de backlog, entonces aún necesita establecer un estándar razonable. Los parches deben estar dentro de su conocimiento, como mínimo, 30 días para los tipos de activos normales.

Debido a que el objetivo es minimizar el riesgo, debe trabajar en las áreas problemáticas si tiene lagunas en la información de activos, si tiene lagunas en la información de amenazas, cobertura de gestión de vulnerabilidades, entonces debe trabajar en esas áreas problemáticas diferentes y ver dónde puede aprovechar cosas como su herramienta de vulnerabilidad para descubrir activos si le falta una CMDB. Lo más importante aquí es crear un plan para llegar a donde debe estar, ya que cada paso en la recopilación de estos puntos de datos minimiza su riesgo y le da una idea.

El objetivo debe ser tener una cobertura completa de estos tres, pero a medida que avanza y mientras crece su cobertura de exploración de vulnerabilidad, la información de sus activos construyendo una CMDB, incorporando información de amenazas en su herramienta de administración de vulnerabilidades podrá comenzar priorizando

Fuente: Helpnetsecurity.com

Compartir