Plan de Respuesta a Incidentes de IA

Taxonomía de incidentes

Este plan de respuesta a incidentes cubre los incidentes que son exclusivos de los sistemas de IA o que se ven significativamente afectados por ellos. Los incidentes tradicionales de ciberseguridad (malware, acceso no autorizado, DDoS) siguen el plan de respuesta a incidentes existente; este plan lo complementa para escenarios específicos de IA.

Categoría 1: Explotación de inyección de prompts

• Descripción: Un atacante inyecta con éxito instrucciones que anulan el comportamiento previsto del sistema de IA
• Indicadores: Salidas inesperadas de la IA, exposición del prompt del sistema, acciones no autorizadas por agentes de IA, patrones de salida anómalos detectados por el monitoreo
• Ejemplos: Un chatbot orientado al cliente proporciona información no autorizada, un agente de IA ejecuta llamadas a herramientas no previstas, el prompt del sistema se extrae y se publica

Categoría 2: Fuga de datos de IA

• Descripción: Se exponen datos sensibles a través de las salidas del sistema de IA, ya sea por memorización de datos de entrenamiento, errores de recuperación de RAG o registro de eventos de prompts y respuestas
• Indicadores: Salidas de IA que contienen PII, credenciales o datos confidenciales no presentes en la entrada del usuario; datos no autorizados que aparecen en contenido generado por IA
• Ejemplos: Un chatbot de IA revela los datos de otro cliente, un asistente de código genera claves de API provenientes de datos de entrenamiento, un sistema RAG expone documentos confidenciales a usuarios no autorizados

Categoría 3: Compromiso del modelo

• Descripción: El propio modelo de IA es manipulado: datos de entrenamiento envenenados, pesos modificados o modelo sustituido
• Indicadores: Cambios repentinos de comportamiento, exactitud degradada en los conjuntos de validación, nuevos sesgos o salidas dañinas que antes no estaban presentes
• Ejemplos: Ataque a la cadena de suministro sobre los pesos del modelo, ajuste fino adversario mediante envenenamiento de datos, sustitución del modelo en el pipeline de despliegue

Categoría 4: Amplificación de ataques habilitada por IA

• Descripción: Un atacante utiliza los sistemas de IA de la organización para amplificar un ataque tradicional: generando contenido de phishing, automatizando el reconocimiento o explotando integraciones de herramientas
• Indicadores: Sistemas de IA que generan grandes volúmenes de comunicaciones salientes, patrones inusuales de uso de herramientas, contenido generado por IA utilizado en ingeniería social
• Ejemplos: Un atacante utiliza la IA interna para generar correos de phishing dirigidos, un agente de IA es explotado para exfiltrar datos a través de integraciones de API aprobadas

Categoría 5: Incidentes de sesgo y equidad

• Descripción: El sistema de IA produce salidas discriminatorias, dañinas o injustas que afectan a personas o grupos
• Indicadores: Quejas de clientes sobre trato discriminatorio, informes de medios de comunicación, detección interna mediante monitoreo de equidad
• Ejemplos: Una IA de contratación perjudica sistemáticamente a un grupo protegido, una IA de moderación de contenido marca de forma desproporcionada contenido de grupos demográficos específicos

Matriz de severidad

Árbol de decisión de clasificación

1. ¿Existe exposición de datos confirmada que involucre datos regulados (PII, PHI, PCI)? → Si es así, mínimo SEV-2; si la exposición es masiva, SEV-1
2. ¿El sistema de IA está siendo explotado activamente? → Si es así, mínimo SEV-2; si la explotación afecta a los clientes, SEV-1
3. ¿El modelo de IA ha sido comprometido (pesos, datos de entrenamiento, configuración)? → Si es así, mínimo SEV-2
4. ¿El sistema de IA está produciendo salidas dañinas o discriminatorias para los usuarios finales? → Si es así, mínimo SEV-2
5. ¿Se trata de una vulnerabilidad confirmada sin evidencia de explotación? → SEV-3
6. ¿Se trata de una violación de políticas o una vulnerabilidad potencial sin impacto confirmado? → SEV-4

Reclasificación de severidad

La severidad puede aumentarse en cualquier momento durante la respuesta a medida que se dispone de nueva información. Las reducciones de severidad requieren la aprobación del Comandante de Incidentes y una justificación documentada.

Fase 1: Detección y triaje (0-30 minutos)

1. Alerta recibida: Incidente detectado mediante monitoreo, informe de usuario o notificación externa
2. Evaluación inicial: El analista de seguridad de guardia revisa el contexto de la alerta, confirma que está relacionada con IA y realiza la clasificación de severidad inicial
3. Comandante de incidentes asignado: Según la severidad:

- SEV-1/SEV-2: Ingeniero de seguridad senior o CISO

- SEV-3/SEV-4: Analista de seguridad de guardia

1. Canal de comunicación establecido: Se crea un canal de incidentes dedicado en [TOOL] con la siguiente convención de nomenclatura: ai-incident-[DATE]-[SEQ]
2. Notificación inicial: Se notifica a las partes interesadas según la matriz de escalamiento por severidad

Fase 2: Contención (30 minutos - 4 horas)

Acciones de contención inmediata por categoría

Fase 3: Investigación (4-48 horas)

1. Recopilación de evidencia: Conservar todos los registros, prompts, respuestas, versiones del modelo y configuraciones del sistema
2. Análisis de causa raíz: Determinar cómo ocurrió el incidente, qué vulnerabilidad fue explotada y cuál es el radio de impacto
3. Evaluación de impacto: Identificar todos los usuarios, datos y sistemas afectados
4. Construcción de la línea de tiempo: Elaborar una línea de tiempo detallada desde el compromiso inicial hasta la detección

Fase 4: Erradicación y recuperación (1-7 días)

1. Remediación de la vulnerabilidad: Implementar correcciones para la causa raíz
2. Restauración del sistema: Restaurar los sistemas de IA a un estado limpio verificado
3. Pruebas de verificación: Ejecutar el playbook de red teaming de IA contra el sistema remediado
4. Mejora del monitoreo: Implementar monitoreo adicional para el patrón de ataque específico

Comunicación interna

Matriz de notificación

Frecuencia de actualizaciones de estado

Plantilla de actualización de estado

ACTUALIZACIÓN DE ESTADO DE INCIDENTE DE IA
ID de incidente: [ID]
Severidad: [SEV-X]
Estado: [Investigando / Conteniendo / Erradicando / Recuperando / Cerrado]
Hora de actualización: [TIMESTAMP]

Situación actual: [Resumen de 1-2 oraciones]
Acciones tomadas desde la última actualización: [Lista con viñetas]
Próximos pasos: [Lista con viñetas]
ETA para la próxima actualización: [TIMESTAMP]
Comandante de incidentes: [NAME]

Comunicación externa

Notificación regulatoria

Comunicación con clientes

Se requiere notificar a los clientes cuando los incidentes de IA resulten en la exposición de datos de clientes, la entrega de asesoramiento generado por IA que sea materialmente incorrecto, o resultados discriminatorios que afecten a los clientes. Todas las comunicaciones con clientes deben ser revisadas por Legal y PR antes de su distribución.

Reunión de revisión posterior al incidente

Plazo: Se realiza dentro de los 5 días hábiles posteriores al cierre del incidente

Asistentes:

• Comandante de incidentes
• Todos los respondedores involucrados en el incidente
• Propietario del sistema de IA
• Líder de seguridad
• Líder de ingeniería
• [ROLE TITLE] (representante del Comité de Gobernanza de IA)

Agenda:

1. Revisión de la línea de tiempo del incidente (15 min) — Recorrer la línea de tiempo completa desde la detección hasta el cierre
2. Análisis de causa raíz (30 min) — Presentar y discutir la causa raíz técnica
3. Eficacia de la respuesta (20 min) — Evaluar qué funcionó bien y qué se podría mejorar
4. Análisis de brechas de detección (15 min) — Evaluar por qué el incidente no se detectó antes
5. Validación de la remediación (10 min) — Confirmar que todas las remediaciones estén implementadas y verificadas
6. Elementos de acción (15 min) — Asignar y programar las acciones de seguimiento

Informe posterior al incidente

El Comandante de Incidentes elabora un informe escrito dentro de los 10 días hábiles posteriores a la reunión de revisión:

Métricas monitoreadas

Proceso de lecciones aprendidas

Captura

Las lecciones aprendidas se capturan a partir de tres fuentes:

1. Reunión de revisión posterior al incidente: El facilitador documenta las lecciones identificadas durante la discusión
2. Retrospectivas de los respondedores: Cada respondedor envía observaciones individuales dentro de los 3 días hábiles posteriores al cierre del incidente
3. Análisis de métricas: Análisis cuantitativo de las métricas de respuesta en comparación con las metas

Clasificación

Cada lección se clasifica por categoría:

Distribución

Integración en los procesos organizacionales

Las lecciones aprendidas deben dar lugar a actualizaciones concretas en al menos uno de los siguientes elementos:

1. Este plan de respuesta a incidentes: Actualizar los procedimientos, categorías o criterios de severidad según los nuevos tipos de incidentes
2. Playbook de red teaming de IA: Agregar nuevos escenarios de ataque descubiertos durante los incidentes
3. Lista de Verificación de Defensa contra Inyección de Prompts: Actualizar los controles técnicos según las técnicas de ataque observadas
4. Lista de Verificación de Validación de Despliegue de IA: Agregar verificaciones que habrían evitado el incidente
5. Materiales de capacitación: Actualizar la capacitación en seguridad de IA con estudios de caso reales (anonimizados)
6. Monitoreo y detección: Implementar nuevas reglas de detección y alertas basadas en los indicadores observados

Seguimiento

Todas las lecciones aprendidas se registran en la Base de Conocimiento de Incidentes de IA mantenida por [DEPARTMENT]. Cada entrada incluye: referencia del incidente, descripción de la lección, categoría, acción tomada, fecha de implementación y evaluación de eficacia (evaluada en la siguiente revisión trimestral).