Casos de seguridad y playbooks (SOAR)

Eventos de seguridad convierte en casos lo que encuentran tus reglas de detección, tu inteligencia de amenazas y tus productos de seguridad conectados: un caso por cada asunto que merece una investigación, con todas las detecciones sobre el mismo usuario, host o dirección agrupadas en él. Los analistas gestionan los casos en una cola, y los playbooks responden a ellos, por sí solos o con un clic.

Cómo funciona#

Abre Productos → Eventos de seguridad → Casos de seguridad → Casos abiertos para la cola. Asignados a mí, Sin asignar, Casos cerrados y Todos los casos son páginas propias a su lado, y cada una lista los casos que dice su nombre.

Antes de empezar#

Los permisos sobre casos y playbooks dependen de los tres roles de seguridad. Project Owner y Project Admin pueden hacerlo todo.

Cada uno de estos permisos también se puede conceder por separado, desde crear un caso hasta aprobar los pasos de un playbook; consulta Referencia de permisos.

De dónde vienen los casos#

Todos los orígenes están activados por defecto. Una conexión abre casos para Alta y superior salvo que elijas otro nivel; las alertas por debajo de ese nivel se siguen importando como eventos.

Cómo se agrupan las detecciones#

Una detección trata sobre una entidad: el valor por el que agrupa su regla, como la dirección IP de una regla de fuerza bruta, o el indicador que nombra una coincidencia de inteligencia de amenazas. Una detección sin entidad queda aislada.

• Cuando ya hay un caso abierto sobre esa entidad, la detección se suma a él. Las entidades y el mapeo de ATT&CK del caso crecen, y su prioridad sube hasta la de la detección, nunca baja.
• Cuando no lo hay, se abre un caso nuevo, con el nombre de la detección y con la prioridad de esta.
• Una detección que se vuelve a disparar incrementa el recuento de su fila en lugar de añadir otra.

La prioridad de un caso se deriva de la gravedad de la detección:

Gestionar un caso#

Un caso pasa por cuatro estados. Puede saltarse alguno, como un falso positivo que se cierra directamente desde Nuevo, y se puede reabrir.

La página del caso tiene todo lo necesario para gestionarlo:

• Arriba: Assign to Me, Run Playbook, Declarar incidente y Close Case, los pasos de estado y la prioridad, en el menú junto a ellos.
• Status200 AI: lo que Status200 AI ha sacado del caso, la prioridad y el playbook que sugiere, y la evidencia que hay detrás. Consulta Status200 AI en la seguridad.
• Detecciones: lo que se disparó para abrir el caso o sumarse a él, cuántas veces y el último evento coincidente.
• Entidades: los usuarios, hosts y direcciones de los que trata el caso, con su actividad en todos tus eventos de seguridad de los últimos 7 días. Cada una se abre en Correlacionar.
• MITRE ATT&CK: las tácticas y técnicas a las que corresponden sus detecciones, cada una enlazada a su página en attack.mitre.org.
• Ejecuciones de playbooks: lo que hizo cada playbook en el caso, paso a paso, y los pasos que esperan aprobación.
• Notas y Cronología: lo que escribió el equipo y todo lo que pasó, con quién lo hizo.

Para gestionar varios casos a la vez, selecciónalos en la cola y usa Assign to Me, Change Status o Change Priority.

Cerrar un caso#

Close Case pide un veredicto y una nota de cierre opcional:

Los veredictos se cuentan en la vista general. Una regla cuyos casos se cierran una y otra vez como falso positivo es una regla que hay que ajustar.

Un caso abierto a partir de alertas de Google SecOps también las cierra en Google SecOps, con el veredicto y la nota de cierre, cuando su conexión tiene activado Cerrar las alertas cuando se cierra su caso: consulta Google SecOps.

Declarar un incidente#

Declarar incidente abre un incidente de Status200 para el caso, con la gravedad que elijas, y enlaza los dos en ambos sentidos: la descripción del incidente nombra el caso, y la cabecera del caso enlaza al incidente. A partir de ahí toman el relevo la guardia, las páginas de estado y el postmortem. Requiere un rol que pueda tanto gestionar casos como crear incidentes.

Notificaciones#

Status200 avisa a las personas de tres cosas de un caso. Nadie tiene que configurar nada: un proyecto que solo hizo clic en Activar lo recomendado se entera de sus casos de prioridad Alta y Crítica por correo y por push.

• Solo se avisa a las personas que pueden ver el caso: Project Owner, Project Admin y los roles Security Admin, Security Member y Security Viewer. A un rol limitado a algunas etiquetas solo se le avisa de los casos con esas etiquetas.
• A nadie se le avisa de lo que hizo: quien abre un caso a mano, lo asigna o inicia una ejecución no recibe una notificación de ello.
• Cada persona se entera de un caso una sola vez. Un caso que se abre con prioridad Medium y después sube a Crítico llega, al subir, a las personas que eligieron Alta y Crítica o Solo Crítica, y no otra vez a las que eligieron Media y superior, que ya se enteraron cuando se abrió.
• El ataque de prueba de Enviar un ataque de prueba abre un caso que no avisa a nadie.
• Un caso Crítico y un paso que espera aprobación se envían al instante, nunca se retienen en un resumen de correos.
• La Cronología del caso indica a quién se avisó y cuándo.

Elegir de qué se te avisa#

Cada persona elige por sí misma, en Ajustes de usuario → Ajustes de notificaciones → Seguridad: los canales de cada notificación (correo, SMS, llamada, push, Telegram, Slack, Microsoft Teams o webhook) y, en Nuevo caso de seguridad, la prioridad a partir de la cual se le avisa:

No se envían mensajes de WhatsApp para los casos de seguridad. Una notificación push abre la app de Status200, y su enlace abre el caso en el navegador.

Publicar en canales de Slack y Microsoft Teams#

Para publicar en un canal, añade una regla en Productos → Eventos de seguridad → Espacio de trabajo → Slack (o Microsoft Teams). Si no hay ninguno de los dos conectado, la única entrada de la sección es Conectar Slack o Teams. Una regla nombra los canales en los que publicar (y, en Microsoft Teams, los chats) y, si quieres, los casos a los que se aplica:

Cada una de las tres notificaciones se publica en los canales de todas las reglas con las que coincide el caso en ese momento. Una regla en la que Prioridad del caso de seguridad contiene cualquiera de Crítico y Alta publica los casos de prioridad Alta y Crítico en cuanto se abren, y un caso Medium cuando sube a Alta. Un caso de seguridad nunca tiene un canal propio.

Playbooks#

Un playbook es una lista de pasos que se ejecutan sobre un caso. Crea uno en Productos → Eventos de seguridad → Playbooks, a partir de una plantilla o desde cero, y añade sus pasos en su página.

Cuándo se ejecuta un playbook#

Cualquier playbook habilitado también se puede ejecutar a mano, con Run Playbook en un caso. Un playbook que se ejecuta por sí solo se puede acotar:

• For Cases At Least: solo los casos de esta prioridad o superior.
• Only For Detections From: solo cuando la detección que originó el caso procede de este origen.
• Only For These Detection Rules: solo cuando procede de una de estas reglas.

Un playbook deshabilitado no se ejecuta ni por sí solo ni a mano.

Pasos#

Un playbook tiene como máximo 25 pasos. Se ejecutan en orden, cada uno cuando ha terminado el anterior. Además, cada paso puede:

• Needs Approval: detener la ejecución antes del paso hasta que alguien lo apruebe en el caso. Los cuatro pasos que dejan a alguien sin acceso siempre se detienen, salvo que un Security Admin lo desactive.
• Only If Threat Intel Matched: omitir el paso salvo que un paso Check entities against threat intel anterior de la misma ejecución haya encontrado un indicador conocido.
• Carry On If It Fails: ejecutar el paso siguiente aunque este falle. Si está desactivado, un paso fallido detiene la ejecución.

Contención#

Los pasos de contención actúan a través de una conexión de eventos de seguridad con el producto, y esa conexión necesita algo más que acceso de lectura:

Un paso de contención solo actúa sobre los usuarios o hosts de los que trata el caso, nunca sobre todos los que el caso nombra:

• El valor por el que se agrupa una detección del caso, como la cuenta por la que agrupa una regla de viaje imposible, o el host que nombra la alerta de un producto conectado.
• Un usuario o host del caso que tu inteligencia de amenazas conoce como indicador.

Un caso agrupado por una dirección, como un ataque de fuerza bruta contra tu VPN, no trata de ninguno de los dos: sus pasos de contención se omiten, y la cuenta contra la que lo intentó y la puerta de enlace que alcanzó quedan intactas. Un paso actúa como máximo sobre 10 usuarios o hosts. Busca cada uno en el producto por su nombre e indica en la ejecución qué hizo con cada uno: hecho, ya hecho, no encontrado, rechazado o protegido.

Entidades protegidas#

Protected Entities, en Playbooks en el menú, lista los usuarios y hosts a los que ningún playbook aplica contención, como las cuentas de acceso de emergencia, los controladores de dominio y las puertas de enlace VPN. Un valor coincide sin distinguir mayúsculas de minúsculas, y * representa cualquier secuencia de caracteres: svc-* protege todas las cuentas de servicio. Un paso informa de un usuario o host protegido como protegido y no lo toca. La lista la mantienen los Security Admins.

Aprobación#

Los cuatro pasos que dejan a alguien sin acceso esperan aprobación. Solo un Security Admin puede desactivar Needs Approval en uno de ellos, y Status200 registra quién lo hizo. La aprobación lista en Act On los usuarios o hosts sobre los que actuaría el paso, todos marcados: desmarca los que deba dejar intactos. Los protegidos no se ofrecen. Quien inició una ejecución no puede aprobar sus pasos: lo hace otra persona, aunque sí puede rechazarlos.

Deshacer#

Los pasos para deshacer actúan sobre los usuarios o hosts de los que trata el caso, igual que los pasos que deshacen. Cuando la ejecución se ha detenido, un usuario o host contenido tiene además un botón propio en su paso: Unsuspend, Lift Containment o Liberar. El cierre de una sesión de Okta no se puede deshacer. Cada reversión se guarda en la cronología del caso y en el registro de auditoría del proyecto.

Mensajes#

Una nota, un email, una publicación de Slack y una de Teams pueden usar los valores del caso:

Un email o una publicación sin mensaje propio envía un resumen del caso.

Ejecuciones y aprobaciones#

Cada ejecución aparece, paso a paso, en su caso y en Productos → Eventos de seguridad → Playbooks → Ejecuciones de playbooks:

Un paso que espera aprobación muestra Approve y Rechazar en la ejecución, con un comentario opcional. Aprobar hace que la ejecución continúe desde ese paso; rechazar la termina. La decisión, quién la tomó y su comentario se guardan en el paso, en la cronología del caso y en el registro de auditoría del proyecto. Esperando aprobación, en Playbooks en el menú, lista las ejecuciones que esperan una decisión y las cuenta; Ejecuciones de playbooks lista todas las ejecuciones.

Una ejecución que deja de recibir noticias de su worker, por ejemplo tras un reinicio, se retoma: una ejecución en cola vuelve a ponerse en cola a los 2 minutos, y una ejecución que lleva 30 minutos sin dar señales se marca como fallida.

La vista general#

El producto se abre en Productos → Eventos de seguridad → Vista general:

• Los casos abiertos asignados a ti, los casos abiertos que nadie ha tomado todavía y los pasos de playbook que esperan aprobación; cada uno abre la página que los lista.
• Tiempo medio de reconocimiento, Tiempo medio de contención y Tiempo medio de cierre, sobre los casos abiertos en los últimos 30 días: desde que se abre un caso hasta que alguien se hace cargo de él (se asigna a una persona o sale de Nuevo), hasta que pasa a Contenido y hasta que pasa a Cerrado. Un caso que sigue esperando no cuenta en la media.
• Los casos abiertos cada día durante 30 días, por prioridad, y las detecciones generadas cada día durante 14 días, por origen.
• Los casos abiertos por prioridad y por estado, los veredictos de los últimos 30 días, las tácticas de ATT&CK detrás de los casos, las detecciones que más se dispararon y las entidades que nombran más hallazgos.

Encima, una franja muestra cómo está configurada la seguridad: sus orígenes, detecciones, casos y playbooks, cada uno con sus cifras. Un proyecto que aún no la ha configurado ve allí Activar lo recomendado y Enviar un ataque de prueba; consulte Primeros pasos con la seguridad. Cuando nada necesita a nadie, la página dice Todo tranquilo, y los gráficos aparecen en cuanto hay algo que representar.

Encontrar amenazas#

• Entidades clasifica los usuarios, hosts, direcciones y hashes que más nombran tus hallazgos, en el último día, semana o mes, y busca cualquier valor en 30 días de eventos.
• Rule Library tiene reglas de detección listas para usar, para amenazas de identidad, endpoints, nube, red, web y Kubernetes. Cada una es una regla Sigma escrita para los campos a los que se normaliza cada origen conectado. Añadir regla la crea como una regla de detección tuya, activada y que abre casos en lugar de alertas; cámbiala en Reglas de detección como cualquier otra. Las reglas marcadas como Recomendadas encuentran amenazas en datos que Status200 ya tiene, y un botón añade las que aún no tiene.
• ATT&CK Coverage dibuja la matriz MITRE ATT&CK resaltando las técnicas que cubren tus reglas habilitadas, y marca con un contorno las que cubriría una regla de la biblioteca.

Automatizar#

• Flujos de trabajo: un caso o una nota puede iniciar un flujo de trabajo cuando se crea, se actualiza o se elimina. Un paso Run a workflow inicia un flujo de trabajo cuyo desencadenante es un webhook.
• API: los casos, las notas, las detecciones, los playbooks, las ejecuciones y las entidades protegidas tienen la misma API REST que el resto de Status200, en /security-case, /security-case-note, /security-detection, /security-playbook, /security-playbook-run y /security-protected-entity. Consulta Referencia de la API.
• Agentes de IA: el servidor MCP tiene herramientas para casos, notas, detecciones y playbooks. Consulta Servidor MCP.

Solución de problemas#

Próximos pasos#