CASO DE ESTUDIO · TECHCORP LATAM · IDENTIDAD Y ACCESO
Esta semana estuve analizando la gestión de identidad y acceso como perímetro organizacional: las brechas más frecuentes, el proceso de revisión y sus fricciones. Hoy quiero bajar eso al caso concreto que da contexto a todo lo anterior: qué brechas de identidad tenía TechCorp Latam antes del incidente de ransomware, cómo contribuyeron a la capacidad del atacante de operar dentro de la red, y qué cambió en el modelo de acceso después de la remediación.
EL ESTADO DEL MODELO DE ACCESO ANTES DEL INCIDENTE
TechCorp Latam no tenía una postura de seguridad negligente en términos generales. Tenía WatchGuard cubriendo el perímetro de sus dos data centers, switching Cisco en el core y las sucursales, y algunos procesos de seguridad documentados. Lo que no tenía era un proceso activo de gestión del modelo de acceso. La política existía en papel. La administración periódica, no.
El resultado de esa ausencia, acumulado durante meses, era un conjunto de brechas de identidad que una revisión de accesos básica habría encontrado en el primer ejercicio.
La más crítica era la rotación de credenciales de administrador de dominio. La política documentaba rotación semestral. La última rotación verificada había sido 11 meses antes del incidente. En ese período, esas credenciales eran conocidas por técnicos que habían rotado de rol y por al menos una persona que ya no estaba en la organización. No había forma de saber con certeza cuántas personas tenían esas credenciales al momento del incidente, porque nunca se habían gestionado con esa granularidad.
El segundo problema era un acceso de proveedor externo activo 8 meses después del cierre del contrato. La empresa de integración que había implementado parte de la infraestructura de red tenía acceso a la consola de gestión con privilegios elevados. Ese acceso nunca fue revocado formalmente porque el cierre del contrato no generó una notificación al equipo de TI. La cuenta existía, las credenciales eran válidas, y el acceso permitía gestión remota de infraestructura crítica.
El tercero era una cuenta activa de un técnico que había salido de la organización 8 meses antes. La cuenta tenía accesos a varios sistemas internos incluyendo la red de gestión. El proceso de offboarding había incluido la devolución del equipo y la desactivación del correo corporativo, pero no la revisión y desactivación de todos los accesos de sistemas. Esa cuenta no tenía actividad reciente registrada en los logs, lo que era tranquilizador desde cierta perspectiva pero no significaba que no pudiera usarse.
El cuarto problema era privilege creep documentado pero no remediado: tres usuarios del equipo técnico tenían privilegios de administrador local en sistemas que excedían lo necesario para sus roles actuales. Esos privilegios habían sido otorgados en distintos momentos para tareas puntuales y nunca retirados. En un escenario de movimiento lateral dentro de la red, esos privilegios ampliaban significativamente la superficie de acción disponible para un atacante que ya hubiera comprometido una de esas cuentas.
¿POR QUÉ ESTAS BRECHAS IMPORTAN EN EL CONTEXTO DEL RANSOMWARE?
El ransomware que afectó a TechCorp Latam no entró por una vulnerabilidad técnica de día cero. El vector de entrada inicial involucró credenciales comprometidas. Una vez dentro, el movimiento lateral dentro de la red fue facilitado por la disponibilidad de credenciales de administrador con acceso amplio y por los privilegios elevados de cuentas que el atacante pudo comprometer progresivamente.
El perímetro tecnológico, el WatchGuard en el borde de la red, no podía detener ese movimiento porque el tráfico generado por las credenciales comprometidas era indistinguible del tráfico legítimo de administración. El firewall vio actividad autorizada de cuentas válidas con privilegios correctamente asignados. Desde su perspectiva, todo estaba en orden.
Este es el punto que más me interesa subrayar con este caso, porque es el que conecta directamente con el argumento de esta semana: la inversión en tecnología de perímetro no puede compensar un modelo de acceso mal administrado. No porque la tecnología sea insuficiente, sino porque opera sobre un supuesto que el modelo de acceso roto invalida: que las credenciales válidas corresponden a usuarios legítimos con acceso justificado.
ERROR COMÚN
Asumir que la ausencia de actividad sospechosa en los logs de una cuenta huérfana indica que es segura. Una cuenta sin actividad reciente no es una cuenta sin riesgo: es una cuenta que todavía no ha sido usada por quien la tiene. La diferencia entre las dos es imposible de determinar sin saber si las credenciales siguen siendo conocidas por personas fuera de la organización. La única forma de eliminar ese riesgo es desactivar la cuenta, no monitorear su inactividad.
¿QUÉ CAMBIÓ DESPUÉS DEL INCIDENTE?
La remediación de TechCorp Latam incluyó dos dimensiones paralelas: la renovación de infraestructura y la reconstrucción del modelo de acceso.
En infraestructura, la decisión fue reemplazar el entorno completo por Fortinet: firewalls en ambos data centers y sucursales, switching, APs y gestión centralizada con FortiManager y FortiAnalyzer. Eso resolvió también parte del problema de acceso, porque la migración obligó a reconstruir desde cero los perfiles de acceso a los sistemas de gestión, sin arrastrar la acumulación histórica del entorno anterior.
En el modelo de acceso, los cambios fueron más estructurales que tecnológicos. Se estableció una política de rotación de credenciales de administrador con cumplimiento técnico forzado, no solo documentado. Se implementó un proceso formal de offboarding que incluye la revocación verificada de todos los accesos como paso obligatorio antes del cierre del expediente de salida. Los accesos de terceros pasaron a tener fecha de vencimiento técnicamente configurada, vinculada a la vigencia del contrato. Y se definió una revisión semestral del modelo de acceso con certificación por jefatura.
Ninguno de esos cambios requería nueva tecnología. Todos requerían proceso, disciplina y respaldo organizacional. Ese respaldo llegó después del incidente porque el costo de no tenerlo se había vuelto concreto e inocultable. La pregunta que el caso deja abierta, y que he estado analizando toda la semana, es por qué ese mismo respaldo no pudo obtenerse antes.
DECISIÓN QUE DEBE TOMAR EL CIO
Hacer el diagnóstico básico antes de que un incidente lo haga urgente: cruzar el listado de cuentas activas con el listado de empleados vigentes, revisar los accesos de terceros contra los contratos activos, verificar cuándo fue la última rotación de credenciales de administrador. Ese diagnóstico, que puede completarse en días, ya muestra si la organización tiene el mismo tipo de brechas que TechCorp Latam tenía antes del incidente. La diferencia es que hacerlo ahora lo convierte en una decisión proactiva. Esperar a que el incidente lo revele lo convierte en una remediación de emergencia.
Las brechas de identidad que el ransomware encontró en TechCorp Latam no aparecieron el día del incidente. Llevaban meses ahí, visibles para quien hubiera hecho la revisión. Nadie la hizo porque no había una urgencia concreta que la justificara. Hasta que la hubo.
Mañana, el cierre de la semana: quién es responsable del modelo de acceso en la organización, y por qué esa responsabilidad suele quedar en un limbo entre TI, RRHH y las jefaturas de área.
#IdentidadYAcceso #IAM #TechCorpLatam #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #CyberLeadership #Liderazgo #Chile #ZeroTrust #ActiveDirectory #Ransomware #NISTCSF #ISO27001
Comentarios
Publicar un comentario