Planes de respuesta a incidentes tras NIST SP 800-61 Rev. 3: roles, prioridades, escalado y ejercicios

Casi todos los equipos de seguridad tienen un plan de respuesta a incidentes. Muchos menos tienen uno que se pueda seguir a las 3 de la mañana, con el director general al teléfono y la mitad de la información sin confirmar. La diferencia casi nunca está en la extensión del documento. Está en si el plan dice quién decide, qué cuenta como incidente, cómo se priorizan los incidentes y cuándo se escala, y en si alguien lo ha ensayado alguna vez.

En abril de 2025, NIST publicó la SP 800-61 Revisión 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management. Sustituye a la Revisión 2, la Computer Security Incident Handling Guide de 2012 en la que se basan la mayoría de los planes actuales. En este artículo vemos qué cambió y lo convertimos en una lista práctica para revisar tu propio plan.

Qué cambió: de un ciclo de cuatro fases a todo el CSF

La Revisión 2 describía un ciclo de vida en cuatro fases: preparación; detección y análisis; contención, erradicación y recuperación; y actividad posterior al incidente. La Revisión 3 lo reemplaza por un modelo basado en las seis funciones del NIST Cybersecurity Framework (CSF) 2.0: Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar. Según NIST, las seis funciones tienen un papel vital en la respuesta a incidentes.

El nuevo modelo tiene dos niveles:

• Preparación: Gobernar, Identificar y Proteger. No son la respuesta en sí, pero evitan algunos incidentes y te preparan para manejar los que ocurran.
• Respuesta: Detectar, Responder y Recuperar. Es la respuesta a incidentes en sentido estricto.

Entre ambos está la Mejora, que forma parte de Identificar. A ella llegan las lecciones aprendidas en todas las funciones, no solo en una reunión al final.

NIST también explica por qué el dibujo anterior ya no encaja. El modelo circular reflejaba una época en la que los incidentes se trataban como hechos ocasionales y la respuesta y la recuperación solían terminar en uno o dos días. Hoy la respuesta es una actividad continua, integrada en la operación diaria.

Quién hace qué

Un plan que solo nombra al SOC está incompleto. La Revisión 3 describe roles que van mucho más allá del equipo técnico:

• La dirección supervisa la respuesta, asigna el presupuesto y puede tener que tomar decisiones de alto impacto, como apagar un servicio crítico.
• El área legal revisa planes, políticas y procedimientos para asegurar que cumplen la ley aplicable, y revisa los contratos con terceros.
• Comunicación gestiona la relación con los medios y, a través de ellos, con el público. Conviene tener una estrategia de medios antes de necesitarla.
• Los terceros, como un MSSP o un proveedor cloud, comparten la responsabilidad. Lo que pueden y no pueden hacer durante un incidente debe quedar en el contrato.

Escribe los nombres, con sus suplentes. El peor momento para descubrir que nadie puede autorizar desconectar un servidor es en pleno incidente.

Qué es un incidente y qué va primero

Dos decisiones marcan toda la respuesta, y las dos deben estar en el plan antes de que pase nada.

Declarar un incidente

NIST recomienda declarar un incidente solo después de aplicar criterios de incidente definidos a lo detectado, teniendo en cuenta los falsos positivos conocidos. Sin criterios, cada alerta se convierte en un debate o, peor, nada se declara formalmente y nadie se hace cargo. Aquí es donde más duele la fatiga de alertas: cuanto más ruido llega al equipo, más tarde se declaran los incidentes reales.

Priorizar incidentes

La Revisión 3 es directa: como los recursos son limitados, los incidentes no deben atenderse por orden de llegada. Las decisiones de triaje, priorización, escalado y recuperación deben basarse en un conjunto de factores de riesgo, como:

• La criticidad de los activos afectados.
• El impacto funcional en el negocio.
• La recuperabilidad: cuánto cuesta volver a la normalidad.

Define estos factores y una escala sencilla por adelantado, para que dos analistas que miran el mismo incidente le den la misma prioridad.

Escalar no es lo mismo que elevar

NIST hace una distinción útil. Escalar suele significar aumentar los recursos o los plazos asignados a un incidente. Elevar significa involucrar a niveles más altos de la dirección. Tu plan necesita disparadores para ambas cosas: por ejemplo, un incidente en un sistema crítico para el negocio escala a más personas en la respuesta, y uno que puede requerir una comunicación pública o una notificación al regulador se eleva a la dirección y al área legal.

Pon umbrales concretos por escrito. "Escalar si es necesario" no es una regla; "escalar cuando un incidente afecta a un sistema de producción de la cadena de pagos" sí lo es.

Playbooks: el plan en pasos

El plan fija las reglas; los playbooks las convierten en pasos. NIST describe los playbooks como pasos o tareas concretas que las personas ejecutan en escenarios específicos. Empieza por los tipos de incidente que más ves: un phishing que termina en una cuenta comprometida, ransomware en un equipo, credenciales filtradas, un sistema expuesto a internet que está siendo explotado.

Un buen playbook responde, para un escenario: cómo confirmarlo, cómo contenerlo, a quién llamar, qué evidencia conservar y cuándo se da por cerrado. Debería caber en pocas páginas.

Ensáyalo: ejercicios de mesa

Un plan que nadie ha probado es una hipótesis. NIST señala que los ejercicios y pruebas de respuesta a incidentes aportan información útil para evaluar el programa, y remite a la SP 800-84 para ejercicios de mesa y simulaciones.

No hace falta crearlos desde cero. Los CISA Tabletop Exercise Packages (CTEP) incluyen escenarios de ejemplo, preguntas para el debate, plantillas de roles y una plantilla de informe posterior, con escenarios cibernéticos como ransomware, amenazas internas y phishing. Una hora alrededor de una mesa con TI, legal, comunicación y dirección suele revelar más huecos que un año revisando el documento.

Aprende durante el incidente, no solo después

La Revisión 3 recomienda compartir las lecciones aprendidas en cuanto se identifican, sin esperar a que termine la recuperación. Después, los informes de seguimiento y las reuniones de lecciones aprendidas siguen siendo la principal fuente de mejoras, y NIST recomienda un informe posterior a la acción que recoja el incidente, las acciones de respuesta y recuperación y lo aprendido.

La lección más valiosa suele ser técnica: la vulnerabilidad o la mala configuración por la que entró el atacante. Llévala directamente a la remediación, para corregir también la misma debilidad en activos similares. Lo explicamos en cerrar el ciclo entre el SOC y la gestión de vulnerabilidades.

Lista de control para tu plan

• Roles con nombre y suplente: dirección, legal, comunicación y terceros.
• Criterios escritos para declarar un incidente.
• Una escala de prioridad basada en criticidad del activo, impacto funcional y recuperabilidad.
• Disparadores de escalado y de elevación con umbrales concretos.
• Playbooks para los tipos de incidente más frecuentes.
• Planes de continuidad de negocio sincronizados con el plan de respuesta, como recomienda NIST.
• Al menos un ejercicio de mesa al año, con su informe posterior.
• Un camino de las lecciones aprendidas a la remediación.

Preguntas frecuentes

¿La Revisión 2 quedó obsoleta? NIST la sustituyó formalmente. Sus cuatro fases siguen encajando en el nuevo modelo, así que un plan existente es un punto de partida, no algo que tirar.

¿Un equipo pequeño necesita todo esto? La estructura se adapta. En un equipo pequeño una persona puede cubrir varios roles, pero las decisiones (criterios, prioridades, escalado) tienen que estar por escrito.

¿Cada cuánto hay que probarlo? NIST no fija una frecuencia; pide revisar los planes periódicamente y usar ejercicios para evaluar el programa. Pruébalo después de cambios importantes y con una frecuencia regular que puedas sostener.

Cómo ayuda priorIQ.ai

SentinelIQ añade una capa de triaje con IA sobre el SIEM o XDR que ya usas, como Microsoft Sentinel, Splunk, Elastic, QRadar o Wazuh. Enriquece y clasifica las alertas, suprime falsos positivos y muestra solo incidentes confirmados, de modo que tus criterios de declaración se aplican a señal y no a ruido. Su historial de incidentes está indexado y se puede consultar, lo que ayuda al redactar el informe posterior. Los incidentes confirmados elevan la prioridad de remediación en PriorIQ Core: si un host está bajo ataque, sus vulnerabilidades suben en la cola, y el trabajo llega como tickets a Jira, ServiceNow o Freshservice. Solicita una demo.