Todos los proyectos

Convertir los hallazgos del SOC en un proceso de remediación que Workplace pudiera ejecutar

Proceso de remediación del SOC a WorkplaceSOCWorkplaceDetectarDefender, CrowdStrike, DarktraceAnalizaralcance, severidad, activos afectadosInformarun formato, una categoríaClasificarcategoría → playbookRemediaraislar, resetear, borrar, revocarEvidencia + cierrequé se hizo, cuándo, quiénLas categorías que se repiten pasan a ser candidatas a remediación automática

Un centro de operaciones de seguridad es bueno viendo. Defender for Endpoint, CrowdStrike Falcon y Darktrace producen entre los tres un flujo constante de hallazgos: una máquina que habla con algo con lo que no debería, un inicio de sesión que no encaja, un fichero que parece del tipo equivocado. Lo que el SOC normalmente no puede hacer es actuar sobre un portátil en un aula de Barcelona. Eso es el equipo de Workplace.

Cuando lideraba ese equipo, el traspaso entre ambos era un hilo de chat. Cada alerta llegaba con una forma distinta, con una idea distinta de urgencia, y quien la cogía decidía en el momento qué hacer. Funcionaba, porque la gente era buena. No escalaba, y no se podía medir.

El proceso

Acordamos con el SOC un procedimiento operativo estándar, y tiene menos que ver con tecnología que con quitar decisiones del momento de la alerta:

  1. El SOC informa en un solo formato, con una categoría de una lista corta acordada (credencial comprometida, malware en endpoint, sospecha de exfiltración, incumplimiento de política…) y los activos implicados.
  2. Cada categoría se corresponde con un playbook en el lado de Workplace: qué hacer primero, qué evidencia recoger, qué hacer después. Aislar el dispositivo en Defender, revocar sesiones en Entra, resetear la contraseña, borrar, reinscribir.
  3. Cada acción se registra de la misma manera: qué se hizo, cuándo, quién, y la alerta se cierra de vuelta al SOC con ese registro adjunto.

Nada exótico. El valor es que la cuarta vez que llega 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.

Adónde lleva

La verdadera razón para estandarizar es el paso siguiente. Cuando una categoría tiene un playbook fijo y todas sus acciones son cosas que una API puede hacer (aislar un dispositivo, revocar sesiones, resetear 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 paso sea un cambio de ejecutor, no un rediseño.

Qué te puedes llevar de esto

Si tu SOC y tu equipo de endpoints hablan por chat, escribe primero las categorías. Los playbooks salen solos, y la automatización sigue a los playbooks.

Todos los proyectos