El Equipo Indio de Respuesta ante Incidentes Informáticos (CERT-In) ha publicado la guía CISG-2026-02 de 38 páginas, que fija plazos estrictos para la remediación de vulnerabilidades: las vulnerabilidades conocidas explotadas en sistemas con acceso desde Internet deben cerrarse en un plazo de 12 horas, cuando sea viable. El documento está directamente motivado por el aumento de las amenazas asociadas al uso, por parte de los atacantes, de herramientas de inteligencia artificial y grandes modelos de lenguaje para automatizar la detección y explotación de vulnerabilidades. La guía afecta a todas las organizaciones que dependen de infraestructura en la nube, cadenas de suministro de software, tecnologías operativas y plataformas basadas en IA.
Requisitos clave sobre plazos de remediación
CERT-In introduce un sistema diferenciado de plazos de parcheo basado en la evaluación de riesgos. Es uno de los modelos de gestión de vulnerabilidades más agresivos entre los equipos CERT nacionales:
- Vulnerabilidades conocidas explotadas en sistemas expuestos a Internet y sistemas críticos — 12 horas (cuando sea viable)
- Vulnerabilidades críticas en sistemas externos — 1 día
- Vulnerabilidades conocidas explotadas en sistemas internos — 1 día (si no se han documentado medidas de mitigación alternativas)
- Vulnerabilidades internas críticas en sistemas de alto valor — 3 días
- Vulnerabilidades de alta severidad — 5 días, en función de la priorización del riesgo
Cuando no hay un parche disponible, CERT-In recomienda aplicar medidas temporales: aislar los sistemas afectados, restringir el acceso, proteger mediante WAF y gateways de API, reforzar la monitorización o desactivar la funcionalidad vulnerable hasta la publicación de la corrección.
Por qué precisamente 12 horas: el factor de aceleración de ataques por IA
La justificación de unos plazos tan ajustados es consecuencia directa de la evaluación de CERT-In sobre el impacto de la IA en el panorama de amenazas. Según la guía, «los ciberataques con uso de IA reducen el tiempo que necesitan los atacantes para detectar, armar y explotar vulnerabilidades, servicios expuestos, credenciales débiles, API inseguras y sistemas mal configurados».
CERT-In destaca varias direcciones de uso de la IA por parte de los atacantes: reconocimiento de la superficie de ataque, análisis de exploits, generación de contenido de phishing convincente y creación de malware. Según se indica, estas capacidades permiten acortar significativamente los tiempos de preparación de los ataques y eludir los controles de seguridad tradicionales. Cabe señalar que en la guía no se aportan datos cuantitativos concretos sobre la magnitud de este uso: se habla de una tendencia que CERT-In considera lo suficientemente madura como para merecer una respuesta regulatoria.
Un bloque específico de la guía se dedica a los riesgos para los propios sistemas de IA. CERT-In advierte sobre amenazas mediante prompt injection, fugas de datos, jailbreak de modelos, manipulación de modelos, envenenamiento de datos de entrenamiento, robo de modelos y compromiso de los pipelines de orquestación.
Principios de protección y requisitos de arquitectura
La guía define una estrategia de protección integral que va mucho más allá del patch management:
- Suposición de compromiso (assume breach) — preparación para una detección, contención y recuperación rápidas
- Arquitectura de confianza cero (Zero Trust) — verificación continua y privilegios mínimos
- Defensa en profundidad (defense-in-depth) — controles multinivel para evitar puntos únicos de fallo
- Seguridad por defecto (secure-by-design) — integración de la seguridad en sistemas, aplicaciones y flujos de trabajo de IA
- Gestión de riesgos de la cadena de suministro — mediante SBOM, validación del origen de los componentes y evaluación de dependencias, incluidos los modelos de IA
- Gobernanza formal de los sistemas de IA — establecimiento de mecanismos de control sobre el uso de la IA y garantía de visibilidad sobre sus integraciones y comportamiento
CERT-In también insiste en comprobar regularmente la eficacia de las defensas mediante pentesting, evaluación de vulnerabilidades, ejercicios de red team y auditorías independientes.
Contexto: advertencia previa sobre modelos de IA de frontera
La guía apareció un mes después de que CERT-In publicara una advertencia independiente CIAD-2026-0020 sobre las capacidades cibernéticas de los modelos de IA de frontera de Anthropic y OpenAI. En ese documento se subrayaba que la «doble naturaleza» de estos modelos puede «reducir la barrera de entrada para los atacantes y utilizarse para acelerar la ejecución de ataques, automatizar workflows de explotación y escalar campañas de ciberataques». De este modo, la nueva guía es la continuación lógica del trabajo sistemático de CERT-In para adaptar el marco regulatorio a la realidad de las amenazas potenciadas por IA.
Recomendaciones prácticas
Para las organizaciones sujetas a la guía de CERT-In, los pasos prioritarios son los siguientes:
- Realizar una auditoría de los sistemas expuestos a Internet y contrastarlos con los catálogos de vulnerabilidades conocidas explotadas. Garantizar la capacidad de aplicar parches de emergencia dentro de las 12 horas.
- Implantar una gestión continua de vulnerabilidades que cubra no solo defectos de software, sino también errores de configuración, API inseguras, servicios expuestos públicamente y credenciales débiles.
- Diseñar procedimientos de mitigación temporal para situaciones en las que no haya parche disponible: plantillas de reglas de WAF, procedimientos de aislamiento y pautas para desactivar funcionalidades.
- Evaluar los riesgos específicos de la IA — inventariar los modelos utilizados, comprobar la protección frente a prompt injection y fugas de datos, y garantizar el control de la cadena de suministro de componentes de IA.
- Formalizar la gobernanza de la IA — documentar las políticas de uso de los sistemas de IA y garantizar la monitorización de sus integraciones.
La guía de CERT-In marca un referente que probablemente influirá en las expectativas regulatorias de otras jurisdicciones. Las organizaciones deberían evaluar desde ahora su capacidad para soportar un ciclo de parcheo de 12 horas para vulnerabilidades críticas y, si los procesos actuales no lo permiten, empezar por automatizar la detección de vulnerabilidades y el despliegue de correcciones en los sistemas con acceso externo.
