¿Qué es la respuesta a incidencias?

¿Qué es la respuesta a incidencias?

La respuesta a incidencias (incident response) es la forma organizada en que un equipo gestiona una incidencia: un suceso imprevisto que interrumpe un servicio o amenaza la seguridad, como una caída, una fuga de datos o una cuenta comprometida. Abarca detectar el problema, calcular su alcance, limitar el daño, restaurar el servicio y aprender de ello para que ocurra menos.

Hay dos variantes. Las incidencias operativas (caídas, respuestas lentas, un despliegue defectuoso) buscan restaurar el servicio cuanto antes. Las de seguridad (una intrusión, malware, credenciales robadas) añaden la custodia de pruebas y obligaciones legales. Comparten la misma estructura, por eso un solo proceso puede cubrir ambas.

El ciclo de respuesta a incidencias: no hay un número único de fases

No existe un número universal de fases. El modelo clásico de NIST SP 800-61 Revisión 2 (2012) tiene cuatro: preparación, detección y análisis, contención, erradicación y recuperación, y actividad posterior al incidente. En abril de 2025 NIST sustituyó esa revisión por SP 800-61 Revisión 3, que organiza la respuesta en torno a las seis funciones del NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) y reinyecta las lecciones aprendidas en todas ellas. También indica que cada organización debe usar el modelo de ciclo que mejor le encaje. Las cuatro fases clásicas siguen siendo un vocabulario útil:

1. Preparación. Se hace antes de que algo falle: turnos de guardia, vías de escalado, guías operativas (runbooks), roles, plantillas de mensajes, simulacros.
2. Detección y análisis. Salta una alerta o un cliente avisa. Alguien lo confirma, valora la gravedad y a quién afecta, y declara la incidencia.
3. Contención, erradicación y recuperación. Primero se frena el daño (revertir, desactivar una función, conmutar por error, revocar credenciales); después se elimina la causa y se recupera el servicio.
4. Revisión posterior. Se reconstruye la cronología, se buscan las causas que contribuyeron, se acuerdan acciones y se cumplen. Sin buscar culpables, o la gente deja de avisar de lo que sale mal.

Roles

Incluso un equipo de dos personas gana al decidir quién hace qué; una persona puede asumir varios roles:

• Comandante de la incidencia (incident commander): dirige la respuesta y toma las decisiones. Coordina en lugar de arreglar.
• Técnicos de respuesta: investigan y aplican la solución según las indicaciones del comandante.
• Responsable de comunicación: mantiene informados a clientes y compañeros. Véase comunicación de incidencias.
• Secretario o escriba: anota la cronología mientras ocurre, lo que facilita mucho la revisión.

Un ejemplo

Es un ejemplo inventado. A las 14:05 dos ubicaciones de monitorización informan de que POST /checkout devuelve errores 500. El técnico de guardia lo confirma, declara una incidencia grave (los niveles de gravedad y sus nombres los define cada equipo) y nombra un comandante. El responsable de comunicación publica "Investigando" en la página de estado. Un técnico relaciona los errores con el despliegue de las 13:50 y el comandante decide revertir en lugar de depurar en directo. Los errores cesan, el equipo vigila la tasa de errores un rato y da la incidencia por resuelta. La revisión posterior descubre que el despliegue se saltó una comprobación en preproducción; la lista de acciones añade esa comprobación y una alerta más rápida.

Errores comunes

• Sin un responsable único. Varias personas cambiando cosas a la vez se pisan el trabajo. Nombre siempre un comandante.
• Investigar antes de contener. Suele ser mejor frenar el daño con una solución provisional y buscar la causa después con calma. En un incidente de seguridad, conserve las pruebas mientras contiene.
• Alertas ruidosas. Si se ignoran los avisos, una incidencia real se pierde entre ellos. Véase fatiga de alertas.
• Silencio hacia fuera. Los clientes notan la caída antes que su aviso. Mantenga la página de estado en una infraestructura que sobreviva a la incidencia.
• Una revisión sin seguimiento. Un postmortem cuyas acciones nunca se ejecutan solo registra por adelantado la próxima incidencia.
• Leer la guía operativa por primera vez durante la incidencia. Ensaye con ejercicios de mesa (tabletop) o game days.

Incidentes de seguridad y plazos legales

Los incidentes de seguridad pueden activar plazos legales. Según el artículo 33 del RGPD, el responsable del tratamiento debe notificar a la autoridad de control una violación de la seguridad de los datos personales sin dilación indebida y, de ser posible, en un plazo de 72 horas desde que tuvo constancia, salvo que sea improbable que suponga un riesgo para los derechos y las libertades de las personas físicas. Sepa de antemano quién lo decide.

Relación con las pruebas y la monitorización

La respuesta empieza por la detección, y esta depende de la observabilidad: métricas, registros y comprobaciones que le avisan de que algo falla antes que los clientes. También forma parte de la ingeniería de fiabilidad, donde las revisiones sin culpa y los objetivos de nivel de servicio deciden qué se corrige después. LoadFocus no es una plataforma de respuesta a incidencias y no gestiona sus guardias ni su proceso. Aporta dos entradas:

• La monitorización de API ejecuta comprobaciones programadas (cada 5 minutos en el plan gratuito) desde varias de sus 25 regiones, verifica código de estado, cuerpo, cabeceras y tiempo de respuesta, y avisa por correo, Slack, Microsoft Teams o webhook, y en los planes de pago también por PagerDuty y Opsgenie. Exigir varios fallos seguidos o varias ubicaciones con error reduce los falsos avisos.
• Las páginas de estado llevan la parte pública: las actualizaciones pasan de investigando a identificado, en observación y resuelto, y luego puede publicarse un postmortem. En la página de estado es donde los clientes miran primero.

Las pruebas de carga pertenecen a la preparación: las pruebas de carga muestran dónde se rompe un sistema con volumen antes de que lo descubra el tráfico real. Para hábitos que mantienen útiles las alertas, consulte la guía de buenas prácticas de monitorización.

Preguntas frecuentes: respuesta a incidencias

¿Cuántas fases tiene la respuesta a incidencias?

Depende del modelo. NIST SP 800-61 Revisión 2 usaba cuatro fases. La Revisión 3 (abril de 2025) vincula la respuesta a las seis funciones del Cybersecurity Framework 2.0 y recomienda usar el ciclo que mejor encaje con cada organización. Lo importante es cubrir preparación, detección, contención con recuperación y aprendizaje, como quiera llamarlos.

¿Quién debería ser el comandante de la incidencia?

Alguien formado para el rol, no necesariamente la persona más veterana. La tarea es coordinar y decidir, no arreglar. Muchos equipos mantienen un grupo rotativo de comandantes para que el rol no dependa de una sola persona.

¿Qué diferencia hay entre incidencia y problema?

En el vocabulario de ITIL, una incidencia es una interrupción imprevista concreta y un problema es la causa subyacente de una o varias incidencias. Un mismo problema, como un pool de conexiones agotado, puede provocar varias incidencias con el tiempo.

¿Deberían ser públicos los postmortems?

Es una decisión de criterio. Muchos equipos publican un resumen público más corto para las incidencias graves visibles para el cliente y mantienen internamente el análisis detallado. Elija lo que elija, cuente qué pasó, qué va a cambiar y para cuándo.

¿Cómo se practica la respuesta a incidencias?

Recorra un escenario en un ejercicio de mesa, organice un game day inyectando un fallo real en un entorno seguro y deje que los nuevos técnicos de guardia observen una respuesta antes de dirigir una.