Respuesta directa
En pocas palabras
Para responder a una vulnerabilidad zero-day en un sistema de IA, valida la señal sin esperar un CVE, fija el componente y release afectados, determina exposición y capacidad del atacante, activa responsables y protege evidencia. Si no existe parche, reduce la superficie con aislamiento, desactivación, privilegio mínimo, filtrado, segmentación o un proceso manual; busca explotación sin interpretar la ausencia de indicadores como seguridad; coordina con el proveedor; y, cuando llegue un fix, prueba la ruta y las regresiones antes de desplegarlo por etapas. Cierra solo después de verificar producción, residuos, datos, comunicaciones y riesgo residual.
Define zero-day por la decisión que exige, no por el titular
El término zero-day se usa de formas distintas. Para operar, define una condición de seguridad nueva o recién conocida para la que todavía no existe una corrección disponible y validada en tu contexto, o cuyo conocimiento defensivo llega sin tiempo de preparación. Puede existir un identificador, advisory parcial o mitigación. Lo importante es que la organización debe reducir exposición antes de contar con un fix normal y comprobado.
No confundas vulnerabilidad, explotación e incidente. Una vulnerabilidad es una condición que puede habilitar un efecto no autorizado. Explotación significa que alguien usa esa condición. Un incidente requiere evidencia de compromiso o impacto en tu entorno. La etiqueta zero-day no demuestra que fuiste atacado, y la ausencia de CVE no reduce el riesgo. Conserva hechos, hipótesis y desconocidos por separado desde el primer registro.
Activa el proceso con una señal creíble y una autoridad clara
La señal puede llegar por un investigador, proveedor, CERT, feed, comportamiento anómalo, prueba interna o noticia pública. Registra fuente, hora, confidencialidad, activos nombrados, versiones, precondiciones, impacto propuesto y evidencia disponible. Valida autenticidad del canal y evita ejecutar pruebas no confiables en producción. No esperes un boletín perfecto para asignar dueño y evaluar exposición.
Define criterios de activación: posible ejecución remota, cruce entre organizaciones, acceso a secretos, control de herramientas, exposición pública, explotación observada o impacto sobre un servicio crítico. Nombra líder técnico, autoridad de riesgo, responsable de comunicación, enlace con proveedor y suplentes. Un war room sin derecho a desactivar una función solo acelera conversaciones; la autoridad y los límites deben existir antes de la emergencia.
Fija el sujeto exacto y construye el alcance desde runtime
Relaciona la condición con paquete, imagen, modelo, parser, servidor, plugin, driver, API o servicio administrado exactos. Resuelve aliases, forks, builds y digests. Usa SBOM o AI/ML-BOM, registry, lineage, manifests y telemetría para encontrar dónde opera realmente. Una dependencia puede existir en build, notebook o entrenamiento aunque no aparezca en el contenedor de inferencia.
Dibuja la ruta de entrada a efecto: quién puede alcanzar el componente, qué autenticación necesita, qué datos procesa, con qué privilegios corre y qué sistemas toca después. Separa internet, red interna, tenant, región y función. Un match de nombre no confirma aplicabilidad; una búsqueda sin resultados tampoco demuestra ausencia si el inventario está incompleto. Etiqueta explícitamente cada zona no observada.
Preserva una baseline antes de que la contención borre señales
Antes de reiniciar, bloquear o reconstruir, conserva dentro de la autoridad permitida logs, procesos, conexiones, identidades, cambios, digests, configuración, timestamps, alertas y artefactos volátiles necesarios. Registra zona horaria y sincronización. Minimiza datos personales y secretos; usa repositorio restringido, hashes, control de acceso y cadena de manejo proporcional. Una captura indiscriminada puede crear otro riesgo.
Fija también el comportamiento normal: volumen, errores, latencia, llamadas de herramientas, accesos a datos, patrones de RAG y cambios del CRM. Esa baseline ayuda a buscar anomalías y a evaluar el efecto de la mitigación. No prometas una investigación forense que la telemetría no soporta. Declara retención, huecos, sensores caídos y conclusiones que no pueden demostrarse.
Prioriza con exposición e impacto mientras la severidad madura
Durante las primeras horas pueden faltar vector, CVSS, CVE, exploit fiable y lista de versiones. Decide con lo que sí conoces: exposición, autenticación, privilegios, datos, blast radius, criticidad, facilidad de abuso, controles y explotación observada. Mantén una prioridad provisional con razones y siguiente revisión. La incertidumbre alta puede justificar más precaución, no una puntuación inventada.
CISA KEV es una señal de explotación observada para vulnerabilidades publicadas y debe alimentar la prioridad cuando aplica; no cubre todo zero-day y no demuestra ataque en tu organización. Separa inteligencia externa de evidencia interna. Una condición no listada puede ser urgente. Una condición listada necesita todavía confirmar producto, release y exposición locales.
| Criterio | Qué sabes | Decisión inmediata |
|---|---|---|
| Señal | Reporte o inteligencia aún no validada | Autenticar, asignar y delimitar |
| Aplicable | Componente y ruta existen en el release | Reducir exposición y probar |
| Explotada | Existe uso observado en algún entorno | Acelerar contención y hunting |
| Incidente | Hay efecto o compromiso propio | Responder, recuperar y comunicar |
Diseña una contención que pueda ejecutarse y revertirse
Elige controles según la ruta: retirar el endpoint, desactivar formato o plugin, aislar workers, bloquear una entrada, reducir permisos, separar tenants, limitar egress, rotar secretos, aplicar una regla de gateway, forzar autenticación, bajar cuota o pasar a revisión manual. Para un servicio administrado, puede ser necesario cambiar de proveedor, región, modelo o modo. Conserva qué ataque interrumpe cada control y qué rutas quedan abiertas.
Una virtual patch o regla de filtrado puede comprar tiempo, pero depende de cobertura, orden, codificación, evasiones y disponibilidad del sensor. No la llames corrección. Prueba casos normales y adversos, observa falsos positivos y define owner, vigencia, rollback y criterio de reemplazo. Si el control impide una función esencial, la autoridad compara exposición y continuidad con alternativas no automatizadas.
Aplica controles a cada frontera de IA, no solo al modelo
Un parser vulnerable antes del RAG puede requerir bloquear formatos o procesar archivos en un sandbox. Una herramienta con autorización débil puede pasar a allowlist, scopes mínimos y aprobación humana. Un servidor de inferencia vulnerable puede aislarse por red o migrarse a una imagen corregida. Un notebook sin exposición pública puede seguir teniendo secretos, datasets y capacidad de publicar artefactos; limita credenciales y promoción.
Revisa prompts, memoria, embeddings, retrieval, modelos, plugins y llamadas externas por separado. No uses filtros de contenido para una vulnerabilidad de memoria, ni un prompt defensivo para corregir autorización. Si el comportamiento no encaja en una vulnerabilidad tradicional, conserva el caso en threat model, evaluación o incidente de IA sin forzarlo a CVE. La contención debe bloquear la capacidad no autorizada, no solo cambiar el texto visible.
Busca explotación con hipótesis, no con una sola IOC
Construye hipótesis desde la ruta: qué logs cambiarían, qué procesos o conexiones aparecerían, qué identidad se usaría, qué datos se consultarían y qué acción aguas abajo ocurriría. Busca en ventanas anteriores y posteriores, regiones, réplicas, colas, notebooks y proveedores. Conserva consultas, cobertura, falsos positivos y límites. Un indicador publicado puede ser útil, pero un atacante puede cambiarlo.
La ausencia de evidencia no es evidencia de ausencia cuando faltan logs, la retención expiró o el actor evitó sensores. Expresa la conclusión con alcance: no se encontraron señales en estas fuentes y este periodo. Si aparecen indicios, activa el proceso de incidente, amplía preservación, revoca accesos, concilia datos y comunica según obligaciones. No cierres el zero-day solo porque una búsqueda inicial terminó limpia.
Coordina proveedor, investigador y terceros sin filtrar detalles
Usa el canal de seguridad del proveedor y comparte sujeto, versión, precondiciones, reproducción mínima, impacto y mitigación observada. Alinea identificador de caso, cadencia y permisos de redistribución. Si varias organizaciones están afectadas, define quién coordina, corrige, asigna CVE, redacta advisory y avisa a cada población. Comparte el mínimo necesario mediante un canal restringido.
No esperes pasivamente. Mantén contención local, fecha de revisión y alternativa si el proveedor no responde. Evita publicar exploit o abrir una issue pública antes de coordinar. A la vez, no aceptes secreto indefinido sin progreso. Registra acuerdos y desacuerdos. La divulgación responsable busca que la información accionable llegue con una protección disponible y evita sorpresas, sin prometer control absoluto sobre la fecha.
Comunica decisiones por audiencia y nivel de certeza
El equipo operativo necesita activos, controles y siguientes acciones. Liderazgo necesita exposición, impacto potencial, continuidad, decisiones y riesgo residual. Soporte necesita un guion sin detalles explotables. Clientes afectados necesitan saber qué producto, periodo, acción y canal aplican. Legal y privacidad evalúan contratos, datos y obligaciones. Un solo mensaje para todos suele revelar demasiado o decir demasiado poco.
Distingue confirmado, probable, investigado y desconocido. No declares brecha sin evidencia ni seguridad completa porque el servicio sigue en línea. Fecha cada actualización y corrige públicamente si cambian los hechos. Evita publicar un CVE, exploit o versión afectada antes de que la coordinación lo permita. Mantén registro de aprobaciones y de quién recibió cada comunicación.
Controla el cambio de emergencia sin exigir el proceso normal completo
Un zero-day puede justificar acortar pruebas y aprobaciones, no eliminar identidad, responsable, rollback, observabilidad o registro. Define un carril de emergencia con gates mínimos: sujeto y digest, hipótesis, revisión proporcional, prueba crítica, autoridad, condición de alto, backup y verificación. Si no hay tiempo para canary amplio, aumenta monitoreo y limita población o capacidad.
Documenta lo omitido y crea una deuda con propietario y fecha. Una mitigación urgente puede afectar calidad, latencia, costo o conversión; mide esos efectos sin usar continuidad comercial para ocultar exposición. Evita cambios simultáneos no relacionados. Promueve el mismo artefacto probado y conserva una alternativa que no restaure silenciosamente la ruta vulnerable.
Cuando llegue el fix, valida eficacia y regresiones antes de confiar
Obtén el fix de un canal autorizado y verifica versión, firma, checksum, provenance o attestation disponibles. Revisa el delta y nuevas dependencias. Ejecuta la reproducción contra baseline y candidato; añade bypasses. Prueba función, IA, datos, permisos, rendimiento, costo, recuperación y controles temporales. La existencia de un paquete o imagen nueva no demuestra que cubra tu variante.
Despliega por etapas cuando sea posible, con población, duración, señales y condición de alto. Confirma digest en réplicas, workers, jobs, notebooks y regiones. Busca versiones residuales. Retira cada control temporal solo después de demostrar que su reemplazo funciona. Si el fix falla o produce una regresión bloqueante, conserva una mitigación aprobada y reabre coordinación; no marques resuelto por calendario.
Cierra exposición, incidente y comunicación como resultados separados
La vulnerabilidad puede quedar corregida mientras una investigación sigue abierta. El incidente puede estar contenido mientras clientes aún deben actualizar. La comunicación puede terminar después de confirmar impacto y remediación. Mantén condiciones de cierre distintas. Actualiza BOM, lineage, VEX, riesgo, advisory, inventario, runbooks y excepciones con el estado efectivo y las limitaciones.
Realiza una revisión sin culpa: tiempo hasta detectar, delimitar, contener, obtener fix, verificar y recuperar; decisiones acertadas; señales faltantes; controles que fallaron; comunicación; deuda y escapes. Convierte hallazgos en dueños, fechas y pruebas. Ensaya escenarios futuros sin parche. El éxito no es que el tablero vuelva a verde, sino que la organización pueda demostrar qué riesgo redujo y qué incertidumbre permanece.
Aplica la respuesta zero-day a los límites verificables de Cerravi
En Cerravi, una señal zero-day se relacionaría con release, digest, AI/ML-BOM, lineage, ambiente, organización, ruta, evidencia, mitigación y autoridad. La respuesta conectaría vulnerabilidad, incidente, cambio, backup, journal, readiness, comunicación y validación sin fusionar estados. La operación podría desactivar una integración, limitar una ruta o pasar a revisión manual antes de tener un parche.
Este proceso no amplía capacidades públicas. Cerravi organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente desde los recorridos públicos. Las propuestas usan productos y precios conocidos y piden revisión si falta un importe. Las monedas permanecen separadas salvo conversión aprobada. Forecast aplica reglas transparentes del CRM, no un modelo predictivo entrenado o calibrado, y no garantiza cierres. Responder bien reduce exposición; no certifica seguridad, cumplimiento ni ausencia de compromiso.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué es una vulnerabilidad zero-day?
Operativamente es una condición nueva o recién conocida para la que todavía no existe una corrección disponible y validada en el contexto afectado, o cuyo conocimiento llega sin preparación defensiva. No implica por sí sola explotación ni incidente y puede o no tener CVE.
¿Qué se puede hacer si todavía no existe un parche?
Se puede aislar el componente, desactivar una ruta, bloquear entradas, reducir permisos, limitar red o egress, rotar secretos, aplicar filtrado temporal, cambiar de proveedor o usar un proceso manual. Cada control debe probarse, monitorearse, vencer y ser reemplazado por una corrección.
¿Un zero-day significa que la empresa ya fue atacada?
No. La vulnerabilidad describe una condición; la explotación describe su uso; un incidente propio requiere evidencia de efecto o compromiso. Debe hacerse threat hunting, pero una búsqueda sin hallazgos tampoco demuestra ausencia si la cobertura o retención son incompletas.
¿CISA KEV contiene todos los zero-day?
No. KEV reúne vulnerabilidades publicadas con evidencia de explotación conocida y es una señal importante de prioridad. Una condición nueva puede no estar listada, y una entrada listada todavía necesita análisis de producto, release, alcance y exposición local.
¿Cuándo puede cerrarse la respuesta a un zero-day?
Cuando la ruta está contenida o corregida en el release efectivo, el fix y sus regresiones fueron validados, no quedan residuos relevantes, el hunting y los datos tienen conclusiones con límites, las comunicaciones aplicables terminaron y el riesgo residual tiene autoridad y seguimiento.