El candado en la puerta no sirve si alguien ya está adentro.
Tu empresa puso contraseña. Después puso doble autenticación. Después revisó los accesos. Y el atacante entró igual — porque nunca rompió nada. Llegó con las llaves de alguien que ya había entrado antes.
El 60% de las brechas de seguridad en 2025 involucraron un elemento humano — no una falla técnica. El atacante no hackeó el sistema. Convenció, robó o esperó hasta que alguien lo dejó entrar. Verizon DBIR 2025.
Instalas cámaras. Contratas vigilancia. Tienes protocolo.
Un día alguien copia la llave magnética de un empleado.
Entra por la puerta principal. Saluda al guardia. Se sienta en un escritorio.
El sistema registra: acceso autorizado.
Tú ves en el reporte: todo normal.
Él lleva tres meses adentro.
Eso no es ciencia ficción. Es el método de ataque más común del mundo en este momento — y el que más tiempo tarda en detectarse. No requiere hackers de película. No requiere vulnerabilidades de software exóticas. Requiere una sola cosa: una sesión activa que alguien no cerró, en un equipo que nadie revisó, desde una conexión que nadie validó.
Y mientras eso sucede, tu empresa sigue operando. Los reportes salen limpios. El acceso aparece como legítimo. La persona cuya sesión fue copiada sigue trabajando sin saber nada. El atacante está en tu correo, en tu CRM, en tu sistema de nómina o en tu plataforma de ventas — con permisos completos, sin alarmas, sin rastro obvio.
Este artículo no es para el área de TI. Es para el director general, el director de operaciones, el consejo, el dueño de empresa. Porque la decisión que permite o evita este escenario no la toma el técnico. La toman ustedes — cuando aprueban políticas, cuando asignan presupuesto, cuando deciden si esto es un problema de TI o un problema del negocio.
Es un problema del negocio.
Los números que nadie pone en la junta directiva
Ocho meses. Ese es el tiempo promedio que una empresa tarda en darse cuenta de que tiene a alguien no autorizado dentro de sus sistemas. Ocho meses en los que ese alguien puede leer, copiar, modificar, extorsionar, vender o simplemente esperar el momento oportuno. Y en el 88% de los casos, no entró rompiendo nada. Entró con una contraseña que alguien más tenía — y que ya no debería haber estado activa.
El trabajo híbrido multiplicó las superficies de riesgo: empleados conectándose desde casa, desde cafeterías, desde dispositivos personales que nunca fueron revisados por nadie. Cada una de esas conexiones es una puerta. La pregunta es cuántas están abiertas ahora mismo.
Tres casos reales. Sin nombres. Porque podría ser cualquiera.
Los siguientes escenarios no son hipotéticos. Son patrones documentados que se repiten en empresas de todos los tamaños, en todos los sectores. Los detalles específicos han sido generalizados — pero la mecánica es exacta.
"Teníamos MFA. Lo hackearon igual."
Una empresa de servicios financieros con 300 empleados había implementado doble autenticación en todos sus sistemas hace dos años. El director de TI lo reportó al consejo como un logro de seguridad. Tenían contraseñas, MFA, y acceso remoto por VPN. Estaban, según todos los criterios internos, protegidos.
Lo que no tenían era validación del equipo desde el que se conectaba cada usuario. Un empleado del área comercial recibió un correo que parecía ser del proveedor de software que usaban a diario. Ingresó a un portal idéntico al real. Puso su usuario, su contraseña, aprobó el MFA en su celular como siempre. Lo que no sabía es que el portal era falso — y que en ese momento, un atacante en otro país estaba copiando su token de sesión activo.
El token de sesión es lo que el sistema usa para reconocer que "ya validaste quién eres" durante las horas siguientes. No requiere contraseña ni MFA nuevamente. Es una llave temporal — y el atacante acababa de copiarla.
Durante las siguientes seis semanas, el atacante accedió al CRM, descargó la base de datos de clientes completa y exploró los sistemas de nómina. El sistema registraba todo como acceso legítimo del empleado. Nadie sospechó nada hasta que un cliente llamó para preguntar por una llamada que nunca realizó.
"El ex empleado se fue hace seis meses. Seguía teniendo acceso."
Una empresa con operaciones en cuatro países y más de 2,000 empleados tenía un proceso de baja de personal que incluía, en papel, la revocación de accesos digitales. En la práctica, el proceso dependía de que RRHH notificara a TI, TI notificara a cada administrador de sistema, y cada administrador ejecutara la baja en su plataforma respectiva. Correo. ERP. Sistema de ventas. Almacén. Plataforma de proveedores. Diecinueve sistemas en total.
Un supervisor de operaciones fue dado de baja en términos no amistosos. RRHH notificó a TI. TI ejecutó la baja en los sistemas principales. Pero en tres plataformas secundarias — incluida la de gestión de proveedores y la de aprobación de órdenes de compra — el acceso nunca fue revocado. El supervisor lo sabía. Esperó cuatro meses.
Luego comenzó a aprobar órdenes de compra a un proveedor que era de su propiedad, a través de la plataforma que seguía siendo accesible con sus credenciales originales. El sistema los registraba como órdenes legítimas aprobadas internamente.
"Pasamos la auditoría. Nos hackearon tres semanas después."
Una empresa del sector salud con presencia en doce estados había invertido el año anterior en una consultoría de seguridad que certificó sus sistemas bajo estándares internacionales. El reporte fue presentado al consejo con resultados positivos. La empresa había invertido bien, había mejorado sus controles, había pasado el pentest. El consejo aprobó el informe y pasó al siguiente punto del orden del día.
Lo que la auditoría no evaluó — porque no estaba en su alcance — era el comportamiento de los dispositivos desde los que el personal directivo se conectaba a los sistemas. Tres miembros del comité ejecutivo usaban sus laptops personales para acceder al sistema de expedientes médicos y al ERP financiero. Esas laptops no tenían cifrado activado, no tenían antivirus corporativo, no estaban inscritas en ningún sistema de gestión de dispositivos. Nunca habían sido revisadas por nadie.
Un ataque de infostealer — un programa malicioso que se instala silenciosamente y registra todo lo que se escribe y todo a lo que se accede — había estado activo en una de esas laptops durante meses antes de la auditoría. Los certificados de seguridad del sistema no decían nada de eso. El sistema estaba seguro. El equipo desde el que se accedía al sistema, no.
Verificó al usuario. Aprobó el acceso. Registró la sesión.
Nadie le preguntó al sistema si el equipo era de confianza.
Nadie se lo había enseñado a preguntar.
Qué es Zero Trust — en lenguaje de personas
Zero Trust no es un producto. No se compra en una tienda de software. No es una caja que se instala y listo. Es una decisión sobre cómo tu empresa piensa acerca de la confianza — y la decisión es esta: no confiar en nada de forma automática, verificar todo de forma continua.
En el modelo tradicional de seguridad, la lógica era: si estás dentro de la red de la empresa, eres de confianza. Si pasaste el acceso inicial, eres de confianza. Si tienes la contraseña correcta y el MFA, eres de confianza. Esa lógica funcionaba cuando todos trabajaban en la misma oficina, en las mismas computadoras, conectados al mismo servidor físico.
En 2026, esa realidad no existe. El correo está en la nube. El CRM está en la nube. El sistema de nómina está en la nube. Los empleados se conectan desde casa, desde el aeropuerto, desde su celular personal, desde la laptop que compraron ellos mismos. El "perímetro de seguridad" que antes era las cuatro paredes de la oficina ahora no existe. Y sin embargo, la mayoría de las empresas siguen usando el modelo de seguridad diseñado para ese perímetro que ya no está ahí.
Esas cuatro preguntas — repetidas en cada acceso, en cada sesión, en cada transacción — son la diferencia entre los tres casos que acabas de leer y una empresa que los hubiera detectado antes de que se convirtieran en crisis.
La decisión de implementar Zero Trust no la toma el área de TI. La toma el director general cuando decide que la seguridad de los sistemas es un tema de agenda en el consejo — no una línea en el reporte técnico trimestral.
Por qué esto es un problema del consejo, no del área de TI
Aquí está el punto que más incomoda en las conversaciones con dirección: en los tres casos anteriores, el área de TI hizo su trabajo. Implementó lo que le pidieron. Reportó lo que podía reportar. El problema no estaba en la tecnología — estaba en las decisiones que se tomaron por encima de ella.
La decisión de permitir que directivos usen equipos personales sin control corporativo no la tomó TI. La tomó alguien que pensó que pedir a un director que usara una laptop de empresa era incómodo. La decisión de no invertir en un sistema centralizado de gestión de accesos que revoque credenciales automáticamente cuando alguien es dado de baja no la tomó TI — la tomó quien aprobó el presupuesto y decidió que no era prioritario. La decisión de celebrar que "pasaron el pentest" sin preguntar qué no estaba en el alcance de ese pentest la tomó quien recibió el reporte y lo archivó.
Bajo ISO 31000 — el estándar de gestión de riesgo operacional — estos escenarios no son accidentes. Son riesgos identificables, medibles y mitigables que deben estar en la matriz de riesgo de cualquier empresa que opere con datos, sistemas o clientes. Y bajo las disposiciones de la CNBV para entidades financieras reguladas, la responsabilidad de esa matriz no recae en el CISO. Recae en el consejo.
El CISO y TI no son lo mismo — y confundirlos sale caro
Hay una confusión costosa que se repite en demasiadas organizaciones mexicanas: creer que el área de TI y el CISO son el mismo problema. No lo son. TI opera los sistemas. El CISO protege la información. Cuando una sola persona o un solo equipo hace las dos cosas, inevitablemente una de las dos se hace mal — y casi siempre es la seguridad la que cede ante la operación.
El CISO no es un técnico avanzado. Es un perfil de riesgo: alguien que entiende qué información tiene la empresa, qué valor tiene, quién puede acceder a ella, cómo podría salir, y qué controles existen para detectarlo cuando ocurra. Ese perfil necesita dos cosas que pocas empresas le dan: independencia del área de TI para reportar riesgos sin filtros, y acceso directo al consejo para que los riesgos lleguen a quienes tienen autoridad para mitigarlos.
La CISA — la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos — y el NIST CSF 2.0 coinciden en algo que en México todavía cuesta escuchar: la gobernanza de seguridad no es función del área técnica. Es función del consejo. El CSF 2.0 añadió por primera vez una función explícita de Govern — Gobernar — como el primero de sus seis pilares, por encima de Identificar, Proteger, Detectar, Responder y Recuperar. Porque sin gobernanza, los otros cinco no funcionan.
Cifrado, desarrollo seguro y el principio de privilegio mínimo
Hay tres prácticas que las organizaciones más serias del mundo aplican de forma consistente y que en México siguen siendo la excepción. No son complejas. Son disciplina.
Cifrado en todas las capas, no solo en tránsito. La mayoría de las empresas cifra los datos cuando viajan entre sistemas — el "candado" del navegador que todos conocen. Lo que pocas hacen es cifrar los datos en reposo: archivos almacenados en servidores, bases de datos, laptops corporativas, discos de respaldo. Un atacante que obtiene acceso a un servidor sin cifrado no necesita credenciales adicionales. Tiene todo. El NIST CSF 2.0 y la CISA son explícitos: cifrado de datos en reposo y en uso no es opcional en entornos que manejan información sensible. Incluso enmascarar información para que no se copiada, bloquear copiado de pantallas, etc. Expiración de sesiones, tokens, blindar dispositivos si presentan cambios.
Desarrollo seguro desde el inicio, no como revisión final. La mayoría de las vulnerabilidades en sistemas empresariales no vienen de ataques sofisticados externos. Vienen de código mal escrito, validaciones faltantes, credenciales hardcodeadas en repositorios, APIs sin autenticación adecuada. El principio de Secure by Design — impulsado actualmente por CISA como estándar para proveedores tecnológicos que operan en infraestructura crítica — establece que la seguridad no es una capa que se añade al final del desarrollo. Es un requisito que se diseña desde el primer día, en cada función, en cada API, en cada endpoint. Se valida todo, no solo una parte, se protege activamente cada servicio/API, se limita, etc.
Privilegio mínimo en todo, sin excepciones. El principio de privilegio mínimo (Least Privilege) significa que cada usuario, cada sistema y cada proceso tiene acceso únicamente a lo que necesita para hacer su trabajo — nada más. No porque no se confíe en las personas, sino porque el alcance del daño posible se limita drásticamente cuando los accesos están calibrados. El director general no necesita acceso de escritura a la base de datos de producción. El sistema de nómina no necesita leer los expedientes de clientes. El proveedor de mantenimiento no necesita acceso permanente — necesita acceso temporal, acotado, registrado y revocable. Elige entre roles y atributos, pero haz algo.
El código inseguro no falla el día que se escribe. Falla meses después, en producción, con datos reales, cuando el costo de corregirlo es entre 10 y 100 veces mayor que haberlo escrito bien desde el principio. Eso no es un dato técnico. Es un dato financiero.
Observabilidad: no puedes defender lo que no puedes ver
Una de las razones por las que los atacantes permanecen dentro de los sistemas durante 258 días en promedio es que la mayoría de las empresas no tienen visibilidad real de lo que ocurre en su infraestructura. Tienen herramientas de monitoreo. Tienen logs. Tienen alertas. Pero no tienen la capacidad de correlacionar todo eso en tiempo real y detectar el patrón anómalo antes de que se convierta en crisis.
Observabilidad no es lo mismo que monitoreo. El monitoreo te dice qué pasó. La observabilidad te dice por qué pasó, dónde empezó y cómo se está propagando — en tiempo real, antes de que el daño sea completo. Incluye trazabilidad de todas las sesiones activas, correlación de comportamiento por usuario y dispositivo, alertas automáticas cuando un perfil de acceso se desvía del patrón habitual, y la capacidad de cerrar una sesión comprometida en segundos, no en días.
El NIST CSF 2.0 lo llama Detect — Detectar — y lo coloca como función crítica paralela a la protección. Porque una organización que solo protege pero no detecta está apostando a que nunca falle ningún control. Y esa apuesta, estadísticamente, ya la perdió.
Lo que la observabilidad real implica en la práctica: saber en este momento cuántas sesiones activas hay en tus sistemas, desde qué dispositivos, desde qué ubicaciones geográficas, y cuáles se comportan de forma diferente a su patrón histórico. Si no tienes esa respuesta disponible en menos de un minuto, no tienes observabilidad. Tienes logs.
El Excel con datos de clientes. El PDF de la propuesta comercial. La información que se regala.
Hay una categoría de riesgo de información que no aparece en ningún pentest, que no activa ninguna alerta de seguridad perimetral, y que en muchas organizaciones representa la mayor exposición real de datos sensibles: la información que sale por decisión humana, en formatos no controlados, sin ningún rastro.
El gerente comercial que exporta la base completa de clientes a un Excel para "trabajarla más fácil" desde casa. El director de finanzas que manda el estado de resultados por WhatsApp porque el correo corporativo "tarda mucho". El proveedor externo al que se le da acceso completo a la carpeta de Drive porque "necesita ver unos archivos". El consultor que se va con una copia de la base de datos de producción porque nadie formalizó qué datos podía llevarse.
Estos no son problemas de hackers. Son problemas de decisiones. Y son los más difíciles de controlar técnicamente porque no violan ningún sistema — son acciones autorizadas, tomadas por personas con acceso legítimo, que en ese momento no pensaron — o no les importó — el riesgo que estaban creando.
Las organizaciones serias resuelven esto con una combinación de política, tecnología y cultura: clasificación de información (no todos los datos tienen el mismo nivel de sensibilidad ni merecen las mismas restricciones), DLP —Data Loss Prevention— que detecta y bloquea transferencias no autorizadas de información sensible, y una cultura donde las personas entienden el valor de los datos que manejan, no como regla burocrática, sino como parte de su responsabilidad profesional.
El costo real de los falsos ahorros
Hay una conversación que ocurre en muchas juntas de presupuesto y que, vista desde afuera, es difícil de entender. La empresa decide no invertir en gestión de identidades centralizada porque "es caro". No contratar un CISO dedicado porque "TI puede cubrirlo". No implementar cifrado en los laptops del equipo directivo porque "eso complica el trabajo". No revisar los accesos de proveedores porque "es mucho proceso".
Esas decisiones tienen un costo calculable. No hipotético — calculable, con los datos que ya existen:
La empresa que decidió no invertir $200,000 pesos en gestión de accesos centralizada tampoco contrató el proceso de revocación automática. El ex empleado del Caso 02 desvió 4.3 millones de pesos. La empresa que no cifró las laptops del equipo directivo ahorró quizás $50,000 pesos en licencias de software. El Caso 03 resultó en notificación al INAI u otra Entidad, investigación regulatoria, cobertura en medios y pérdida de contratos institucionales. No hay una forma honesta de calcular el "ahorro" sin ponerlo junto al costo de lo que evitó.
Lo más costoso en seguridad no es la inversión en los controles correctos. Es la ausencia de ellos en el momento equivocado.
Lo que un director puede pedir mañana — sin saber nada de tecnología
No hace falta entender cómo funciona un token de sesión para hacer las preguntas correctas. Estas preguntas, hechas en la próxima junta con TI, con el CISO o con el proveedor de seguridad, cambian la conversación de operativa a estratégica:
Una última cosa
En más de veinte años construyendo y asegurando plataformas en sectores regulados — fintech con aprobación CNBV, salud con COFEPRIS, energía con ASEA, aviación, etc — he visto este patrón repetirse con una consistencia que ya no me sorprende, pero que sigue costando caro cada vez.
La empresa que invirtió en el pentest y pensó que con eso alcanzaba. El consejo que aprobó la política de seguridad sin saber que sus propias laptops eran el punto débil. El director que confundió "cumplir con el estándar" con "estar protegido". El proveedor que vendió la herramienta correcta sin decirle al cliente que la herramienta sola no resuelve el problema de comportamiento. El ejecutivo que decidió no contratar al CISO porque "TI puede hacerlo" — y que tres años después estuvo sentado frente al regulador explicando por qué los datos de sus clientes estaban en un foro de la dark web.
Y he visto lo contrario también. Las organizaciones donde alguien tomó la decisión de construir la seguridad como arquitectura, no como parche. Donde el CISO tiene acceso al consejo y presupuesto real. Donde el desarrollo seguro es un requisito, no una aspiración. Donde los datos se tratan como el activo que son — con clasificación, con controles, con rendición de cuentas.
Esas organizaciones no son inmunes. Pero cuando ocurre un incidente, lo detectan en días, no en meses. Lo contienen antes de que sea crisis. Y tienen el plan de respuesta listo — porque sabían que tarde o temprano lo necesitarían.
Zero Trust no es cara. No es complicada en su esencia. Requiere hacer las preguntas correctas con la honestidad suficiente para aceptar que las respuestas actuales no son suficientes. Eso sí requiere algo que ninguna herramienta puede vender: la decisión de que la seguridad es un tema del negocio — y que empieza en el consejo.
Fuentes · IBM Cost of a Data Breach Report 2024 — costo promedio global $4.88M USD (+10% vs 2023, récord histórico); tiempo promedio identificar y contener brecha: 258 días; brechas por credenciales robadas: 292 días; escasez de personal de seguridad añade $1.76M al costo; IA y automatización reducen costo en $2.2M y aceleran detección 100 días · Verizon Data Breach Investigations Report (DBIR) 2025 — análisis de más de 20,000 incidentes; 60% de brechas con elemento humano; credenciales robadas en 22% como vector inicial; 88% de ataques a apps web con credenciales robadas; ransomware en 44% de brechas; 2,800 millones de contraseñas en foros criminales en 2024; 46% de dispositivos no administrados contienen credenciales corporativas · Verizon DBIR 2026 (publicado mayo 2026) — vulnerabilidades de software superan a contraseñas robadas como vector de acceso inicial en 2025 · NIST Cybersecurity Framework (CSF) 2.0, febrero 2024 — primera actualización mayor desde 2014; nueva función Govern como primer pilar; integración explícita de Zero Trust, privilegio mínimo, cifrado en reposo y en uso, protección de datos en tránsito y en reposo · nist.gov/cyberframework · NIST Special Publication 800-207 — Zero Trust Architecture (ZTA): verificación continua, privilegio mínimo, micro-segmentación, cifrado de todas las comunicaciones · CISA Zero Trust Maturity Model 2.0 (2023) — 5 pilares: Identidad, Dispositivos, Redes, Aplicaciones y Cargas de Trabajo, Datos + 3 capacidades transversales: Visibilidad y Analítica, Automatización y Orquestación, Gobernanza · cisa.gov/zero-trust · CISA Secure by Design (2024) — principios de desarrollo seguro para proveedores de software en infraestructura crítica; eliminar categorías enteras de vulnerabilidades por diseño · ISO 31000:2018 — gestión de riesgo operacional; matriz de riesgo como responsabilidad del consejo · ISO 27001:2022 — sistema de gestión de seguridad de la información; controles de acceso, cifrado, gestión de activos, continuidad · CNBV — Disposiciones de Carácter General aplicables a Instituciones de Crédito (Circular Única de Bancos); responsabilidad del consejo en riesgo tecnológico y operacional · INAI — Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP); obligación de notificación de brechas; sanciones por exposición no autorizada · Infografía de referencia: @CycuraMX — "Una contraseña no garantiza un equipo seguro".
Si tu organización necesita traducir la seguridad tecnológica a decisiones de negocio — o construir la arquitectura correcta en un entorno regulado — la conversación vale la pena.
The How Maker · #JMCoach
Riesgo Operacional · Seguridad por Diseño · Zero Trust · Arquitectura en Sectores Regulados · Fintech · Salud · Energía · Gobierno · Asesoría Ejecutiva y de Consejo
