Caso TechCorp Latam: ¿cuando la confusión entre gobierno de datos y ciberseguridad generó brechas reales?
Esta semana hemos construido el argumento conceptual: gobierno de datos y ciberseguridad son disciplinas distintas, con preguntas distintas, y la confusión entre ellas tiene consecuencias concretas. Hoy es el momento de mostrar esas consecuencias en un caso real.
TechCorp Latam es la organización que hemos seguido a lo largo de esta serie. Ya desarrollamos el ransomware, la respuesta de crisis, las semanas de recuperación y los cambios estructurales que vinieron después. Hoy vuelvo a ese caso con una lente específica: qué brechas concretas existieron entre gobierno de datos y ciberseguridad antes del incidente, cómo contribuyeron a su impacto, y qué cambió después.
No todo lo que salió mal en esa noche fue un problema de gobierno de datos. Pero parte de lo que convirtió un incidente de ciberseguridad en una crisis de semanas sí lo fue.
El estado del gobierno de datos antes del incidente
Antes del ransomware, TechCorp Latam tenía un equipo de TI funcional con WatchGuard en el perímetro, Cisco en el switching, gestionando segmentación interna y en sucursales. La infraestructura de seguridad existía. Lo que no existía era gobierno de datos en ninguna forma reconocible.
No había clasificación formal de datos. Los servidores alojaban mezclas de información crítica, información operacional de bajo riesgo y datos históricos de uso infrecuente, todos bajo los mismos controles de acceso y el mismo nivel de protección. No había Data Owners definidos: las solicitudes de acceso llegaban a TI, que las otorgaba según quién pedía y qué sistema estaba involucrado, sin un proceso formal de validación desde el negocio. No había política de retención documentada: los datos se acumulaban indefinidamente en los servidores porque nadie había definido qué podía eliminarse ni cuándo.
La ciberseguridad, sin esos insumos, operaba en el vacío. Protegía todo con el mismo nivel de intensidad, lo que en la práctica significa que no priorizaba nada. Los controles de acceso en el FortiGate eran técnicamente correctos pero no estaban calibrados sobre una clasificación de datos que nadie había hecho. La arquitectura de backups en VEEAM existía, pero nadie había definido qué datos requerían RTO de cuatro horas y cuáles podían tolerar 48 horas de pérdida. Todo era igual de importante porque nadie había definido qué era más crítico.
Las tres brechas concretas que amplificaron el incidente
El ransomware entró. Eso es un problema de ciberseguridad. Pero lo que convirtió una intrusión en una crisis de semanas tiene raíces en la ausencia de gobierno de datos. Tres brechas concretas:
Brecha 1: sin clasificación, sin prioridad de recuperación. Cuando el equipo llegó al data center a las 4 de la mañana y empezó a desconectar cables para contener la propagación, la primera pregunta táctica era qué segmentos preservar primero. Sin una clasificación de datos que indicara qué servidores contenían los activos más críticos para la continuidad del negocio, esa decisión se tomó a juicio del equipo técnico en tiempo real, bajo presión máxima y sin información completa. El proceso de recuperación posterior tuvo el mismo problema: sin un inventario priorizado de datos por criticidad, la secuencia de recuperación fue menos eficiente de lo que habría sido con ese mapa disponible. Semanas de recuperación que con gobierno de datos habrían sido días.
Brecha 2: sin custodios, sin notificación estructurada. Cuando la organización tuvo que evaluar qué datos habían sido potencialmente comprometidos y a quién notificar, no había un inventario de Data Owners que pudiera responder rápidamente qué conjuntos de datos estaban en qué servidores y cuál era su sensibilidad. Las áreas de negocio tuvieron que ser contactadas una por una para reconstruir ese mapa en medio de la crisis. Ese proceso lento, realizado mientras la recuperación técnica avanzaba en paralelo, generó incertidumbre sobre las obligaciones de notificación y retraso en la comunicación con partes afectadas. Sin custodios definidos, la pregunta "¿de quién son estos datos?" no tenía respuesta rápida.
Brecha 3: sin política de retención, superficie de exposición acumulada. Los servidores comprometidos contenían datos de años anteriores que nadie había eliminado porque no había una política que estableciera cuándo podían o debían eliminarse. Parte de los datos comprometidos en el incidente eran datos que, bajo una política de retención correctamente implementada, habrían sido eliminados meses o años antes. La ausencia de esa política no solo generó riesgo adicional; generó también incertidumbre sobre el alcance real del compromiso, porque nadie sabía con exactitud qué había en esos servidores más allá de lo que el equipo técnico conocía por proximidad operativa.
Lo que cambió estructuralmente después del incidente
La recuperación de TechCorp Latam no fue solo técnica. Fue también estructural, y parte de esa estructura fue la creación de los elementos básicos de gobierno de datos que no habían existido antes.
El primer cambio fue la clasificación de datos. Como parte del proceso de recuperación e inventario post-incidente, se realizó por primera vez una clasificación formal de los datos de la organización, identificando cuáles eran críticos para la operación, cuáles eran sensibles desde el punto de vista normativo y cuáles podían considerarse de bajo riesgo. Ese ejercicio, que en condiciones normales habría tardado meses en aprobarse, se realizó en semanas (meses en realidad) porque el incidente había generado la urgencia y el mandato que normalmente no existen.
El segundo cambio fue la definición de custodios por área de negocio. Las gerencias funcionales asumieron formalmente la responsabilidad de los datos de su dominio: el gerente comercial para datos de clientes, el CFO para datos financieros, el gerente de operaciones para datos de producción. Esa asignación formal permitió que las políticas de acceso que la ciberseguridad implementó en la nueva infraestructura Fortinet tuvieran una base de negocio validada, no solo una decisión técnica.
El tercer cambio fue la integración de ambos dominios en el comité de ciberseguridad. El comité formal que se creó después del incidente, con el encargado de seguridad, el encargado de la red, el coordinador de continuidad operativa y el gerente de TI, incorporó como insumo regular los reportes de clasificación de datos de las áreas de negocio. No era un comité de gobierno de datos, pero sí era el primer mecanismo que conectaba las decisiones de negocio sobre los datos con las decisiones técnicas de seguridad.
Mañana cierro la semana con la conversación que el Data Officer y el CISO deberían tener, y que en pocas organizaciones de la región ocurre antes de que algo salga mal. Esa conversación, bien estructurada, es lo que evita que las brechas de esta semana se repitan en tu organización.
Mañana: el cierre de la semana con la conversación que falta
Suscríbete al newsletter Cybersecurity Insights en LinkedIn para recibir cada entrega directamente.
#GobiernoDeDatos #Ciberseguridad #TechCorpLatam #CIO #ITManager #Fortinet #Cisco #WatchGuard #pfSense #ISO27001 #NISTCSF #CasoDeEstudio #GestiónDeRiesgos #CyberLeadership #Chile
Comentarios
Publicar un comentario