Ayer definimos el gobierno de datos, sus cuatro pilares y el límite donde termina su responsabilidad. Hoy viene la segunda parte: dónde empieza concretamente la ciberseguridad y, sobre todo, qué pasa en la práctica cuando nadie ha definido ese límite con claridad.
La respuesta corta a dónde empieza la ciberseguridad es conocida: en la tríada CIA, Confidencialidad, Integridad y Disponibilidad. Pero esa respuesta, por sí sola, es tan abstracta como inútil para una organización que necesita saber qué hace concretamente el equipo de ciberseguridad con los datos que el gobierno de datos le entrega como insumo.
Hoy lo desarrollo en términos operativos: qué responsabilidades concretas asume la ciberseguridad, cómo se articulan con el stack Fortinet, Cisco, pfSense, WatchGuard y Ubiquiti, y qué brechas específicas aparecen cuando el límite entre los dos dominios queda sin definir.
Las tres responsabilidades concretas de la ciberseguridad sobre los datos
La ciberseguridad opera sobre los datos que el gobierno de datos ha clasificado, catalogado y asignado a custodios. Su trabajo no empieza preguntando qué datos existen ni quién los posee; esas respuestas las recibe del gobierno de datos. Su trabajo empieza donde las decisiones de negocio sobre los datos necesitan traducirse a controles técnicos que las hagan reales.
Confidencialidad: implementar quién puede acceder y en qué condiciones. El gobierno de datos define que los datos de clientes son confidenciales y que solo el equipo comercial debería acceder. La ciberseguridad implementa esa decisión: configura las reglas de acceso en el FortiGate, establece los perfiles de usuario con privilegios mínimos, habilita MFA en los accesos a sistemas que contienen datos sensibles, segmenta la red en pfSense para que otros segmentos no puedan acceder aunque lo intenten, y monitorea en FortiAnalyzer los accesos anómalos que sugieran que alguien está accediendo a datos que no debería. Sin la clasificación previa del gobierno de datos, ninguna de esas acciones tiene una base sobre la que calibrarse.
Integridad: garantizar que los datos no son alterados sin autorización. El gobierno de datos define que ciertos datos, como los registros financieros o los contratos, no pueden modificarse sin aprobación explícita del custodio. La ciberseguridad implementa los controles que garantizan esa inmutabilidad: logs de auditoría en FortiAnalyzer que registran cada modificación con fecha, usuario y origen; políticas de control de versiones en los sistemas que alojan esos datos; controles de integridad que detectan modificaciones no autorizadas. En entornos donde Cisco gestiona el switching de core, la implementación de políticas de acceso a nivel de red añade una capa adicional de control sobre qué sistemas pueden modificar datos en qué servidores.
Disponibilidad: garantizar que los sistemas y datos estén accesibles cuando se necesitan. El gobierno de datos define el RTO (Recovery Time Objective) y el RPO (Recovery Point Objective) para cada conjunto de datos críticos, es decir, cuánto tiempo puede la organización operar sin esos datos y hasta qué punto en el tiempo puede recuperarlos. La ciberseguridad implementa los mecanismos que hacen posible cumplir esos objetivos: arquitectura de backups aislados e inmutables, redundancia en la infraestructura de red con Fortinet y Cisco, planes de respuesta a incidentes que incluyan procedimientos de recuperación verificados. Sin el RTO y RPO definidos por el gobierno de datos, el equipo de ciberseguridad diseña su arquitectura de disponibilidad sin saber qué nivel de pérdida de datos y tiempo de recuperación es aceptable para el negocio.
¿Qué pasa cuando nadie define el límite?
La zona gris entre gobierno de datos y ciberseguridad es donde ocurren las brechas más costosas. No porque nadie esté trabajando, sino porque cada dominio asume que el otro está cubriendo lo que en realidad nadie está cubriendo.
Brecha 1: datos críticos sin clasificar que la ciberseguridad no prioriza. Si el gobierno de datos no ha clasificado los datos, el equipo de ciberseguridad no sabe qué activos son más valiosos para el negocio. Aplica controles uniformes sobre todos los datos, lo que en la práctica significa que los datos de mayor criticidad no necesariamente reciben el mayor nivel de protección. En el caso del ransomware de TechCorp Latam, la ausencia de clasificación formal significó que el equipo técnico a las 4 de la mañana no tenía una lista priorizada de qué servidores recuperar primero. Esa ausencia alargó el tiempo de recuperación y aumentó el costo del incidente.
Brecha 2: políticas de acceso que nadie autorizó formalmente. Cuando no hay un Data Owner definido, las solicitudes de acceso a datos las aprueba quien puede técnicamente otorgar ese acceso, generalmente el administrador de sistemas o el equipo de TI. Eso produce dos problemas: accesos otorgados sin la validación de negocio de que ese acceso es necesario y apropiado, y ausencia de un responsable formal de negocio que pueda revocar ese acceso cuando cambian las circunstancias. El principio de mínimo privilegio que CIS Controls exige en el Control 6 no puede aplicarse correctamente si nadie ha definido cuál es el privilegio mínimo necesario para cada función, y esa definición es una decisión de negocio, no técnica.
Brecha 3: incidentes de seguridad que se convierten en crisis de cumplimiento normativo. Cuando ocurre un incidente de seguridad que involucra datos personales, las obligaciones legales de notificación (a reguladores, a personas afectadas, a socios comerciales) dependen de saber exactamente qué datos fueron comprometidos, de quién eran y qué sensibilidad tenían. Esa información proviene del gobierno de datos. Si el gobierno de datos no existe o es incompleto, el equipo legal y de cumplimiento enfrenta un incidente de ciberseguridad sin el mapa de datos necesario para gestionar las obligaciones normativas correspondientes. El incidente técnico se transforma en una crisis de gobernanza con plazos legales que corren.
¿Cómo se ve el límite bien definido en la práctica?
Cuando el límite entre gobierno de datos y ciberseguridad está bien definido, la colaboración entre los dos dominios tiene una estructura clara. El Data Owner de cada conjunto de datos críticos participa en la definición de las políticas de acceso junto con el equipo de ciberseguridad, no como destinatario de una decisión ya tomada sino como parte del proceso de decisión. El resultado es una política de acceso que es técnicamente implementable y que refleja las necesidades reales del negocio.
La clasificación de datos del gobierno de datos alimenta directamente las prioridades de CIS Controls: los controles del IG1 y del IG2 que se aplican primero son los que protegen los datos clasificados como críticos y confidenciales. La arquitectura de backups que diseña la ciberseguridad respeta los RTO y RPO definidos por el gobierno de datos para cada conjunto de datos. Los logs de auditoría que mantiene FortiAnalyzer cubren los accesos a los sistemas que alojan datos clasificados como sensibles, no todos los sistemas de forma indiscriminada.
En TechCorp Latam, después del incidente, ese modelo se implementó con el comité de ciberseguridad actuando como punto de integración entre ambos dominios: el encargado de seguridad, el encargado de la red, el coordinador de continuidad operativa y el gerente de TI revisaban conjuntamente las políticas de protección de datos en función de la clasificación que las áreas de negocio habían definido. No era una estructura perfecta, pero era infinitamente mejor que la ausencia total de coordinación que precedió al ransomware.
Mañana: el caso de TechCorp Latam, cómo la confusión entre gobierno de datos y ciberseguridad contribuyó al incidente y qué cambió estructuralmente después. El viernes cierro la semana con la conversación que el Data Officer y el CISO deberían tener pero que en pocas organizaciones ocurre.
Esta semana: gobierno de datos vs. ciberseguridad
Suscríbete al newsletter Cybersecurity Insights en LinkedIn para recibir cada entrega directamente.
#Ciberseguridad #GobiernoDeDatos #DataGovernance #CIO #ITManager #Fortinet #Cisco #WatchGuard #pfSense #ISO27001 #NISTCSF #CIATriad #GestiónDeRiesgos #CyberLeadership #Chile
Un marco de gobernanza es necesario pero no suficiente. Reduce riesgos de forma estructurada, pero debe complementarse con:
ResponderBorrar**Controles técnicos proactivos, monitoreo continuo con IA/análisis de comportamiento real, cultura organizacional, cómo adaptación constante a nuevas amenazas y no todos cumplen.
Por Ejemplo: Todos confian en (Zero Trust con gobernanza integrada). Muchas organizaciones aún confían por defecto. Pero recuerda Siempre Asumir “nunca confíes, siempre verifica” + gobernanza de acceso. JAMAS CONFIES QUE TODO ESTA BIEN. .