Ciberseguridad y seguridad de la información

Playbook para SOC: Cómo construir un proceso de respuesta consistente a una alerta

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la construcción de un Playbook para SOC en el ámbito de SOC y operaciones

Respuesta rápida

Un Playbook para SOC es un proceso documentado que define cómo manejar un tipo específico de alerta: cuál es la entrada, qué verificaciones se realizan, qué evidencias se recopilan, cuáles son los puntos de decisión, cuándo se escala y qué acciones están permitidas. Un buen Playbook crea consistencia sin anular el pensamiento analítico, y se prueba y actualiza según resultados reales y cambios en el entorno.

En cada SOC existe conocimiento que no está escrito en ningún lugar: un analista experimentado sabe qué consulta ejecutar, a quién llamar y cuándo una alerta específica es peligrosa. El problema surge en el turno de noche, al incorporar un nuevo empleado o durante un incidente a gran escala, cuando el conocimiento reside en la cabeza de una persona que no está disponible.

Un Playbook convierte el conocimiento en un flujo de trabajo. No es un guion rígido que sustituye el juicio, sino un marco que asegura que las verificaciones críticas no se olviden, que las autorizaciones estén claras y que cada decisión quede documentada. Microsoft Sentinel permite crear Incident Tasks manuales o automáticas, y utilizar Automation Rules y Logic Apps Playbooks para añadir tareas y realizar acciones.

En este artículo construiremos un Playbook para la alerta de Impossible Travel. Es importante recordar que el nombre puede referirse a diferentes tipos de detección en los productos de Microsoft: Atypical Travel e Impossible Travel son Risk Detections separados, y algunos se calculan Offline y requieren la licencia adecuada. Por lo tanto, un Playbook debe comenzar entendiendo la fuente de la alerta y no asumiendo que todos los productos se comportan de la misma manera.

Checklist, Runbook, Playbook y Automatización — ¿Cuál es la diferencia?

Un Checklist es una lista de verificación corta. Un Runbook describe instrucciones operativas detalladas para realizar una acción, por ejemplo, aislar una estación o restablecer una contraseña. Un Playbook describe un escenario de respuesta de principio a fin, incluyendo decisiones, roles, evidencias y rutas de escalada. La automatización o SOAR ejecutan parte de los pasos en el sistema.

Se pueden combinar: un Playbook de cuenta sospechosa remite a un Runbook para cancelar sesiones, incluye un Checklist para Triage y activa la automatización para enriquecer la IP. La separación es importante porque no todos los pasos son adecuados para la automatización, y no todas las instrucciones operativas deben aparecer en el cuerpo del proceso de investigación.

Un buen Playbook se escribe para una situación definida. "Investigación de ciberseguridad" es demasiado amplio; "Impossible Travel en una cuenta de empleado" es lo suficientemente específico para definir entradas y decisiones.

Cuándo se necesita un Playbook

Se prioriza la construcción de un Playbook cuando la alerta es común, su manejo varía entre analistas, existe una acción de riesgo, se requiere coordinación con otro equipo o el SLA es corto. Incluso un incidente raro pero de alto impacto, como la sospecha de una afectación de Domain Admin, justifica un Playbook.

Comience con datos reales: examine de diez a veinte Incidents de este tipo, qué verificaron los analistas, dónde se produjeron retrasos, qué preguntas se repitieron y qué causó cierres incorrectos. El proceso debe resolver un problema operativo, no solo parecer ordenado.

Defina un Owner: una persona o equipo responsable de la versión, la prueba y la mejora. Un Playbook sin propietario se vuelve obsoleto rápidamente.

Componentes de un buen Playbook

Título y objetivo: cuál es el escenario y cuál es el riesgo. Alcance: a qué fuentes, usuarios y entornos se aplica. Trigger: nombre de la regla, campos obligatorios y condiciones de entrada. Roles: quién realiza el Triage, quién aprueba la contención y quién se mantiene informado. Prerrequisitos: permisos, herramientas, logs y datos de contacto.

Pasos de trabajo: enriquecimiento inicial, verificaciones de identidad/activo/red, puntos de decisión, acciones de respuesta, conservación de evidencias, comunicación y cierre. Para cada paso, defina entrada, acción, resultado y criterio de éxito. En lugar de "verificar IP", escriba "verifique si la IP pertenece a la VPN corporativa, proveedor de la nube, TOR o una fuente con reputación negativa; guarde la fuente y la fecha de verificación".

Añada también Non-goals y límites. Por ejemplo: Tier 1 no suspende una cuenta de administrador sin la aprobación del Incident Commander; Automation no cierra una alerta si el usuario es Privileged; Playbook no reemplaza un proceso legal para la conservación de evidencias.

Puntos de decisión y rutas de escalada

Un punto de decisión debe ser binario o tener opciones definidas. "¿Es sospechoso?" es ambiguo. Mejor: "¿Confirma el usuario ambas conexiones en un canal autenticado, y ambas proceden de un dispositivo gestionado con MFA válido?" Cada respuesta conduce a una ruta diferente.

Para cada ruta, establezca condiciones de escalada: cuenta Privileged, Token sospechoso, MFA inesperado, actividad después del inicio de sesión, inicio de sesión desde un dispositivo no gestionado o negativa del usuario. Indique a quién escalar, en qué canal, qué datos adjuntar y cuál es el tiempo máximo.

No construya un Playbook que dependa únicamente de la respuesta del usuario. Un atacante puede responder a través de una cuenta comprometida. La verificación humana debe hacerse en un canal alternativo y en cruce con la telemetría.

Evidencias, documentación y versiones

Determine qué evidencias deben conservarse: identificadores de Risk Detection y Sign-in, IP, ubicación, dispositivo, Client App, Conditional Access, MFA, User Agent, sesiones, acciones en la nube y alertas relacionadas. Especifique un formato de tiempo uniforme y cómo guardar capturas de pantalla o exports.

Cada Playbook debe tener una Versión, fecha, Owner, Change Log y fecha de próxima Revisión. Después de cambiar una regla, una fuente de datos o un producto de identidad, se debe verificar si los campos y los pasos siguen siendo válidos.

Siga las métricas: tiempo de Triage, tasa de finalización de tareas, tasa de cierres incorrectos, número de escaladas, tareas omitidas y tiempo hasta la contención. La métrica no es solo la velocidad; un proceso rápido que pierde incidentes no tiene éxito.

Ejemplo: Playbook para alerta de Impossible Travel

Objetivo: evaluar si dos actividades geográficas imposibles fueron causadas por robo de identidad, VPN/Proxy, servicio en la nube o datos de ubicación inexactos. Trigger: Risk Detection tipo Impossible Travel o alerta equivalente, con usuario, dos eventos, tiempos y direcciones de origen.

Paso A — Enriquecimiento automático: extracción de Sign-in Logs, Reputation, asociación ASN, estado del dispositivo, MFA, Conditional Access, Risk State y otras alertas. Paso B — Triage: ¿La cuenta es Privileged? ¿Una de las direcciones es anónima o maliciosa? ¿La actividad sigue activa? Si es así, escalada inmediata.

Paso C — Verificación de explicación legítima: VPN corporativa, Secure Web Gateway, teléfono que cambia de red, servicio SaaS que actúa en nombre del usuario, o base de datos Geo-IP incorrecta. Paso D — Verificación del usuario en un canal alternativo: ¿realizó la actividad, en qué dispositivos y confirmó un MFA inusual?

Paso E — Decisión: Si ambas actividades son reconocidas y respaldadas por telemetría, cierre como Benign Positive. Si el dato de ubicación es incorrecto, False Positive debido a los datos. Si el usuario lo niega o existen anomalías de Token/Session, cancelación de sesiones, solicitud de reautenticación, verificación de acciones posteriores y escalada a IR según autorización.

Paso F — Cierre y feedback: documentación de las evidencias, la clasificación, las acciones y si se requiere Tuning. No se debe excluir a un usuario completo solo porque viaja con frecuencia; se deben examinar las características de la fuente, el dispositivo y la autenticación.

Checklist práctico

He definido el escenario y el Alcance.
He especificado el Trigger y los campos obligatorios.
He definido Roles y autorizaciones.
Cada paso incluye entrada, acción y resultado.
Los puntos de decisión son claros.
Existen rutas de escalada y SLA.
Se han definido las evidencias obligatorias.
Existen Versión, Owner y fecha de Revisión.
Se ha verificado qué es adecuado para la automatización y qué requiere una persona.

Errores comunes

Escribir un documento largo sin decisiones prácticas.
No definir quién está autorizado para realizar la Contención.
Construir un Playbook según la interfaz de un solo producto sin documentar la dependencia de la versión.
No incluir una ruta cuando faltan datos.
No probar el proceso en un ejercicio de Tabletop o con Incidentes históricos.

Resumen y CTA

Construya una primera versión de un solo Playbook, ejecútelo en tres Incidents históricos y anote dónde el analista aún necesita adivinar. En el próximo artículo sobre Timeline, aprenderá cómo definir dentro del Playbook un resultado de investigación cronológico y uniforme.

Preguntas frecuentes

¿Un Playbook tiene que ser automático?

No. Un Playbook puede ser un proceso humano, semiautomático o automático. La automatización es una posible implementación de algunos de los pasos.

¿Cuál es la diferencia entre un Playbook y un Runbook?

Un Playbook gestiona un escenario y decisiones; un Runbook detalla la ejecución de una acción operativa específica. Las organizaciones usan los términos de manera diferente, por lo que es importante definirlos internamente.

¿Cuánto debe durar un Playbook?

Lo suficientemente largo como para asegurar la consistencia, pero corto y accesible durante un incidente. Las instrucciones técnicas detalladas pueden trasladarse a Runbooks vinculados.

¿Con qué frecuencia se debe actualizar?

Al menos en una fecha de Revisión regular y después de un cambio significativo en una regla, producto, infraestructura, permisos o un Incidente que haya encontrado una brecha en el proceso.

¿Qué se debe automatizar primero?

El enriquecimiento, la creación de tareas, el etiquetado, la asignación y las notificaciones son buenos candidatos. Las acciones destructivas o de alto impacto requieren controles y aprobación según el riesgo.