COMENTARIO
El mes pasado se cumplieron 25 años de funcionamiento del programa de Vulnerabilidades y Exposiciones Comunes (CVE). lanzado en septiembre de 1999. Es difícil imaginar un mundo sin CVE. Gran parte de la actividad de “gestión de vulnerabilidades”, antes de que CVE se hiciera popular, dependía de comparar números de versión de análisis remotos y ejecutar exploits sospechosos encontrados en lugares oscuros de Internet para validar los resultados. Hemos recorrido un largo camino en lo que respecta al seguimiento de vulnerabilidades. Sin embargo, nuestro viaje ha estado lleno de obstáculos y todavía tenemos muchos desafíos que superar, entre ellos:
-
Volumen: Para mantener el ritmo del número de CVE creados cada año, tuvimos que aumentar el formato de numeración y asignar CNA (CVE Numbering Authorities), repartiendo así responsabilidades y dificultando la coherencia.
-
Fechas de seguimiento: En determinadas circunstancias, CVE se emitirá en el año en curso pero con un año anterior en la designación. A veces esto se debe a que los CNA tienen CVE preasignados para uso futuro. Sin embargo, esto puede hacer que el seguimiento y análisis de las vulnerabilidades en la base de datos CVE por año sea impreciso. Esto es poco común pero problemático porque lleva a los profesionales de la seguridad a creer que se trata de una vulnerabilidad más antigua y es posible que algunos no le presten atención.
-
Mercado libre: Aunque existen ciertas pautas y obstáculos, en la mayoría de los casos cualquiera puede obtener un CVE. Si bien es importante no limitar la creación de CVE para evitar que las personas intenten ocultar una vulnerabilidad, el concepto de libre mercado ha causado problemas. Hay informes recientes de personas que automatizan el proceso de creación de CVE (cientos de ellos) basándose en errores corregidos previamente en los repositorios de GitHub.
Aunque la creación de un seguimiento formal de vulnerabilidades fue enorme para la industria, no fue hasta 2005 que comenzamos a asignar una clasificación de gravedad utilizando cvss. Esto tampoco está exento de desafíos, tales como:
-
Calificación subjetiva: Cualquiera puede detectar una vulnerabilidad usando cvss y publicar los resultados. Necesitamos controles y equilibrios. Si los investigadores de seguridad que encontraron el error califican la gravedad como diferente a la del proveedor que creó el software, deberíamos poder ver ambas puntuaciones.
-
Sólo refleja vulnerabilidad: Aunque puede utilizar CVSS para personalizar la puntuación de su entorno y tener en cuenta los controles de compensación, la mayoría de los usuarios estarán satisfechos con lo publicado. A menudo, las vulnerabilidades son clasificadas por la CNA propietaria del software y no tienen ningún incentivo para calificarlas altamente.
-
Varias versiones de CVSS: Desde el lanzamiento de la versión 1 de CVSS en 2005, se han lanzado tres versiones posteriores hasta noviembre de 2023. Es posible que una entrada CVE anotada con una versión anterior no se actualice a la última versión. Las puntuaciones CVSS también deben actualizarse debido a cambios en el panorama de la investigación de seguridad o nueva información sobre vulnerabilidades. Estos cambios, si ocurren, pueden ser difíciles de rastrear.
¿Qué hacemos ahora?
Dado que existen ventajas y desventajas en cada uno de estos programas destinados a ayudar a las organizaciones a tomar decisiones informadas basadas en riesgos, ¿cómo saber qué solucionar primero? Muchos confiarán en un mecanismo, probablemente CVSS, elegirán un número mágico y arreglarán cualquier cosa que esté por encima de ese número mágico. El problema es que ésta es una visión muy limitada del mundo de la vulnerabilidad. No todo lo que necesita ser arreglado tendrá una puntuación CVSS alta, o incluso una puntuación baja. Podemos optar por seguir uno o más de los marcos anteriores, como MITRE ATT&CK, CISA KEV y EPSS. Seguirlos individualmente puede ser complicado y se perderían partes del panorama general. Si solo parcheó CISA KEV, se perderá algunas técnicas de atacante que no abordan vulnerabilidades y CVE. Un enfoque combinado no es una mala idea, pero confiar únicamente en consejos externos a su organización es como simplemente agitar una bola Magic 8 y usarla como guía para aplicar correcciones.
Lo que más importa cuando se trata de aplicar parches es el impacto en su organización. Mi mejor consejo es identificar las partes más críticas de su negocio, conectarlas a sistemas y aplicaciones, parchearlas primero y aplicar tantos parches a esos sistemas como sea posible.
Conclusión
Con demasiada frecuencia escucho a la gente rechazar vulnerabilidades Esto podría ser devastador por diversas razones, como “Nadie está atacando estas vulnerabilidades hoy”, “No soy el objetivo de ataques a nivel de estado-nación” y “Un atacante ya debería estar en el sistema”. Ninguna de estas cosas importa cuando un grupo de atacantes inteligentes está decidido a tener éxito. Se centrarán en todas las debilidades de su superficie de ataque: hardware, firmware y software, desde el hardware básico hasta la nube. Los ataques anteriores al sistema operativo podrían dañar permanentemente o inutilizar un sistema, por ejemplo, si un atacante accediera al controlador de administración de la placa base (BMC) y provocara un ciclo de reinicio infinito. A través de ataques de firmware de bajo nivel, los actores malintencionados pueden dañar permanentemente el hardware. Los atacantes pueden usar la Interfaz de firmware extensible unificada (UEFI) para eludir las protecciones del sistema operativo, ser persistentes en el sistema (piense en un ransomware que simplemente no desaparece) y permitir que los atacantes sean sigilosos. En este punto, cada vulnerabilidad ya está disponible para su explotación.
Parchear las vulnerabilidades es un proceso complejo y hay varios factores que influyen en la decisión de aplicar un parche o miles de parches a miles de sistemas. Por muy compleja que pueda ser esta tarea, es algo en lo que debemos seguir mejorando; de lo contrario, los atacantes se beneficiarán enormemente. Ah, y deja la Bola Mágica 8, por favor.