La mitigación de ataques es el punto en el que un sistema de seguridad puede causar daño operativo. Bloquear un host, aislar un segmento o rotar credenciales puede ser correcto, pero la misma acción puede interrumpir un servicio crítico si la hipótesis es errónea.
Los LLMs pueden ayudar a comparar respuestas siempre que el espacio de acciones esté restringido fuera del modelo.
1. Separar evidencia, recomendación y acción
Un registro de incidente debe distinguir tres objetos:
- Evidencia: observaciones y su procedencia.
- Recomendación: respuesta propuesta con supuestos y efectos esperados.
- Acción: operación aprobada por política y ejecutada por un plano de control separado.
Mezclar estos objetos impide saber si un resultado incorrecto nació en la detección, en el razonamiento o en la ejecución.
2. Una propuesta de mitigación acotada
Para cada acción candidata , pide al modelo:
Si no ves la fórmula completa, enfócala y usa las flechas izquierda y derecha, o desliza horizontalmente.La propuesta está incompleta si no incluye alcance o recuperación. Recomendar “bloquear al atacante” no es operativo sin identificar el activo, la duración y el paso de validación.
3. Los playbooks como límite de autoridad
El LLM debería seleccionar playbooks aprobados o completar sus parámetros, no inventar comandos. Un motor de políticas puede rechazar acciones que superen la criticidad del activo, la autoridad del usuario o el radio de impacto permitido.
Esto también limita la prompt injection. El texto no confiable puede influir en la explicación, pero no puede conceder un permiso nuevo al modelo.
4. Feedback después de mitigar
El sistema debe registrar si la acción redujo la señal, produjo un efecto lateral, requirió rollback o reveló otra causa raíz. Ese feedback mejora la investigación siguiente, pero debe revisarse antes de convertirse en datos de entrenamiento.
Algunos campos útiles son:
- identificadores de evidencia,
- playbook y parámetros elegidos,
- identidad de quien aprobó,
- estado observado después de la acción,
- evento de rollback o caducidad,
- corrección del analista.
5. Un primer caso de uso realista
Empieza comparando en modo de solo lectura dos o tres opciones aprobadas. Pide al modelo que explique por qué una es preferible, qué evidencia falta y qué invalidaría la recomendación. Después puedes plantear automatización de bajo riesgo con caducidad corta y rollback automático.
El objetivo del apoyo de LLM no es eliminar al responsable de la respuesta. Es hacer más visible el compromiso entre velocidad, evidencia y riesgo operativo.
De una recomendación a una transacción comprobable
Como ejemplo de diseño, considera un aislamiento temporal aprobado sobre un equipo de laboratorio. La propuesta identifica el activo mediante un identificador estable, el playbook y su versión, las evidencias que justifican la medida y el estado esperado antes y después. También incluye el responsable y el momento de expiración. No debe depender de que el modelo recuerde una instrucción anterior.
Antes de ejecutar, el controlador vuelve a comprobar los permisos y las precondiciones. El estado puede haber cambiado desde la aprobación: el activo pudo ser sustituido, la alerta cerrada o la política actualizada. Este problema de tiempo entre comprobación y uso exige validación al ejecutar, no solo al generar el plan.
Idempotencia, caducidad y compensación
Un reintento de red no debe duplicar una acción. Asigna un identificador a la operación y comprueba si ya se aplicó. Si una acción no tiene una inversión exacta, documenta una compensación y sus límites; revocar un token, por ejemplo, no permite recuperar el mismo secreto de forma segura.
Para evaluar este flujo, introduce fallos de laboratorio: respuesta de herramienta ausente, timeout después de aplicar el cambio o permiso revocado antes de ejecutar. Mide acciones duplicadas, cambios fuera de alcance y recuperaciones fallidas. Son fallos distintos de una mala explicación.
NIST SP 800-61 Rev. 3 aporta el marco de respuesta a incidentes. OWASP sobre exceso de agencia describe riesgos de funcionalidad, permisos y autonomía excesivos. Los patrones transaccionales anteriores son una propuesta de ingeniería para aplicarlos a un flujo concreto.
La ciberdefensa autónoma acotada amplía el ciclo de control y las pruebas de agentes ante prompt injection cubren entradas manipuladas.
