4.1.1.-Proceso completo de respuesta a incidentes
4.1.1. Proceso completo de respuesta a incidentes¶
Idea principal
Responder a un incidente no consiste en improvisar cuando algo falla. Es seguir un proceso preparado, con personas responsables, decisiones claras, evidencias bien tratadas y acciones orientadas a contener, erradicar, recuperar y aprender.
Cuando una organización detecta un incidente, el objetivo no es solo "arreglar el problema técnico". El objetivo real es reducir el impacto, mantener el servicio cuando sea posible, proteger las evidencias, recuperar con seguridad y evitar que vuelva a ocurrir.
En este tema vamos a trabajar el proceso completo de respuesta a incidentes tomando como referencia el ciclo clásico de NIST SP 800-61 Rev. 2 y conectándolo con el RA4 del módulo. Aunque NIST SP 800-61 Rev. 2 ha sido sustituido por NIST SP 800-61 Rev. 3, sigue siendo una referencia útil para entender la secuencia operativa clásica de respuesta: preparación, detección y análisis, contención, erradicación, recuperación y actividad post-incidente.
El objetivo de este tema no es memorizar fases. Lo importante es entender qué se decide en cada fase, quién debe participar, qué se documenta y cómo convertir todo eso en un plan de respuesta a incidentes usable en una organización real.
| Código | Descripción |
|---|---|
| RA4 | Implementa medidas de ciberseguridad en redes y sistemas respondiendo a los incidentes detectados y aplicando las técnicas de protección adecuadas. |
| CE a) | Se han desarrollado procedimientos de actuación detallados para dar respuesta, mitigar, eliminar o contener los tipos de incidentes de ciberseguridad más habituales. |
| CE b) | Se han preparado respuestas ciberresilientes ante incidentes que permitan seguir prestando los servicios de la organización y fortaleciendo las capacidades de identificación, detección, prevención, contención, recuperación y cooperación con terceros. |
| CE c) | Se ha establecido un flujo de toma de decisiones y escalado de incidentes interno y/o externo adecuados. |
| CE d) | Se han llevado a cabo las tareas de restablecimiento de los servicios afectados por un incidente hasta confirmar la vuelta a la normalidad. |
| CE e) | Se han documentado las acciones realizadas y las conclusiones que permitan mantener un registro de "lecciones aprendidas". |
| CE f) | Se ha realizado un seguimiento adecuado del incidente para evitar que una situación similar se vuelva a repetir. |
Definición
La respuesta a incidentes es el conjunto organizado de capacidades, roles, decisiones y procedimientos que permiten gestionar un incidente de ciberseguridad desde su detección hasta su cierre, reduciendo el impacto en la organización y mejorando sus defensas.
En este documento se seguirá una secuencia estructurada que incluye: entender qué problema resuelve la respuesta a incidentes, recorrer el ciclo completo de respuesta, aprender a tomar decisiones y escalar, construir una plantilla de plan de respuesta, y aplicar el proceso a un caso práctico.
Qué deberías saber al terminar
Al acabar este tema deberías poder:
- explicar el ciclo completo de respuesta a incidentes;
- diferenciar política, plan, procedimiento, playbook y runbook;
- priorizar un incidente según impacto funcional, impacto en la información y recuperabilidad;
- proponer un flujo de escalado interno y externo;
- redactar una estructura básica de plan de respuesta a incidentes;
- cerrar un incidente con documentación, lecciones aprendidas y seguimiento.
1. Qué problema resuelve la respuesta a incidentes¶
En ciberseguridad no basta con prevenir. Las organizaciones aplican medidas de protección, monitorizan sistemas y forman al personal, pero siempre queda riesgo residual. Un correo de phishing puede llegar, una cuenta puede verse comprometida, un servidor puede quedar expuesto o una copia de seguridad puede fallar justo cuando más se necesita.
La respuesta a incidentes existe para que, cuando ocurra algo así, la organización no dependa de decisiones improvisadas.
Evento no es lo mismo que incidente
Un evento es algo observable en un sistema o red: un inicio de sesión, una conexión bloqueada por el firewall, una alerta del antivirus o una petición HTTP.
Un incidente es un evento, o conjunto de eventos, que supone una violación real o probable de una política de seguridad, una práctica aceptable o un requisito de protección.
Dicho de forma sencilla: todos los incidentes son eventos, pero no todos los eventos son incidentes. El trabajo del equipo de respuesta empieza cuando hay indicios suficientes para pensar que el evento puede afectar a la seguridad, la continuidad o la información de la organización.
2. De la capacidad al documento: política, plan y procedimientos¶
Antes de hablar de fases, conviene ordenar tres niveles que suelen mezclarse:
| Elemento | Para qué sirve | Ejemplo |
|---|---|---|
| Política de respuesta | Define compromisos, alcance, autoridad y obligaciones generales. | "Todo incidente crítico debe notificarse al responsable de seguridad y registrarse en la herramienta de tickets." |
| Plan de respuesta | Explica cómo se organiza la capacidad de respuesta de la organización. | Roles, equipos, canales, niveles de severidad, escalado, comunicación y métricas. |
| Procedimientos, playbooks y runbooks | Describen pasos concretos para actuar ante escenarios específicos. | Playbook de ransomware, runbook para aislar un endpoint, procedimiento de restauración desde backup. |
La política responde a qué debe cumplirse. El plan responde a cómo se organiza la respuesta. Los procedimientos responden a qué pasos se siguen en un caso concreto.
Ejemplo
Si una empresa sufre un ransomware:
- la política indica quién tiene autoridad para declarar incidente crítico;
- el plan indica qué equipos participan, cómo se escala y cómo se comunica;
- el playbook indica las acciones específicas para ransomware;
- el runbook puede indicar comandos o pasos técnicos para aislar equipos, bloquear IoC o restaurar servicios.
3. Ciclo completo de respuesta a incidentes¶
El ciclo clásico de NIST organiza la respuesta en cuatro grandes bloques:
- Preparación.
- Detección y análisis.
- Contención, erradicación y recuperación.
- Actividad post-incidente.
En la práctica no siempre se avanza en línea recta. A veces se contiene un equipo y después se vuelve al análisis porque aparecen nuevos equipos afectados. Otras veces se recupera parcialmente un servicio y se mantiene una monitorización reforzada durante días.
flowchart LR
A[Preparación] --> B[Detección y análisis]
B --> C[Priorización y escalado]
C --> D[Contención]
D --> E[Erradicación]
E --> F[Recuperación]
F --> G[Actividad post-incidente]
G --> A
D -. Nuevos indicios .-> B
F -. Monitorización reforzada .-> BIdea clave
La respuesta a incidentes es un ciclo de mejora. Cada incidente bien gestionado debe dejar a la organización mejor preparada para el siguiente.
4. Fase 1: preparación¶
La preparación consiste en dejar lista la organización antes de que ocurra el incidente. Es la fase menos visible, pero es la que marca la diferencia cuando hay presión.
En esta fase se definen los equipos, las herramientas, los contactos, los canales de comunicación, los criterios de severidad, los procedimientos y los recursos necesarios.
4.1. Elementos mínimos de preparación¶
Un equipo de respuesta necesita, como mínimo:
- contactos internos y externos: seguridad, sistemas, redes, dirección, legal, comunicación, proveedores, CERT/CSIRT o cuerpos competentes;
- canales de comunicación alternativos: si el correo corporativo está comprometido, debe existir otra forma de coordinarse;
- herramientas de análisis: SIEM, EDR, visores de logs, herramientas forenses, analizadores de tráfico, repositorios de IoC;
- información de contexto: inventario de activos, diagramas de red, servicios críticos, propietarios de sistemas y dependencias;
- procedimientos probados: playbooks, runbooks, plantillas de informe, formularios de registro y cadena de custodia;
- copias de seguridad verificadas: no basta con tener backups; hay que saber si se pueden restaurar.
Error frecuente
Pensar que un plan de respuesta es solo un PDF guardado en una carpeta. Un plan que nadie ha probado, que no tiene responsables claros o que no incluye contactos actualizados no sirve cuando el incidente ya está en marcha.
4.2. Preparación también es prevención¶
NIST plantea la preparación no solo como organización de la respuesta, sino también como reducción de incidentes. Si los sistemas están mal bastionados, no hay registro de eventos o los usuarios no saben reportar una sospecha, el equipo de respuesta trabajará tarde y con poca información.
En la práctica, preparar la respuesta también implica:
- endurecer sistemas y redes;
- aplicar parches;
- configurar registros suficientes;
- sincronizar relojes con NTP;
- formar al personal;
- revisar permisos;
- probar restauraciones;
- hacer simulacros de incidentes.
5. Fase 2: detección y análisis¶
La detección y el análisis convierten señales dispersas en una decisión: hay incidente o no lo hay. Esta fase conecta con unidades anteriores, pero aquí nos interesa su impacto en la respuesta: si el análisis es lento o confuso, la contención también lo será.
Las señales pueden venir de muchas fuentes:
| Fuente | Qué puede aportar |
|---|---|
| SIEM | Correlación de eventos, alertas por reglas y patrones anormales. |
| EDR o antivirus | Procesos sospechosos, malware, aislamiento de endpoint, actividad anómala. |
| Logs de sistemas y aplicaciones | Accesos, errores, cambios de configuración, acciones de usuarios. |
| Dispositivos de red | Conexiones bloqueadas, tráfico anómalo, flujos NetFlow, reglas activadas. |
| Usuarios y personal técnico | Avisos de comportamiento raro, caídas, correos sospechosos o errores. |
| Terceros | Avisos de proveedores, clientes, CERT/CSIRT, OSINT o inteligencia de amenazas. |
Precursor e indicador
Un precursor es una señal de que un incidente podría ocurrir: por ejemplo, la publicación de un exploit para una vulnerabilidad que afecta a un servidor de la organización.
Un indicador es una señal de que el incidente puede estar ocurriendo o haber ocurrido: por ejemplo, conexiones a un dominio de mando y control, creación de cuentas desconocidas o cifrado masivo de archivos.
5.1. Analizar no es mirar una alerta aislada¶
Una alerta por sí sola rara vez cuenta toda la historia. El equipo debe correlacionar información: hora, usuario, equipo, dirección IP, proceso, hash, servicio afectado, logs relacionados y contexto del activo.
Alerta inicial:
EDR detecta powershell.exe con conexión externa sospechosa.
Preguntas de análisis:
- En qué equipo ocurre?
- Qué usuario lanzó el proceso?
- Hay otros equipos con el mismo patrón?
- El dominio externo aparece en inteligencia de amenazas?
- Hay movimiento lateral o robo de credenciales?
- El equipo presta un servicio crítico?
Lo importante aquí es no caer en dos extremos: ni ignorar señales por parecer pequeñas, ni declarar crisis por cada alerta. La respuesta necesita evidencias suficientes para actuar con criterio.
6. Fase 3: priorización y escalado¶
Cuando se confirma o se sospecha razonablemente un incidente, hay que decidir con qué urgencia se atiende y a quién se informa.
NIST propone priorizar usando tres factores muy útiles:
- Impacto funcional: qué servicios o procesos deja de prestar la organización.
- Impacto en la información: si afecta a confidencialidad, integridad o disponibilidad de datos.
- Esfuerzo de recuperación: cuánto tiempo y cuántos recursos hacen falta para volver a una situación aceptable.
6.1. Matriz sencilla de severidad¶
| Nivel | Criterio orientativo | Ejemplo | Escalado |
|---|---|---|---|
| Bajo | No afecta a servicios críticos ni a información sensible. | Malware bloqueado en un equipo no crítico. | Equipo técnico y registro del incidente. |
| Medio | Afecta parcialmente a un servicio o requiere intervención coordinada. | Cuenta comprometida sin evidencias de exfiltración. | Seguridad, sistemas y responsable del servicio. |
| Alto | Afecta a un servicio crítico, a varios equipos o a datos sensibles. | Ransomware contenido en varios puestos. | Responsable de seguridad, dirección, legal y comunicación si procede. |
| Crítico | Interrumpe servicios esenciales, hay exfiltración, impacto público o riesgo legal relevante. | Cifrado de servidores críticos o fuga de datos personales. | Comité de crisis, dirección, legal, comunicación, proveedores y organismos competentes. |
Decisión crítica
Los incidentes no deben atenderse por orden de llegada. Un ticket antiguo de baja severidad puede esperar si aparece un incidente que compromete un servicio crítico o información sensible.
6.2. Flujo de escalado¶
El flujo de escalado evita dudas en momentos de presión. Debe indicar qué hacer si una persona no responde, cuándo escalar a dirección, cuándo involucrar a legal y cuándo contactar con terceros.
flowchart TD
A[Alerta o notificación] --> B{Hay indicios de incidente?}
B -- No --> C[Registrar evento y cerrar o monitorizar]
B -- Si --> D[Clasificar severidad]
D --> E{Severidad alta o crítica?}
E -- No --> F[Gestión técnica por equipo responsable]
E -- Si --> G[Activar responsable de seguridad]
G --> H[Convocar equipo de respuesta]
H --> I{Impacto legal, datos personales o comunicación pública?}
I -- Si --> J[Escalar a legal, dirección y comunicación]
I -- No --> K[Ejecutar playbook técnico]
J --> K
K --> L[Seguimiento, recuperación y cierre]7. Fase 4: contención¶
La contención busca frenar el daño. No siempre significa apagar un servidor. A veces consiste en aislar un equipo, bloquear un dominio, deshabilitar una cuenta o cortar una ruta de red. La medida correcta depende del tipo de incidente, del impacto en el servicio y de la necesidad de conservar evidencias.
7.1. Criterios para elegir una estrategia de contención¶
Antes de actuar, el equipo debe valorar:
- daño potencial si no se actúa;
- necesidad de preservar evidencias;
- disponibilidad del servicio;
- tiempo necesario para aplicar la medida;
- eficacia de la contención;
- duración de la solución: puntual, temporal o permanente.
| Escenario | Contención posible | Riesgo si se hace mal |
|---|---|---|
| Equipo con malware activo | Aislar desde EDR o VLAN de cuarentena. | Perder evidencia volátil si se apaga sin capturar datos necesarios. |
| Cuenta comprometida | Deshabilitar cuenta, revocar sesiones y rotar credenciales. | Dejar tokens activos o no revisar accesos relacionados. |
| DDoS contra web pública | Filtrado con proveedor, CDN, WAF o reglas de red. | Bloquear tráfico legítimo y agravar la indisponibilidad. |
| Exfiltración en curso | Cortar canal de salida y preservar logs. | Cortar demasiado tarde o no identificar otros canales. |
Contener con cabeza
La contención debe ser rápida, pero no ciega. Una medida precipitada puede destruir evidencia, tumbar un servicio crítico o avisar al atacante antes de conocer el alcance real.
8. Fase 5: erradicación¶
Una vez contenido el incidente, hay que eliminar la causa y los elementos que lo mantienen vivo. Erradicar no es solo borrar malware: también implica cerrar la vulnerabilidad explotada, eliminar persistencias, revisar cuentas, corregir configuraciones y confirmar que no quedan equipos afectados.
Acciones habituales de erradicación:
- eliminar malware, scripts, tareas programadas o servicios maliciosos;
- deshabilitar cuentas comprometidas;
- revocar sesiones y tokens;
- aplicar parches;
- corregir reglas inseguras;
- cerrar accesos expuestos;
- revisar persistencia en endpoints, servidores y nube;
- buscar IoC en el resto de la organización.
Ejemplo
Si el incidente entró por una VPN sin MFA, erradicar no es solo cerrar la sesión del atacante. Hay que revisar cuentas usadas, activar o reforzar MFA, rotar credenciales, comprobar accesos laterales y buscar actividad similar en logs anteriores.
9. Fase 6: recuperación¶
La recuperación devuelve los servicios a un estado operativo y confiable. La palabra importante es confiable: no se trata de levantar sistemas lo antes posible a cualquier precio, sino de confirmar que vuelven limpios, monitorizados y sin la vulnerabilidad que permitió el incidente.
9.1. Tareas de recuperación¶
Durante la recuperación se suelen realizar estas acciones:
- restaurar desde copias limpias;
- reconstruir sistemas comprometidos cuando no se pueda confiar en ellos;
- aplicar parches y endurecimiento;
- validar integridad de datos;
- probar servicios con usuarios o responsables funcionales;
- mantener monitorización reforzada;
- comunicar la vuelta al servicio.
| Pregunta | Por qué importa |
|---|---|
| ¿La copia usada es anterior al compromiso? | Restaurar una copia ya comprometida reintroduce el problema. |
| ¿El servicio funciona técnicamente? | Hay que comprobar disponibilidad, rendimiento y dependencias. |
| ¿El servicio es seguro? | Deben corregirse vulnerabilidades y credenciales afectadas. |
| ¿Hay monitorización reforzada? | Un recurso atacado puede volver a ser atacado. |
| ¿Quién valida la normalidad? | La vuelta al servicio debe confirmarla también el área propietaria. |
Vuelta a la normalidad
Un incidente no está recuperado porque "el servidor enciende". Está recuperado cuando el servicio funciona, los datos son confiables, el riesgo está controlado y las personas responsables aceptan la vuelta a operación.
10. Fase 7: actividad post-incidente¶
La actividad post-incidente convierte el incidente en aprendizaje. Es una fase que muchas organizaciones omiten porque, cuando el servicio vuelve, parece que el problema ha terminado. En realidad, si no se documenta y no se corrigen las causas, el incidente puede repetirse.
10.1. Reunión de lecciones aprendidas¶
Tras un incidente importante conviene reunir a las personas implicadas pocos días después del cierre. El objetivo no es buscar culpables, sino entender qué pasó y mejorar el proceso.
Preguntas útiles:
- ¿Qué ocurrió exactamente y en qué línea temporal?
- ¿Cómo se detectó?
- ¿Se siguieron los procedimientos?
- ¿Qué información faltó al principio?
- ¿Qué decisiones funcionaron bien?
- ¿Qué acciones dificultaron la recuperación?
- ¿Qué controles habrían evitado o reducido el incidente?
- ¿Qué indicadores deben vigilarse en el futuro?
- ¿Qué cambios hay que hacer en el plan, los playbooks o la arquitectura?
10.2. Informe final¶
El informe final debe permitir que otra persona entienda el incidente sin haber estado presente. Debe incluir hechos, decisiones, evidencias, impacto, acciones y mejoras.
Estructura mínima de informe post-incidente
1. Resumen ejecutivo.
2. Alcance e impacto.
3. Línea temporal.
4. Vector de entrada y causa raíz, si se conoce.
5. Evidencias principales.
6. Acciones de contención.
7. Acciones de erradicación.
8. Acciones de recuperación.
9. Comunicaciones y escalados realizados.
10. Lecciones aprendidas.
11. Medidas correctivas y preventivas.
12. Responsables y fechas de seguimiento.
11. Del proceso al plan de respuesta¶
Hasta aquí hemos estudiado el proceso completo: qué fases sigue una organización desde que se prepara hasta que aprende después del incidente. Ese proceso explica la lógica de trabajo, pero en una organización real debe convertirse en un documento operativo: el plan de respuesta a incidentes.
El plan no repite todos los detalles técnicos de cada fase. Su función es dejar por escrito cómo se activa la respuesta, quién coordina, qué roles intervienen, qué canales se usan, cómo se escala una decisión, cómo se documenta la línea temporal y cuándo se considera que el servicio ha vuelto a la normalidad.
Siguiente paso
En el punto 4.1.2. Planes de respuesta a incidentes se trabaja cómo diseñar ese documento: estructura, roles, canales, severidades, gestión de evidencias, comunicación, seguimiento y revisión.
12. Del plan a los playbooks y runbooks¶
Una vez definido el plan general, la organización necesita guías más concretas para incidentes frecuentes o críticos. Ahí aparecen los playbooks y los runbooks.
| Documento | Pregunta que responde | Nivel |
|---|---|---|
| Plan de respuesta | ¿Cómo se organiza la respuesta a cualquier incidente? | Organizativo |
| Playbook | ¿Cómo actuamos ante este tipo de incidente? | Táctico |
| Runbook | ¿Qué pasos técnicos exactos ejecutamos? | Operativo |
La idea importante es evitar que el plan se convierta en un documento enorme e inmanejable. El plan marca el marco común; los playbooks concretan la respuesta ante ransomware, phishing, fuga de información, cuenta comprometida, DDoS o supply chain; y los runbooks detallan tareas repetibles como aislar un equipo, recoger logs, restaurar una copia o bloquear indicadores de compromiso.
Continuidad del tema
En el punto 4.1.3. Playbooks y runbooks de respuesta a incidentes se explica cómo diseñar estas guías sin duplicar el plan y cómo conectarlas con la práctica del repositorio de plantilla de respuesta a incidentes.
13. Organización de la capacidad de respuesta según NIST¶
NIST SP 800-61r2 no se limita a explicar fases técnicas. Antes de responder a un incidente, insiste en que la organización debe crear una capacidad formal de respuesta. Dicho de forma sencilla: no basta con tener personas técnicas muy buenas; hace falta un sistema de trabajo reconocido por la organización.
Esa capacidad debe incluir política, plan, procedimientos, equipo, recursos, relaciones internas y externas, formación y mejora continua. Si falta cualquiera de estos elementos, la respuesta dependerá demasiado de personas concretas y será difícil repetirla con calidad.
13.1. Elementos de una política de respuesta¶
La política es el documento que da autoridad al proceso. Según NIST, suele incluir estos elementos:
| Elemento de política | Traducción práctica para clase |
|---|---|
| Compromiso de dirección | La respuesta a incidentes está respaldada por la organización, no es una iniciativa aislada del equipo técnico. |
| Propósito y objetivos | Explica qué se quiere conseguir: reducir impacto, recuperar servicios, proteger evidencias y mejorar. |
| Alcance | Indica a qué sistemas, personas, sedes, servicios y terceros afecta. |
| Definición de incidente | Evita dudas sobre qué se considera incidente y qué solo es un evento. |
| Roles, responsabilidades y autoridad | Aclara quién puede aislar equipos, cortar servicios, comunicar o escalar. |
| Requisitos de comunicación | Define qué se comunica, a quién, cuándo y por qué canal. |
| Severidad y priorización | Permite decidir qué incidentes se atienden antes y con qué recursos. |
| Formularios y registros | Facilita documentar el incidente desde el primer momento. |
Idea clave
La política convierte la respuesta a incidentes en una responsabilidad organizativa. Sin política, el equipo técnico puede saber qué hacer, pero no siempre tendrá autoridad para hacerlo.
13.2. Modelos de equipo de respuesta¶
NIST describe varias formas de organizar el equipo de respuesta. No hay un único modelo válido; depende del tamaño, distribución y recursos de la organización.
| Modelo | Cuándo encaja | Riesgo principal |
|---|---|---|
| Equipo centralizado | Organizaciones pequeñas o con infraestructura concentrada. | Puede saturarse si hay muchas sedes o servicios. |
| Equipos distribuidos | Organizaciones grandes, con varias sedes o áreas técnicas. | Puede haber criterios distintos si no existe coordinación común. |
| Equipo coordinador | Organizaciones donde un equipo guía a otros equipos locales. | Puede tener poca autoridad si no está bien definido. |
| Parcialmente externalizado | Cuando se externaliza monitorización 24/7 o apoyo especializado. | El proveedor puede no conocer suficiente el contexto interno. |
| Totalmente externalizado | Cuando no hay capacidad interna suficiente. | La organización puede perder conocimiento y dependencia operativa. |
En cualquier modelo, NIST recalca que debe existir una persona responsable de la respuesta a incidentes y suplencias claras. También recomienda perfiles con conocimientos técnicos, capacidad de análisis, comunicación, trabajo en equipo y gestión del estrés.
13.3. Equipos internos que deben participar¶
Un incidente rara vez lo resuelve solo "ciberseguridad". En función del caso, pueden intervenir:
- dirección, para priorizar impacto de negocio y autorizar decisiones;
- sistemas y redes, para cambios técnicos, aislamiento, restauración y monitorización;
- seguridad de la información, para análisis, contención, evidencias y coordinación;
- legal, si hay datos personales, responsabilidades, denuncias o conservación de evidencias;
- comunicación, si hay usuarios, clientes, medios o reputación afectados;
- recursos humanos, si el incidente implica a personal interno;
- continuidad de negocio, si hay servicios críticos interrumpidos;
- proveedores, si el servicio afectado está externalizado.
Error frecuente
Tratar un incidente grave como si fuera solo una avería técnica. En cuanto hay impacto legal, reputacional, económico o de continuidad, la respuesta necesita coordinación organizativa.
13.4. Servicios que puede prestar el equipo¶
Además de responder a incidentes, NIST contempla que el equipo pueda asumir o coordinar otros servicios:
| Servicio | Utilidad |
|---|---|
| Detección de intrusiones | Revisar alertas, sensores, SIEM, EDR o IDS/IPS. |
| Distribución de avisos | Comunicar vulnerabilidades, amenazas o campañas activas. |
| Concienciación | Enseñar a usuarios y personal técnico a detectar y reportar incidentes. |
| Intercambio de información | Compartir indicadores, tendencias y aprendizajes con equipos internos o externos. |
14. Tipos de incidentes y fuentes de información¶
NIST recomienda preparar la organización para cualquier incidente, pero prestar especial atención a los vectores habituales. Esto ayuda a crear playbooks útiles y evita intentar escribir un procedimiento distinto para cada ataque posible.
14.1. Vectores de ataque comunes¶
| Vector NIST | Explicación didáctica | Ejemplo |
|---|---|---|
| Medios externos o extraíbles | Entrada desde USB, disco externo u otro dispositivo. | Malware introducido por una memoria USB. |
| Desgaste o fuerza bruta (attrition) | Ataques repetitivos para degradar, adivinar o saturar. | DDoS o fuerza bruta contra VPN. |
| Web | Ataques desde aplicaciones o sitios web. | XSS, SQL injection o explotación de un CMS vulnerable. |
| Correo electrónico | Ataques mediante mensajes, adjuntos o enlaces. | Phishing con documento malicioso. |
| Suplantación (impersonation) | Sustituir algo legítimo por algo malicioso. | Man in the middle, punto Wi-Fi falso o spoofing. |
| Uso indebido | Incumplimiento de políticas por una persona autorizada. | Uso de software no permitido o fuga por almacenamiento personal. |
| Pérdida o robo de equipo | Desaparición de portátiles, móviles, discos o tokens. | Robo de un portátil con datos sensibles. |
| Otros | Casos que no encajan en categorías anteriores. | Incidente híbrido o cadena de ataque compleja. |
14.2. Fuentes de precursores e indicadores¶
Para detectar incidentes, NIST agrupa las fuentes en alertas, logs, información pública y personas. En clase conviene entenderlo como una idea muy práctica: una alerta aislada no basta; hay que unir piezas.
| Fuente | Qué aporta |
|---|---|
| IDS/IPS | Alertas de tráfico sospechoso, ataques conocidos o patrones anómalos. |
| SIEM | Correlación de eventos de varias fuentes. |
| Antivirus, antispam y EDR | Detección de malware, comportamiento sospechoso y actividad del endpoint. |
| Integridad de ficheros | Cambios en archivos críticos mediante hashes o verificaciones. |
| Logs de sistema, servicio y aplicación | Accesos, errores, acciones de usuarios y cambios relevantes. |
| Logs de red y flujos | Conexiones, bloqueos, tendencias, NetFlow, sFlow o IPFIX. |
| Información pública | Vulnerabilidades, exploits, avisos de CERT/CSIRT, OSINT y listas de bloqueo. |
| Personas internas o externas | Usuarios, administración de sistemas, clientes, proveedores u otros equipos que reportan señales. |
15. Coordinación e intercambio de información¶
La sección 4 de NIST SP 800-61r2 se centra en coordinación e intercambio de información. Es una parte fundamental porque muchos incidentes no terminan en la frontera de la organización: pueden afectar a proveedores, clientes, organismos, otros equipos de respuesta, fuerzas y cuerpos de seguridad o fabricantes.
15.1. Relaciones de coordinación¶
| Relación | Para qué sirve | Precaución |
|---|---|---|
| Interna | Coordinar seguridad, sistemas, dirección, legal, comunicación y negocio. | No compartir datos sensibles fuera del grupo necesario. |
| Proveedores | Obtener soporte de servicios, nube, EDR, ISP, hosting o software. | Tener contratos, contactos y SLA preparados antes del incidente. |
| Otros CSIRT/CERT | Compartir indicadores, patrones y recomendaciones. | Acordar qué información se puede compartir y con qué nivel de detalle. |
| Autoridades | Denuncia, obligación legal, investigación o coordinación sectorial. | Usar canales designados y conservar evidencias correctamente. |
| Personas o entidades afectadas | Notificación a clientes, usuarios, terceros o personas afectadas. | Coordinar legal y comunicación para evitar mensajes incompletos o contradictorios. |
| Medios de comunicación | Gestionar impacto público cuando el incidente trasciende. | Designar una única voz autorizada y evitar detalles técnicos sensibles. |
15.2. Formas de compartir información¶
NIST distingue entre intercambio informal y mecanismos más formalizados o parcialmente automatizados.
- Ad hoc: llamadas, correo, mensajería o contactos personales. Es rápido, pero depende demasiado de personas concretas.
- Formalizado: acuerdos de intercambio, contactos oficiales, procedimientos de notificación y reglas sobre qué compartir.
- Parcialmente automatizado: intercambio de indicadores o datos técnicos mediante formatos y plataformas que reducen trabajo manual.
Información granular
No todo se comparte con todo el mundo. Puede haber información de impacto de negocio, información técnica, indicadores, datos personales, evidencias o detalles internos de arquitectura. Cada tipo requiere un nivel de protección distinto.
16. Datos, métricas, retención y anexos de NIST¶
Para que el documento contemple NIST SP 800-61r2 de forma completa, también hay que incluir lo que el estándar trata en sus tablas y anexos: datos mínimos, checklists, escenarios, métricas, retención y pasos de crisis.
16.1. Datos mínimos que conviene registrar¶
NIST propone campos de datos para describir incidentes y acciones de gestión. Una plantilla sencilla para clase puede recoger:
| Tipo de dato | Ejemplos |
|---|---|
| Identificación | ID del incidente, fecha de apertura, estado, persona responsable. |
| Clasificación | Tipo de incidente, vector, severidad, prioridad, sistemas afectados. |
| Detección | Fuente de alerta, indicadores, precursores, hora de detección. |
| Impacto | Impacto funcional, impacto en la información, alcance, personas afectadas. |
| Evidencias | Logs, capturas, hashes, imágenes forenses, cadena de custodia. |
| Acciones | Contención, erradicación, recuperación, comunicaciones y escalados. |
| Cierre | causa raíz, coste estimado, lecciones aprendidas, acciones correctivas. |
16.2. Métricas para mejorar la respuesta¶
NIST recomienda usar los datos recogidos para mejorar, no para generar informes sin utilidad. Algunas métricas útiles son:
- número de incidentes por categoría;
- tiempo desde inicio estimado hasta detección;
- tiempo desde detección hasta contención;
- tiempo de recuperación;
- coste estimado del incidente;
- porcentaje de incidentes repetidos;
- acciones correctivas cerradas dentro de plazo;
- diferencias entre impacto inicial estimado e impacto final.
Métrica sin contexto
Contar incidentes sin interpretar su impacto puede llevar a conclusiones equivocadas. Tener menos incidentes no siempre significa estar mejor: quizá se detecta menos. Tener más incidentes tampoco siempre significa estar peor: quizá se detecta mejor.
16.3. Retención de evidencias y registros¶
NIST dedica atención a conservar evidencias y registros. La organización debe definir durante cuánto tiempo conserva:
- tickets e informes de incidentes;
- logs relevantes;
- imágenes forenses;
- soportes físicos;
- comunicaciones;
- formularios de cadena de custodia;
- actas de lecciones aprendidas.
La decisión depende de requisitos legales, política interna, coste, sensibilidad de los datos y posibilidad de investigación futura.
16.4. Preguntas de simulacro basadas en NIST¶
NIST incluye escenarios para ejercicios de mesa. Una forma sencilla de adaptarlo a clase es usar siempre estas preguntas:
| Momento | Preguntas |
|---|---|
| Preparación | ¿Tenemos política, contactos, herramientas, backups y autoridad para actuar? |
| Detección y análisis | ¿Qué indicadores tenemos? ¿Qué más necesitamos confirmar? ¿Quién valida el incidente? |
| Priorización | ¿Cuál es el impacto funcional, el impacto en la información y el esfuerzo de recuperación? |
| Contención | ¿Qué medida reduce el daño sin destruir evidencias ni tumbar servicios innecesariamente? |
| Erradicación | ¿Qué vulnerabilidad, cuenta, malware o configuración hay que eliminar o corregir? |
| Recuperación | ¿Cómo sabemos que el servicio vuelve limpio, estable y monitorizado? |
| Post-incidente | ¿Qué hay que cambiar para que no se repita? |
16.5. Pasos de crisis¶
El anexo de gestión de crisis de NIST resume acciones que conviene tener muy claras cuando el incidente se descontrola o tiene impacto grave:
- declarar la situación y activar responsables;
- registrar hechos, tiempos y decisiones;
- contener el incidente si sigue activo;
- preservar evidencias;
- eliminar efectos del incidente;
- corregir vulnerabilidades explotadas;
- confirmar la vuelta a la normalidad;
- crear un informe final que explique lo ocurrido, la respuesta y las mejoras.
17. Caso práctico guiado: ransomware en un servidor compartido¶
Imagina que el equipo de soporte recibe varias llamadas: el alumnado y el personal no pueden abrir archivos de una carpeta compartida. Aparecen ficheros con extensiones desconocidas y una nota de rescate. El EDR alerta de actividad anómala en un equipo de administración.
17.1. Aplicación del proceso¶
| Fase | Acción razonable |
|---|---|
| Preparación | Consultar el plan, activar el equipo de respuesta y abrir ticket de incidente. |
| Detección y análisis | Confirmar si hay cifrado, identificar equipos afectados, usuario implicado, hora de inicio y recursos compartidos afectados. |
| Priorización | Clasificar como alto o crítico si afecta a servicios esenciales o datos sensibles. |
| Escalado | Avisar a responsable de seguridad, sistemas, dirección y legal si hay posible fuga o datos personales. |
| Contención | Aislar equipos afectados, bloquear cuenta sospechosa, cortar rutas de propagación y proteger backups. |
| Erradicación | Eliminar malware, revisar persistencia, parchear vulnerabilidad o corregir credenciales comprometidas. |
| Recuperación | Restaurar archivos desde backup limpio, validar integridad y monitorizar accesos. |
| Post-incidente | Documentar línea temporal, causa raíz, coste, decisiones, mejoras y responsables. |
Preguntas para clase
- ¿Qué evidencia recogeríamos antes de apagar un equipo?
- ¿Quién debería autorizar la desconexión de un servidor crítico?
- ¿Qué diferencia hay entre contener el ransomware y recuperar el servicio?
- ¿Qué medidas evitarían una repetición del incidente?
18. Checklist para revisar el proceso de respuesta¶
Antes de dar por entendido el proceso, comprueba que sabes explicar estas preguntas de principio a fin:
- cómo se prepara la organización antes de que ocurra un incidente;
- cómo se detecta y se confirma que un evento es realmente un incidente;
- cómo se estima el impacto funcional, el impacto sobre la información y la recuperabilidad;
- cuándo se escala un incidente y quién debe tomar decisiones sensibles;
- qué diferencia hay entre contener, erradicar y recuperar;
- qué evidencias deben preservarse durante la respuesta;
- cuándo puede considerarse que un servicio ha vuelto a la normalidad;
- cómo se documentan las decisiones, la línea temporal y las lecciones aprendidas;
- qué seguimiento se realiza para evitar que el incidente se repita;
- cómo se conecta este proceso con el plan de respuesta y con los playbooks.
19. Resumen¶
En este tema has aprendido que:
- la respuesta a incidentes debe prepararse antes de que ocurra el incidente;
- el ciclo de respuesta conecta preparación, detección, análisis, contención, erradicación, recuperación y aprendizaje;
- priorizar bien evita gastar recursos en lo menos importante;
- contener no es lo mismo que erradicar ni recuperar;
- un plan de respuesta debe aclarar roles, decisiones, escalado, comunicación, evidencias y cierre;
- las lecciones aprendidas solo tienen valor si terminan en acciones de mejora con seguimiento.
Idea clave
Un buen plan de respuesta a incidentes convierte una situación de presión en una secuencia de decisiones razonadas. No elimina el incidente, pero reduce el daño, acelera la recuperación y mejora la preparación de la organización para la siguiente amenaza.
20. Para seguir practicando¶
- Redacta una matriz de severidad para una organización educativa.
- Crea un playbook de phishing con pasos de contención, erradicación y recuperación.
- Diseña una reunión de lecciones aprendidas para el caso de ransomware anterior.
- Revisa un servicio crítico y define qué evidencias, contactos y backups harían falta para responder a un incidente.
Anexo: Matriz de cobertura de NIST SP 800-61r2¶
La siguiente tabla sirve como supervisión rápida de cobertura. No reproduce el documento NIST punto por punto, pero asegura que todos sus bloques están integrados en estos apuntes de forma didáctica.
| Bloque de NIST SP 800-61r2 | Dónde se trabaja en este tema |
|---|---|
| Resumen ejecutivo | Introducción, idea principal y enfoque de capacidad formal de respuesta. |
| 1. Introducción, propósito, alcance y audiencia | Introducción, RA/CE, definición de respuesta e intención docente del tema. |
| 2.1. Eventos e incidentes | Apartado 1: diferencia entre evento e incidente. |
| 2.2. Necesidad de respuesta | Apartados 1, 3 y 4: riesgo residual, ciclo de respuesta y preparación. |
| 2.3. Política, plan y procedimientos | Apartados 2, 11, 12 y 13.1. |
| 2.3.4. Comunicación con terceros | Apartados 6.2, 11.1 y 15. |
| 2.4. Estructura del equipo | Apartados 11.2, 13.2 y 13.3. |
| 2.5. Servicios del equipo | Apartado 13.4. |
| 2.6. Recomendaciones organizativas | Apartados 13, 18 y 19. |
| 3.1. Preparación | Apartado 4. |
| 3.2. Detección y análisis | Apartado 5. |
| 3.2.1. Vectores de ataque | Apartado 14.1. |
| 3.2.2 y 3.2.3. Signos, precursores, indicadores y fuentes | Apartados 5 y 14.2. |
| 3.2.4. Análisis de incidentes | Apartado 5.1. |
| 3.2.5. Documentación del incidente | Apartados 10.2 y 16.1. |
| 3.2.6. Priorización | Apartado 6. |
| 3.2.7. Notificación | Apartados 6.2, 11.1 y 15. |
| 3.3. Contención, erradicación y recuperación | Apartados 7, 8 y 9. |
| 3.3.2. Evidencias | Apartados 7.1, 10.2, 11.1 y 16.3. |
| 3.3.3. Identificación de hosts atacantes | Apartados 5.1, 7.1 y 14.2, como apoyo al análisis sin desplazar el foco de contención y recuperación. |
| 3.4. Actividad post-incidente | Apartado 10. |
| 3.4.2. Uso de datos recogidos | Apartado 16.2. |
| 3.4.3. Retención de evidencias | Apartado 16.3. |
| 3.5. Checklist de gestión | Apartados 16.4, 16.5 y 18. |
| 4. Coordinación e intercambio de información | Apartado 15. |
| Apéndice A. Escenarios | Apartados 16.4 y 17. |
| Apéndice B. Datos del incidente | Apartado 16.1. |
| Apéndices C y D. Glosario y acrónimos | Definiciones repartidas por el tema: evento, incidente, política, plan, playbook, runbook, precursor, indicador y severidad. |
| Apéndice E. Recursos | Fuentes y referencias. |
| Apéndice F. Preguntas frecuentes | Preguntas de clase y aclaraciones de los apartados 5, 10, 16 y 17. |
| Apéndice G. Pasos de crisis | Apartado 16.5. |
| Apéndice H. Registro de cambios | Nota sobre sustitución de Rev. 2 por Rev. 3 en fuentes y referencias. |
Cobertura de NIST SP 800-61r2
Con estas secciones, el tema contempla el contenido completo de NIST SP 800-61r2 a nivel docente: organización de la capacidad, política, plan, procedimientos, equipo, servicios, preparación, detección, análisis, priorización, notificación, contención, evidencias, erradicación, recuperación, actividad post-incidente, coordinación, intercambio de información, datos, métricas, retención, escenarios y pasos de crisis.
Fuentes y referencias¶
- NIST, Computer Security Incident Handling Guide, Special Publication 800-61 Revision 2, agosto de 2012. Documento usado como referencia clásica para el ciclo de respuesta a incidentes.
- NIST, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, Special Publication 800-61 Revision 3, abril de 2025.
- Normativa del Curso de Especialización en Ciberseguridad en Entornos TI, módulo de Incidentes de ciberseguridad, RA4 y criterios de evaluación asociados.
- ISO/IEC 27035, Information security incident management, como referencia complementaria para gestión de incidentes.
- INCIBE, recursos sobre respuesta a incidentes, ciberresiliencia y gestión de crisis.
Nota sobre NIST SP 800-61 Rev. 2
El PDF utilizado en estos apuntes indica que NIST SP 800-61 Rev. 2 fue retirado el 3 de abril de 2025 y sustituido por NIST SP 800-61 Rev. 3. En clase se usa Rev. 2 para entender el ciclo operativo clásico, pero conviene consultar Rev. 3 cuando se necesite una referencia actualizada.