Cuando se habla de respuesta a incidentes, es fácil imaginar la parte más visible: una alerta crítica, un equipo aislado, una cuenta comprometida, una investigación en curso o una llamada urgente.
Pero buena parte de la calidad de esa respuesta se decide antes de que ocurra el incidente.
Se decide cuando la organización define quién puede actuar, cómo se reporta, dónde se registra, qué escenarios requieren escalamiento, cómo se preserva evidencia y qué debe probarse antes de depender del proceso en una situación real.
Por eso no veo la preparación como una fase administrativa separada de la respuesta. La veo como parte de la propia capacidad de responder.
Bajo presión se descubre lo que realmente estaba definido
En condiciones normales muchas ambigüedades parecen tolerables.
Durante un incidente dejan de serlo.
Preguntas aparentemente simples pueden consumir tiempo valioso:
- ¿esto es un evento o un incidente?;
- ¿qué severidad tiene?;
- ¿quién lidera?;
- ¿quién puede aislar un equipo o revocar una sesión?;
- ¿cuándo debe involucrarse privacidad o cumplimiento?;
- ¿quién informa a dirección?;
- ¿qué se puede comunicar a un tercero?;
- ¿dónde queda la evidencia?;
- ¿quién decide que el incidente puede cerrarse?
La preparación existe para que esas decisiones no empiecen desde cero.
Prepararse no significa intentar predecir todos los incidentes
Ninguna organización puede escribir un procedimiento específico para cada situación posible.
El objetivo debería ser construir una estructura que funcione incluso cuando el escenario no coincida perfectamente con algo previsto.
Esa estructura necesita algunos elementos estables:
Roles y autoridad
No basta con decir quién participa. Hay que entender quién decide qué.
Una respuesta puede involucrar seguridad, tecnología, dirección, privacidad, legal, comunicaciones o proveedores. La coordinación mejora cuando la autoridad y las rutas de escalamiento están pensadas antes de necesitarlas.
Criterios de clasificación y escalamiento
La severidad no debería depender únicamente de la impresión del analista que recibe la alerta.
Impacto potencial, alcance, datos involucrados, activos afectados, posibilidad de propagación, privilegios comprometidos y afectación a procesos críticos pueden modificar la prioridad de respuesta.
Un sistema de registro
La respuesta necesita una fuente común de verdad.
Registrar desde el inicio ayuda a conservar hechos, decisiones, responsables, tiempos y evidencia mientras la investigación evoluciona.
Escenarios operativos
Los playbooks permiten preparar preguntas y acciones para situaciones frecuentes sin pretender que todos los incidentes serán iguales.
Comunicaciones
Definir quién puede comunicar evita que una situación técnica se convierta también en un problema de información contradictoria o no autorizada.
La evidencia también requiere preparación
Muchas evidencias son fáciles de perder.
Un mensaje puede ser borrado. Una sesión puede ser revocada antes de guardar información útil. Un log puede rotar. Una persona puede ejecutar una acción y olvidarse de documentarla.
Por eso la preservación no debería depender únicamente de recordar “tomar capturas”.
Conviene diseñar qué tipos de evidencia pueden ser relevantes y cómo se integran en la línea de tiempo:
- correos y encabezados;
- registros de autenticación;
- alertas de seguridad;
- eventos del endpoint;
- cambios de configuración;
- evidencias de contención;
- decisiones y aprobaciones;
- comunicaciones realizadas.
La evidencia técnica y la evidencia de decisión se complementan. Ambas ayudan a explicar lo ocurrido.
Los simulacros convierten supuestos en aprendizaje
Un plan puede parecer consistente hasta que intentamos ejecutarlo.
Un ejercicio de mesa permite introducir información gradualmente y observar cómo responde el equipo.
Por ejemplo, un escenario puede comenzar como un correo sospechoso y evolucionar:
- el usuario reporta el mensaje;
- se confirma que hizo clic;
- aparece la posibilidad de credenciales entregadas;
- surge actividad de inicio de sesión inusual;
- se descubre que la cuenta tenía acceso a información sensible.
El valor del ejercicio no está en “ganarle” al escenario.
Está en observar:
- cuánto tarda el equipo en registrar;
- si la severidad cambia correctamente;
- si se activa el playbook adecuado;
- si la evidencia se preserva;
- si las decisiones tienen responsables claros;
- si privacidad o cumplimiento entran cuando corresponde;
- si el cierre deja acciones concretas de mejora.
Una buena métrica debe cambiar una decisión
Medir incidentes solo para llenar un reporte aporta poco.
Las métricas son más útiles cuando permiten identificar dónde la capacidad necesita mejorar.
Algunas preguntas que me parecen valiosas son:
- ¿cuánto tardamos en registrar un evento relevante?;
- ¿cuánto tardamos en contener?;
- ¿qué tipos de incidentes se repiten?;
- ¿qué áreas o activos aparecen con mayor frecuencia?;
- ¿qué acciones correctivas siguen abiertas?;
- ¿qué controles fallaron o no aportaron suficiente visibilidad?;
- ¿qué cambió después de las lecciones aprendidas?
La métrica no es el resultado. Es una señal para decidir dónde fortalecer el proceso.
La recuperación también debe entrar en el diseño
Responder no termina en contener al atacante.
Cuando un servicio, cuenta, equipo o información necesita recuperarse, el proceso debe conectar con continuidad y recuperación.
Eso obliga a pensar antes del incidente en:
- respaldos;
- pruebas de restauración;
- dependencias críticas;
- alternativas operativas;
- prioridades de recuperación;
- criterios para devolver un activo a operación.
Una organización no es más resiliente porque tenga backups. Lo es cuando puede recuperar lo que necesita dentro de condiciones aceptables y con suficiente confianza en el resultado.
La preparación reduce decisiones improvisadas, no elimina el criterio
Preparar la respuesta no significa automatizar cada decisión ni convertir a las personas en ejecutores de un procedimiento.
Significa construir un marco que permita usar mejor el criterio cuando realmente hace falta.
Cuando roles, canales, evidencia, escalamiento y escenarios están definidos, el equipo puede concentrarse en lo difícil: entender qué está pasando, evaluar impacto y decidir cómo reducirlo.
Por eso la respuesta a incidentes empieza antes del incidente.
Empieza cuando decidimos cómo queremos actuar cuando todavía no sabemos exactamente qué va a ocurrir.
Trabajo relacionado
Diseño de un modelo operativo para gestionar incidentes de ciberseguridad