· Eduardo Vieira · Crítico · 6 min de lectura
Zero Trust e IEC 62443: Las Nuevas Reglas de la Ciberseguridad OT
Traduzca decisiones Zero Trust a zonas, conductos y políticas de activos e identidades sin hacer que el control dependa de servicios de identidad externos.
Zero Trust puede mejorar la tecnología operacional (OT), pero no como el eslogan “nunca confiar”. Una arquitectura de control necesita decisiones explícitas y repetibles sobre qué sujeto puede usar qué recurso, para qué propósito y bajo qué condiciones. Las zonas y los conductos al estilo IEC 62443 ofrecen un lugar práctico para aplicar esas decisiones sin descuidar la seguridad física ni la disponibilidad.
Esta no es otra lista de verificación del modelo Purdue. Purdue describe la jerarquía funcional; nuestra guía separada sobre Purdue cubre niveles, segmentación y bastionado de activos. La intención de búsqueda aquí es distinta: traducir políticas Zero Trust a rutas de comunicación, identidades, evidencia, excepciones y responsables del ciclo de vida. Es un método de ingeniería, no una afirmación de certificación o cumplimiento.
Traducir principios a rutas aplicables
NIST SP 800-207 define Zero Trust alrededor de la protección de recursos, en vez de segmentos de red, y del acceso concedido mediante políticas dinámicas. En OT, un “recurso” puede ser una sesión de estación de ingeniería, una consulta al historiador o una operación de protocolo permitida. La ubicación por sí sola no establece confianza, aunque sigue siendo útil como señal de política y límite de contención.
Comience por los flujos, no por los productos. Registre sujeto de origen, activo de destino, servicio u operación permitida, propósito operacional, responsable de aprobación, condición temporal y evidencia que conservar. Luego agrupe en zonas los activos con requisitos de seguridad compatibles. Cada flujo permitido entre zonas se convierte en un conducto con reglas de denegación predeterminada. Una VLAN no es la política; es solo un posible mecanismo de aplicación.
No coloque el control en tiempo real detrás de una dependencia directa de identidad en la nube, DNS o un directorio corporativo cuya indisponibilidad pueda detenerlo. Los controladores deben conservar su comportamiento local validado cuando falle el servicio de identidad. Canalice la administración humana mediante servicios de acceso acotados, mientras el tráfico autónomo de seguridad y control utiliza conductos locales previamente validados.
Una matriz de políticas determinista
La siguiente muestra usa únicamente identidades y activos sintéticos. Es deliberadamente pequeña para revisar la política como datos antes de traducirla a reglas de firewall, servidor de salto o aplicación.
| regla | sujeto sintético | zona de origen | recurso sintético | zona de destino | acción permitida | condición | evidencia | alternativa segura |
|---|---|---|---|---|---|---|---|---|
| ZT-01 | operator.alex | Operations | hmi.sim-01 | Cell-A | view, acknowledge | assigned shift | session log | local HMI remains available |
| ZT-02 | vendor.north | Vendor Access | engws.sim-01 | Engineering | interactive maintenance | approved ticket, MFA, 60 min | recording, commands | deny when broker unavailable |
| ZT-03 | historian.sim | OT Services | plc.sim-01 | Cell-A | read approved tags | fixed service identity | flow log | buffer locally; no control impact |
La matriz separa identidad de autoridad. Que vendor.north esté autenticado no autoriza acceso arbitrario a la subred; ZT-02 concede un recurso, un propósito y una condición breve. Del mismo modo, la identidad de servicio del historiador no puede escribir valores de control. Pruebe las rutas permitidas y denegadas con activos sintéticos antes del despliegue.
Acotar el acceso remoto y de proveedores
El acceso remoto es un conducto, no un derecho sobre una VPN plana. Termínelo en una zona de acceso controlado; exija cuenta individual atribuible, MFA resistente al phishing cuando sea compatible, orden de trabajo aprobada, ventana definida y lista explícita de destinos. Encamine la sesión mediante un servicio de salto administrado; no exponga HMI, PLC ni protocolos de ingeniería directamente a Internet pública.
Para proveedores, separe autenticación, autorización y supervisión. Deshabilite cuentas permanentes cuando sea viable, prohíba identidades compartidas, grabe sesiones administrativas cuando la política y la ley lo permitan, y ofrezca una forma local de finalizar el acceso. El acceso de emergencia necesita procedimiento local documentado, credenciales limitadas, revisión posterior y simulacros. No debe convertirse silenciosamente en la ruta habitual.
Observar decisiones sin perturbar el control
Recoja evidencia en los puntos de aplicación de políticas: resultado de conexión, identificador de regla, sujeto, destino, servicio solicitado, hora y causa de denegación. Añada monitoreo pasivo donde pueda observar sin introducir una falla en línea. Establezca una línea base de conductos esperados y alerte sobre nuevos pares origen-destino, ingeniería fuera de ventanas aprobadas, denegaciones repetidas o desvíos de política.
Una alerta no demuestra automáticamente un incidente. Los protocolos OT, mantenimiento, conmutación y secuencias de arranque producen cambios legítimos. Envíe alertas a personas que comprendan el contexto del proceso, defina escalamiento, sincronice el tiempo cuando sea seguro y proteja los registros contra alteraciones. Evite escaneo activo o respuestas automáticas que puedan perturbar dispositivos frágiles salvo validación con el responsable del activo.
Tratar activos heredados con controles compensatorios
Algunos PLC no admiten identidad moderna, cifrado ni registros detallados. No finja que un dispositivo sin contraseña se volvió Zero Trust. Limite su conducto a pares conocidos y operaciones necesarias, sitúe la administración detrás de un intermediario bastionado, restrinja el acceso físico, conserve copias de configuración, observe pasivamente y documente riesgo residual y responsable.
Los controles compensatorios son excepciones acotadas, no invisibilidad permanente. Declare capacidad no soportada, amenaza reducida, exposición restante, método de validación, fecha de vencimiento o revisión y disparador de reemplazo. NIST SP 800-82 Rev. 3 enfatiza adaptar salvaguardas a los requisitos de rendimiento, confiabilidad y seguridad física de OT; un control de ciberseguridad que interrumpe un lazo validado puede crear otro peligro.
Gobernar el ciclo de vida
Asigne responsables de activos, zonas, conductos, identidades y excepciones. Revise la política cuando cambien equipos, firmware, integradores, recetas, contratos de soporte remoto o rutas de red. Revoque accesos cuando terminen funciones o contratos. Pruebe la restauración de administración y control locales tras fallas de identidad, servicio de salto o registro.
Mida pocos resultados útiles: activos desconocidos investigados, cuentas obsoletas eliminadas, reglas temporales vencidas, rutas denegadas probadas, excepciones atrasadas y simulacros de recuperación completados. Los cambios deben pasar revisión de ingeniería, revisión de seguridad física cuando corresponda, validación por etapas, plan de reversión y ventana aprobada. Una certificación puede imponer requisitos adicionales, pero este artículo no evalúa ni promete certificación o cumplimiento.
Fuentes oficiales
Consultadas el 2026-07-24:
- ISA, Serie de normas ISA/IEC 62443.
- Comité ISA99, Seguridad de sistemas de automatización y control industrial.
- NIST, SP 800-207: Zero Trust Architecture.
- NIST, SP 800-82 Rev. 3: Guide to Operational Technology Security.
- CISA, Principles of Operational Technology Cyber Security.
- CISA, Guide to Securing Remote Access Software.
El resultado no es “desconfiar de todos”. Es un conjunto revisable de decisiones de mínimo privilegio, aplicado en conductos acotados, observado mediante evidencia útil y diseñado para que la pérdida de identidad corporativa no detenga el proceso.
