Ir al contenido principal

La reunión de seguridad en la nube que termina hablando de dinero

La reunión de seguridad en la nube que termina hablando de dinero

La reunión de seguridad en la nube que termina hablando de dinero

Llevo quince años sentado en reuniones donde alguien plantea un problema de seguridad y, veinte minutos después, esa misma reunión terminó hablando de presupuesto. No es casualidad. Es un patrón, y esta semana lo desarmé pieza por pieza: los contratos que nadie lee, los accesos que nadie revoca, los datos que nadie sabe dónde están, la resiliencia que nadie prueba. Hoy quiero cerrar con la conversación que las contiene a todas, porque ahí es donde se decide si la nube fue una decisión de seguridad o una decisión de costo disfrazada de estrategia.

Voy a ser directo: en la mayoría de las organizaciones que he visto en Chile y en la región, esa conversación la gana el costo. Y la gana no porque el CFO tenga razón técnica, sino porque llega a la mesa con un lenguaje que el directorio entiende de inmediato: números. El CISO, en cambio, llega con probabilidades, con escenarios, con "qué pasaría si". Contra una hoja de cálculo, un escenario pierde casi siempre.

La misma reunión, dos lecturas distintas Lo que plantea el CISO • Exposición de datos críticos • Dependencia del proveedor • Continuidad sin probar Lo que escucha el directorio • Cuánto cuesta reducirlo • Cuánto cuesta el proveedor • Cuánto cuesta probarlo La decisión que queda Se aprueba el presupuesto más bajo El riesgo queda documentado, no mitigado

Esta semana usé el caso de TechCorp Latam para mostrar cómo se ve esto puertas adentro. Después del ransomware, la migración a Azure de los sistemas críticos se hizo bajo presión operacional, no bajo una estrategia de nube pensada con calma. Y ahí surgió una figura que quiero destacar hoy: el subgerente que diseñó esa solución en plena crisis. Fue quien entendió los sistemas, quien tomó las decisiones técnicas bajo presión, quien sostuvo la migración con lo que había disponible en ese momento.

Meses después, cuando la urgencia bajó y llegó la revisión de costos, la empresa trajo a un IT Manager nuevo con un mandato claro: reducir gasto en la nube. Servicios innecesarios, sí, eso correspondía. Pero con el tiempo, la conversación técnica que había sostenido al subgerente durante la crisis desapareció de las reuniones. Las promesas de reconocimiento y de un rol más senior se fueron postergando. El subgerente terminó renunciando, y con él se fue el conocimiento operativo más fino de esa arquitectura, el que no está en ningún documento porque se construyó en tiempo real, resolviendo problemas que nadie había anticipado.

Esto es lo que casi nunca se mide cuando la conversación de nube se reduce a costos: el costo de perder a la persona que entiende por qué la arquitectura quedó como quedó. Se puede optimizar una factura de Azure en una tarde. Reconstruir ese conocimiento tácito toma meses, y muchas veces se reconstruye a costa de errores que ya se habían evitado una vez.

¿Cómo se cambia esta conversación entonces? No creo que la solución sea que el CISO aprenda a hablar de números, aunque ayuda. Creo que el cambio real ocurre cuando la seguridad deja de presentarse como un capítulo aparte y se integra directamente en cada decisión de costo. No "cuánto cuesta el firewall" versus "cuánto cuesta la nube", sino una sola conversación donde el costo de un control de seguridad se compara con el costo real de no tenerlo, incluyendo el conocimiento que se pierde cuando la gente que construyó la solución termina renunciando.

Llevamos toda la semana hablando de contratos mal leídos, accesos mal gestionados, datos sin trazabilidad y continuidad sin probar. El hilo común de todos esos errores es el mismo: la nube se gestionó como si fuera propia, con la misma confianza operacional del centro de datos local, sin ajustar el modelo mental a que ahora hay un tercero de por medio. Y esa conversación, la que reencuadra la nube como una relación con riesgos compartidos y no como una extensión gratuita de la infraestructura propia, sigue siendo, en mi experiencia, la conversación que menos se tiene en los directorios chilenos y latinoamericanos.

La próxima semana entramos en otro terreno. Por ahora, si algo de esta serie te sirvió para tu próxima reunión de presupuesto de nube, ya cumplió su propósito.

Comentarios

Entradas más populares de este blog

¿Por qué CIS Controls antes que cualquier otra cosa? Serie: CIS Controls — Post 1 de 5

SERIE CIS CONTROLS · POST 1 DE 5 Estrategia · Liderazgo en TI ¿Por qué CIS Controls antes que cualquier otra cosa? El argumento estratégico para empezar por donde el riesgo es mayor, no por donde el proceso es más visible. Priorización por riesgo No todos los controles valen lo mismo Lenguaje de negocio Traduce técnica en riesgo medible Complementa ISO 27001 Donde la norma dice qué, CIS dice cómo LB Luis Bolívar IT Manager · Cybersecurity Insights #CISControls #Ciberseguridad Serie CIS Controls — Post 1 de 5: el argumento estratégico para empezar por donde el riesgo es mayor. Cuando TechCorp Latam implementó CIS Controls por primera vez, lo hizo después de un ransomware que comprometió el 65% de sus servidores. No fue una decisión estratégica planificada; fue un...

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos Serie · Post 2 de 6 🔍 Función ID — IDENTIFY NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos No puedes proteger lo que no sabes que tienes. IDENTIFY es el mapa que toda organización necesita antes de implementar cualquier control de seguridad. Analizamos sus 3 categorías y construimos el inventario de TechCorp Latam. 📅 Publicación 2 de 6 ⏱ Lectura: ~10 min 🏢 TechCorp Latam · Inventario desde cero El error más costoso en ciberseguridad: proteger sin saber qué tienes Imagina contratar una empresa de seguridad para custodiar tu edificio, pero nadie te da el plano del edificio. ¿Cuántas entradas hay? ¿Dónde están los archivos más valiosos? ¿Qué puertas dan al exterior? Sin ese plano, la seguridad es aleatoria. Exactamente eso ocurre cuando una organización invierte en firewalls, antivirus y monitoreo sin haber hecho antes un trabajo sistemático de identif...

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Serie · Post 5 de 6 🚨 Función RS — RESPOND NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Todo lo que TechCorp Latam construyó en GOVERN, IDENTIFY, PROTECT y DETECT llegó a su momento de verdad: un ataque de ransomware real. Esta es la historia de cómo respondieron, qué salió bien y qué lección pagaron caro. 📅 Publicación 5 de 6 ⏱ Lectura: ~12 min 🏢 TechCorp Latam · El momento de la verdad El momento para el que todo lo anterior te prepara Llevan cuatro funciones construyendo su programa. Tienen gobernanza, inventario de activos, controles activos y visibilidad de red. Y aun así, el incidente ocurre. Porque esa es la realidad del riesgo cibernético: los controles reducen la probabilidad, no la eliminan . El objetivo de un programa maduro de ciberseguridad no es hacer que los incidentes sean imposibles — es hacer que sean contenibles, detectables y recuper...