4.1.2.-Planes de respuesta

4.1.2. Planes de respuesta a incidentes

Idea principal

Un plan de respuesta a incidentes convierte el proceso general de respuesta en una forma de trabajo concreta para una organización: quién decide, quién ejecuta, cómo se comunica, cómo se documenta y cómo se recupera el servicio.

En el punto anterior hemos visto el proceso completo de respuesta a incidentes: preparación, detección, análisis, contención, erradicación, recuperación y actividad post-incidente. Ese proceso explica la lógica de la respuesta. Ahora necesitamos convertirlo en un documento operativo que pueda usarse en una organización real.

Ese documento es el plan de respuesta a incidentes. Su función no es repetir la teoría del ciclo de respuesta, sino dejar preparada la forma de actuar antes de que llegue la crisis.

Definición

Un plan de respuesta a incidentes es un documento aprobado por la organización que define cómo se organiza, coordina, ejecuta, comunica, documenta y mejora la respuesta ante incidentes de ciberseguridad.

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.

Qué deberías saber al terminar

Al acabar este tema deberías poder:

• explicar para qué sirve un plan de respuesta;
• distinguir plan, política, procedimiento, playbook y runbook;
• diseñar la estructura mínima de un plan;
• definir roles, canales, severidades y escalado;
• relacionar el plan con los playbooks y con una práctica de implantación.

1. Por qué hace falta un plan

En un incidente real hay presión, información incompleta y decisiones con impacto sobre servicios, datos, personas y reputación. Si cada equipo actúa por su cuenta, pueden aparecer problemas graves:

• se toman decisiones contradictorias: un equipo decide apagar un sistema, otro decide mantenerlo encendido para analizarlo;
• se corta un servicio sin autorización: un equipo decide cortar el acceso a una aplicación, pero no se avisa a los usuarios ni a los responsables de negocio;
• se pierde evidencia: un equipo borra un sistema para eliminar el malware, pero no se guarda una copia para análisis forense;
• no se avisa a quien debe decidir: un equipo detecta un incidente grave, pero no lo comunica a la dirección ni a los responsables de seguridad;
• se comunica información sensible por canales inadecuados: un equipo comparte detalles del incidente por email sin cifrar, exponiendo información a terceros.
• se recupera un sistema sin haber eliminado la causa: un equipo restaura un servidor afectado sin haber erradicado el malware, lo que provoca una nueva infección.
• nadie documenta qué se hizo ni qué queda pendiente: un equipo actúa sobre un incidente, pero no deja registro de las acciones tomadas ni de las decisiones pendientes, dificultando el seguimiento y la mejora.

El plan evita esa improvisación. No elimina la complejidad del incidente, pero reduce dudas y crea una referencia común para todo el equipo.

Relación con el punto anterior

El documento 4.1.1 Proceso completo de respuesta a incidentes explica el ciclo y los criterios de actuación. Este punto explica cómo convertir ese ciclo en un plan concreto para una organización.

2. Qué debe y qué no debe contener

Un buen plan debe ser conciso, directivo, específico y flexible. Esta idea aparece en la plantilla práctica del repositorio incident-response-plan-plantilla: no se busca un documento enorme, sino un plan que pueda usarse durante una crisis.

Debe contener	No debería convertirse en
Roles y autoridad de decisión.	Un tratado teórico sobre respuesta a incidentes.
Canales y contactos.	Una lista desactualizada que nadie revisa.
Criterios de severidad y escalado.	Un documento ambiguo que no permite decidir.
Flujo de trabajo durante el incidente.	Un texto genérico que no se adapta a la organización.
Plantillas de registro e informe.	Un repositorio desordenado de capturas y notas.
Referencias a playbooks.	Una colección de procedimientos técnicos mezclados sin estructura.

Error frecuente

Un plan de respuesta no es útil por estar escrito, sino por estar aprobado, probado, actualizado y conocido por las personas que deben usarlo.

3. Estructura recomendada de un plan

La estructura siguiente adapta NIST SP 800-61r2 y la plantilla práctica del repositorio de referencia a un formato manejable para clase.

3.1. Portada y control del documento

Debe indicar:

• nombre de la organización;
• autoría o equipo responsable;
• número de revisión;
• fecha de publicación;
• fecha de última revisión;
• fecha de última prueba o simulacro;
• ubicación del documento oficial.

Plan de respuesta a incidentes de [ORGANIZACIÓN]
Autoría: [nombre/equipo]
Revisión: [número]
Publicado: [fecha]
Última revisión: [fecha]
Última prueba: [fecha]

3.2. Propósito y alcance

El propósito explica por qué existe el plan. El alcance indica a quién y a qué aplica.

Ejemplo

Este plan define cómo responder a incidentes que afecten a sistemas, servicios, redes, aplicaciones, datos, identidades, proveedores y usuarios de la organización.

Debe quedar claro si incluye:

• sedes físicas: oficinas, centros de datos, tiendas, etc.;
• sistemas en la nube: servicios SaaS, IaaS, PaaS, etc.;
• dispositivos personales o corporativos: laptops, móviles, IoT, etc.;
• servicios externalizados: proveedores, partners, etc.;
• proveedores: servicios de seguridad, consultoría, etc.;
• alumnado, clientela, personal interno o usuarios externos: empleados, estudiantes, clientes, etc.

3.3. Criterios para declarar incidente

El plan debe ayudar a decidir si una situación es un incidente o debe tratarse por soporte ordinario.

La plantilla práctica usa una lógica muy útil basada en NIST:

Observar -> Orientar -> Decidir -> Actuar -> Revisar

En la práctica:

1. se recopila información inicial;
2. se valora impacto funcional e impacto sobre la información;
3. se decide si hay incidente;
4. se activa la respuesta;
5. se revisa y ajusta el alcance.

Pregunta	Si la respuesta es sí...
¿Afecta a la misión, servicio u operación?	Puede existir impacto funcional.
¿Afecta a confidencialidad, integridad o disponibilidad de datos?	Puede existir impacto sobre la información.
¿Puede propagarse o empeorar?	Conviene activar respuesta cuanto antes.
¿Hay dudas razonables?	Es preferible iniciar respuesta y ajustar después.

4. Roles y responsabilidades

El plan debe definir roles antes del incidente. La plantilla práctica propone una estructura inspirada en gestión de incidentes:

Rol	Función principal
Incident Commander	Dirige la respuesta, toma decisiones y coordina equipos.
Deputy Incident Commander	Apoya al mando y puede sustituirlo si es necesario.
Scribe	Registra línea temporal, decisiones, acciones y evidencias.
Subject Matter Expert	Aporta conocimiento experto de sistemas, negocio o tecnología afectada.
Liaison	Coordina comunicación con partes internas o externas.

Mando durante el incidente

Durante un incidente grave, el Incident Commander tiene autoridad operativa sobre la respuesta, aunque no sea la persona de mayor rango jerárquico en la organización. Su función es coordinar, no ejecutar todas las tareas técnicas.

5. Canales de comunicación

El plan debe indicar canales principales y alternativos. Esto es importante porque un incidente puede afectar al correo corporativo, al directorio de identidades o a herramientas habituales.

Recomendaciones:

• priorizar llamada, chat seguro y repositorio seguro de ficheros: son más resistentes que el correo;
• evitar el correo principal si puede estar comprometido: usar un canal alternativo para comunicaciones críticas;
• no usar SMS o mensajería informal para tratar detalles sensibles: pueden ser interceptados o no archivados adecuadamente;
• cifrar comunicaciones con terceros cuando proceda: proveedores, clientes, medios, etc.
• mantener un canal único de coordinación para evitar versiones contradictorias: un chat o una sala de incidentes donde se centralice la información.
• definir una persona o equipo autorizado para comunicación externa: prensa, clientes, reguladores, etc.

6. Ritmo de trabajo durante el incidente

La plantilla práctica introduce el concepto de battle rhythm, que podemos traducir como ritmo de coordinación durante la respuesta. Consiste en mantener llamadas, actualizaciones y decisiones con una cadencia clara.

6.1. Llamada inicial

La llamada inicial debe responder a estas preguntas:

• quién asume el mando: quién es el Incident Commander y quién le apoya;
• quién documenta: quién es el Scribe y dónde se registra la información;
• quién falta y debe incorporarse: expertos, liaisons, etc.;
• qué se sabe: qué ha pasado, qué sistemas o servicios están afectados, qué impacto se observa;
• qué impacto hay: funcional, sobre la información, reputacional, legal, etc.;
• qué hipótesis existen: qué se cree que ha pasado, qué escenarios se barajan, etc.;
• qué acciones se han hecho ya: qué se ha intentado, qué resultados se han obtenido, etc.;
• qué equipos deben activarse: qué grupos técnicos, de negocio o externos deben involucrarse;

6.2. Actualizaciones periódicas

En incidentes relevantes no basta con una llamada inicial. Deben programarse actualizaciones periódicas con tres líneas de trabajo:

1. Investigación: qué sabemos y qué necesitamos confirmar. Qué hipótesis se están validando o descartando. Qué evidencias se han recopilado.
2. Remediación: qué acciones de contención, erradicación y recuperación se proponen.
3. Comunicación: qué se comunica, a quién y con qué aprobación. Qué información se comparte con clientes, proveedores, reguladores, medios, etc.

7. Expediente del incidente

Todo incidente debe tener un expediente o espacio seguro de trabajo. Puede ser un ticket, carpeta protegida, sistema de gestión de incidentes o repositorio seguro.

Debe recoger:

• nombre o código del incidente: algo que lo identifique de forma única y fácil de recordar;
• estado: abierto, en investigación, en remediación, cerrado, etc.;
• severidad: crítica, alta, media, baja, etc.;
• impacto funcional e impacto en la información: qué servicios o sistemas se han visto afectados y qué datos se han comprometido;
• línea temporal: qué ha pasado, cuándo y qué acciones se han tomado;
• sistemas afectados: qué sistemas, aplicaciones, redes o dispositivos se han visto afectados;
• evidencias: qué logs, capturas, muestras o datos se han recopilado para investigar el incidente;
• IoC de red y de host: qué indicadores de compromiso se han identificado, como IPs, dominios, hashes, etc.;
• cuentas afectadas: qué identidades o usuarios se han visto comprometidos o involucrados;
• acciones de investigación, remediación y comunicación: qué se ha hecho, qué se propone hacer y qué se ha comunicado;
• decisiones y autorizaciones: qué decisiones se han tomado, quién las ha aprobado y qué criterios se han seguido.
• responsables y siguientes pasos: quién es responsable de cada acción y qué se debe hacer a continuación.

Consejo práctico

Si no se documenta durante el incidente, después será mucho más difícil reconstruir qué ocurrió, justificar decisiones y aprender de la respuesta.

8. Relación entre plan y playbooks

El plan define la forma general de actuar. Los playbooks desarrollan respuestas concretas por tipo de incidente.

Documento	Pregunta que responde
Plan de respuesta	¿Cómo se organiza la respuesta en esta organización?
Playbook	¿Qué hacemos ante este tipo concreto de incidente?
Runbook	¿Qué pasos técnicos exactos ejecutamos para una tarea concreta?

Ejemplos de playbooks recomendables:

• phishing;
• ransomware;
• compromiso de identidad y acceso;
• defacement web;
• compromiso de proveedor o cadena de suministro;
• pérdida o robo de dispositivo;
• fuga de información.

9. Revisión posterior y mejora continua

Un plan no termina cuando el servicio vuelve. Debe incluir una revisión posterior al incidente, también llamada AAR (After Action Review), hotwash, debrief o post-mortem.

Preguntas mínimas:

1. ¿Qué ocurrió?: descripción objetiva de los hechos, sin juicios ni opiniones.
2. ¿Qué debería haber ocurrido?: descripción de lo que se esperaba que ocurriera, según el plan o las mejores prácticas.
3. ¿Cuáles fueron las causas raíz?: análisis de las causas técnicas, organizativas o humanas que originaron el incidente.
4. ¿Qué debemos dejar de hacer?: prácticas, procedimientos o comportamientos que no aportan valor o incluso perjudican la respuesta.
5. ¿Qué debemos empezar a hacer?: prácticas, procedimientos o comportamientos que podrían mejorar la
6. ¿Qué debemos mantener?: prácticas, procedimientos o comportamientos que funcionan bien y deben seguirse.
7. ¿Qué acciones correctivas tienen responsable y fecha?: asignar responsables y plazos para implementar las mejoras identificadas.

Idea clave

Un plan de respuesta maduro no busca culpables. Busca hechos, causas, decisiones mejorables y acciones concretas para reducir la probabilidad o impacto de incidentes futuros.

10. Práctica relacionada: plantilla de plan de respuesta

Para trabajar este punto de forma práctica se usará el repositorio:

• incident-response-plan-plantilla

Ese repositorio permite crear un plan de respuesta realista a partir de piezas Markdown:

Archivo o carpeta	Uso didáctico
README.md	Explica cómo descargar, adaptar, construir y usar la plantilla.
info.yml	Centraliza los datos de la organización mediante variables.
during.md	Contiene el núcleo operativo del plan durante el incidente.
roles/	Define roles como Incident Commander, Deputy, Scribe, SME y Liaison.
playbooks/	Incluye playbooks por tipo de incidente.
after.md	Guía la revisión posterior al incidente.
examples/plan.md	Muestra un ejemplo de plan generado.

Actividad sugerida

Adaptad info.yml, revisad during.md, asignad roles mínimos y justificad qué playbooks necesita vuestra organización según sus riesgos principales.

11. Checklist de calidad del plan

Antes de dar por válido un plan, comprueba que:

• tiene propósito y alcance claros;
• define cuándo se declara un incidente;
• asigna roles y autoridad de decisión;
• incluye contactos y canales alternativos;
• establece severidades y escalado;
• explica cómo abrir el expediente del incidente;
• separa investigación, remediación y comunicación;
• enlaza playbooks concretos;
• define cómo se documentan evidencias;
• incluye recuperación y vuelta a la normalidad;
• obliga a realizar revisión posterior;
• tiene responsables para acciones de mejora;
• se revisa y prueba periódicamente.

12. Resumen

En este tema has aprendido que:

• el plan convierte el proceso de respuesta en una forma de trabajo concreta;
• debe ser usable durante una crisis, no solo correcto sobre el papel;
• los roles, canales, severidad y documentación deben estar definidos antes del incidente;
• el plan se apoya en playbooks y runbooks para incidentes concretos;
• la práctica del repositorio permite construir un plan realista y adaptable.

Fuentes y referencias

• NIST, Computer Security Incident Handling Guide, Special Publication 800-61 Revision 2.
• NIST, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, Special Publication 800-61 Revision 3.
• Counteractive Security, Incident Response Plan Template.
• IES Rafael Alberti, incident-response-plan-plantilla.

Presentación

Slides

Este documento no tiene todavía una presentación Reveal.js asociada.