Convertir los hallazgos del SOC en un proceso de remediación que el equipo de Workplace pudiera ejecutar
- El problema
- Los hallazgos del SOC llegaban al equipo de endpoints como hilos de chat; cada alerta era una conversación.
- Qué construí
- Un procedimiento común: un formato de informe, una lista de categorías, un playbook por categoría y un registro por actuación.
- Qué salió de ahí
- Respuestas idénticas, tiempos de cierre medibles y categorías listas para remediación automática.
Un centro de operaciones de seguridad es bueno viendo. Entre Defender for Endpoint, CrowdStrike Falcon y Darktrace sale un goteo constante de hallazgos: un equipo hablando con algo con lo que no debería, un inicio de sesión que no encaja, un fichero que parece el tipo de fichero equivocado. Lo que un SOC normalmente no puede hacer es actuar sobre un portátil que está en un aula. Eso le toca al equipo de Workplace.
Cuando yo llevaba ese equipo, el traspaso entre los dos era un hilo de chat. Cada alerta llegaba con una forma distinta y con una idea distinta de la urgencia, y quien la cogía decidía sobre la marcha qué hacer. Funcionaba, porque la gente era buena. Pero no escalaba, y sobre todo no se podía medir.
El proceso
Acordamos con el SOC un procedimiento normalizado, y va menos de tecnología que de sacar las decisiones del momento de la alerta:
El SOC informa en un único formato, con una categoría de una lista corta y consensuada (credencial comprometida, malware en el endpoint, sospecha de exfiltración de datos, incumplimiento de política…) y los activos implicados.
Cada categoría tiene su playbook en el lado de Workplace: qué se hace primero, qué evidencias se recogen, qué se hace después. Aislar el dispositivo en Defender, revocar sesiones en Entra, restablecer la contraseña, borrar, reinscribir.
Cada actuación se registra igual: qué se hizo, cuándo, quién lo hizo; y la alerta se cierra de vuelta al SOC con ese registro adjunto.
No hay nada exótico ahí; el valor está en que la cuarta vez que entra la misma categoría, la respuesta es idéntica a las tres anteriores, y el tiempo hasta cerrarla es un número que se puede mirar.
A dónde lleva esto
La razón de verdad para normalizar es el paso siguiente. Cuando una categoría tiene un playbook fijo y todas sus actuaciones son cosas que una API sabe hacer (aislar un dispositivo, revocar sesiones, restablecer una credencial), esa categoría es candidata a remediación automática: la herramienta del SOC levanta el hallazgo, el playbook se ejecuta y una persona revisa el registro después, en lugar de hacer el trabajo. El proceso se diseñó para que ese salto fuera un cambio de ejecutor, no un rediseño.