TÉCNICO-GERENCIAL · RESPUESTA A INCIDENTES · PROCESO
Hay algo que me resulta llamativo cuando reviso cómo las organizaciones medianas documentan su respuesta a incidentes. La mayoría tiene algo escrito: un procedimiento de tres páginas, un diagrama de flujo en una presentación de PowerPoint, un párrafo en la política de seguridad que dice que en caso de incidente se debe notificar al área de TI. Y cuando ocurre un incidente real, ese documento no se usa. No porque el equipo sea negligente, sino porque la diferencia entre un proceso documentado y un proceso operacional es exactamente la diferencia que nadie trabajó.
Un proceso documentado dice qué debería ocurrir. Un proceso operacional dice quién hace qué, con qué herramienta, en qué tiempo, con qué criterio para tomar cada decisión, y a quién notifica antes de ejecutar. Esa diferencia es la que determina si una organización responde al incidente o reacciona al caos que el incidente produce.
¿POR QUÉ EL PROCESO FALLA ANTES DE EMPEZAR?: EL PROBLEMA DE LOS ROLES
El primer lugar donde el proceso de respuesta falla en organizaciones medianas no es en la fase de contención ni en el análisis forense. Falla en la fase cero: quién recibe la alerta y qué hace en los primeros 15 minutos. En equipos pequeños donde las personas tienen múltiples responsabilidades, la alerta de seguridad llega a la misma persona que está en una reunión, o resolviendo un problema de impresora, o de vacaciones. Si no hay claridad sobre quién es el primero en responder y quién es el segundo cuando el primero no está disponible, los primeros minutos del incidente se pierden en coordinar quién se encarga en lugar de empezar a contener.
La solución no es compleja pero requiere una decisión explícita: para cada tipo de alerta, hay un responsable primario y un sustituto. Esos nombres están en el runbook con su número de teléfono directo, no solo su correo corporativo que pueden no revisar fuera de horario. Y ambas personas saben que son el responsable primario y el sustituto respectivamente, porque lo discutieron y lo practicaron, no porque lo leyeron en un documento que alguien subió a la intranet.
FASE 1 Y 2: DETECCIÓN Y TRIAJE — LAS DECISIONES QUE NADIE DEFINIÓ
Cuando llega una alerta, la primera pregunta es si es real o un falso positivo. Esa pregunta parece simple pero en la práctica es la que consume más tiempo en equipos sin experiencia previa en respuesta a incidentes, porque no hay criterios definidos para responderla rápidamente. El técnico mira la alerta, no sabe con certeza si es una amenaza real o un comportamiento inusual pero legítimo, y empieza a investigar sin un marco que le diga qué buscar primero y cuánto tiempo dedicarle antes de escalar.
El runbook tiene que incluir criterios de triaje que respondan esa pregunta: qué combinación de indicadores confirma que una alerta merece respuesta inmediata versus investigación diferida versus cierre como falso positivo. Por ejemplo, una alerta de autenticaciones fallidas masivas que proviene de una IP externa desconocida y que coincide con un intento de autenticación exitoso posterior en la misma cuenta requiere respuesta inmediata. La misma alerta que proviene de una IP interna conocida durante una migración programada probablemente es un falso positivo que se cierra con nota.
El criterio de severidad también tiene que estar definido antes del incidente, no durante. Una escala simple de tres niveles: crítico (operación afectada o datos potencialmente comprometidos, respuesta en minutos), alto (comportamiento anómalo confirmado sin impacto visible aún, respuesta en horas), medio (anomalía que requiere investigación no urgente, respuesta en el día). Cada nivel tiene un protocolo de notificación distinto y tiempos objetivo distintos. Sin esa escala predefinida, cada incidente genera una discusión sobre qué tan grave es en lugar de ejecutar el protocolo que corresponde.
FASE 3: CONTENCIÓN — EL ERROR QUE DESTRUYE LA EVIDENCIA
La contención es la fase donde el instinto lleva a cometer el error más frecuente y más costoso en la respuesta a incidentes: apagar el equipo comprometido. El instinto es comprensible, la máquina está haciendo algo malo, la solución obvia es apagarla. El problema es que apagar el equipo destruye la memoria volátil donde puede estar la evidencia más valiosa para entender qué ocurrió: el proceso malicioso que estaba corriendo, las conexiones de red activas, las credenciales que el atacante estaba usando en ese momento.
La contención correcta aísla el equipo de la red, lo que detiene la propagación y la comunicación con el comando y control del atacante, sin apagarlo. En entornos con Fortinet, eso puede hacerse desde FortiManager bloqueando el segmento de red o la IP específica sin tocar físicamente el equipo. En entornos con segmentación por VLANs en switching Cisco, puede hacerse reasignando el puerto del equipo comprometido a una VLAN de cuarentena configurada previamente.
Esa capacidad de cuarentena técnica tiene que estar preparada antes del incidente. No es algo que se configura durante la crisis. El runbook incluye el procedimiento exacto para aislar un equipo en cada tipo de segmento de red de la organización, con los comandos o los pasos en la interfaz de gestión, para que quien ejecuta la contención no tenga que investigar cómo se hace mientras el atacante sigue activo.
La contención también requiere una decisión de autorización. ¿Puede el técnico de guardia aislar un servidor de producción por su cuenta o necesita autorización de su jefe? ¿Puede aislar una workstation de un área de negocio sin consultar al gerente del área? Esas decisiones tienen que estar tomadas de antemano porque durante el incidente no hay tiempo de buscar autorizaciones y el retraso tiene un costo directo en el alcance del daño.
ERROR COMÚN
Apagar el equipo comprometido como primera acción de contención. Es el error más frecuente y el más costoso para la investigación posterior. La memoria volátil del equipo contiene información que no existe en ningún otro lugar: el proceso malicioso activo, las conexiones de red en curso, las credenciales en uso. Apagar el equipo destruye esa evidencia de forma irreversible. La contención correcta aísla de la red sin apagar. Si no existe un procedimiento de cuarentena técnica preparado, el runbook tiene que incluir explícitamente "no apagar el equipo" como primera instrucción de la fase de contención.
FASE 4: ANÁLISIS — LO QUE LOS LOGS DICEN Y LO QUE NO
El análisis post-contención tiene el objetivo de entender el alcance real del incidente: cuándo entró el atacante, qué sistemas tocó, qué credenciales usó, qué datos pudo haber accedido o exfiltrado. Esa reconstrucción se hace sobre los logs disponibles, y la calidad del análisis depende directamente de la calidad y retención de esos logs.
Aquí aparece una limitación que muchas organizaciones descubren durante el incidente y no antes: la retención de logs es insuficiente para cubrir el período relevante. Si el atacante estuvo activo durante 15 días y los logs de autenticación se retienen solo 7, los primeros 8 días del compromiso son un punto ciego que no puede reconstruirse. TechCorp Latam tuvo exactamente ese problema: la retención de logs de VPN era de 30 días, insuficiente para el período de acceso del integrador que analizamos la semana pasada.
El análisis también requiere una metodología básica de reconstrucción cronológica. El objetivo es construir un timeline de los eventos: primera actividad anómala detectada en los logs, movimientos subsiguientes, sistemas afectados en orden cronológico, última actividad del atacante antes de la contención. Ese timeline es el insumo para determinar el alcance real del compromiso y es lo que permite responder la pregunta más urgente desde el punto de vista de datos: ¿qué información pudo haber sido accedida o exfiltrada?
FASE 5: CIERRE Y APRENDIZAJE — LA FASE QUE SIEMPRE SE OMITE
Una vez remediado el incidente, la presión organizacional es volver a la normalidad lo más rápido posible. Los sistemas están funcionando de nuevo, el equipo está agotado, hay trabajo acumulado. El post-mortem queda para después, y después frecuentemente nunca llega.
El cierre formal del incidente no es burocracia: es la única oportunidad de convertir el costo del incidente en valor para la organización. El post-mortem no busca culpables. Busca responder cuatro preguntas: ¿qué pasó exactamente y cuál fue el impacto real?, ¿qué funcionó bien en la respuesta?, ¿qué falló o tardó más de lo que debería?, ¿qué cambia en el proceso, en las herramientas o en la configuración para que el mismo vector no produzca el mismo resultado la próxima vez?
Esas respuestas se documentan en un informe breve que llega a la gerencia. No un informe técnico de 40 páginas, sino una síntesis ejecutiva de una o dos páginas que responde qué pasó, qué impacto tuvo, qué se hizo para resolverlo, y qué inversión o cambio de proceso se requiere para reducir la probabilidad de recurrencia. Ese informe es también el argumento más poderoso que TI puede tener para conseguir el presupuesto o el respaldo que el incidente demostró ser necesario.
DECISIÓN QUE DEBE TOMAR EL CIO
Revisar si el proceso de respuesta actual tiene estas cuatro condiciones: roles nombrados con sustitutos para cada fase, criterios predefinidos de severidad y triaje, procedimiento de cuarentena técnica preparado en FortiGate y switching Cisco antes del incidente, y retención de logs suficiente para cubrir el período de detección tardía probable. Si alguna de esas cuatro condiciones falta, el proceso existe en teoría pero no está listo para usarse cuando importa.
El proceso de respuesta que no se practica no existe. Existe el documento que lo describe. La diferencia entre los dos se hace evidente en los primeros quince minutos de un incidente real, cuando nadie sabe con certeza quién está a cargo, qué se hace primero, y si el paso siguiente requiere autorización o no. Mañana: el caso TechCorp Latam, cómo se respondió al ransomware y qué habrían necesitado tener listo antes para que esa respuesta fuera diferente.
#RespuestaIncidentes #IncidentResponse #DetecciónDeIncidentes #Fortinet #FortiAnalyzer #Cisco #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001
Comentarios
Publicar un comentario