0x71 Dominio 4 CySA - Incident Response
Incident Response · CySA+ · SOC
Mentalidad SOC sobre respuesta a incidentes, reporting, stakeholders, KPIs, vulnerabilidades, RCA y todas esas trampas que separan un análisis útil de un simple volcado de logs, para el examen como hice con los anteriores dominios.
En ciberseguridad hay una frase que suena muy bien en presentaciones: “tenemos un plan de respuesta a incidentes”.
El problema empieza cuando el incidente ocurre de verdad, el SIEM empieza a gritar, alguien de negocio pregunta si hay impacto, legal pide cautela, sistemas quiere reiniciar el servidor, desde los responsables se quiere saber si esto es una brecha y el analista todavía está intentando saber que está pasando.
Con el material de CySA de la mano voy hacer un post distinto algo mas personal y crítico y no solo ceñirme al contenido para estudiar y aprobar el examen como en los anteriores post de los dominios CySA.
La respuesta a incidentes no va solo de herramientas. No va solo de EDR, SIEM, YARA, Sigma, NetFlow, PCAPs o Event IDs. Va de tomar decisiones bajo presión sin romper más cosas.
Y ahí es donde se nota la diferencia entre mirar logs y hacer análisis. Un log te dice que algo pasó. Un analista tiene que explicar qué significa, qué impacto tiene, qué prioridad merece, a quién hay que avisar y qué se debe hacer después.
Esto no pretende ser una chuleta bonita para memorizar el Dominio 4 de CySA+.
0x00 Antes del incidente
La parte menos sexy de la respuesta a incidentes es la preparación. Nadie quiere hablar de políticas, procedimientos, playbooks, escalados, contactos, evidencias, SLAs o cadena de custodia. Hasta que una alerta crítica aparece un viernes a las 18:47.
Entonces descubres si tu organización tiene realmente un proceso o solo una carpeta llamada IR_plan_final_v3_definitivo.pdf que nadie ha leído desde 2021.
Jerarquía documental
| Documento | Función real |
|---|---|
| Policy | Define autoridad, alcance y qué se considera incidente. No debe incluir herramientas ni pasos técnicos. |
| Procedures | Explican el cómo genérico: creación de tickets, escalado, preservación de logs, comunicación interna. |
| Playbooks | Son recetas tácticas para amenazas concretas: phishing, ransomware, insider threat, cryptojacking, exfiltración. |
La Policy es el marco de autoridad. Tiene lenguaje administrativo, no técnico. No debería decir “usar Wireshark”, “ejecutar volatility” o “buscar Event ID 1102”. Eso pertenece a procedimientos y playbooks.
¿Por qué? Porque una política suele requerir aprobación ejecutiva y mucha burocracia, lo he visto durante años con incidencias, se necesita un INC para un CRQ que tiene una o varias TAS etc…Si metes herramientas concretas en una policy, acabas con un documento obsoleto cada seis meses.Y en un incidente serio, un documento obsoleto no da confianza: da miedo.
Trampa examen Si el escenario pregunta qué debe contener una política de respuesta a incidentes, nunca metas comandos, herramientas o pasos tácticos.
La policy responde a qué, quién y con qué autoridad.
El playbook responde a cómo.
Otro punto importante del temario es el famoso Statement of Management Commitment.El CSIRT necesita autoridad real para tomar decisiones que pueden impactar negocio.Aislar un servidor crítico, cortar accesos, bloquear cuentas, retener evidencia o retrasar una restauración no son decisiones pequeñas.
Por eso la dirección debe respaldar formalmente el proceso.Si el equipo de respuesta no tiene autoridad antes del incidente, durante el incidente solo tendrá opiniones.Esto normalmente no es transparente a técnicos o usuarios finales de negocio.
0x01 El CSIRT
Uno de los errores más comunes es pensar que un incidente de seguridad se resuelve únicamente con analistas.
Un incidente toca sistemas, datos, personas, contratos, reputación, regulación, comunicación pública y continuidad de negocio.El equipo técnico puede identificar el malware, reconstruir la timeline y aislar el host.Pero no debería decidir solo si se comunica una brecha, si se involucra a fuerzas de la ley o si se despide a un empleado.
Roles
| Stakeholder | Qué aporta |
|---|---|
| Management | Autoridad, presupuesto, recursos y decisiones de negocio. |
| Legal Counsel | Evalúa responsabilidad legal, regulatorios y comunicaciones externas. |
| HR | Gestiona insider threats, medidas disciplinarias y políticas internas. |
| PR | Controla la narrativa pública y evita comunicados improvisados. |
| SME | Aporta contexto experto sobre un sistema concreto: DBA, redes, cloud, ERP, industrial, etc. |
El SME es especialmente importante.Si una alerta aparece en una base de datos crítica, el analista puede saber mucho de logs, pero quizá no sabe qué consultas son normales en ese motor, qué jobs nocturnos existen o qué comportamiento es esperado.Ahí entra el experto de la materia.
El SOC detecta > El SME contextualiza > El CSIRT coordina > Legal protege > Management autoriza > PR comunica.
Si todo eso no está alineado, el incidente se convierte en una reunión infinita con gente gritando y pisandose en la meet sin orden, mirando dashboards y nadie tomando decisiones.
Law Enforcement
No se llama a la policía “porque suena grave”.
Se consulta con Legal y Management.
Las fuerzas de la ley pueden necesitar preservar evidencia para juicio, incluso incautar sistemas.
Eso puede chocar con el objetivo de negocio: recuperar servicio.
0x02 Event, Adverse Event, Incident
Una de las primeras cosas que debe hacer un analista es clasificar.Y clasificar bien evita dos problemas ya que es minimizar algo grave o declarar una crisis por algo que no lo es.
Jerarquía NIST
- Event: cualquier ocurrencia observable. Un login, una conexión, un cambio de permiso.
- Adverse Event: evento con consecuencia negativa. Una caída, un fallo, un malware detectado.
- Security Incident: violación confirmada o probable de una política de seguridad.
Un usuario accediendo a una carpeta puede ser normal.Un usuario accediendo a una carpeta sensible por error puede ser un evento adverso.Un usuario accediendo a esa carpeta para copiar datos y sacarlos fuera puede ser un incidente de seguridad.
La diferencia no siempre está en el log también puede estar en el contexto de la acción del usuario.
0x03 Severidad
La severidad no debería decidirse por volumen de alertas o por el acojone que te da si ves una alerta…Se decide mirando impacto.
Clasificar impacto
| Pilar | Pregunta real |
|---|---|
| Functional Impact | ¿Se ha parado la operación o solo hay degradación? |
| Economic Impact | ¿Cuánto cuesta cada hora de indisponibilidad? |
| Recoverability Effort | ¿Podemos recuperarlo internamente o necesitamos ayuda externa? |
| Information Impact | ¿Hay PII, secretos industriales, integridad alterada o datos publicados? |
Aquí hay dos ejemplos que parecen simples, pero son oro para pensar como analista
- Si un portátil perdido tenía Full Disk Encryption activo, el impacto sobre la información puede ser nulo
- Si datos sensibles ya fueron publicados en Internet, la recuperabilidad puede ser imposible.
En un SOC real, esta diferencia importa mucho (no lo digo yo que no tengo experiencia real lo dice el señor CySA.No es lo mismo una alerta técnicamente fea que un impacto real sobre el negocio.
0x04 PICERL
PICERL es una forma sencilla de recordar el ciclo de vida de respuesta a incidentes Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.
Lo importante es no saltarse pasos por ansiedad y no tener la mente fría el daño ya está hecho ahora pensemos como paliar cuanto antes las consecuencias.
PICERL
| Fase | Qué significa de verdad |
|---|---|
| Preparation | Tener playbooks, jump kits, contactos, NTP, logging y simulacros antes de necesitarlos. |
| Identification | Determinar si hay incidente, qué alcance tiene y qué evidencia lo demuestra. |
| Containment | Limitar el daño sin destruir evidencia ni alertar innecesariamente al atacante. |
| Eradication | Eliminar malware, persistencia, cuentas ocultas, vulnerabilidad raíz y accesos comprometidos. |
| Recovery | Restaurar con seguridad, monitorizar y validar que el sistema vuelve limpio. |
| Lessons Learned | Aprender sin culpar, actualizar playbooks, mejorar controles y alimentar el SIEM. |
Contención antes que erradicación.
Ahora abre una incidencia o un JIRA para un CRQ y una TAS y que lo apruebe media empresa.
0x05 NTP
NTP parece un detalle menor hasta que intentas reconstruir una timeline con logs de FW, EDP, proxy, VPN, AD, BBDD y SIEM.
Si cada sistema tiene una hora distinta, la correlación se rompe.Y cuando se rompe la correlación, se rompe la historia que tratas de averiguar, esto ocurre en la red exterior mucho yo tuve una incidencia peculiar en ISE y hay un post sobre ello.
Sin tiempos sincronizados, una línea temporal puede perder valor analítico, operativo e incluso legal.
Un buen reporte de incidente no es solo una colección de pantallazos.Es una narrativa técnica verificable y personalmente tratando incidencia se me ha tachado siempre de “muy intenso” cuando es a lo mejor lo que hace falta solo que matizando lo esencial (síntesis) algo que personalmente trato de mejorar.Y para que esa narrativa sea verificable, los eventos tienen que estar ordenados con precisión.
0x06 IoC vs IoA
Esta diferencia parece académica, pero en análisis real importa muchísimo.
La forma fácil de no liarse
| Concepto | Qué es | Ejemplo |
|---|---|---|
| IoC | Artefacto estático. Un sustantivo. | Hash, IP, dominio, ruta, clave de registro. |
| IoA | Comportamiento dinámico. Un verbo. | Beaconing, movimiento lateral, credential dumping, inyección. |
Un hash malicioso te dice que algo conocido está o estuvo presente.Un patrón de beaconing te dice que algo se está comportando como un implante.
El IoC suele ser reactivo.El IoA permite cazar antes de tener una firma perfecta.
Por eso los buenos equipos no viven solo de listas de indicadores.Buscan comportamientos.
0x07 Logs
Hay eventos que no deberían pasar desapercibidos.No porque sean siempre confirmación absoluta de compromiso, sino porque tienen mucho peso contextual.
Windows Event IDs útiles en respuesta
| Event ID | Significado | Lectura defensiva |
|---|---|---|
| 4625 | Login fallido | Múltiples fallos pueden indicar brute force o password spraying. |
| 4624 | Login exitoso | Después de muchos 4625 puede indicar compromiso exitoso. |
| 1102 | Security log borrado | Señal fuerte de anti-forensics. Muy raro fuera de mantenimiento controlado. |
Hay otro patrón muy simple y muy potente >múltiples 4625 seguidos de un 4624 desde el mismo origen.
Eso puede ser ruido o puede ser un ataque de fuerza bruta que acaba de funcionar.
Y si además la cuenta es una cuenta de servicio, el horario es raro y el Logon Type es interactivo o RDP, el nivel de sospecha sube bastante.Se que es el típico ejemplo digamos… mas académico, pero hay cientos de post en Medium por ejemplo de gente con ejemplos de investigaciones y correlaciones con Splunk donde se buscan y se ven estos patrones habitualmente.
Una cuenta svc_backup con Logon Type 2 o 10 a las 03:00 AM no debería tratarse como “curioso”.
Una cuenta de servicio no debería estar abriendo sesión interactiva como si fuera una persona.
0x08 DNS
DNS es uno de esos protocolos que casi siempre está permitido, casi siempre está poco vigilado y casi siempre tiene cosas interesantes.
Cuando un atacante quiere comunicarse con infraestructura externa, DNS puede convertirse en un canal perfecto para esconder ruido dentro de lo aparentemente normal.
Patrones DNS raros
- DNS Tunneling: muchas consultas TXT, subdominios largos, cadenas con pinta de base64.
- DGA: dominios aparentemente aleatorios y muchos errores NXDOMAIN.
- Fast-flux: un dominio resolviendo constantemente a IPs distintas con TTLs bajos.
De nuevo, el secreto está en el comportamiento.Un dominio raro no siempre es malo.Un patrón raro sostenido, repetido y correlacionado con otros eventos empieza a oler a popó.
0x09 Collection no es Exfiltration
Esta es una trampa muy típica en CySA y también una confusión real en análisis.Si el atacante comprime datos dentro de la máquina, todavía no ha exfiltrado pero se está preparando.
Diferencia operativa
| Fase | Qué ocurre |
|---|---|
| Collection | El atacante reúne, copia o comprime datos dentro del entorno. |
| Exfiltration | Los datos salen de la red hacia infraestructura externa. |
Ejemplo tonto, aparece un ZIP enorme en C:\Temp\stage.Eso huele a staging y collection.Si después ves 9 GB saliendo hacia una IP externa desconocida, ahora sí estás mirando posible exfiltration.
Para detectar ese segundo escenario, tiene sentido usar Flow logs con análisis heurístico.No buscas solo una firma lo que se busca es desviación respecto al comportamiento normal.
0x0A Contención
La contención es una de las fases más delicadas.Aquí el instinto puede ser peligroso.Si ves algo comprometido, quieres desconectarlo todo pero desconectar sin pensar puede destruir evidencia, activar mecanismos defensivos del malware o cortar visibilidad.
Estrategias de contención
| Estrategia | Uso recomendado |
|---|---|
| Segmentation | Mover el host a una VLAN de cuarentena con tráfico controlado. |
| Isolation | Cortar red interna pero permitir tráfico controlado para observar C2. |
| Removal | Desconexión física total. Útil si hay exfiltración masiva inmediata, pero arriesgada. |
Dead Man’s Switch → algunos malware pueden ejecutar acciones destructivas si pierden conectividad.
Tirar del cable puede parecer contundente, pero no siempre es la opción más inteligente.
0x0B Forense
En forense, el orden importa.Si apagas una máquina antes de capturar memoria, procesos activos y conexiones, acabas de perder parte de la escena.
Order of Volatility
- CPU cache, registros y RAM.
- Procesos activos y conexiones de red.
- Tablas ARP, routing cache y DNS cache.
- Discos HDD/SSD.
- Backups y medios históricos.
Después viene la adquisición con integridad el coñazo de documentar, usar write blockers, crear imagen bit a bit, calcular hash del original y de la copia o registrar cadena de custodia.
La evidencia no es solo encontrar algo yo creo que es demostrar que lo encontraste sin alterarlo.
Si alguien pregunta quién tocó la evidencia, cuándo, por qué y cómo, la cadena de custodia debería responder sin improvisar.
0x0C Erradicación y recuperación
Pasar un antivirus y dar el host por limpio es una forma bastante optimista de dormir mal.
Si un sistema ha estado comprometido, el atacante puede haber dejado persistencia, cuentas ocultas, tareas programadas, servicios modificados, credenciales robadas o un rootkit.
Por eso, en muchos escenarios serios, la respuesta robusta es wipe and rebuild o en castellano llano, borrar y reconstruir desde una imagen limpia conocida.
Antes de volver a producción
- Verificar cuentas y permisos.
- Rotar credenciales comprometidas.
- Confirmar que el logging hacia el SIEM funciona.
- Escanear vulnerabilidades de nuevo.
- Validar que el parche cerró la causa raíz.
- Monitorizar comportamiento tras la reincorporación.
Recuperar no es encender otra vez, es volver a operar con garantías y rápido si es algo de negocio perdiendo pasta por minuto.
0x0D Vulnerabilidades
La gestión de vulnerabilidades tiene un problema clásico y es confundir severidad técnica con prioridad real.
CVSS es útil pero no es el juez final que dicta sentencia.
¿Ordenar de mayor a menor CVSS?
Una vulnerabilidad 9.8 en un laboratorio aislado puede ser menos urgente que una 7.5 en un servidor público con datos PII.
- Asset Criticality: importancia del activo para negocio.
- Exposure: si está expuesto a Internet o segmentado.
- Threat Intelligence: explotación activa, CISA KEV, PoC público.
- Data Sensitivity: si maneja PII, credenciales o datos críticos.
El reporte de vulnerabilidades no debería ser un PDF de 800 páginas exportado del escáner o redactado por Chat GPT.Eso no es reporting, yo lo entiendo como vomitar encima de alguien y esperar que sobreviva.
Un buen reporte traduce hallazgos en plan de acción, qué se corrige primero, por qué, qué impacto tiene, qué equipo lo ejecuta o qué alternativa existe si no se puede parchear.
Sistemas legacy: si no puedes parchear un ICS o un sistema propietario end-of-life, no fuerces un parche genérico.
Implementa controles compensatorios: segmentación, filtrado, monitoreo, restricciones de acceso.
0x0E Reporting
Un error típico del perfil técnico es escribir todos los reportes como si los fuera a leer otro analista.
Tus responsables no necesitan una lista de hashes, puertos, rutas de archivo y reglas Sigma.Pero si necesitan que no tartamudees en una meet si piden explicaciones además de saber impacto, riesgo, estado, decisiones necesarias y próximos pasos.
Qué va en cada sitio
| Sección | Contenido |
|---|---|
| Executive Summary | Impacto, estado, riesgo, acciones tomadas y decisiones pendientes. Sin jerga profunda. |
| Timeline | Secuencia cronológica de eventos relevantes con timestamps consistentes. |
| Technical Analysis | IoCs, IoAs, TTPs, MITRE ATT&CK, logs interpretados, hipótesis y validación. |
| Evidence Appendix | Logs crudos, PCAPs, hashes, capturas, artefactos y evidencias de soporte. |
Los logs crudos no van en el resumen ejecutivo.Las PCAPs no van en la timeline.Las evidencias técnicas van en apéndices.
Un reporte bien escrito protege al equipo.Un reporte mal escrito puede crear confusión, riesgo legal o decisiones equivocadas.Además da mala imagen.
0x0F Single Pane of Glass
Durante un incidente, tener información repartida en diez consolas distintas es una receta para la discrepancia.
El concepto de Single Pane of Glass busca precisamente eso que en una vista consolidada para reducir silos, mejorar correlación y permitir reporting coherente.
SIEM vs SOAR
SIEM → si el verbo es agregar, correlacionar, visualizar o alertar, piensas en SIEM.
SOAR → Si el verbo es automatizar, orquestar, ejecutar playbooks o integrar respuestas entre plataformas, piensas en SOAR.
SOAR el el niño listo
El dashboard no es decoración.Es una herramienta de reducción de incertidumbre.Pero si está mal configurado, se convierte en ruido con colores.De una vista todo como cuando se filtra una bandeja de correo delegada con cientos de correos, lo importante y lo urgente.
0x10 KPIs
Medir un SOC solo por volumen de alertas es como medir la salud de una ciudad por el número de sirenas que se escuchan.Aquí hago un inciso para todos aquellos obsesionados con los KPIs y que si la cosa baja pues despido gente.Puede indicar actividad.No necesariamente eficacia.
Métricas
| KPI | Qué mide |
|---|---|
| MTTD | Tiempo medio de detección. Evalúa visibilidad, SIEM, IoCs, IoAs y monitoreo. |
| MTTR Respond | Tiempo medio de respuesta. Evalúa escalado, playbooks y agilidad operativa. |
| MTTR Remediate | Tiempo medio de remediación. Evalúa parcheo, erradicación y cierre real. |
| Alert Volume | No demuestra eficacia por sí solo. Puede indicar mala afinación y fatiga de alertas. |
Si el MTTD es alto, tienes un problema de visibilidad.Si el MTTR es alto, tienes un problema de proceso, recursos, burocracia, playbooks o capacidad operativa.
La métrica buena no es la que queda bonita en un dashboard la mas guapa de la pandilla es la que te obliga a mejorar algo.
0x11 RCA y Lessons Learned
Cuando termina la parte intensa del incidente, empieza una de las fases más importantes y es entender que ha pasado con tanto CAOS, por qué pasó y cómo evitar repetirlo.
El Root Cause Analysis es técnico.Busca la causa raíz y no se queda en síntomas.
RCA
- Identificar problemas y eventos.
- Establecer una timeline.
- Diferenciar factores causales de la causa raíz.
- Documentar el análisis y priorizar hallazgos.
Las Lessons Learned miran el proceso completo por ejemplo qué salió bien, qué salió mal, qué se tardó demasiado, qué comunicación falló, qué playbook no ayudó y qué herramienta estaba ciega.
No-blame → la reunión post-incidente no debería ser una caza de brujas.
El objetivo es mejorar el sistema, no sacrificar a quien estaba de guardia.
Una buena sesión de Lessons Learned termina con cambios concretos en los playbooks, reglas nuevas, IoCs añadidos al SIEM, umbrales ajustados, procedimientos corregidos o responsabilidades más claras.
0x12 MITRE, Kill Chain y Diamond Model
Los frameworks no están para decorar.Sirven para ordenar pensamiento.
Frameworks
| Framework | Para qué sirve |
|---|---|
| MITRE ATT&CK | Mapear tácticas, técnicas y procedimientos. Muy útil para threat hunting. |
| Cyber Kill Chain | Entender en qué fase del ataque estás y dónde romper la cadena. |
| Diamond Model | Relacionar adversario, capacidad, infraestructura y víctima para pivotar investigación. |
En MITRE, la táctica responde a por qué.
- La técnica responde a cómo.
- Persistence es la intención.
- Scheduled Task puede ser el método.
0x13 Sanitización
Cuando un medio deja de usarse, no basta con borrar archivos.Borrar no es destruir.Formatear rápido no es sanitizar.
NIST SP 800-88
| Nivel | Qué implica |
|---|---|
| Clear | Sobrescritura lógica. Protege frente a recuperación simple. |
| Purge | Degaussing o borrado criptográfico. Resiste recuperación avanzada. |
| Destroy | Destrucción física. Para datos de máxima sensibilidad o medios no recuperables. |
En seguridad, el ciclo no termina cuando el sistema vuelve.Pero…cuando sabes qué evidencia conservar, qué medio sanitizar, qué riesgo queda y qué controles han cambiado ahí si tienes todo claro.
0x14 Las trampas
Hay preguntas de examen que son trampasEn este examen caemos como moscas, conviene informarse bien con calma, leer muchos blogs buenos y no ser un papagayo.
Checklist
- FDE activo en portátil perdido: Information Impact puede ser None.
- Datos publicados online: Recoverability puede ser Not Recoverable.
- ZIP en C:\Temp: Collection, no Exfiltration.
- 9 GB saliendo a IP externa: Flow logs + análisis heurístico.
- Event ID 1102: posible anti-forensics crítico.
- Gerencia: Executive Summary, no dump técnico.
- Legacy sin parche: Compensating Control, no parche inventado.
- Alert Volume: no es KPI de éxito por sí solo.
- RCA: documenta causa raíz; implementar controles viene después.
- Lessons Learned: revisa lo bueno y lo malo, no solo fallos.
0x15 No soy analista aún ¿o si?
Cada vez que estudio respuesta a incidentes acabo llegando a la misma conclusión y es que la parte difícil no es saber qué comando ejecutar, para eso me hago mis chuletas no soy una IA que aprende datos absurdos, si acaso con el tiempo aprendes comandos o sintaxis SPL en búsquedas en Splunk pero… no hay nada de malo en reconocer que no lo sabes todo y las chuletas bien documentadas ayudan mucho.
La parte difícil es mantener criterio cuando todo el mundo quiere una respuesta rápida sin tirarte por la ventana.
Un buen analista no es el que genera más alertas dicen academicamente, el que convierte señales dispersas en una historia coherente ese si.
Mira logs, impacto, stakeholders, evidencias y negocio mira también tiempos o qué control falló o si un proceso no existía y apareció, se curioso.
Responder a incidentes no es apagar fuegos.
Es entrar en una habitación llena de humo, ordenar las señales, proteger la evidencia, reducir el daño, explicar el impacto y conseguir que la organización salga más fuerte que antes.
Al final un incidente no solo te enseña qué falló en un sistema y como consecuencia enseña qué tan preparada estaba realmente tu organización.
[ EOF ]
“Logs do not explain themselves. Incidents do not forgive improvisation.”