Un zero-day (día cero) es una vulnerabilidad de software desconocida por el fabricante del producto y, por extensión, un ataque que explota esa falla antes de que salga la primera corrección oficial. El término hace referencia al tiempo disponible para reaccionar: si el parche llega justo cuando el ataque ocurre, el usuario tiene "días cero" de protección efectiva.
Estas brechas son críticas porque, al ser desconocidas, las defensas tradicionales (como las actualizaciones automáticas o las listas de características de las amenazas) a menudo las dejan pasar. Su impacto abarca desde la pérdida de datos personales hasta el colapso de infraestructuras críticas, convirtiéndolas en una de las mayores preocupaciones en ciberseguridad moderna.
Definición y concepto
Una vulnerabilidad zero-day es un fallo de seguridad en un sistema informático, dispositivo o software que el fabricante aún no conoce o, aunque lo conoce, no ha lanzado una parche oficial para corregirlo. El término proviene del inglés zero-day, que significa "día cero". Este nombre hace referencia al hecho de que los desarrolladores tienen cero días de anticipación para arreglar el defecto antes de que los atacantes lo exploten. La exposición comienza en el momento exacto en que el error es descubierto y utilizado, dejando a los usuarios en una ventana de vulnerabilidad crítica.
Origen y significado del término
La noción de "día cero" surge en la industria del software a finales del siglo XX. Originalmente, se refería al primer día en que un error era conocido por el equipo de desarrollo. Si el error se descubría en el "día cero", la corrección podía aplicarse rápidamente. Sin embargo, con el tiempo, el significado evolucionó. Hoy, se aplica específicamente a aquellas vulnerabilidades donde el tiempo entre el descubrimiento del fallo y su explotación es mínimo o nulo. Esto crea una presión inmensa sobre los equipos de ingeniería, que deben trabajar contra reloj para minimizar el daño. La urgencia es lo que define a estas amenazas.
Dato curioso: El término se popularizó tras el ataque de 2013 a Google Chrome, donde se descubrió que los usuarios tenían "días cero" de exposición antes de que el navegador se actualizara automáticamente. Esto cambió la percepción pública sobre la velocidad necesaria en las actualizaciones del software.
Diferencias clave: Error, Vulnerabilidad y Amenaza
Para entender la gravedad de un zero-day, es necesario distinguir tres conceptos que a menudo se confunden. Un error (o bug) es cualquier imperfección en el código o diseño. No todos los errores son críticos; algunos solo afectan la interfaz gráfica. Una vulnerabilidad es un error específico que puede ser explotado para reducir la eficacia de un recurso. Finalmente, una amenaza es cualquier evento o acción externa que puede causar daño al sistema. Un zero-day ocurre cuando una vulnerabilidad desconocida es explotada por una amenaza antes de que se aplique la corrección. La distinción es fundamental para la gestión de riesgos.
Impacto en software y hardware
Las vulnerabilidades zero-day afectan tanto al software como al hardware, aunque los mecanismos varían. En el software, como sistemas operativos o aplicaciones, los fallos suelen residir en cómo el programa procesa los datos de entrada. Un atacante puede enviar un dato malicioso que el software no espera, provocando que el sistema ejecute instrucciones no deseadas. En el hardware, los fallos pueden ser más difíciles de corregir. Un ejemplo conocido es el fallo Spectre en los procesadores, donde la arquitectura misma permitía filtrar datos. Corregir esto requiere actualizaciones de microcódigo o incluso cambiar físicamente el chip, lo que añade complejidad. La consecuencia es directa: la seguridad depende de la rapidez de la respuesta técnica.
¿Cómo funcionan los ataques zero-day?
Un ataque zero-day no es un fenómeno mágico, sino una carrera de velocidad entre un error de software y la atención del desarrollador. El término "zero-day" hace referencia al número de días que tiene el desarrollador para corregir el fallo antes de que los atacantes lo utilicen. En teoría, el día cero es aquel en el que el parche llega a la pantalla del usuario, pero a menudo, ese día nunca llega o llega demasiado tarde.
El mecanismo de la vulnerabilidad
Todo comienza con un defecto en el código fuente. Los programadores son humanos y los lenguajes de programación son complejos. Un error común es el "desbordamiento de búfer", donde se escribe más datos de los que el espacio de memoria reservado puede contener. Si un atacante inyecta exactamente la cantidad correcta de datos, puede sobrescribir instrucciones adyacentes y forzar al programa a ejecutar código extraño.
Este error existe desde que se compiló el software, pero permanece invisible hasta que alguien lo encuentra. Ese alguien puede ser un ingeniero de calidad, un analista de seguridad o un hacker de la calle. La diferencia radica en el momento en que se revela el fallo al público.
Debate actual: ¿Deben las empresas revelar inmediatamente cada error encontrado o mantenerlo en reserva como "arma" estratégica? Esta tensión entre transparencia y estrategia define gran parte de la caza de errores modernos.
La cadena de ataque (Exploit)
Para que el error se convierta en un ataque exitoso, se necesita un exploit. Un exploit es una secuencia de instrucciones diseñada específicamente para activar la vulnerabilidad. Piensa en el error como una puerta entreabierta y el exploit como la llave maestra que la empuja con la fuerza justa.
El proceso suele seguir estos pasos concretos:
- Identificación: El atacante localiza la variable vulnerable en el software objetivo.
- Inyección: Se introduce el dato malicioso (el exploit) en el flujo normal de datos.
- Ejecución: El software procesa el dato, activa el error y ejecuta el código oculto.
- Recolección: El código ejecutado abre una puerta trasera, permitiendo al atacante leer archivos o controlar el dispositivo.
Si el exploit funciona en la pantalla del usuario sin que este haga clic en nada, se llama "ataque de disparo en la oscuridad". Si requiere una acción, como abrir un archivo PDF, es un ataque basado en interacción. La complejidad del exploit determina qué tan difícil es detectar la intrusión antes de que ocurra.
El parche y la ventana de exposición
La defensa contra estos ataques es el parche. Un parche es una actualización de software que corrige el error de código. Cuando la empresa lanza el parche, comienza la "ventana de exposición". Este es el periodo crítico entre el lanzamiento del parche y el momento en que todos los usuarios lo instalan.
Durante esta ventana, el error sigue siendo un zero-day para quienes aún no se han actualizado. La duración de esta ventana depende de la velocidad de adopción del usuario final. Si el sistema operativo es Windows y hay millones de usuarios, la ventana puede durar semanas o incluso meses. Si es un servidor crítico, puede durar solo horas.
La consecuencia es directa: la actualización no es opcional, es una necesidad de supervivencia digital. Sin embargo, actualizar también introduce riesgos, ya que un parche mal diseñado puede crear nuevos errores. Por eso, las empresas prueban los parches antes de lanzarlos, pero la presión por cerrar la brecha zero-day a menudo acelera el proceso, dejando margen para nuevos descubrimientos.
Historia y evolución
El concepto de "zero-day" no nació con las pantallas táctles, sino con la llegada de la primera red de computadoras. La percepción de estos errores ha evolucionado de ser simples fallos de software a convertirse en activos estratégicos en la guerra de datos. Comprender esta historia requiere mirar hacia atrás, más allá de los parches inmediatos.
Los inicios: El Gusano Morris
En 1988, el mundo conoció su primer gran enemigo invisible. El Gusano Morris, lanzado por un joven investigador llamado Robert Morris, aprovechó una vulnerabilidad en el servicio fingerd de Unix. Este error permitía a un atacante ejecutar comandos remotos sin una autopsia previa del código fuente. El resultado fue el primer gran atasco de Internet, afectando al 10% de las máquinas conectadas. Fue la primera señal de que un solo fallo podía paralizar una red global.
Esa época estableció un precedente: el software es inherentemente frutable. Sin embargo, en los años noventa, estos errores se trataban como inconvenientes menores, a menudo resueltos con parches semanales. La gestión era reactiva y lenta, sin la presión comercial que veríamos décadas después.
La era de la precisión: Stuxnet y el poder del tiempo
Todo cambió con la aparición de Stuxnet en 2010. Este gusano, dirigido principalmente a las centrales nucleares de Irán, no atacaba al azar. Se centró en una vulnerabilidad específica del sistema operativo Windows y del software de control industrial Siemens. Lo impactante no fue solo el objetivo, sino la precisión con la que se explotó un error conocido como "MS10-047".
Dato curioso: Stuxnet utilizó hasta cuatro vulnerabilidades distintas, lo que sugiere que los ingenieros del error podían permitirse el lujo de dejar algunas sin explotar, o que necesitaban redundancia para asegurar el éxito del ataque.
Este evento marcó un punto de inflexión. Los errores zero-day dejaron de ser solo fallos técnicos para convertirse en armas de precisión. La gestión de estos errores pasó a ser más crítica, con equipos de respuesta rápida que trabajaban bajo la sombra de la amenaza de una explotación silenciosa.
La crisis de la transparencia: Heartbleed y el costo del silencio
En 2014, el mundo descubrió el fallo Heartbleed en la biblioteca OpenSSL, que protege gran parte del tráfico web. Este error permitía a los atacantes leer la memoria del servidor, revelando claves privadas y contraseñas. Lo más alarmante no fue el error en sí, sino que había existido durante dos años sin que nadie lo notara.
La gestión de estos errores se ha vuelto más compleja con el tiempo. Hoy en día, las empresas compiten por descubrir y explotar los errores antes de que los demás lo hagan. Esto ha llevado a una mayor inversión en la caza de errores y a la creación de programas de recompensas para los investigadores. La percepción ha cambiado de ver los errores como fallos inevitables a considerarlos activos valiosos que deben ser gestionados con urgencia.
La evolución de los errores zero-day refleja la maduración de la informática. De ser simples fallos en el código, se han convertido en elementos centrales en la estrategia de seguridad. La gestión moderna implica una combinación de detección temprana, parches rápidos y una comprensión profunda de cómo los atacantes pueden explotar estos fallos. La historia de estos errores es la historia de cómo hemos aprendido a vivir con la imperfección del software.
¿Qué diferencia un zero-day de otras vulnerabilidades?
La distinción fundamental entre una vulnerabilidad de día cero y otras fallas de software no radica en su gravedad intrínseca, sino en el factor tiempo. Un defecto de código puede ser técnicamente idénto a uno descubierto hace años, pero la clasificación cambia según el conocimiento compartido entre el desarrollador y el atacante.
El espectro de la vulnerabilidad
En el ciclo de vida de un fallo de seguridad, existen tres estados principales. Primero está la vulnerabilidad conocida, que ha sido identificada y, a menudo, etiquetada con un identificador único llamado CVE (Common Vulnerabilities and Exposures). En este estado, la comunidad técnica ya sabe que el agujero existe. Luego viene el parche, que es la corrección aplicada por el fabricante para cerrar ese hueco. Finalmente, el día cero ocurre cuando el atacante descubre y explota el fallo antes de que el desarrollador tenga la oportunidad de lanzar el parche.
La diferencia crítica es la asimetría de la información. Cuando un usuario tiene instalada una vulnerabilidad conocida sin aplicar el parche, asume un riesgo calculado. Conoce el enemigo. En cambio, ante un día cero, el usuario está luchando a ciegas; el atacante sabe exactamente qué botón presionar, mientras que el defensor apenas sabe si hay una puerta abierta.
| Característica | Vulnerabilidad de Día Cero | Vulnerabilidad Conocida (CVE) | El Parche |
|---|---|---|---|
| Conocimiento del atacante | Completo | Completo | Parcial o Nulo |
| Conocimiento del defensor | Nulo o Inicial | Completo | Completo |
| Estado de la corrección | Pendiente de lanzamiento | Ya lanzado (pero no instalado) | Aplicado |
| Riesgo principal | Sorpresa y rapidez | Negligencia humana | Obsolescencia |
La consecuencia es directa: los días cero son más difíciles de mitigar porque no hay una solución oficial inmediata. El defensor debe confiar en medidas temporales, como actualizaciones de software de terceros o cambios de comportamiento, mientras espera la intervención del fabricante.
La ventana de exposición
El concepto central para entender el riesgo del día cero es la "ventana de exposición". Este término se refiere al lapso de tiempo que transcurre desde que el atacante descubre el fallo hasta que el parche llega a la mayor parte de los usuarios afectados. Esta ventana puede durar desde unas pocas horas hasta varios años, dependiendo de la complejidad del software y de la rapidez de respuesta del equipo de desarrollo.
Dato curioso: Algunas vulnerabilidades de día cero permanecieron ocultas durante décadas. El famoso fallo "Heartbleed" en OpenSSL, descubierto en 2014, afectaba al software desde 2011, lo que significa que la ventana de exposición estuvo abierta durante tres años antes de que el mundo supiera que el corazón de Internet estaba sangrando datos.
La importancia de esta ventana radica en la probabilidad estadística de ser atacado. Mientras más larga sea la ventana, mayor es la probabilidad de que un atacante encuentre el fallo y lo explote antes de que el parche se aplique. Los equipos de seguridad miden esta exposición para priorizar recursos. Si la ventana es corta, el riesgo se concentra en la velocidad de despliegue del parche. Si es larga, el riesgo se distribuye en el tiempo, permitiendo que los atacantes realicen una caza más metódica de las presas.
No existe una fórmula matemática única para calcular el riesgo absoluto de un día cero, pero los analistas a menudo utilizan modelos de probabilidad que consideran la tasa de descubrimiento y la velocidad de aplicación del parche. La relación básica puede expresarse conceptualmente como:
Riesgo∝Velocidad de Adopcioˊn del ParcheDuracioˊn de la VentanaEsto significa que incluso si la ventana de exposición es larga, el riesgo disminuye drásticamente si los usuarios instalan el parche rápidamente. Por el contrario, una ventana corta puede ser devastadora si la adopción del parche es lenta. La gestión de esta dinámica es lo que separa a una vulnerabilidad gestionada de una crisis de seguridad de día cero.
Detección y mitigación
La gestión de las vulnerabilidades zero-day requiere un enfoque proactivo, ya que, por definición, el parche definitivo aún no ha llegado. La estrategia se divide en dos frentes: identificar la amenaza antes de que se convierta en una catástrofe y limitar su propagación una vez que entra en el sistema. Ninguna herramienta es perfecta, por lo que la defensa en profundidad es la norma.
Métodos de detección técnica
El análisis estático examina el código fuente o el binario sin ejecutarlo. Los ingenieros buscan patrones sospechosos, como funciones de entrada no validadas o desbordamientos de búfer clásicos. Este método es rápido pero genera muchos falsos positivos. Por otro lado, el análisis dinámico ejecuta el software en un entorno aislado, conocido como "caja de arena" o sandbox, para observar su comportamiento en tiempo real. Se monitorean las llamadas al sistema, el uso de la memoria y el tráfico de red. Si el programa se comporta de forma anómala, como intentar acceder a un archivo inusual, la alerta se dispara.
Dato curioso: El primer uso documentado de una vulnerabilidad zero-day fue en 1994, cuando el sistema operativo Windows NT fue atacado mediante un error en la gestión de memoria, años antes de que el término se popularizara en la industria.
Contención y el modelo Zero Trust
Cuando la detección falla, la contención es vital. La segmentación de red divide la infraestructura en zonas más pequeñas. Si un servidor en el departamento de ventas es infectado, el atacante debe trabajar para cruzar las fronteras hacia la base de datos de recursos humanos. Esto frena la propagación lateral. Este concepto se integra en el modelo Zero Trust (Confianza Cero), que asume que ninguna entidad, interna o externa, es confiable por defecto. Cada solicitud de acceso se verifica continuamente.
La fórmula de riesgo asociada a la exposición de un activo en un entorno de confianza cero puede conceptualizarse como la probabilidad de que una amenaza explote una vulnerabilidad dada la exposición actual:
R=P(E)×V×ExDonde R es el riesgo, P(E) la probabilidad de explotación, V la vulnerabilidad inherente y Ex la exposición del activo. Reducir Ex mediante segmentación disminuye directamente R, incluso si la vulnerabilidad V sigue sin parchear.
Parches rápidos y mitigación temporal
Una vez identificada la vulnerabilidad, los editores emiten parches rápidos. Estos no siempre son perfección técnica; a menudo priorizan la velocidad sobre la elegancia del código. Para el usuario final, la mitigación implica aplicar actualizaciones automáticas y, en casos críticos, activar reglas temporales en los filtros de entrada (firewalls) o en los gestores de paquetes. La velocidad de respuesta es el factor crítico: cada hora sin parche aumenta la ventana de oportunidad para los atacantes. La consecuencia es directa: la latencia entre la detección y la aplicación del parche define el costo del desastre.
Aplicaciones y ejemplos prácticos
Los errores zero-day no son abstracciones teóricas; son herramientas de precisión en la caza de datos. Su valor radica en la sorpresa: el parche existe, pero el objetivo aún no lo ha aplicado. Esto convierte a los fallos sin corregir en activos comerciales y estratégicos, a menudo más valiosos que el propio software que los alberga.
El mercado de los fallos: de la memoria RAM al bolsillo
El uso práctico de estos errores se divide principalmente en dos frentes: la explotación directa en el navegador para capturar la sesión del usuario, y la inyección profunda en el sistema operativo para lograr persistencia. En los navegadores web, un fallo zero-day en el motor de renderizado (como V8 en Chrome o Gecko en Firefox) permite ejecutar código cuando el usuario visita una página web específica. Esto se conoce como "drive-to-the-death". El usuario hace clic, el script se ejecuta y, a menudo, el navegador se reinicia, ocultando la huella.
Dato curioso: En el mercado secundario de los errores, un fallo crítico en el navegador Safari o Chrome puede alcanzar los 100.000 dólares, mientras que un fallo en el kernel de iOS puede superar los 500.000 dólares. La escasez genera precios altos.
Los sistemas operativos ofrecen un terreno más rico para la explotación. Un ejemplo clásico es el fallo "Heartbleed" en OpenSSL (2014). Aunque técnicamente fue un error de implementación que permitió leer la memoria del servidor, su naturaleza de "zero-day" durante casi un año permitió a los atacantes extraer claves privadas y sesiones de usuario sin que el servidor supiera qué se había fugado. La consecuencia fue una reconstrucción casi total de la confianza en la capa de transporte de internet.
Casos de estudio: Stuxnet y los teléfonos inteligentes
El gusano Stuxnet (2010) demostró cómo combinar múltiples fallos zero-day para atacar un objetivo físico. Utilizó cuatro fallos distintos, incluyendo uno en el controlador de impresión de Windows y otro en la comunicación entre el sistema operativo y el controlador lógico programable (PLC) de una planta nuclear iraní. No se trataba solo de leer un archivo; era apretar un botón en la pantalla de control sin tocar el teclado. Este caso marcó el inicio de la guerra cibernética moderna, donde el software afecta a la materia física.
En el ámbito móvil, el caso de Pegasus (desarrollado por NSA) ilustra la vulnerabilidad de los dispositivos personales. Este software espía aprovechó fallos zero-day en la aplicación de mensajería WhatsApp y en el sistema operativo iOS. El mecanismo era elegante: enviaba un paquete de datos corrupto (a menudo un archivo PDF o un audio) que el teléfono procesaba antes de que el usuario lo abriera. El fallo en el procesador de imágenes permitía ejecutar código en la memoria, logrando acceso casi total al teléfono. La defensa era difícil porque no requería interacción compleja del usuario, solo la recepción del mensaje.
La defensa contra estos errores se basa en la mitigación, no solo en la corrección. Las técnicas como la aleatorización de direcciones de memoria (ASLR) y la protección contra la ejecución de datos (DEP) dificultan que el código explotado se ejecute en la ubicación esperada. Sin embargo, ante un fallo zero-day, estas defensas son a menudo barreras de tiempo, no muros definitivos. La rapidez en la aplicación de parches sigue siendo la estrategia más efectiva para los usuarios finales.
Ejercicios resueltos
Simulación de análisis de vulnerabilidad
Para comprender la dinámica de los errores tipo zero-day, es útil modelar matemáticamente la exposición y analizar escenarios prácticos. A continuación, se presentan ejercicios que ilustran cómo calcular el riesgo y aplicar mitigaciones.
Ejercicio 1: Cálculo de la ventana de exposición
Una empresa utiliza un servidor web con un parche crítico publicado el lunes a las 09:00 h. El equipo de TI aplica el parche el miércoles a las 15:00 h. Calcula la duración exacta de la ventana de exposición.
La ventana de exposición es el intervalo temporal entre la aparición del parche y su implementación efectiva. Se calcula restando el tiempo inicial al tiempo final:
W=Tparche−TinicioDesglosemos el tiempo:
- Del lunes 09:00 al martes 09:00: 24 horas.
- Del martes 09:00 al miércoles 09:00: 24 horas.
- Del miércoles 09:00 al miércoles 15:00: 6 horas.
Sumando estos intervalos, obtenemos:
W=24+24+6=54 horasLa consecuencia es directa: durante 54 horas, el servidor fue vulnerable a cualquier atacante que supiera explotar ese error específico.
Ejercicio 2: Identificación de vectores de ataque
Un equipo de desarrollo descubre una vulnerabilidad en una librería de análisis de imágenes. Los desarrolladores acceden a la librería a través de un repositorio público (GitHub) y la instalan mediante un gestor de paquetes (NPM). Identifica dos vectores de ataque posibles.
Un vector de ataque es la ruta que sigue la amenaza para llegar al objetivo. En este caso, hay dos puntos débiles claros:
- Versión del repositorio: Si el desarrollador clona el código fuente directamente desde la rama main, cualquier compromiso en el repositorio afecta al código base.
- Gestor de paquetes: Si el gestor NPM descarga la librería sin verificar la firma digital, un atacante puede inyectar código malicioso en la versión publicada.
La identificación temprana de estos vectores permite aislar el riesgo antes de que se convierta en una brecha total.
Ejercicio 3: Aplicación de medidas de mitigación
Una aplicación crítica tiene una vulnerabilidad zero-day conocida, pero el parche oficial llegará en dos semanas. El equipo de seguridad debe reducir el impacto inmediato. Propón y evalúa dos medidas de mitigación.
Las medidas de mitigación buscan reducir la severidad del riesgo cuando la solución definitiva no está lista. Se evalúan por su efectividad y costo:
- Aislamiento de red (Segmentación): Se coloca el servidor en una subred privada con acceso limitado. Esto reduce la superficie de ataque. La efectividad es alta si el tráfico entrante es constante.
- Parche temporal (Hotfix): Se aplica un parche rápido desarrollado internamente. Esto resuelve el error específico pero puede introducir nuevas inercias en el código.
El aislamiento de red suele ser la opción más segura a corto plazo porque no modifica el código base, reduciendo la probabilidad de errores secundarios.
Dato curioso: El término "zero-day" hace referencia al día cero, que es el día en que el desarrollador tiene "cero días" para corregir el error antes de que los usuarios lo descubran. No es un error de cálculo, sino de tiempo.
Preguntas frecuentes
¿Por qué se llama "día cero"?
El nombre proviene del momento en que el fabricante descubre la falla. El día en que se lanza el parche se considera el "día uno". Por lo tanto, cualquier ataque que ocurra antes de esa fecha sucede en el "día cero" de conocimiento público.
¿Son los zero-days exclusivos del software de escritorio?
No. Pueden afectar a cualquier sistema basado en código: sistemas operativos (Windows, macOS, Linux), aplicaciones móviles (iOS, Android), navegadores web e incluso el firmware de dispositivos IoT (luces inteligentes, cámaras de seguridad).
¿Puede un usuario promedio detectar un ataque zero-day?
Es difícil. Como la falla es desconocida, las alertas suelen ser genéricas. Sin embargo, herramientas avanzadas de análisis de comportamiento (como los detectores de anomalías) pueden identificar comportamientos extraños en el sistema, como un proceso que consume mucha memoria sin razón aparente.
¿Qué tan frecuentes son los ataques zero-day?
Son menos comunes que las vulnerabilidades conocidas, pero su impacto suele ser mayor. Según diversos informes de la industria, se descubren entre 10 y 20 vulnerabilidades zero-day críticas por año en los sistemas operativos más populares, aunque el número exacto varía según la fuente.
¿Cómo se mitigan si no hay un parche oficial?
La mitigación se basa en la defensa en profundidad. Esto incluye usar firewalls estrictos, limitar los permisos de usuario (para que el daño se quede en un ámbito reducido) y emplear soluciones de seguridad basadas en la nube que pueden actualizar las reglas de detección más rápido que el software local.
Resumen
Los ataques zero-day representan una amenaza significativa debido a su naturaleza sorpresa, explotando fallos de software antes de que los fabricantes lancen una corrección. Su efectividad radica en la brecha de tiempo entre la aparición de la falla y su detección, lo que obliga a las organizaciones a depender de estrategias de defensa en profundidad y análisis de comportamiento.
La gestión de estas vulnerabilidades requiere un enfoque proactivo, que incluye la actualización constante del software, la segmentación de redes y el uso de herramientas de inteligencia de amenazas. Entender la diferencia entre un zero-day y una vulnerabilidad conocida es fundamental para priorizar recursos y minimizar el impacto potencial en la infraestructura tecnológica.