Automatizar el SOC no es comprar una plataforma SOAR y activar todos los playbooks de una vez. Es decidir, con criterio, qué decisiones puede tomar la máquina por sí sola, cuáles necesitan a una persona y quién responde cuando algo sale mal. Este checklist ordena esa decisión para el CISO: qué automatizar primero, cómo definir niveles de autonomía, cómo acordar la contención con el negocio y cómo demostrar que la automatización funciona.
Por qué automatizar y por dónde empezar
El argumento central es el tiempo. La NIST SP 800-61 Rev. 3, publicada en abril de 2025, reorganizó las recomendaciones de respuesta a incidentes en torno a las funciones del NIST CSF 2.0 y trata la respuesta como parte de la gestión de riesgos, no como un evento aislado. Detectar y contener más rápido reduce el impacto, y la automatización ayuda en eso. La ganancia real, sin embargo, está en quitarle al analista el trabajo repetitivo para que dedique su tiempo a lo que exige criterio, como explicamos en SOC tradicional vs. SOC moderno.
La regla práctica para elegir el primer objetivo: empiece por lo que es frecuente, estandarizado y de bajo riesgo si falla. Deje para después lo raro, lo ambiguo o lo que puede detener la operación.
- Enriquecimiento de alertas. Consultar la reputación de IP, dominio y hash, el dueño y la criticidad del activo, el historial del usuario y la técnica de MITRE ATT&CK asociada. Es solo lectura: no modifica nada en el entorno.
- Triaje. Agrupar alertas duplicadas, descartar patrones ya confirmados como falsos positivos y ajustar la prioridad según la criticidad del activo. Requiere reglas documentadas y revisión periódica.
- Apertura y enrutamiento de casos. Crear el caso en el sistema de tickets con las evidencias ya adjuntas y enviarlo a la cola correcta, con el plazo correcto. Elimina el traspaso informal entre quien detecta y quien actúa.
- Contención de bajo riesgo. Acciones reversibles y de alcance limitado: bloquear un indicador ya confirmado como malicioso, poner en cuarentena un correo de phishing, forzar el cambio de contraseña de una cuenta común, aislar una estación de usuario mediante el EDR.
Playbooks SOAR y niveles de autonomía
Un playbook es la secuencia documentada de pasos para un tipo de caso: qué recopilar, qué verificar, cuándo escalar y qué ejecutar. Antes de convertirse en automatización, debe existir en papel y funcionar de forma manual. La CISA publicó playbooks de respuesta a incidentes y vulnerabilidades para organismos federales estadounidenses que sirven como modelo de estructura, y el estándar abierto CACAO, de OASIS, define un formato para describir playbooks de seguridad de modo que puedan compartirse y ejecutarse en distintas herramientas.
Cada acción de un playbook debe tener un nivel de autonomía explícito. Una escala sencilla, de cuatro escalones:
- Solo notificar. La automatización detecta, enriquece y avisa. Ninguna acción en el entorno.
- Sugerir. La automatización propone la acción, con la justificación y las evidencias. El analista decide y ejecuta.
- Ejecutar con aprobación. La acción está lista; una persona autorizada la aprueba con un clic y la plataforma la ejecuta y la registra.
- Ejecutar. La plataforma actúa sola y avisa después. Reservado para acciones preaprobadas, reversibles y ya probadas.
Un playbook nuevo debe empezar en los escalones más bajos y subir solo tras un período de observación en el que sus sugerencias hayan resultado correctas. La misma acción puede tener niveles distintos según el objetivo: aislar la estación de un colaborador puede ser automático; aislar un servidor de pagos, nunca sin aprobación.
Preaprobación de la contención con el negocio
El peor momento para discutir si el SOC puede deshabilitar la cuenta de un director es durante el incidente. Esa conversación debe darse antes, con las áreas de negocio, y quedar documentada.
- Matriz de acciones por activo. Para cada clase de activo (estaciones, servidores, cuentas comunes, cuentas privilegiadas, sistemas críticos), qué acciones están preaprobadas y en qué nivel de autonomía.
- Lista de excepciones. Activos y cuentas que nunca reciben acciones automáticas, como sistemas de producción sensibles y cuentas de servicio que sostienen procesos críticos. Para cuentas privilegiadas, vea también gestión de accesos privilegiados.
- Dueños y aprobadores. Quién aprueba cada tipo de acción, con suplentes y contactos fuera del horario laboral.
- Criterios de comunicación. A quién se informa después de una acción automática y por qué canal.
La contención también tiene costo. Aislar un servidor por error detiene la operación. La preaprobación existe para equilibrar el riesgo del ataque con el riesgo de la propia respuesta, y esa decisión es del negocio, no solo de seguridad.
Pruebas y rollback
Una automatización equivocada se equivoca a escala. Antes de subir un playbook de nivel, confirme:
- Pruebas en entorno controlado. Ejecutar el playbook sobre casos reales anteriores o en laboratorio antes de producción.
- Rollback documentado y probado. Toda acción de contención necesita un camino de vuelta conocido: desbloquear, reactivar, sacar del aislamiento.
- Límites de seguridad. Un tope de acciones por ventana de tiempo (por ejemplo, nunca aislar más de un número definido de equipos sin aprobación humana) para que un error de regla no se convierta en incidente.
- Revisión en cada cambio. Las actualizaciones de herramientas, API y reglas de detección pueden romper un playbook sin aviso. Incluya los playbooks en la gestión de cambios.
Métricas que muestran si la automatización funciona
- MTTR. Tiempo desde la detección hasta la contención. Compare los casos tratados con y sin automatización, por tipo de incidente.
- Porcentaje de casos automatizados. Cuántos casos se resolvieron total o parcialmente mediante playbook. No es una meta en sí: automatizar el caso equivocado solo acelera el error.
- Falsos positivos. La tasa de falsos positivos que llegan al analista y, sobre todo, las acciones automáticas ejecutadas sobre algo legítimo. Esto último debe seguirse caso por caso.
- Reversiones. Cuántas acciones automáticas necesitaron rollback y por qué.
Gobernanza y pista de auditoría
Cada acción automática debe responder a las mismas preguntas que una acción humana: qué se hizo, cuándo, en qué activo, con base en qué evidencia, mediante qué playbook y versión, y quién lo aprobó. En la práctica:
- Registro inmutable. Logs de ejecución guardados fuera del alcance de quienes operan la plataforma.
- Versionado de playbooks. Historial de cambios con autor, revisor y fecha.
- Cuentas de servicio con mínimo privilegio. La plataforma SOAR tiene acceso a firewall, EDR y directorio; ella misma es un objetivo y necesita credenciales protegidas y monitoreadas.
- Revisión periódica. Un comité o dueño formal revisa niveles de autonomía, excepciones y métricas, en línea con la función Govern del CSF 2.0.
Errores comunes
- Automatizar un proceso que no existe. Si el playbook manual no está claro, la automatización solo cristaliza la confusión.
- Empezar por la contención. Saltarse el enriquecimiento y el triaje e ir directo a bloqueos automáticos es la forma más rápida de perder la confianza del negocio.
- Preaprobación informal. "Lo acordamos por correo" no protege a nadie el día de la crisis.
- Playbook sin dueño. Un playbook sin responsable se desactualiza y falla justo cuando se necesita.
En la práctica: automatización con validación humana
En el SOC de Network Secure, la plataforma Open-XDR realiza el triaje, el enriquecimiento con Threat Intelligence y la contención automática, y el analista valida, investiga lo crítico y ajusta las reglas. Conozca más sobre el servicio de SOC y MDR y cómo se conecta con su plan de respuesta a incidentes.
Preguntas frecuentes
¿Qué es SOAR?
SOAR (Security Orchestration, Automation and Response) es la categoría de herramienta que integra las soluciones de seguridad y ejecuta playbooks. Su valor depende de los playbooks y de la gobernanza, no solo de la herramienta.
¿La automatización reemplaza a los analistas del SOC?
No. Absorbe las tareas repetitivas y estandarizadas. Investigar casos ambiguos, tomar decisiones con impacto en el negocio y mejorar las detecciones sigue requiriendo personas.
¿Qué acciones de contención pueden ser totalmente automáticas?
Las que son reversibles, de alcance limitado, preaprobadas por el negocio y probadas, como la cuarentena de un correo malicioso o el aislamiento de una estación de usuario. Las acciones sobre sistemas críticos y cuentas privilegiadas deben requerir aprobación humana.
¿Cómo saber si la automatización funciona?
Siga el MTTR por tipo de caso, los falsos positivos y las acciones automáticas que necesitaron rollback.
Fuentes consultadas: NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (abril de 2025); NIST Cybersecurity Framework 2.0 (CSWP 29), función Govern; CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks; OASIS, CACAO Security Playbooks Version 2.0; MITRE ATT&CK y MITRE D3FEND. La escala de niveles de autonomía es una propuesta práctica de este artículo, no una clasificación de una norma. Este artículo es educativo y no sustituye la evaluación de su entorno y de sus procesos de respuesta.