Zero Day Threat (amenaza de día cero)

Una amenaza de día cero (zero day threat) es la que aprovecha una vulnerabilidad de seguridad para la que el fabricante todavía no ha publicado corrección. Los atacantes pueden explotarla desde el momento en que la conocen, y no hay parche que aplicar. El vehículo suele ser un exploit escrito a medida para ese fallo.

Esa es la definición estricta, y conviene sostenerla porque la expresión se usa a la ligera para tres cosas distintas, y solo una de ellas es un día cero. La que tiene corrección publicada y sin desplegar se llama n-day, y no es un problema de amenazas, sino del proceso de actualización de seguridad.

Y la distinción no es académica, porque decide dónde va el presupuesto: a casi todas las organizaciones las compromete un n-day, no un día cero. Lo que sigue explica por qué, y qué se mide de verdad cuando auditamos ese hueco.

El nombre se refiere a cuántos días ha tenido el fabricante para responder, que son cero. Conviene separar tres estados, porque la misma expresión se usa a la ligera para los tres. Una vulnerabilidad que nadie conoce, que es un riesgo que no se puede gestionar. Una vulnerabilidad bajo explotación sin corrección disponible, que es el zero-day de verdad y que exige mitigar y detectar en vez de parchear. Y una vulnerabilidad con corrección que la organización no ha desplegado, que es un n-day y que es un problema de proceso.

Solo el segundo es lo que la palabra debería significar. El tercero es lo que compromete a casi todas las organizaciones, y llamarlo zero-day en el informe de un incidente traslada la culpa del ciclo de parcheo al destino.

El presupuesto sigue a la palabra equivocada. Prepararse para lo verdaderamente desconocido es caro y consiste sobre todo en detección, segmentación y capacidad de respuesta. Cerrar la ventana del n-day es comparativamente barato y es justo lo que casi ningún parque ha hecho, y por eso los episodios de explotación masiva que vemos van detrás de la divulgación pública y no delante: la ventana entre que se publica una corrección y se despliega se mide en semanas o en meses, y la explotación empieza con frecuencia en días.

El segundo fallo es la respuesta a una divulgación sin corrección, que es donde sí se aplica la definición de verdad. Las acciones correctas son quitar exposición, aplicar la mitigación del fabricante, buscar evidencias de explotación dando por supuesto que puede haber ocurrido ya, y subir el registro del componente afectado. Esperar es una decisión, y suele ser la que se toma.

Tercero, un zero-day es caro de conseguir y caro de quemar, así que se usa contra objetivos que valgan ese coste. A casi todas las organizaciones las compromete un exploit de algo parcheado el trimestre pasado, o unas credenciales compradas a un intermediario, que no necesitan ninguna vulnerabilidad.

No usamos exploits sin divulgar en los proyectos de clientes, y merece la pena decirlo con claridad, porque un informe debería reflejar lo que haría un atacante decidido normal. Lo que sí medimos es la ventana del n-day: cuánto tarda una corrección publicada en llegar a producción en el parque que probamos, que es un número sobre el que el cliente puede actuar. El catálogo KEV es la lista más corta de cosas que arreglar primero, y la antigüedad del elemento sin parchear más viejo en una máquina alcanzable es la cifra que predice el incidente siguiente. Ver también la gestión de parches.