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;
- se corta un servicio sin autorización;
- se pierde evidencia;
- no se avisa a quien debe decidir;
- se comunica información sensible por canales inadecuados;
- se recupera un sistema sin haber eliminado la causa;
- nadie documenta qué se hizo ni qué queda pendiente.
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;
- sistemas en la nube;
- dispositivos personales o corporativos;
- servicios externalizados;
- proveedores;
- alumnado, clientela, personal interno o usuarios externos.
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:
En la práctica:
- se recopila información inicial;
- se valora impacto funcional e impacto sobre la información;
- se decide si hay incidente;
- se activa la respuesta;
- 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;
- evitar el correo principal si puede estar comprometido;
- no usar SMS o mensajería informal para tratar detalles sensibles;
- cifrar comunicaciones con terceros cuando proceda;
- mantener un canal único de coordinación para evitar versiones contradictorias;
- definir una persona o equipo autorizado para comunicación externa.
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 documenta;
- quién falta y debe incorporarse;
- qué se sabe;
- qué impacto hay;
- qué hipótesis existen;
- qué acciones se han hecho ya;
- qué equipos deben activarse.
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:
- Investigación: qué sabemos y qué necesitamos confirmar.
- Remediación: qué acciones de contención, erradicación y recuperación se proponen.
- Comunicación: qué se comunica, a quién y con qué aprobación.
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;
- estado;
- severidad;
- impacto funcional e impacto en la información;
- línea temporal;
- sistemas afectados;
- evidencias;
- IoC de red y de host;
- cuentas afectadas;
- acciones de investigación, remediación y comunicación;
- decisiones y autorizaciones;
- responsables y siguientes pasos.
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:
- ¿Qué ocurrió?
- ¿Qué debería haber ocurrido?
- ¿Cuáles fueron las causas raíz?
- ¿Qué debemos dejar de hacer?
- ¿Qué debemos empezar a hacer?
- ¿Qué debemos mantener?
- ¿Qué acciones correctivas tienen responsable y fecha?
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:
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.