Ivanti Blog: Publicaciones de

Cómo la gestión de parches basada en riesgos prioriza los exploits activos

Fri, 03 Jan 2025 18:10:36 Z

La resistencia al cambio siempre está presente, especialmente si cree que los procesos que tiene implantados son eficientes y eficaces. Muchas organizaciones piensan así de sus procedimientos de gestión del software hasta que sufren una brecha o un incidente de seguridad y se preguntan qué ha fallado.

La realidad es que la mayoría de los programas de gestión de parches se basan en suposiciones y recomendaciones, en lugar de en datos sobre vulnerabilidades explotadas activamente. La gestión de parches basada en riesgos es la respuesta a este problema.

En este artículo encontrará:

Qué falla al mantener las prioridades habituales.
Qué es la gestión de parches basada en riesgos.
Por qué es el momento idóneo para adoptar la gestión de parches basada en riesgos.

Los problemas de la priorización habitual de parches

Las actualizaciones de funciones de software, las correcciones de seguridad, las correcciones de errores, las mejoras de rendimiento y muchos otros tipos de versiones de software existen desde los inicios del sector. Los proveedores suelen asignar una clasificación de gravedad u otra puntuación a cada una de ellas para indicar a los clientes qué consideran más importante.

Por desgracia, no existe ningún estándar sectorial asociado a estas clasificaciones, por lo que tenemos que comparar y priorizar las versiones para desplegarlas en nuestros sistemas basándonos en recomendaciones. Además, estas clasificaciones rara vez se actualizan para tener en cuenta el contexto de amenazas activas, aunque las vulnerabilidades cambien.

Pasar por alto una vulnerabilidad explotada activamente

Aunque son mejor que nada, las clasificaciones de gravedad de los proveedores suelen quedarse cortas. Pensemos en la vulnerabilidad Follina (CVE-2022-30190) publicada en mayo de 2022. Esta vulnerabilidad en la Herramienta de diagnóstico de soporte técnico de Microsoft Windows (MSDT) permite la ejecución remota de código.

Follina fue objeto de ataques durante varios meses antes de que Microsoft respondiera finalmente con varias actualizaciones. De forma alarmante, Microsoft solo asignó a esta vulnerabilidad una puntuación de 7.8 en Common Vulnerability Scoring System (CVSS) v3 y una gravedad de Importante. Si solo aplicaba parches en función de una gravedad Crítica, se le habría pasado por alto, dejando una brecha importante en su superficie de ataque.

Y lo que es peor, la puntuación CVSS de Follina se mantuvo en 7.8 incluso después de que se revelara que la vulnerabilidad se estaba explotando activamente para distribuir el ransomware Bisamware, lo que exponía a las organizaciones que la habían pasado por alto a un riesgo aún mayor.

Información sobre la amenaza de ransomware asociada a CVE-2022-30190 mostrada en Ivanti Neurons for VULN KB

Limitaciones de CVSS

Las clasificaciones de gravedad se «complementan» con puntuaciones CVSS de FIRST. A cada CVE se le asigna un número CVSS, como el 7.8 otorgado a CVE-2022-30190 en el ejemplo anterior.

Uno de los principales objetivos al calcular el número CVSS real es garantizar la estandarización, de modo que todas las CVE se puntúen de forma coherente y puedan compararse con precisión. Cuanto mayor sea la puntuación CVSS de una vulnerabilidad y del parche asociado, más crítico será desplegarlo en la mayoría de los entornos.

En el caso de actualizaciones de software que abordan varias CVE, normalmente se tiene en cuenta el valor CVSS más alto para la priorización. Pero ¿es realmente preciso ese valor?

Los resultados de un análisis de puntuaciones CVSS en un artículo reciente mostraron que existe una discrepancia en casi el 20 % de las puntuaciones CVSS (25 000). Este análisis se basó en una comparación de las puntuaciones notificadas en la National Vulnerability Database (NVD) del NIST y las comunicadas directamente por los propios proveedores.

Incoherencias en la gravedad asignada por los proveedores

Un punto importante que conviene tener en cuenta es que, históricamente, los proveedores han asignado su propia terminología a la gravedad (por ejemplo, crítica, importante). Usar la puntuación de gravedad del proveedor como mecanismo de priorización puede funcionar bien al comparar todos los parches de un proveedor determinado, pero no siempre ofrece una comparación precisa de parches entre distintos proveedores. De hecho, muchos utilizan terminología completamente diferente.

Del mismo modo, la gravedad asignada por el proveedor no siempre es un indicador positivo. Muchas vulnerabilidades de día cero solo reciben la calificación de Importante por parte de Microsoft, pero tienen puntuaciones CVSS elevadas. Esto demuestra que aplicar parches usando la gravedad y CVSS para la priorización se basa en suposiciones y recomendaciones, y puede dar lugar a un entorno vulnerable.

¿Por qué priorizar los exploits activos por encima de cualquier otro método de priorización?

Según la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA), una vulnerabilidad explotada activamente es “one for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner.” En términos sencillos, una vulnerabilidad bajo explotación activa es aquella que un actor de amenazas ha utilizado para lanzar un ciberataque.

Por tanto, para minimizar el riesgo de un ataque contra su organización, debe priorizar las vulnerabilidades explotadas activamente por encima de todas las demás. La buena noticia es que la mayoría de las vulnerabilidades no se están explotando activamente y, por tanto, suponen poco o ningún riesgo para su organización. Puede identificar las que sí se han explotado mediante la gestión de parches basada en riesgos.

¿Qué es la gestión de parches basada en riesgos?

La gestión de parches basada en riesgos es una extensión de la gestión de vulnerabilidades basada en riesgos, que va más allá de la gravedad asignada por los proveedores y de las puntuaciones CVSS básicas para identificar y cualificar las vulnerabilidades concretas que suponen el riesgo más significativo para una organización. Esto incorpora el contexto de riesgo real al proceso de gestión de parches para que los equipos de TI puedan centrar sus esfuerzos en las actualizaciones con vulnerabilidades explotadas conocidas que más importan para la postura de seguridad de una organización.

¿Cómo puede mi organización adoptar la gestión de parches basada en riesgos?

Para las organizaciones preparadas para adoptar un enfoque de gestión de parches basado en riesgos, un buen punto de partida es el catálogo Known Exploited Vulnerabilities (KEV) de CISA. CISA dio un gran paso adelante para ayudar a priorizar vulnerabilidades cuando presentó la Directiva operativa vinculante 22–01 junto con su catálogo KEV. Cuando se publicó originalmente, el catálogo contenía unas 200 vulnerabilidades explotadas activamente. Desde entonces, ha aumentado hasta casi 900.

CISA elabora la lista con el conocimiento de que las vulnerabilidades que contiene están siendo explotadas en escenarios reales por amenazas activas. Sin embargo, la lista tiene sus limitaciones, ya que actualmente excluye 131 vulnerabilidades asociadas al ransomware.

¿Es el catálogo KEV de CISA el único recurso disponible para la gestión de parches basada en riesgos?

Las organizaciones con prácticas de gestión de parches basada en riesgos más maduras aprovechan metodologías avanzadas de puntuación de riesgos en lugar de CVSS o además de este. Estas metodologías asignan puntuaciones a cada vulnerabilidad identificada en el entorno de una organización, lo que permite ampliar el enfoque basado en riesgos más allá del KEV de CISA.

Muchos proveedores del ámbito de la gestión de vulnerabilidades basada en riesgos han desarrollado metodologías de puntuación propias que representan el riesgo real que supone una vulnerabilidad. Lo hacen ofreciendo clasificaciones de riesgo dinámicas que dan un peso adicional a las vulnerabilidades explotadas activamente.

Por ejemplo, la Vulnerability Risk Rating (VRR) de Ivanti ha asignado a Follina una puntuación de 10, una puntuación que representa con mayor precisión el riesgo que plantea esa vulnerabilidad que su puntuación CVSS de 7.8.

Diferencia entre las puntuaciones VRR y CVSS v3 y los niveles de gravedad de CVE-2022-30190, tal como se muestra en Ivanti Neurons for VULN KB

Por qué es el momento idóneo para adoptar la gestión de parches basada en riesgos

Si cree que se ha quedado atrás con las actualizaciones del sistema o se siente desbordado por los nuevos sistemas y aplicaciones de su empresa, ahora es el momento idóneo para adoptar la gestión de parches basada en riesgos.

Incluso si considera que cuenta con un programa sólido basado en clasificaciones de gravedad y puntuaciones CVSS, es hora de superar la resistencia al cambio e iniciar un nuevo proceso antes de que su empresa sufra las graves consecuencias de una brecha de datos derivada de una vulnerabilidad explotada.

Empiece utilizando el KEV de CISA para priorizar sus actualizaciones y reservar presupuesto para una solución de gestión de vulnerabilidades y parches basada en riesgos. Con las herramientas adecuadas implantadas, puede identificar rápidamente los sistemas de mayor riesgo para aplicarles parches primero y avanzar por la lista para garantizar que sus sistemas estén protegidos.

¿Quiere dar el primer paso? Consulte este eBook, una guía integral para implantar un programa moderno de gestión de parches basada en riesgos.

Procesos eficaces de gestión moderna de parches y prácticas recomendadas para las operaciones de aplicación de parches

Thu, 01 Aug 2024 06:01:00 Z

Ejecutar un programa de gestión de vulnerabilidades basado en el riesgo es esencial para mantener un entorno informático empresarial seguro. En un blog anterior, «Cómo la implementación de una gestión de parches basada en el riesgo prioriza los exploits activos», ofrecí mi perspectiva sobre cómo priorizar las vulnerabilidades. Perfeccionar el aspecto operativo de la protección de sus sistemas es esencial para ese proceso.

Llevar a cabo operaciones de aplicación de parches en su organización puede ser un proceso complejo. Incluso con cierta perspectiva sobre la prioridad de las vulnerabilidades, debe seguir teniendo en cuenta:

La cadencia de publicación de los parches.
Políticas de apoyo para que este proceso sea eficaz.
Campañas para implementar las actualizaciones.
Acuerdos de nivel de servicio (SLA) y medición del cumplimiento.

Puede parecer mucho que equilibrar, pero un sistema flexible que gestione los eventos planificados y pueda tener en cuenta los imprevistos le dará el control total.

¿Tiene el control?

Hay algunas facetas de las publicaciones de parches que puede planificar y otras que no.

Tomemos como ejemplo la cadencia de publicación de parches de seguridad. En el Patch Tuesday, el segundo martes de cada mes, Microsoft intenta publicar todas sus actualizaciones más recientes. Estas incluyen actualizaciones para sistemas operativos, Office y otras aplicaciones de usuario, herramientas de desarrollo como Visual Studio y componentes en la nube de Azure, por mencionar algunos ejemplos.

Patch Tuesday, que celebró su 20.º aniversario en octubre de 2023, es la base de muchos programas de aplicación de parches, ya que proporciona un momento concreto para distribuir todas las actualizaciones más recientes de Microsoft y de terceros disponibles. Ningún otro proveedor ha tenido un impacto tan profundo a la hora de impulsar los programas de aplicación de parches de las organizaciones y, hasta el día de hoy, el ciclo mensual de parches, anclado en Patch Tuesday, sigue siendo un estándar del sector.

Otros proveedores han intentado seguir su ejemplo y publicar sus actualizaciones conforme a un calendario:

Oracle publica su Critical Patch Update una vez por trimestre.
Adobe suele publicar sus actualizaciones una vez al mes, a menudo en sincronía con Patch Tuesday.
Google empezó recientemente a publicar una única actualización cada semana.

Sin embargo, la mayoría de los proveedores publican actualizaciones de seguridad tan pronto y con tanta frecuencia como pueden para asegurarse de abordar las vulnerabilidades lo antes posible. Esto genera un flujo aleatorio e interminable de actualizaciones que deben priorizarse y distribuirse constantemente en toda la organización.

Proceso de gestión de parches para políticas y campañas

Poner bajo control el caos de las publicaciones de parches requiere un conjunto de reglas claramente definido y una infraestructura para aplicarlas. En el ámbito de los parches, esto se traduce en políticas y campañas.

La política de parches requiere una amplia variedad de consideraciones más allá de priorizar las vulnerabilidades, incluido el impacto de las actualizaciones en las operaciones empresariales, la aplicabilidad a distintos tipos de sistemas, el grado de control sobre las actualizaciones y otros factores.

Las políticas de parches ofrecen un claro contraste, en función de su empresa. Para un servidor que aloja aplicaciones empresariales críticas, su política implica un conjunto de actualizaciones claramente definido bajo un estricto control de configuración, se ejecuta únicamente durante una ventana de mantenimiento definida y siempre exige un reinicio al finalizar para garantizar que el sistema esté completamente actualizado. La política de parches para el portátil de un usuario de marketing identifica una serie de aplicaciones con actualizaciones aprobadas que pueden estar presentes o no, y permite al usuario retrasar las actualizaciones y reiniciar cuando le resulte conveniente.

Las campañas tienen en cuenta estas políticas, pero también aportan control sobre la miríada de parches que se publican constantemente.

Las prácticas recomendadas de la gestión moderna de parches requieren aplicar parches con más frecuencia que una sola vez al mes. Los parches de Google Chrome se publican semanalmente, y los parches de día cero pueden publicarse en cualquier momento. Una campaña mensual dejará muchos sistemas vulnerables durante periodos prolongados.

Establezca tres tipos de campañas

Una práctica recomendada es establecer tres tipos de campañas: mantenimiento periódico, actualizaciones prioritarias e implementaciones críticas.

Campaña de mantenimiento periódico

Las campañas de mantenimiento periódico aplican el despliegue mensual estándar de parches por anillos que la mayoría de las organizaciones utilizan hoy. Esta campaña incluye:

Pruebas iniciales en un entorno controlado para garantizar que los parches se instalen según lo previsto.
Despliegue a un grupo piloto más amplio de usuarios pioneros atentos para informar de incidencias.
Despliegue a los grupos predefinidos de sistemas de producción para completar la distribución global.

Los parches de una campaña de mantenimiento incluyen actualizaciones de seguridad que se publican con menor frecuencia, como las publicaciones de Patch Tuesday de Microsoft, así como mejoras de rendimiento o de aplicaciones. Los sistemas objetivo de esta campaña también pueden ser aquellos que tienen ventanas de mantenimiento limitadas y no pueden interrumpirse sin un impacto empresarial importante. Lo más probable es que la mayoría de los parches entren en la campaña de actualizaciones prioritarias.

Campaña de actualizaciones prioritarias

La campaña de actualizaciones prioritarias está diseñada para abordar rápidamente aquellos sistemas que tienen una exposición continua a nuevas vulnerabilidades, pero que pueden actualizarse con mayor frecuencia. Los sistemas de usuario que ejecutan aplicaciones de productividad y navegadores entran en esta campaña y suelen ser los que presentan mayor riesgo por su exposición al phishing, malware y ransomware.

Los parches asociados a esta campaña suelen tener la máxima prioridad debido a vulnerabilidades con explotación conocida, pero también pueden tener un impacto empresarial relativamente bajo y requerir el reinicio de un navegador o una aplicación. Como resultado, las políticas pueden tener un ciclo de pruebas más corto antes de su publicación y distribuirse con mayor rapidez a grupos más amplios de sistemas que no son críticos para la empresa; por ejemplo, puede que los servidores no tengan instalado un navegador, pero los portátiles de ventas sí.

Campaña de respuesta de día cero

La campaña de respuesta de día cero se reserva para la implementación de emergencia de parches, obligatoria para la empresa o el sector, que debe estar lista en un plazo breve. Esta campaña tiene prioridad sobre todas las demás.

La política de esta campaña podría acortar el tiempo o reducir los estándares entre despliegues con controles de aprobación, o podría ignorarlos por completo en función del SLA que deba cumplirse. Lo más importante en las campañas de respuesta de día cero: sigue siendo una distribución controlada de parches, y toda la actividad se sigue notificando para realizar un seguimiento preciso de los eventos de la campaña hasta su finalización.

El tiempo de exposición determina el cumplimiento

Si el cumplimiento se mide en términos de equipos completamente parcheados, con esta métrica la mayoría de los sistemas solo cumplen durante un número limitado de horas al mes. Aunque técnicamente es exacto, se trata de un indicador deficiente para mostrar la seguridad del sistema a lo largo del tiempo en un programa basado en el riesgo. Mostrar el «tiempo de exposición» a una vulnerabilidad determinada o a un grupo de vulnerabilidades proporciona un mejor indicador del riesgo.

Este es un ejemplo: CVE-2024-4761 se notificó como corregida en una actualización de Google Chrome publicada el 14 de mayo, que coincidió con el Patch Tuesday de mayo. Al día siguiente, este parche de Chrome se añadió a una campaña de actualizaciones prioritarias que incluía un periodo de distribución de dos semanas en 500 sistemas del Grupo 1 y 1000 sistemas del Grupo 2. Suponiendo que la mayoría de los sistemas se actualizaran correctamente dentro de ese plazo de dos semanas, un informe mostraría cuándo se actualizó cada sistema, pero, lo que es más importante, cuánto tiempo permaneció cada uno de estos 1500 sistemas sin parchear: expuesto a la vulnerabilidad y en riesgo.

Este es un ejemplo sencillo de una vulnerabilidad y un parche. Pero si hubiera varios parches en la campaña con varias vulnerabilidades, la información podría agregarse para ofrecer una vista más completa de la campaña. Si se ejecutaran varias campañas durante el mismo periodo, el resultado podría superponerse o combinarse para proporcionar una evaluación del riesgo aún más precisa.

Con estos datos, puede mostrar a un auditor el verdadero estado de seguridad de sus sistemas. Quizá más importante aún, puede empezar a evaluar los resultados y mejorar la eficacia de su operación moderna de gestión de parches. En ese momento, es usted quien dirige la operación, y no al revés.