Playbooks y gestión de tickets

Un playbook (o runbook) es un procedimiento documentado, paso a paso, para gestionar un tipo específico de alerta o incidente. Los playbooks hacen que la respuesta sea coherente, rápida y auditable.

Sin playbooks, dos analistas podrían gestionar la misma alerta de phishing de formas completamente distintas. Con ellos, la calidad de la respuesta no depende de quién esté de turno.

Un buen playbook tiene una estructura predecible para que los analistas puedan seguirlo bajo presión:

• Disparador — qué alerta o condición activa este playbook
• Alcance — qué cubre y qué no cubre
• Pasos — acciones de investigación y respuesta ordenadas
• Puntos de decisión — lógica de ramificación para distintos hallazgos
• Criterios de escalado — cuándo transferir el caso
• Condiciones de cierre — cuándo termina el caso

Considere un correo electrónico de phishing denunciado. Un playbook habitual establece pasos claros:

Los incidentes reales no son lineales. Los playbooks incluyen puntos de decisión que generan distintas ramas según lo que encuentre.

Por ejemplo, en el playbook de phishing:

• ¿Alguien hizo clic en el enlace? Si no, contenga la situación y cierre el caso. Si sí, pase a la gestión del compromiso de credenciales.
• ¿Se introdujeron credenciales? Si la respuesta es afirmativa, fuerce el restablecimiento de la contraseña y compruebe si hay inicios de sesión sospechosos.

Las ramificaciones mantienen el playbook proporcionado: poco esfuerzo para los avisos inofensivos y una respuesta completa ante un compromiso real.

Un sistema de tickets (gestión de casos) es el sistema de registro oficial de cada alerta e incidente. Cada caso es un ticket que registra toda la investigación.

Entre las plataformas habituales se incluyen el gestor de casos de SOAR, ServiceNow, Jira o una herramienta de IR dedicada. El ticket es el lugar donde se almacenan las evidencias, la cronología y las decisiones, de modo que nada dependa de la memoria o de los mensajes de chat.

Un ticket útil registra todo lo necesario para comprender y auditar un caso:

• Título — conciso y específico
• Severidad y estado
• Activos y usuarios afectados
• Cronología de los pasos de la investigación con marcas de tiempo
• Evidencias e IOC
• Clasificación final y acciones realizadas

Redacte el ticket como si una persona desconocida fuera a leerlo durante una auditoría dentro de un año, porque es posible que lo haga.

Los campos coherentes de estado y severidad facilitan la gestión de las colas y dan sentido a las métricas.

Cuando un incidente puede dar lugar a acciones legales o a la intervención de Recursos Humanos, la gestión de las evidencias es importante. La cadena de custodia documenta quién recopiló cada evidencia, cuándo lo hizo y cómo se almacenó.

Los tickets contribuyen a ello registrando:

• La hora exacta y el origen de cada artefacto
• El analista que lo recopiló
• Los hashes que demuestran que la evidencia no fue alterada

Una gestión descuidada de las evidencias puede hacer que los hallazgos sean inadmisibles o impugnables.

Los tickets permiten aplicar Acuerdos de nivel de servicio (SLAs) que definen con qué rapidez deben reconocerse y resolverse las alertas según su severidad.

Ejemplos de objetivos de SLA:

• SEV1: reconocer en un plazo de 15 minutos
• SEV2: reconocer en un plazo de 1 hora
• SEV3: responder en un plazo de 4 horas

Las marcas de tiempo del ticket alimentan las métricas que muestran si el SOC cumple estos compromisos.

Los playbooks se deterioran si no se mantienen. Las herramientas cambian, los atacantes evolucionan y los pasos quedan obsoletos. Trate los playbooks como documentos vivos.

Actualícelos cuando:

• Se añada una herramienta o fuente de datos nueva
• Una revisión posterior a un incidente revele una deficiencia
• Aparezca una nueva técnica de ataque
• Un analista encuentre un paso confuso o incorrecto

Utilice control de versiones para los playbooks y revíselos periódicamente.

Muchos pasos de los playbooks son mecánicos y resultan ideales para la automatización con SOAR. Automatizarlos permite que los analistas se concentren en tareas que requieren criterio.

Pasos que suelen automatizarse:

• Descargar el correo electrónico original y extraer los IOC
• Realizar consultas de reputación
• Eliminar el correo malicioso de todas las bandejas de entrada
• Actualizar el ticket con los hallazgos

El analista sigue tomando las decisiones clave; la automatización solo ejecuta las partes rutinarias con mayor rapidez y de forma coherente.

Ha aprendido cómo los playbooks y los tickets estructuran el trabajo del SOC:

• Los playbooks proporcionan pasos coherentes y repetibles, con puntos de decisión y criterios de escalación
• El sistema de tickets es el sistema de registro oficial de cada caso
• Los buenos tickets registran la cronología, las evidencias, los IOC y la clasificación final, y respaldan la cadena de custodia
• Los SLAs establecen objetivos de tiempo de respuesta que se controlan mediante las marcas de tiempo de los tickets
• Mantenga los playbooks actualizados y automatice sus pasos mecánicos con SOAR

A continuación, medirá el rendimiento del SOC mediante el MTTD y el MTTR.