Un incidente rara vez empieza con certeza. Puede surgir como una alerta, un reporte de usuario, un comportamiento fuera de lo habitual o una falla operativa. El desafío inicial es tomar decisiones útiles sin borrar el contexto que permitirá entender lo ocurrido.
Este artículo organiza los primeros pasos, desde el triaje hasta la contención, y explica por qué el orden de las acciones importa tanto como las propias acciones.
Primero: evento, evento adverso e incidente
Tres palabras que parecen sinónimas y no lo son. El NIST las distingue con precisión, y la distinción evita tratar el ruido como una crisis:
- Evento: cualquier suceso observable en un sistema. Un intento de inicio de sesión es un evento.
- Evento adverso: un evento con una consecuencia negativa, sea cual sea su causa, incluso un corte eléctrico o un error operativo.
- Incidente: un suceso que compromete efectivamente o de forma inminente la integridad, la confidencialidad o la disponibilidad de una información o sistema, o que infringe las políticas de seguridad.
La consecuencia práctica: una alerta es un evento hasta que el análisis la eleva a incidente. Declarar un incidente demasiado pronto moviliza personas sin necesidad; declararlo demasiado tarde cuesta tiempo de contención. El triaje existe precisamente para tomar esa decisión basándose en evidencias.
El modelo cambió: del ciclo de cuatro fases a las seis funciones
Quien estudió respuesta a incidentes probablemente aprendió el ciclo de cuatro fases de la revisión anterior del NIST: preparación → detección y análisis → contención, erradicación y recuperación → actividad posterior al incidente.
La revisión 3 del SP 800-61, publicada en abril de 2025, abandonó ese modelo. El documento explica el motivo: cuando se creó el ciclo, los incidentes eran relativamente raros, de alcance limitado y se resolvían en uno o dos días, por lo que resultaba realista tratar la respuesta como un conjunto separado de actividades a cargo de un equipo separado. Hoy los incidentes son frecuentes, la recuperación tarda semanas o meses y las lecciones aprendidas deben circular en cuanto aparecen, no después de terminar la recuperación.
El modelo actual organiza la respuesta según las seis Funciones del CSF 2.0:
| Función | Papel en la respuesta |
|---|---|
| Govern | Define funciones, políticas y criterios de decisión antes del incidente |
| Identify | Conoce los activos, los riesgos y lo que es crítico |
| Protect | Reduce la probabilidad y el impacto de los incidentes |
| Detect | Descubre actividad adversa |
| Respond | Contiene, erradica, comunica y gestiona |
| Recover | Restaura y valida la vuelta a la operación |
Gobernar, Identificar y Proteger son continuas e involucran a toda la organización; Detectar, Responder y Recuperar entran en acción durante el incidente. El cambio de fondo es conceptual: la respuesta a incidentes dejó de ser un proceso aislado y pasó a formar parte de la gestión del riesgo, integrada en las operaciones.
En la práctica, lo que sigue continúa siendo válido en cualquier modelo. Si tu organización utiliza el ciclo de cuatro fases, no está equivocado: el propio NIST indica que cada organización debe utilizar el modelo que mejor le sirva.
Primero, registra lo que sabes
Anota la hora con zona horaria, el origen de la alerta, el activo involucrado, las personas avisadas y las acciones ya tomadas. Conserva los identificadores relevantes: cuenta, host, dirección de origen, sesión y eventos relacionados. Esta línea de tiempo evita que la investigación dependa de la memoria o de mensajes dispersos en un chat.
Un registro útil separa tres columnas:
| Hora (UTC) | Observación | Clasificación |
|---|---|---|
| 14:02 | Inicio de sesión de j.silva desde un ASN poco habitual | Hecho |
| 14:03 | MFA aprobado al primer intento | Hecho |
| 14:05 | Cuenta posiblemente comprometida | Hipótesis |
| 14:07 | Verificar si se registró un método MFA nuevo | Siguiente prueba |
«La cuenta puede estar comprometida» es diferente de «la cuenta fue utilizada por un tercero». Separar hecho, interpretación y siguiente prueba mejora la comunicación con quien decide sobre el riesgo y evita que una hipótesis se convierta en conclusión por repetición.
Define el impacto y la urgencia
Pregunta qué sistemas y datos podrían estar involucrados, si hay actividad en curso y cuál sería el efecto de esperar. La prioridad no debe depender del volumen de la alerta: un suceso raro en un sistema crítico puede exigir actuar antes que una secuencia ruidosa en un entorno de bajo riesgo.
Criterios que sustentan la decisión:
- criticidad del activo: qué se detiene si deja de funcionar;
- privilegio de la cuenta: qué alcanza además de a sí misma;
- exposición de datos: naturaleza y volumen;
- persistencia: ¿hay indicios de acceso mantenido?
- propagación: ¿puede alcanzar otros sistemas?
Si estos criterios no existen en la organización, registra la carencia para mejorar después el proceso y decide con lo que tienes, documentando el razonamiento.
Contén sin destruir la investigación
A veces es necesario revocar una sesión, deshabilitar una cuenta, aislar una máquina o bloquear un indicador. La acción debe reducir el riesgo inmediato y ser proporcional a la confianza en la evidencia.
El orden importa. En un host sospechoso, recopilar antes de apagar conserva lo que solo existe en memoria:
- Aísla la red antes de intervenir en el host: interrumpe el acceso sin borrar el estado.
- Preserva la memoria volátil, si hay capacidad para hacerlo, antes de cualquier reinicio.
- Recopila los registros que sustentan la decisión, incluidos los que podrían rotar pronto.
- Después ejecuta la contención más invasiva.
Apagar una máquina borra los procesos en ejecución, las conexiones abiertas y, con frecuencia, la evidencia que explicaría cómo ocurrió el acceso. Reiniciar «para limpiar» es la forma más común de destruir la investigación con buena intención.
Evita las acciones amplias por reflejo. Cuando el riesgo exija una contención rápida y no haya tiempo para recopilar, documenta quién decidió, por qué y qué se dejó de recopilar: esa anotación vale más de lo que parece en la revisión posterior.
Coordina la comunicación y la recuperación
Define quién informa a las partes involucradas, con qué frecuencia y por qué canal. Si se sospecha un compromiso del entorno corporativo, considera un canal externo a él: discutir la respuesta en un sistema que el atacante puede estar leyendo es un error costoso.
Una comunicación clara no exige detalles técnicos innecesarios. Un formato que funciona: impacto actual · acción en curso · decisión pendiente · próxima hora de actualización. El último punto reduce la mayor fuente de ruido en un incidente: las personas que preguntan si hay novedades.
Después de la contención, trata la causa que permitió el incidente y confirma que la recuperación funciona. Una corrección solo está completa cuando es posible verificar que el comportamiento no se repite y que los controles de detección siguen siendo útiles.
Cierra el ciclo
Elabora una revisión breve: línea de tiempo, impacto, evidencias, decisiones, mejoras y responsables. El objetivo no es señalar culpables; es hacer a la organización más capaz de reconocer y responder a la siguiente señal relevante.
Dos preguntas que aportan más que un informe largo:
- ¿Qué nos hizo darnos cuenta? Si fue un usuario y no la detección, existe una carencia de telemetría que corregir.
- ¿Qué nos retrasó? Falta de acceso, de contacto, de registros o de criterio: cada una tiene una corrección diferente.
Según el modelo actual, estas lecciones deben compartirse en cuanto aparecen, en lugar de guardarlas para un informe final semanas después.
Siguiente paso
No necesitas un incidente para practicarlo. Elige una alerta reciente de tu entorno, incluso un falso positivo, y escribe para ella la línea de tiempo de tres columnas. El ejercicio revela en minutos qué campos de registro faltan, a quién no sabías avisar y qué criterio de prioridad no está por escrito.
En situaciones reales, deben prevalecer los procedimientos de la organización, las obligaciones legales y los responsables designados. Esta guía sirve para prepararse y razonar, no para sustituir un plan de respuesta aprobado. Practica únicamente en entornos propios o con autorización explícita.
