Zero Trust sin slogans: por dónde empezar según NIST

“Zero Trust” no es una casilla que se marca comprando un producto

En los últimos años el término Zero Trust migró de la literatura técnica al catálogo de ventas. Hoy cualquier fabricante de firewalls, cualquier proveedor de VPN reempaquetada o cualquier plataforma de gestión de identidades puede etiquetar su producto como “solución Zero Trust”, y buena parte del mercado colombiano y latinoamericano ha comprado esa etiqueta sin entender qué hay detrás. El resultado es previsible: organizaciones que “ya implementaron Zero Trust” porque desplegaron un SASE, un ZTNA de acceso remoto o un NAC, y que siguen teniendo movimiento lateral sin restricción, cuentas de servicio con privilegios permanentes y una red plana por dentro del perímetro.

Zero Trust no es un producto. Es un modelo de arquitectura de seguridad definido formalmente por el NIST (National Institute of Standards and Technology, EE. UU.) en la publicación SP 800-207 — Zero Trust Architecture, y complementado operativamente por el CISA Zero Trust Maturity Model. Ninguno de los dos documentos describe una herramienta que se instala. Describen un cambio de postura: dejar de confiar en la ubicación de red como criterio de seguridad y evaluar cada solicitud de acceso de forma explícita, contextual y continua, sin importar si el usuario o el activo está “dentro” o “fuera” del perímetro corporativo.

Este artículo no vende un roadmap mágico ni un checklist de 90 días. Traduce lo que NIST y CISA realmente definen en una secuencia de trabajo realista para equipos de seguridad y para las juntas directivas que autorizan el presupuesto.

Los principios reales de NIST SP 800-207

SP 800-207 no es un estándar de certificación ni un producto a comprar: es un documento conceptual que define un conjunto de tenets (principios) y una arquitectura lógica de referencia. Vale la pena leerlo con precisión porque la mayoría del marketing lo cita de forma incompleta.

Los siete tenets de Zero Trust según NIST

NIST SP 800-207 enumera siete principios que, en conjunto, definen el comportamiento esperado de una arquitectura Zero Trust:

• Todos los orígenes de datos y servicios de cómputo se consideran recursos. Esto incluye dispositivos IoT, APIs, cargas de trabajo en la nube y sistemas SaaS, no solo servidores tradicionales.
• Toda comunicación se asegura sin importar la ubicación de red. Estar dentro de la red corporativa no otorga confianza implícita. El tráfico interno se trata con el mismo escrutinio que el tráfico externo.
• El acceso a recursos individuales se otorga por sesión. La confianza no es permanente: se evalúa cada vez, no una sola vez al inicio de la jornada.
• El acceso se determina mediante política dinámica, que incluye el estado observable de la identidad del solicitante, la aplicación o servicio, y el activo solicitante, además de otros atributos de comportamiento y ambientales.
• La empresa monitorea y mide continuamente la integridad y postura de seguridad de todos los activos propios y asociados. Ningún activo es intrínsecamente confiable de forma permanente.
• Toda autenticación y autorización son dinámicas y se aplican estrictamente antes de permitir el acceso. Esto implica un ciclo continuo de escaneo, evaluación, adaptación y reevaluación.
• La empresa recolecta la mayor cantidad posible de información sobre el estado actual de activos, infraestructura de red y comunicaciones, y la usa para mejorar su postura de seguridad.

De estos siete tenets se derivan los tres principios operativos que suelen resumir el modelo: verificación explícita (nunca confiar, siempre verificar, en cada solicitud), mínimo privilegio (acceso justo-a-tiempo y justo-lo-necesario, sin permisos permanentes acumulados) y asumir la brecha (diseñar la arquitectura partiendo de la premisa de que un atacante ya está dentro del entorno, para minimizar el radio de impacto en lugar de apostarlo todo a evitar la entrada).

La arquitectura lógica: PE, PA y PEP

NIST define tres componentes lógicos centrales que forman el motor de decisión de cualquier arquitectura Zero Trust real. Estos componentes no son necesariamente tres productos distintos —pueden convivir en una misma plataforma o distribuirse entre varias—, pero funcionalmente deben existir de forma diferenciada:

• Policy Engine (PE) — Motor de políticas: es el componente que toma la decisión final de conceder, denegar o revocar el acceso a un recurso para un sujeto determinado. Evalúa la solicitud contra políticas empresariales, fuentes de inteligencia de amenazas, telemetría de comportamiento y señales contextuales (identidad, postura del dispositivo, sensibilidad del recurso, hora, ubicación, patrones anómalos).
• Policy Administrator (PA) — Administrador de políticas: actúa como puente entre la decisión del motor de políticas y su ejecución técnica. Establece o cierra la ruta de comunicación entre el sujeto y el recurso, genera credenciales de sesión temporales y comunica la decisión al punto de aplicación.
• Policy Enforcement Point (PEP) — Punto de aplicación de políticas: es el componente que habilita, monitorea y eventualmente corta la conexión entre el sujeto y el recurso. Puede materializarse como un agente en el endpoint, un gateway de red, un proxy de aplicación o un control específico del recurso.

Este trío es la razón por la que ningún producto aislado “es” Zero Trust: un firewall de nueva generación puede actuar como PEP, una plataforma de identidad puede alimentar señales al PE, pero la arquitectura completa exige que estas piezas trabajen de forma coordinada, con políticas dinámicas y no con reglas estáticas heredadas del modelo perimetral.

NIST también reconoce que existen distintos enfoques de despliegue —basados en mejora de la identidad, en microsegmentación de red, o en perímetros definidos por software (SDP)— y aclara que ninguna organización parte de cero: la migración es incremental, conviviendo con arquitectura perimetral tradicional durante años.

El modelo de madurez de CISA: dónde está realmente su organización

Si SP 800-207 responde qué es Zero Trust, el CISA Zero Trust Maturity Model (versión 2.0, publicado por la Cybersecurity and Infrastructure Security Agency de EE. UU.) responde cómo medir el avance real de una organización hacia ese modelo. Es la herramienta de diagnóstico más citada por equipos de seguridad que necesitan justificar presupuesto con algo más sólido que una diapositiva de vendor.

Los cinco pilares

• Identidad: verificación de usuarios, autenticación multifactor resistente a phishing, gobierno de identidad y acceso de mínimo privilegio. Es, en la práctica, el pilar fundacional del que dependen los demás.
• Dispositivos: visibilidad e inventario completo de todo dispositivo que se conecta (corporativo, BYOD, IoT, OT), evaluación continua de postura y cumplimiento antes y durante la sesión de acceso.
• Redes y entornos: abandono del perímetro único a favor de segmentación granular del tráfico interno y externo, cifrado end-to-end y control de flujos entre cargas de trabajo.
• Aplicaciones y cargas de trabajo: controles de acceso granulares tanto para aplicaciones on-premise como en la nube, integración de seguridad en el ciclo de desarrollo, protección en tiempo de ejecución.
• Datos: clasificación, cifrado y monitoreo continuo de los datos sin importar su estado (en reposo, en tránsito o en uso), con controles de acceso basados en la sensibilidad del dato, no en la ubicación del sistema que lo aloja.

Estos cinco pilares se sostienen sobre tres capacidades transversales que deben madurar en paralelo: visibilidad y analítica (telemetría suficiente para tomar decisiones informadas), automatización y orquestación (respuesta a incidentes y aplicación de políticas sin dependencia exclusiva de intervención manual) y gobierno (políticas, procesos y responsabilidades formalmente definidos, no prácticas ad hoc).

Los cuatro niveles de madurez

CISA define cuatro estadios progresivos, y es normal —esperado, incluso— que una organización se encuentre en niveles distintos según el pilar evaluado:

• Tradicional: controles manuales, estáticos, configurados por silos organizacionales; políticas de acceso amplias y de larga duración; poca o ninguna integración entre pilares.
• Inicial: automatización incipiente en la asignación y configuración de atributos de ciclo de vida, políticas de acceso que comienzan a incorporar variables de riesgo, primeras integraciones entre pilares.
• Avanzado: controles coordinados entre pilares, automatización centralizada de la gestión de configuración y de políticas, visibilidad enriquecida a nivel empresarial, respuesta orquestada ante cambios de riesgo.
• Óptimo: atributos de acceso dinámicos y calculados en tiempo real, acceso justo-a-tiempo y justo-lo-necesario para usuarios y activos no humanos, automatización e interoperabilidad total entre pilares, monitoreo continuo con respuesta automatizada.

El valor práctico de este modelo no es aspiracional: es diagnóstico. Antes de firmar cualquier contrato con un proveedor, un CISO debería poder ubicar a su organización pilar por pilar en esta matriz. Sin ese diagnóstico, cualquier inversión en “Zero Trust” es, en el mejor de los casos, una apuesta sin línea base de medición.

Una ruta de inicio realista: secuencia, no simultaneidad

El error más costoso en la adopción de Zero Trust es tratarlo como un proyecto de compra única. NIST y CISA coinciden en que la transición es incremental y coexiste con arquitectura tradicional durante un periodo prolongado. La secuencia siguiente refleja las dependencias reales entre pilares.

Primero: inventario de identidad y de activos

No existe motor de políticas capaz de tomar decisiones dinámicas sobre sujetos y recursos que la organización no puede nombrar con precisión. Antes de evaluar cualquier plataforma de ZTNA o microsegmentación, el trabajo fundacional es:

• Inventario completo y actualizado de identidades humanas y no humanas (cuentas de servicio, API keys, integraciones automatizadas).
• Inventario de activos: endpoints, cargas de trabajo, dispositivos IoT/OT, aplicaciones críticas y su clasificación de sensibilidad.
• Mapeo de qué identidad accede a qué recurso, con qué frecuencia y bajo qué privilegio actual — no el privilegio documentado, sino el efectivo.

Este paso no es glamoroso ni vendible en una demo, y por eso es el que más se salta. Es también el que determina si todo lo que sigue funciona.

Segundo: autenticación fuerte y gestión de accesos privilegiados

Con el inventario como base, el siguiente movimiento con mayor retorno de reducción de riesgo es:

• MFA resistente a phishing (basado en FIDO2/WebAuthn o certificados, no SMS ni push simple) para todo acceso administrativo y, progresivamente, para acceso estándar.
• Eliminación de accesos permanentes de alto privilegio a favor de elevación temporal (just-in-time) mediante una solución de PAM (Privileged Access Management).
• Consolidación de identidad: reducir cuentas huérfanas, duplicadas o compartidas, que son el punto ciego más explotado en incidentes reales.

Este es el pilar de Identidad de CISA en movimiento de Tradicional hacia Inicial/Avanzado, y es prerrequisito técnico para que el Policy Engine de NIST tenga señales confiables sobre las cuales decidir.

Tercero: microsegmentación de red y visibilidad de tráfico este-oeste

Solo cuando identidad y dispositivos tienen una base sólida tiene sentido atacar la red. La microsegmentación no es instalar un producto de segmentación: es primero entender los flujos de comunicación reales entre cargas de trabajo (algo que en entornos con IoT, OT o sistemas heredados suele estar pobremente documentado), y después escribir políticas de segmentación basadas en esos flujos verificados, no en supuestos.

• Empezar por los activos más críticos (aplicaciones que procesan datos regulados, sistemas de pago, infraestructura de OT) en lugar de intentar segmentar toda la red de una vez.
• Instrumentar visibilidad de tráfico este-oeste antes de bloquear, para evitar interrupciones operativas por reglas mal calibradas.
• Iterar: la microsegmentación madura es un proceso continuo de ajuste de políticas, no una configuración que se completa y se olvida.

Cuarto: monitoreo continuo y automatización de respuesta

El cierre del ciclo —y el salto hacia los niveles Avanzado/Óptimo del modelo CISA— exige telemetría centralizada, correlación de señales entre pilares y capacidad de que el Policy Engine reevalúe sesiones activas en tiempo real, no solo en el momento inicial de autenticación. Aquí es donde SOAR, XDR y analítica de comportamiento aportan valor real, siempre que existan sobre la base de los tres pasos anteriores.

Por qué la mayoría de las implementaciones se quedan a medias

Los patrones de fracaso se repiten con suficiente consistencia como para nombrarlos con precisión:

• Comprar un producto etiquetado “Zero Trust” como sustituto de una estrategia. Un ZTNA de acceso remoto resuelve un problema puntual de conectividad, no la totalidad de los cinco pilares de CISA. Cuando la estrategia es “compramos el producto X”, la organización obtiene una mejora táctica aislada y sigue reportando el proyecto como completo.
• Saltarse el inventario de identidad y activos. Sin una base de identidad confiable y un mapa de activos actualizado, cualquier política dinámica del Policy Engine se construye sobre datos incompletos, lo que en la práctica genera reglas demasiado permisivas (para no romper nada) o demasiado restrictivas (que generan fricción y presión para revertirlas).
• Subestimar el trabajo de microsegmentación. Mapear flujos de comunicación reales entre miles de activos —incluyendo dispositivos IoT y OT que nadie documentó formalmente— es trabajo intensivo y lento. Los proyectos que intentan segmentar todo de una vez, sin fase de descubrimiento, terminan generando interrupciones operativas que le dan munición a quienes se resisten al cambio.
• Sistemas legado incompatibles. Mainframes, aplicaciones industriales y software propietario antiguo no soportan reautenticación continua ni agentes modernos. Integrarlos exige controles compensatorios (proxies, gateways dedicados) y planeación de migración a mediano plazo, no una solución inmediata.
• Patrocinio ejecutivo superficial. Zero Trust modifica flujos de trabajo en toda la organización, no solo en el área de seguridad. Sin compromiso explícito y sostenido de la alta dirección, los presupuestos se recortan en el primer trimestre difícil y las áreas de negocio presionan por excepciones que erosionan el modelo desde dentro.
• Gobierno de identidad débil como cimiento invisible. Es el fallo más subestimado: se invierte en tecnología de detección y aplicación sin resolver primero quién tiene acceso a qué y por qué. Todo lo que se construye encima hereda esa debilidad.

La postura de CIBER-TEC: una trayectoria de madurez, no un proyecto con fecha de cierre

Zero Trust, tal como lo define NIST SP 800-207 y tal como lo mide el modelo de CISA, no tiene un estado de “completado”. Es una trayectoria de madurez continua a través de cinco pilares, con niveles que se alcanzan de forma desigual y que exigen mantenimiento permanente frente a un entorno de amenazas, aplicaciones e infraestructura que nunca deja de cambiar. Cualquier proveedor que ofrezca “Zero Trust llave en mano” en un plazo cerrado está vendiendo una fracción del problema como si fuera la totalidad.

La recomendación práctica para equipos de seguridad y direcciones ejecutivas en Colombia y la región es concreta: antes de evaluar cualquier tecnología, ejecute el diagnóstico de madurez de CISA pilar por pilar, con evidencia real, no percepción. Ese diagnóstico —no el catálogo de un fabricante— es el que debe determinar en qué orden se invierte, empezando casi siempre por el inventario de identidad y activos, porque ninguna arquitectura de decisión dinámica funciona sobre una base que la organización no puede nombrar con precisión.