Muchos fallos en la respuesta a incidentes no se deben a la falta de herramientas, inteligencia o habilidades técnicas. Se deben a lo que sucede inmediatamente después de la detección, cuando la presión es alta y la información es incompleta.
He visto a equipos de IR recuperarse de intrusiones sofisticadas con telemetría limitada. También he visto a equipos perder el control de investigaciones que deberían haber podido gestionar. La diferencia suele aparecer pronto. No horas después, cuando se establecen los plazos o se redactan los informes, sino en los primeros momentos después de que un interviniente se percate de que algo anda mal.
Esos primeros momentos suelen describirse como los primeros 90 segundos. Sin embargo, si se interpreta demasiado literalmente, ese enfoque pierde el sentido. No se trata de reaccionar más rápido que un atacante ni de apresurarse a actuar. Se trata de establecer un rumbo antes de que las suposiciones se consoliden y las opciones desaparezcan.
Los intervinientes toman decisiones discretas de inmediato, como qué analizar primero, qué preservar y si tratar el problema como un problema único del sistema o como el comienzo de un patrón más amplio. Una vez tomadas esas primeras decisiones, condicionan todo lo que sigue. Comprender la importancia de esas decisiones (y acertar) requiere repensar qué representan los «primeros 90 segundos» de una investigación real.
Los primeros 90 segundos son un patrón, no un momento.
Uno de los errores más comunes que veo es tratar la fase inicial de una investigación como un evento único y dramático. Se activa la alerta, se pone en marcha el reloj y los intervinientes lo gestionan bien o no. Así no es como se desarrollan los incidentes reales.
Los “primeros 90 segundos” ocurren cada vez que cambia el alcance de una intrusión.
Se le notifica sobre un sistema que se cree que está involucrado en una intrusión. Accede a él. Decide qué es importante, qué preservar y qué podría revelar este sistema sobre el resto del entorno. Esa misma ventana de decisión se abre de nuevo al identificar un segundo sistema y luego un tercero. Cada vez reinicia el reloj.
Aquí es donde los equipos suelen sentirse abrumados. Observan el tamaño de su entorno y asumen que se enfrentan a cientos o miles de máquinas a la vez. En realidad, se enfrentan a un conjunto mucho menor de sistemas a la vez. El alcance crece gradualmente. Una máquina lleva a otra, luego a otra, hasta que empieza a surgir un patrón.
Quienes responden con eficacia no reinventan su enfoque cada vez que esto sucede. Aplican la misma disciplina inicial cada vez que intervienen en un nuevo sistema. ¿Qué se ejecutó aquí? ¿Cuándo se ejecutó? ¿Qué sucedió a su alrededor? ¿Quién o qué interactuó con él? Esa consistencia es lo que permite ampliar el alcance sin perder el control.
Por eso también es tan importante tomar decisiones tempranas. Si los equipos de respuesta tratan el primer sistema afectado como un problema aislado y se apresuran a solucionarlo, cierran un ticket en lugar de investigar una intrusión. Si no preservan los artefactos correctos a tiempo, pasan el resto de la investigación adivinando. Estos errores pueden agravarse a medida que se amplía el alcance.
Cómo se obstaculizan las investigaciones.
Cuando las investigaciones tempranas fallan, es tentador culpar a la capacitación, la indecisión o la mala comunicación. Estos problemas aparecen, pero suelen ser síntomas, no causas fundamentales. El fallo más recurrente es que los equipos no comprenden bien su propio entorno cuando comienza el incidente.
Los equipos de respuesta se ven obligados a responder preguntas básicas bajo presión. ¿Dónde salen los datos de la red? ¿Qué registros existen en los sistemas críticos? ¿Hasta dónde se remontan los datos? ¿Se conservaron o se sobrescribieron? Estas preguntas ya deberían tener respuestas. Cuando no las tienen, los equipos de respuesta terminan conociendo los componentes críticos de su entorno cuando ya es demasiado tarde.
Por eso es tan perjudicial el registro que se inicia tras una detección. La visibilidad hacia adelante sin contexto retrospectivo limita lo que se puede probar. Aún se pueden reconstruir partes del ataque, pero cualquier conclusión se debilita. Las lagunas se convierten en suposiciones, y las suposiciones en errores.
Otro fallo común es la priorización de la evidencia. Al principio, todo parece importante, por lo que los equipos saltan de un artefacto a otro sin un punto de referencia claro. Esto genera actividad sin progreso. En la mayoría de las investigaciones, la manera más rápida de recuperar la claridad es centrarse en la evidencia de ejecución . Nada significativo ocurre en un sistema sin algo en ejecución. El malware se ejecuta. PowerShell se ejecuta. Las herramientas nativas se abusan. Vivir de la tierra aún deja rastros. Si comprendes qué se ejecutó y cuándo, puedes empezar a comprender la intención, el acceso y el movimiento.
A partir de ahí, el contexto importa. Esto podría significar a qué sistema se accedió en ese momento, quién se conectó al sistema o adónde se dirigió la actividad a continuación. Estas respuestas no existen de forma aislada. Forman una cadena, y esa cadena apunta hacia el entorno.
El fracaso final es el cierre prematuro. Para ahorrar tiempo, los equipos suelen reinstalar un sistema, restaurar los servicios y seguir adelante. Sin embargo, las investigaciones incompletas pueden dejar rastros de acceso pequeños e inadvertidos. Implantes secundarios. Credenciales alternativas. Persistencia discreta. Un indicador sutil de vulnerabilidad no siempre se reactiva de inmediato, lo que crea la ilusión de éxito. Si resurge, el incidente parece nuevo cuando, en realidad, no lo es. Es el mismo que nunca se solucionó por completo.
Fuente y redacción: thehackernews.com
