Metodología práctica, métricas y rol del analista en el ciclo completo de incidentes
Autor: Erick Israel Aguilar Paau
Introducción
Hablar de gestión de incidentes suele remitir de inmediato al modelo clásico definido por NIST SP 800-61, tradicionalmente representado por las fases de preparación, detección, contención, erradicación, recuperación y lecciones aprendidas. Este enfoque, ampliamente difundido en la Revisión 2, sigue siendo válido como referencia conceptual y operativa. No obstante, la Revisión 3 (2025) reestructura estas prácticas dentro del NIST Cybersecurity Framework (CSF) 2.0, enfatizando la respuesta a incidentes como un proceso integrado de gestión de riesgos, más que como una secuencia rígida de pasos.
En la operación diaria de un SOC moderno, la diferencia entre un proceso correctamente documentado y una gestión de incidentes verdaderamente efectiva no radica únicamente en la existencia del marco, sino en cómo el analista ejecuta, prioriza y comunica bajo condiciones de presión, ambigüedad y múltiples eventos simultáneos. La respuesta real rara vez sigue un flujo lineal; requiere decisiones rápidas basadas en contexto, impacto al negocio y evidencia disponible en tiempo real.
Para un profesional certificado en CompTIA CySA+, la gestión de incidentes no consiste simplemente en “seguir fases”, sino en orquestar técnicas, herramientas y personas para que cada acción contribuya de forma medible a la reducción del daño, la optimización de los tiempos de respuesta y la mejora continua de las capacidades defensivas. Este artículo aborda la gestión de incidentes desde la perspectiva del analista que opera frente a un SIEM/XDR, con múltiples tickets abiertos, diversas fuentes de telemetría, canales de comunicación activos y la responsabilidad constante de proteger la operación sin interrumpir el negocio.
De la alerta a la clasificación: el primer filtro crítico
En muchos SOC, el incidente “nace” como una alerta. Puede venir de un SIEM, un XDR, un EDR, un WAF, un CASB o incluso de un usuario que llamó al Service Desk porque “su correo se ve raro”. El primer trabajo del analista es decidir si eso amerita convertirse en incidente formal o si es algo que puede cerrarse rápidamente como falso positivo o evento informativo.
Aquí entran en juego tres elementos clave:
- Contexto: ¿En qué activo está ocurriendo? ¿Es un servidor crítico, una cuenta privilegiada, un endpoint aislado?
- Historial: ¿Es la primera vez que vemos esto o es un patrón recurrente que ya se ha evaluado?
- Riesgo para el negocio: ¿Puede afectar confidencialidad, integridad o disponibilidad de un servicio relevante?
La práctica demuestra que una buena gestión de incidentes comienza con una clasificación consistente. Muchos SOC utilizan matrices de impacto/probabilidad o escalas internas (Severidad 1–4) que permiten decidir si algo se trata como “alto”, “medio” o “bajo”, y qué SLA aplica. CySA+ enfatiza justamente esta capacidad de priorizar, y de no intentar “apagar todos los incendios” por igual.
Construcción del caso: evidencias, línea de tiempo y narrativa técnica
Una vez que se confirma que un evento es un incidente, el analista debe empezar a construir el caso. A nivel práctico, esto implica:
- Consolidar evidencias: logs de autenticación, eventos del EDR/XDR, registros del firewall, alertas previas relacionadas, correos sospechosos, capturas de pantalla, etc.
- Armar la línea de tiempo: ¿Cuándo se observó el primer indicador? ¿Qué pasó después? ¿Se intentó movimiento lateral? ¿Hubo exfiltración?
- Mapear TTPs con MITRE ATT&CK: no por moda, sino porque ayuda a entender el ataque en términos de tácticas (initial access, persistence, lateral movement, exfiltration) y facilita la comunicación con otros equipos.
En muchos casos, el incidente no se resuelve sólo con mirar una alerta. Requiere pivotear entre diferentes fuentes: SIEM, herramientas cloud (CloudTrail, Azure Activity Log, Google SecOps Soar, etc.), registros de aplicaciones y, en algunas ocasiones, capturas de red o análisis forense básico de endpoints.
Coordinación operativa: trabajar más allá del SOC
Una buena gestión de incidentes no se queda dentro del SOC. El analista suele tener que coordinar con:
- Equipos de infraestructura o redes: para aplicar bloqueos, segmentar tráfico o cambiar reglas de firewall.
- Equipos de aplicaciones: para validar si un comportamiento “raro” es legítimo o es un abuso.
- Service Desk / ITSM: para registrar, escalar y documentar acciones siguiendo flujos formales (por ejemplo, en Ivanti, ServiceNow o Jira).
- Equipo legal o de cumplimiento: cuando existe impacto regulatorio, de datos personales o contractual.
Aquí es donde se nota la diferencia entre un proceso inmaduro y uno bien establecido: los flujos de comunicación están claros, las plantillas de notificación ya existen, los grupos de respuesta están definidos, y el analista no tiene que improvisar a quién llamar en medio del incidente.
Métricas que realmente importan: más allá del MTTD y MTTR
En casi cualquier presentación sobre gestión de incidentes aparecen las métricas MTTD (Mean Time to Detect) y MTTR (Mean Time to Respond). Son importantes, sí, pero no son las únicas que cuentan. Desde la perspectiva de un analista CySA+, conviene mirar al menos cuatro tipos de indicadores:
- Volumen y tipo de incidentes: ¿qué proporción corresponde a phishing, malware, credenciales comprometidas, configuraciones erróneas, abuso de privilegios, etc.?
- Porcentaje de incidentes detectados internamente vs reportados por terceros (clientes, proveedores, reguladores).
- Porcentaje de incidentes con causa raíz formalmente documentada.
- Tiempo desde la primera señal (a veces semanas atrás) hasta que alguien la identifica como relevante.
Estas métricas permiten responder preguntas incómodas pero necesarias: ¿estamos detectando lo que debemos? ¿Dónde se nos están escapando las cosas? ¿Qué tipo de incidentes se repiten una y otra vez?
Automatización al servicio del analista
En CySA+ destaca el uso de SOAR y automatización defensiva como componentes clave para elevar la madurez del SOC. En la práctica, la gestión de incidentes mejora sustancialmente cuando:
- El alta de un incidente se genera automáticamente a partir de eventos de alta criticidad del SIEM/XDR.
- Se ejecutan playbooks estándar: por ejemplo, ante un posible compromiso de cuenta, revocar sesiones, forzar cambio de contraseña, revisar actividad en nube y enviar una notificación al usuario.
- La recolección de evidencias se automatiza: extracción de logs, consultas a herramientas de Threat Intelligence, obtención de información del endpoint, etc.
La meta no es reemplazar al analista, sino quitarle trabajo repetitivo, de manera que pueda concentrarse en el análisis y en la toma de decisiones, y no en ejecutar siempre los mismos pasos manuales.
Lecciones aprendidas y madurez real
Una gestión de incidentes madura no termina cuando se “cierra el ticket”. Termina cuando:
- Se documentó qué pasó, cómo se detectó, qué se hizo y qué falló.
- Se actualizan reglas del SIEM/XDR y playbooks de SOAR para que la próxima vez el tiempo de reacción sea menor.
- Se corrigen configuraciones, se ajustan accesos y se aplican controles adicionales que reduzcan la probabilidad de repetición.
- Se comparte el aprendizaje con los equipos relevantes (no sólo con el SOC), especialmente cuando el incidente tuvo causas organizativas: falta de capacitación, procesos débiles, errores de diseño, etc.
En muchos entornos, esta fase es la que más se sacrifica por falta de tiempo. Sin embargo, es la que convierte la experiencia dolorosa de un incidente en un punto de mejora estructural.
Conclusión
La gestión de incidentes, vista desde el analista CySA+, es una mezcla de técnica, disciplina y sentido práctico. No se trata sólo de seguir un manual, sino de entender el contexto del negocio, conocer las herramientas disponibles, priorizar bajo presión y dejar trazabilidad de cada decisión.
Un programa de gestión de incidentes bien llevado convierte al SOC en algo más que un “centro de alarmas”: lo transforma en un equipo capaz de aprender de cada ataque, reducir el impacto de futuros incidentes y hablar el mismo idioma que la organización cuando se trata de riesgo, continuidad y resiliencia. Ese es, en esencia, el rol estratégico que CySA+ espera de un analista que se toma en serio la gestión de incidentes.
