CASO DE ESTUDIO · TECHCORP LATAM · RIESGO DE TERCEROS
Esta semana estuve analizando el riesgo que viene de afuera: los proveedores y terceros con acceso a la infraestructura de la organización, las categorías de mayor riesgo, y los controles básicos disponibles antes de tener un programa formal. Hoy quiero bajar todo eso al caso concreto que ha estado presente en esta serie como referencia: lo que ocurrió con el acceso del integrador en TechCorp Latam, cómo ese acceso se convirtió en un riesgo activo durante meses sin que nadie lo detectara, y qué cambió en la gestión de ese tipo de relación después del incidente.
EL CONTEXTO DE LA RELACIÓN
TechCorp Latam había contratado a una empresa integradora para implementar y configurar la infraestructura de red de sus dos data centers. El proyecto incluyó la configuración del perímetro WatchGuard, la segmentación de red con switching Cisco, la definición de VLANs y las reglas de firewall para los distintos segmentos de la organización. Era un proyecto técnico complejo que requirió varias semanas de trabajo, acceso profundo a la infraestructura, y el uso de credenciales de administración de alto privilegio.
Al cierre del proyecto, el integrador entregó la documentación técnica y las credenciales definitivas de los sistemas. Lo que no ocurrió fue un proceso formal de cierre del acceso remoto del integrador. La cuenta VPN del integrador permaneció activa. Las credenciales que se habían usado durante la implementación, algunas de ellas compartidas entre el equipo del integrador y el equipo interno de TI, no fueron rotadas al concluir el proyecto. El argumento implícito era que podría haber ajustes posteriores y que era conveniente mantener el acceso disponible "por si acaso."
Ese "por si acaso" duró ocho meses. En ese período no hubo ninguna sesión documentada del integrador sobre esa VPN. El acceso estaba activo y no se usaba, lo que desde cierta perspectiva podría parecer que no era un problema. Pero acceso activo y sin uso no es lo mismo que acceso seguro: es un acceso que puede usarse en cualquier momento por cualquiera que tenga las credenciales, que no estaban bajo el control exclusivo de la organización.
LO QUE ESE ACCESO REPRESENTABA
El acceso del integrador no era un acceso cualquiera. Era el acceso de alguien que conocía en profundidad la arquitectura de la red: dónde estaban los sistemas más críticos, cómo estaba segmentada la red, cuáles eran las excepciones de configuración que se habían hecho por limitaciones del proyecto, qué reglas de firewall en el WatchGuard tenían excepciones documentadas y cuáles tenían excepciones que habían quedado sin documentar por las urgencias del cierre de proyecto.
Ese conocimiento de arquitectura, combinado con acceso VPN activo y credenciales no rotadas, creaba un perfil de riesgo equivalente al de un administrador interno con privilegios elevados y conocimiento profundo del entorno. La diferencia es que ese administrador estaba fuera del control organizacional de TechCorp Latam: sus prácticas de seguridad, el estado de sus propios sistemas, quién más en su empresa conocía esas credenciales, eran factores que TechCorp Latam no podía controlar ni verificar.
Lo que hacía el riesgo particularmente difícil de detectar es que no generaba ninguna señal. El acceso VPN estaba activo pero sin uso reciente. Las credenciales eran válidas pero nadie las estaba usando. Ningún sistema de monitoreo interno hubiera levantado una alerta sobre este estado, porque desde la perspectiva del directorio y de los sistemas de autenticación todo estaba en orden.
ERROR COMÚN
Interpretar la ausencia de actividad en una cuenta como evidencia de que no representa riesgo. Una cuenta VPN de integrador sin uso durante ocho meses no es una cuenta segura: es una cuenta que todavía no ha sido usada por quien tiene las credenciales. La distinción es fundamental. El riesgo no está en lo que alguien está haciendo con ese acceso en este momento. Está en lo que podría hacer en cualquier momento futuro. Y ese riesgo no desaparece con el tiempo: crece, porque las credenciales pueden circular por más personas mientras el tiempo avanza.
LA INVESTIGACIÓN POST-INCIDENTE
Después del incidente de ransomware, durante el proceso de investigación forense, el acceso del integrador fue uno de los elementos que surgió como brecha no gestionada. No como vector de entrada confirmado del incidente, sino como una exposición que existía y que en el contexto del análisis completo de la superficie de ataque de TechCorp Latam era imposible ignorar.
Lo que la investigación no pudo determinar con certeza es si ese acceso fue usado de alguna forma durante el período en que estuvo activo sin justificación. Los logs de VPN tenían una retención de 30 días, insuficiente para cubrir los ocho meses del período relevante. Esa ausencia de evidencia no equivale a que el acceso no fue usado: equivale a que no hay forma de saberlo. Y esa incertidumbre es en sí misma una consecuencia de no haber gestionado el acceso correctamente.
¿QUÉ CAMBIÓ DESPUÉS?
La remediación incluyó la implementación completa de infraestructura Fortinet, con FortiManager para gestión centralizada y FortiAnalyzer para análisis de logs. En el contexto de ese reemplazo, el onboarding del nuevo integrador, que implementó la infraestructura Fortinet, se hizo con un protocolo diferente al que existía con el integrador anterior.
Las credenciales usadas durante la implementación fueron rotadas al cierre de cada fase del proyecto, no solo al cierre total. El acceso VPN del integrador fue configurado como just-in-time: inactivo por defecto, habilitado para sesiones específicas coordinadas con el equipo interno, y deshabilitado automáticamente al vencer la ventana. Los logs de acceso remoto pasaron a tener retención de 12 meses en FortiAnalyzer, cubriendo el período relevante para cualquier investigación futura. Y el contrato incluyó cláusulas explícitas de revocación de acceso al cierre del proyecto y de notificación de incidentes.
El protocolo cambió no porque el nuevo integrador sea menos confiable que el anterior. Cambió porque la organización entendió que la confiabilidad del integrador no es el único factor relevante: también lo es la gestión del acceso independientemente de esa confiabilidad.
DECISIÓN QUE DEBE TOMAR EL CIO
Revisar los accesos activos de integradores y proveedores de soporte que hayan completado proyectos en los últimos 18 meses. Para cada uno: ¿el acceso tiene una justificación vigente? ¿Hay alguna sesión activa reciente que indique que el acceso se sigue usando para algo? ¿Las credenciales han sido rotadas desde el cierre del proyecto? Si la respuesta a cualquiera de esas preguntas apunta a un acceso que ya no está justificado, la acción es revocar, no monitorear.
El acceso del integrador en TechCorp Latam no era un riesgo nuevo el día del incidente. Era un riesgo que llevaba ocho meses acumulándose porque nadie había definido que el cierre del proyecto implicaba el cierre del acceso. No por descuido. Por ausencia de proceso. Y esa es exactamente la diferencia que los controles básicos de ayer están diseñados para resolver.
Mañana, el cierre de la semana: cómo llevar el riesgo de terceros a la conversación ejecutiva y qué argumentos mueven esa discusión.
#RiesgoTerceros #SupplyChainSecurity #TechCorpLatam #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #WatchGuard #Cisco #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001 #CasoDeEstudio
Comentarios
Publicar un comentario