Introducción
Cuando ocurre un incidente de ciberseguridad (malware, intrusión, fuga de datos, etc.), solemos pensar: “ya está, lo hemos contenido y recuperado”.
Pero la realidad es que la parte más valiosa para mejorar la seguridad llega después: analizar lo ocurrido, documentarlo, aprender y reforzar defensas para que no se repita.
Analogía del día a día:
Es como un accidente de coche: arreglar el coche (recuperación) está bien, pero luego quieres saber qué falló (frenos, distracción, carretera) y qué cambiarás (revisión, hábitos, ruta) para evitar otro accidente.
En este capítulo vamos a cubrir dos grandes bloques:
Analogía:
El forense es como el trabajo de un equipo de investigación después de un robo: revisan cámaras, huellas y testimonios para reconstruir lo ocurrido.
Mini-checklist práctico (para estudiar)Preserva evidencia (sin “pisarla”).
Recoge datos de forma repetible.
Mantén notas claras (quién, cuándo, dónde).
Asegura integridad (hash / control de cambios).
El RCA busca la razón real por la que el incidente fue posible. No se queda en el síntoma (“hubo malware”), sino en la causa (“entró por un equipo sin parchear y sin MFA”).
Ejemplos típicos de causa raízVulnerabilidad sin parche (software desactualizado).
Credenciales robadas (phishing).
Mala configuración (puerto expuesto, permisos excesivos).
Falta de monitorización (no se detectó a tiempo).
Proceso débil (no había revisión, no había validación).
Analogía:
Si se te inunda la cocina, la causa raíz no es “hay agua en el suelo”, sino “la tubería pierde” o “la lavadora estaba mal conectada”.
Técnica simple para principiantes: “Los 5 porqués”¿Por qué pasó?
¿Por qué eso fue posible?
¿Por qué no lo evitamos antes?
¿Por qué no lo detectamos rápido?
¿Qué cambio lo impediría?
Después de un incidente, toca cambiar cosas: reglas, configuraciones, parches, políticas, etc.
El control de cambios asegura que esos cambios se hagan sin romper el negocio y quedando documentados.
¿Por qué es importante?
Porque en modo “urgencia” es fácil:tocar cosas sin documentar,
crear nuevas caídas,
o abrir nuevos agujeros de seguridad.
Analogía:
Cambiar reglas en producción sin control es como cambiar cableado eléctrico de una casa “a ojo”: puede funcionar… o puedes provocar otro problema.
¿Qué suele incluir? (versión sencilla)Solicitud de cambio (qué, por qué, impacto).
Aprobación (según riesgo).
Ventana de cambio (cuándo se hace).
Plan de rollback (cómo volver atrás si falla).
Verificación (comprobar que quedó bien).
Registro (documentar).
Actualizar el IRP (Incident Response Plan) con lo que aprendiste en el incidente real: qué faltó, qué sobró, qué mejoró.
¿Qué se suele actualizar?Roles y contactos (quién hace qué, y cómo localizarlo).
Playbooks (pasos concretos para incidentes comunes).
Plantillas de comunicación (mensajes internos/externos).
Herramientas (qué se usa y cómo).
Criterios de severidad (qué es crítico y qué no).
Analogía:
Tu IRP es como un manual de emergencias de un edificio. Cuando hay un incendio real, descubres si las salidas estaban bien señalizadas… y ajustas el plan.
Un Indicator of Compromise es una señal que sugiere que un sistema pudo ser comprometido.
Ejemplos comunesHash de un archivo malicioso.
Dominio/IP de comando y control (C2).
Nombre/ruta típica de un malware.
Patrón en logs (por ejemplo, muchas autenticaciones fallidas).
User-Agent raro o conexiones a horas extrañas.
Analogía:
Es como identificar que un coche fue robado porque:aparece una matrícula concreta en cámaras,
o un modelo específico se ve en una zona sospechosa.
¿Para qué sirven los IOCs?Buscar el mismo “rastro” en otros equipos.
Crear reglas en SIEM/EDR.
Compartir inteligencia con otros equipos/organizaciones (cuando aplique).
Consejo de estudio:
Un IOC no es “la prueba final”, es una pista que guía la investigación.
Es reforzar la vigilancia para detectar:reinfecciones,
persistencia,
o ataques similares.
¿Qué se monitoriza más?Logs críticos (autenticación, endpoints, firewall, DNS).
Alertas del SIEM/EDR.
Tráfico de red hacia IOCs conocidos.
Cambios en cuentas y privilegios.
Creación de tareas programadas o servicios raros.
Analogía:
Si te entran a robar, los días siguientes estás más atento: cambias cerraduras, pones alarma y revisas si alguien ronda.
Buenas prácticas sencillas:
Tip de estudio:
Un error típico es comunicar “demasiado técnico” a quien no lo necesita, o “demasiado tarde” a quien sí.
Es el documento que deja constancia del incidente: qué pasó, cómo se detectó, qué se hizo y cuál fue el resultado.
Estructura recomendada (muy Blogger-friendly)Resumen ejecutivo (1 página: qué, impacto, estado).
Línea de tiempo (timeline).
Alcance (sistemas, usuarios, datos).
Causa raíz (RCA).
Acciones realizadas (contención, erradicación, recuperación).
Evidencias (fuentes, logs, artefactos).
Medidas preventivas (qué cambia para que no vuelva a pasar).
Anexos (IOCs, capturas, referencias).
Analogía:
Como el informe final de un perito tras un siniestro: resume, prueba, concluye y recomienda.
Una reunión (o sesión) para responder a:¿Qué funcionó bien?
¿Qué falló?
¿Qué debemos mejorar?
Cómo hacerlo sin “culpas” (muy importante)
En vez de “¿quién la lió?”, mejor:“¿qué control faltaba?”
“¿qué proceso falló?”
“¿qué automatización necesitamos?”
Analogía:
Después de un partido, un entrenador revisa jugadas: no solo para señalar fallos, sino para entrenar mejor.
Porque lo que no se mide, no se mejora.
Los KPIs ayudan a saber si tu respuesta fue rápida y eficaz, y dónde mejorar.
KPIs típicos (muy usados en SOC/IR)MTTD (Mean Time To Detect): tiempo medio en detectar.
MTTR (Mean Time To Respond/Recover): tiempo medio en responder/recuperar.
Dwell Time: cuánto tiempo estuvo el atacante dentro antes de ser expulsado.
# de sistemas afectados (alcance).
# de reincidencias (si volvió a ocurrir).
% de alertas útiles vs falsas (calidad de detección).
Analogía:
Es como medir un servicio de emergencias: tiempo en llegar, tiempo en controlar la situación y número de “recaídas”.
Consejo práctico;
Empieza con pocos KPIs, pero buenos. Por ejemplo:MTTD
MTTR
Reincidencias
Y luego amplías.
Si quieres quedarte con una idea clave, es esta:
Responder a un incidente no es solo “apagar el fuego”.
Es también investigar, aprender, documentar, medir y mejorar para que el siguiente ataque sea más difícil, se detecte antes y tenga menos impacto.
Es como un accidente de coche: arreglar el coche (recuperación) está bien, pero luego quieres saber qué falló (frenos, distracción, carretera) y qué cambiarás (revisión, hábitos, ruta) para evitar otro accidente.
En este capítulo vamos a cubrir dos grandes bloques:
Post-Incident Activities (lo técnico y de mejora continua)
Incident Reporting and Communication (informes, comunicación y métricas)
En términos sencillos: investiga → encuentra causa → aplica cambios con control → actualiza el plan → genera señales (IOCs) → monitoriza → informa → aprende → mide.
El forense digital es el proceso de recoger y analizar evidencias para entender qué pasó, cómo pasó y hasta dónde llegó el incidente.
¿Para qué sirve?
Incident Reporting and Communication (informes, comunicación y métricas)
En términos sencillos: investiga → encuentra causa → aplica cambios con control → actualiza el plan → genera señales (IOCs) → monitoriza → informa → aprende → mide.
Post-Incident Activities
1) Forensics (Análisis forense digital)
¿Qué es?El forense digital es el proceso de recoger y analizar evidencias para entender qué pasó, cómo pasó y hasta dónde llegó el incidente.
¿Para qué sirve?
- Reconstruir la “película” del ataque (línea de tiempo).
- Confirmar qué sistemas se tocaron.
- Saber si hubo robo de información.
- Guardar pruebas por si hay temas legales o regulatorios.
- Logs (sistemas, red, aplicaciones).
- Eventos de autenticación (inicios de sesión raros).
- Artefactos del equipo (procesos, tareas programadas, claves de registro, etc.).
- Tráfico de red (conexiones a IPs extrañas).
- Archivos sospechosos (hashes, rutas, fechas).
Analogía:
El forense es como el trabajo de un equipo de investigación después de un robo: revisan cámaras, huellas y testimonios para reconstruir lo ocurrido.
Mini-checklist práctico (para estudiar)Preserva evidencia (sin “pisarla”).
Recoge datos de forma repetible.
Mantén notas claras (quién, cuándo, dónde).
Asegura integridad (hash / control de cambios).
2) Root Cause Analysis (RCA) — Análisis de causa raíz
¿Qué es?El RCA busca la razón real por la que el incidente fue posible. No se queda en el síntoma (“hubo malware”), sino en la causa (“entró por un equipo sin parchear y sin MFA”).
Ejemplos típicos de causa raízVulnerabilidad sin parche (software desactualizado).
Credenciales robadas (phishing).
Mala configuración (puerto expuesto, permisos excesivos).
Falta de monitorización (no se detectó a tiempo).
Proceso débil (no había revisión, no había validación).
Analogía:
Si se te inunda la cocina, la causa raíz no es “hay agua en el suelo”, sino “la tubería pierde” o “la lavadora estaba mal conectada”.
Técnica simple para principiantes: “Los 5 porqués”¿Por qué pasó?
¿Por qué eso fue posible?
¿Por qué no lo evitamos antes?
¿Por qué no lo detectamos rápido?
¿Qué cambio lo impediría?
3) Change Control Process (Proceso de control de cambios)
¿Qué es?Después de un incidente, toca cambiar cosas: reglas, configuraciones, parches, políticas, etc.
El control de cambios asegura que esos cambios se hagan sin romper el negocio y quedando documentados.
¿Por qué es importante?
Porque en modo “urgencia” es fácil:tocar cosas sin documentar,
crear nuevas caídas,
o abrir nuevos agujeros de seguridad.
Analogía:
Cambiar reglas en producción sin control es como cambiar cableado eléctrico de una casa “a ojo”: puede funcionar… o puedes provocar otro problema.
¿Qué suele incluir? (versión sencilla)Solicitud de cambio (qué, por qué, impacto).
Aprobación (según riesgo).
Ventana de cambio (cuándo se hace).
Plan de rollback (cómo volver atrás si falla).
Verificación (comprobar que quedó bien).
Registro (documentar).
4) Updates to the Incident Response Plan (Actualizar el plan de respuesta a incidentes)
¿Qué es?Actualizar el IRP (Incident Response Plan) con lo que aprendiste en el incidente real: qué faltó, qué sobró, qué mejoró.
¿Qué se suele actualizar?Roles y contactos (quién hace qué, y cómo localizarlo).
Playbooks (pasos concretos para incidentes comunes).
Plantillas de comunicación (mensajes internos/externos).
Herramientas (qué se usa y cómo).
Criterios de severidad (qué es crítico y qué no).
Analogía:
Tu IRP es como un manual de emergencias de un edificio. Cuando hay un incendio real, descubres si las salidas estaban bien señalizadas… y ajustas el plan.
5) Indicator of Compromise Generation (Generación de IOCs)
¿Qué es un IOC?Un Indicator of Compromise es una señal que sugiere que un sistema pudo ser comprometido.
Ejemplos comunesHash de un archivo malicioso.
Dominio/IP de comando y control (C2).
Nombre/ruta típica de un malware.
Patrón en logs (por ejemplo, muchas autenticaciones fallidas).
User-Agent raro o conexiones a horas extrañas.
Analogía:
Es como identificar que un coche fue robado porque:aparece una matrícula concreta en cámaras,
o un modelo específico se ve en una zona sospechosa.
¿Para qué sirven los IOCs?Buscar el mismo “rastro” en otros equipos.
Crear reglas en SIEM/EDR.
Compartir inteligencia con otros equipos/organizaciones (cuando aplique).
Consejo de estudio:
Un IOC no es “la prueba final”, es una pista que guía la investigación.
6) Monitoring (Monitorización después del incidente)
¿Qué es?Es reforzar la vigilancia para detectar:reinfecciones,
persistencia,
o ataques similares.
¿Qué se monitoriza más?Logs críticos (autenticación, endpoints, firewall, DNS).
Alertas del SIEM/EDR.
Tráfico de red hacia IOCs conocidos.
Cambios en cuentas y privilegios.
Creación de tareas programadas o servicios raros.
Analogía:
Si te entran a robar, los días siguientes estás más atento: cambias cerraduras, pones alarma y revisas si alguien ronda.
Buenas prácticas sencillas:
Asegura que los logs se recogen y se revisan (no solo “se guardan”).
Define umbrales y alertas realistas (para evitar ruido).
Revisa especialmente sistemas “joya de la corona” (críticos).
Son las personas o grupos que necesitan saber algo del incidente. Ejemplos típicos:Dirección / gerencia
IT / sistemas
Legal / compliance
Comunicación / prensa
Clientes (si les afecta)
Proveedores (si hay impacto)
Analogía:
En una comunidad de vecinos, ante una fuga de agua:el presidente debe coordinar,
el fontanero arregla,
los vecinos afectados necesitan información,
y la aseguradora quizá también.
Clave: “mensaje correcto, al público correcto”Dirección: impacto, riesgos, decisiones.
Técnicos: detalles y acciones.
Usuarios: instrucciones claras (“cambia contraseña”, “no abras X”).
Externos: comunicación controlada y coherente.
Define umbrales y alertas realistas (para evitar ruido).
Revisa especialmente sistemas “joya de la corona” (críticos).
Incident Reporting and Communication
1) Stakeholder Identification and Communication (Identificar interesados y comunicar)
¿Quiénes son los stakeholders?Son las personas o grupos que necesitan saber algo del incidente. Ejemplos típicos:Dirección / gerencia
IT / sistemas
Legal / compliance
Comunicación / prensa
Clientes (si les afecta)
Proveedores (si hay impacto)
Analogía:
En una comunidad de vecinos, ante una fuga de agua:el presidente debe coordinar,
el fontanero arregla,
los vecinos afectados necesitan información,
y la aseguradora quizá también.
Clave: “mensaje correcto, al público correcto”Dirección: impacto, riesgos, decisiones.
Técnicos: detalles y acciones.
Usuarios: instrucciones claras (“cambia contraseña”, “no abras X”).
Externos: comunicación controlada y coherente.
Tip de estudio:
Un error típico es comunicar “demasiado técnico” a quien no lo necesita, o “demasiado tarde” a quien sí.
2) Incident Response Reporting (Informe de respuesta al incidente)
¿Qué es?Es el documento que deja constancia del incidente: qué pasó, cómo se detectó, qué se hizo y cuál fue el resultado.
Estructura recomendada (muy Blogger-friendly)Resumen ejecutivo (1 página: qué, impacto, estado).
Línea de tiempo (timeline).
Alcance (sistemas, usuarios, datos).
Causa raíz (RCA).
Acciones realizadas (contención, erradicación, recuperación).
Evidencias (fuentes, logs, artefactos).
Medidas preventivas (qué cambia para que no vuelva a pasar).
Anexos (IOCs, capturas, referencias).
Analogía:
Como el informe final de un perito tras un siniestro: resume, prueba, concluye y recomienda.
3) Lessons Learned (Lecciones aprendidas)
¿Qué es?Una reunión (o sesión) para responder a:¿Qué funcionó bien?
¿Qué falló?
¿Qué debemos mejorar?
Cómo hacerlo sin “culpas” (muy importante)
En vez de “¿quién la lió?”, mejor:“¿qué control faltaba?”
“¿qué proceso falló?”
“¿qué automatización necesitamos?”
Analogía:
Después de un partido, un entrenador revisa jugadas: no solo para señalar fallos, sino para entrenar mejor.
4) Metrics and Key Performance Indicators (KPIs)
¿Por qué medir?Porque lo que no se mide, no se mejora.
Los KPIs ayudan a saber si tu respuesta fue rápida y eficaz, y dónde mejorar.
KPIs típicos (muy usados en SOC/IR)MTTD (Mean Time To Detect): tiempo medio en detectar.
MTTR (Mean Time To Respond/Recover): tiempo medio en responder/recuperar.
Dwell Time: cuánto tiempo estuvo el atacante dentro antes de ser expulsado.
# de sistemas afectados (alcance).
# de reincidencias (si volvió a ocurrir).
% de alertas útiles vs falsas (calidad de detección).
Analogía:
Es como medir un servicio de emergencias: tiempo en llegar, tiempo en controlar la situación y número de “recaídas”.
Consejo práctico;
Empieza con pocos KPIs, pero buenos. Por ejemplo:MTTD
MTTR
Reincidencias
Y luego amplías.
Conclusión / Recordatorio para el estudio
Si quieres quedarte con una idea clave, es esta:
Responder a un incidente no es solo “apagar el fuego”.
Es también investigar, aprender, documentar, medir y mejorar para que el siguiente ataque sea más difícil, se detecte antes y tenga menos impacto.
Frase para memorizar (modo examen):
Post-incident = mejora continua: forense + RCA + cambios controlados + actualización del plan + IOCs + monitorización + reporting + lecciones + KPIs.Glosario (definiciones rápidas)
Forensics (Forense digital): técnicas para recoger y analizar evidencias de un incidente.
RCA (Root Cause Analysis): análisis para encontrar la causa real del incidente.
Change Control: proceso para aplicar cambios de forma controlada y documentada.
IOC (Indicator of Compromise): señal técnica que sugiere compromiso (hash, IP, dominio, patrón).
Monitoring: vigilancia continua para detectar recurrencias o persistencia.
Stakeholders: personas/grupos que deben ser informados y coordinados.
MTTD: tiempo medio en detectar un incidente.
MTTR: tiempo medio en responder/recuperar.
IRP (Incident Response Plan): plan y procedimientos para responder a incidentes.
Siguiente paso (si te apetece)
RCA (Root Cause Analysis): análisis para encontrar la causa real del incidente.
Change Control: proceso para aplicar cambios de forma controlada y documentada.
IOC (Indicator of Compromise): señal técnica que sugiere compromiso (hash, IP, dominio, patrón).
Monitoring: vigilancia continua para detectar recurrencias o persistencia.
Stakeholders: personas/grupos que deben ser informados y coordinados.
MTTD: tiempo medio en detectar un incidente.
MTTR: tiempo medio en responder/recuperar.
IRP (Incident Response Plan): plan y procedimientos para responder a incidentes.
Siguiente paso (si te apetece)
No hay comentarios:
Publicar un comentario