saltar al contenido
volver al mapa
concepto
etapa: prepare
2 min de lectura

El ciclo de vida de la respuesta a incidentes

El momento de un incidente no es para inventar un proceso. Los equipos que responden bien definieron roles, niveles de severidad y canales de comunicación mucho antes de que algo fallara.

NIST SP 800-61PagerDuty / OpsgenieSlack or Teams incident channelticketing and case managementTheHiverunbooks in version control

Las fases

La guía de manejo de incidentes del NIST describe un ciclo que la mayoría de los programas adopta de alguna forma. Tómalo como un bucle, no como una línea: lo que aprendes alimenta la preparación.

  • Preparación: política, turnos de guardia, herramientas y accesos listos, logging que responda preguntas, playbooks practicados, listas de contactos (legal, comunicaciones, proveedores, reguladores).
  • Detección y análisis: reconocer que algo anda mal, decidir si es un incidente, acotar su alcance y asignar una severidad.
  • Contención: evitar que se propague o empeore, con la menor interrupción que funcione, preservando la evidencia.
  • Erradicación y recuperación: eliminar el acceso del atacante y la causa, restaurar los sistemas desde un estado confiable y vigilar de cerca mientras vuelven a operar.
  • Actividad posincidente: una , lecciones aprendidas y cambios en detección, controles y playbooks.

Roles y comunicación

  • : es responsable de la respuesta, toma las decisiones y no hace el trabajo técnico.
  • Líderes técnicos: investigan y contienen, uno por frente de trabajo (endpoint, identidad, nube, red).
  • Comunicaciones: actualizaciones internas con un calendario fijo y mensajes externos a clientes, socios y reguladores, aprobados por legal.
  • Escriba: lleva una línea de tiempo, con marcas de tiempo en UTC, de lo que se vio y se hizo y quién lo hizo.
  • Usa un canal como fuente de verdad y un canal fuera de banda por si el principal está comprometido.

Severidad y un registro

Acuerda los niveles de severidad con antelación para que nadie discuta sobre ellos durante el evento, y abre un registro en el momento en que declares el incidente.

incident-record.ymlyaml
id: INC-2026-0142
declared_at: 2026-10-13T14:05:00Z      # siempre en UTC
severity: SEV2                          # SEV1 datos de clientes o caída del núcleo; SEV2 contenido pero grave; SEV3 menor
commander: a.silva
summary: Inicios de sesión sospechosos en la consola de administración desde un país nuevo
scope:
  affected: [identity-provider, admin-console]
  data_at_risk: none confirmed
timeline:
  - { at: 2026-10-13T13:52:00Z, event: "Alert fired: impossible travel", by: detection }
  - { at: 2026-10-13T14:05:00Z, event: "Incident declared", by: a.silva }
next_update: 2026-10-13T15:00:00Z

Principios que valen en todo incidente

  • Preserva la evidencia antes de cambiar cosas: haz snapshots, copia los logs, registra lo que hiciste.
  • Contén de forma proporcional: apagar producción a veces es lo correcto y muchas veces es una reacción exagerada.
  • Asume que el atacante está mirando: no anuncies el plan en el canal que podría estar leyendo.
  • Decide con información incompleta y actualiza a medida que llegan los hechos.
  • Anótalo sobre la marcha; la memoria bajo estrés no es confiable.
  • Practica con ejercicios de mesa para que la primera vez no sea la real.
Postmortemrevisión sin culpablesUna revisión escrita de un incidente que pregunta cómo lo permitió el sistema, no quién se equivocó, y termina con acciones que tienen responsable.ver en el glosario →Comandante del incidenteICLa persona que es responsable de la respuesta y toma las decisiones, mientras otros hacen el trabajo técnico. Mantener estos roles separados evita que el líder desaparezca en los detalles técnicos.ver en el glosario →

conexiones en el mapa

actualizado el 14/10/2026 · fuentes para profundizar · reportar un error

en otros dominios

Desbloquea

pon a prueba lo que entendiste

Cargando preguntas…