Detectar rápido no sirve de mucho si la respuesta tarda horas. La automatización de la respuesta a incidentes es donde la mayoría de los SOC recuperan más tiempo con menos inversión. En el libro IA en Ciberseguridad la tratamos junto con SOAR y playbooks inteligentes; aquí tienes una guía práctica para empezar sin romper nada.
Qué es SOAR y qué problema resuelve
SOAR (Security Orchestration, Automation and Response) agrupa tres capacidades:
- Orquestación: conectar herramientas que no se hablan entre sí (SIEM, EDR, firewall, correo, directorio, ticketing) mediante sus API.
- Automatización: ejecutar secuencias de pasos sin intervención humana.
- Gestión de casos: registrar cada incidente, sus evidencias, decisiones y tiempos.
La pieza central es el playbook: la versión ejecutable de un procedimiento de respuesta. Hoy estas capacidades vienen como producto independiente o integradas en plataformas de SIEM y XDR.
Qué automatizar primero
Un buen candidato cumple tres condiciones: ocurre a menudo, los pasos son siempre los mismos y un error tiene poco impacto.
| Tarea | Frecuencia | Riesgo de automatizar | Veredicto |
|---|---|---|---|
| Enriquecer una IP o URL con reputación | Muy alta | Nulo | Automatizar ya |
| Analizar un adjunto en sandbox | Alta | Bajo | Automatizar ya |
| Abrir y rellenar el ticket | Muy alta | Nulo | Automatizar ya |
| Bloquear una URL maliciosa en el proxy | Media | Bajo | Automatizar con buena confianza |
| Deshabilitar una cuenta de usuario | Baja | Medio | Con aprobación humana |
| Aislar un servidor de producción | Baja | Alto | Con aprobación humana |
Anatomía de un playbook: phishing reportado
El phishing reportado por empleados es el caso de uso clásico: muy frecuente y muy repetitivo. Así se vería el flujo, escrito en pseudocódigo (cada plataforma tiene su propio formato, visual o en YAML, pero la lógica es la misma):
nombre: phishing-reportado
disparador: correo_reenviado_a_buzon_de_phishing
pasos:
- extraer:
de: [remitente, asunto, urls, adjuntos, cabeceras]
- enriquecer:
urls: [reputacion, captura_de_pantalla]
adjuntos: [hash_en_inteligencia, sandbox]
remitente: [spf_dkim_dmarc, antiguedad_del_dominio]
- clasificar: # aquí entra un modelo de IA
modelo: clasificador_phishing
salida: [veredicto, confianza]
- decidir:
si: veredicto == "malicioso" y confianza >= 0.9
entonces:
- bloquear_url: proxy
- buscar_y_eliminar: correos_con_mismo_remitente_o_url
- responder_al_usuario: "Gracias, era phishing y ya lo eliminamos"
- abrir_caso: { prioridad: alta }
si: veredicto == "malicioso" # confianza media
entonces:
- abrir_caso: { prioridad: media, asignar: nivel_2 }
si_no:
- responder_al_usuario: "Gracias por avisar, el correo es legítimo"
- cerrar_caso: { motivo: falso_positivo }
- si_hubo_clics: # alguien abrió el enlace
requiere_aprobacion: true
acciones: [forzar_cambio_de_contrasena, revocar_sesiones]
Fíjate en tres decisiones de diseño: el umbral de confianza separa la acción automática de la revisión humana; el usuario recibe respuesta (lo que refuerza que siga reportando); y las acciones con impacto sobre personas requieren aprobación.
Niveles de autonomía
- Asistido: el playbook enriquece y sugiere; el analista ejecuta todo.
- Semiautomático: el playbook ejecuta las acciones de bajo riesgo y pide aprobación para el resto, a menudo con un botón en el chat del equipo.
- Automático con supervisión: ejecuta todo y notifica; el humano puede revertir.
Sube de nivel solo cuando el playbook haya demostrado, con datos, que sus decisiones son correctas. Y diseña cada acción automática con su reversión: si bloqueas, debes poder desbloquear con un clic.
Dónde entra la IA
- Clasificación: decidir si un correo, un archivo o un comportamiento es malicioso y con qué confianza.
- Selección del playbook: reconocer qué tipo de incidente es y lanzar el flujo adecuado.
- Priorización: ordenar los casos abiertos por riesgo real, como en un SOC inteligente.
- Documentación: un LLM puede redactar el resumen del incidente y la cronología a partir de los pasos ejecutados, para que el analista solo los revise.
Errores comunes
- Automatizar un proceso que no está claro: si el procedimiento manual es confuso, el playbook automatizará la confusión.
- Playbooks sin propietario: las API de las herramientas cambian y los playbooks se rompen en silencio. Asigna un responsable y prueba los flujos periódicamente.
- Bloqueos sin lista de excepciones: un falso positivo que bloquea el dominio de un proveedor crítico puede causar más daño que el ataque.
- No medir: compara el MTTR y las horas de analista antes y después de cada playbook.
Playbooks inteligentes para tu equipo
El libro IA en Ciberseguridad trata la automatización de respuesta a incidentes con SOAR e incluye plantillas, checklists y un ejemplo de informe de incidente con IA.
Comprar en Amazon