Conectar el software de OEE a la red de PLC de una planta de fabricación crea una nueva vía de datos entre los entornos de tecnología operativa (OT) y tecnología de la información (TI).
En la mayoría de las plantas, las redes OT están deliberadamente aisladas de las redes TI corporativas para proteger los sistemas de producción de amenazas de ciberseguridad: una brecha en un PLC de producción supone un riesgo para la seguridad y la continuidad del negocio, no solo un riesgo para la seguridad de los datos.
Cualquier software que atraviese este límite OT-TI, incluidas las plataformas de OEE, requiere una evaluación rigurosa de seguridad antes de su despliegue. El panorama de seguridad del software de OEE ha mejorado significativamente en los últimos cinco años, pero la variación entre proveedores es grande.
Las plataformas de OEE nativas en la nube, basadas en arquitecturas de seguridad modernas, tienen perfiles de seguridad fundamentalmente diferentes a los sistemas de OEE locales construidos en la década de 2000 que no fueron diseñados teniendo en cuenta la seguridad del límite OT-TI.
Las preguntas en una evaluación de seguridad deben sacar a la luz estas diferencias y generar evidencia documentada de la postura de seguridad del proveedor que sus equipos de seguridad de TI y OT puedan revisar antes de aprobar la conectividad de la red.
Las consecuencias de una evaluación de seguridad insuficiente para OEE van desde menores, acceso no autorizado a datos o problemas de cumplimiento de privacidad, hasta graves, ransomware que entra en la red OT a través de un servidor de OEE comprometido y perturba las operaciones de producción.
Dado que el software de OEE está conectado al equipo de producción en todas las líneas, una plataforma de OEE comprometida tiene mayor acceso a la red que la mayoría de los sistemas TI que se conectan al entorno OT.
Este perfil de riesgo elevado justifica una revisión de seguridad más exhaustiva que las evaluaciones estándar de software empresarial.
Preguntas sobre arquitectura y flujo de datos: (1) ¿La plataforma OEE utiliza una arquitectura de flujo de datos unidireccional de OT a IT (solo lectura desde los PLC), o tiene capacidad de comunicación bidireccional?
(2) ¿Dónde se almacenan los datos de producción: on-premise, en una región específica de la nube o en una nube compartida multiinquilino? (3) ¿El servidor OEE se coloca en una DMZ entre las redes OT e IT, o requiere acceso directo a ambas redes simultáneamente?
(4) ¿Qué puertos y protocolos de red requiere la plataforma OEE que estén abiertos entre las redes OT e IT? (5) ¿La plataforma OEE admite despliegue sin conexiones entrantes desde Internet (aislada/air-gapped o despliegue on-premise)?
Preguntas sobre autenticación y control de acceso: (6) ¿La plataforma admite SAML 2.0 u OIDC para integración de SSO empresarial? (7) ¿Se admite la autenticación multifactor (MFA) y puede hacerse obligatoria para todos los roles de usuario?
(8) ¿La plataforma implementa control de acceso basado en roles (RBAC) que limite el acceso a los datos según planta, línea y función? (9) ¿Existen credenciales de administrador separadas para la aplicación OEE y la infraestructura subyacente (base de datos, SO)?
(10) ¿Cómo se gestionan y rotan las claves de API y las credenciales de cuentas de servicio?
Preguntas sobre seguridad de datos: (11) ¿Los datos se cifran en tránsito usando TLS 1.2 o superior para todas las comunicaciones? (12) ¿Los datos se cifran en reposo y qué estándar de cifrado se utiliza? (13) ¿Qué datos de producción se envían a la nube y cuáles se mantienen on-premise?
(14) ¿La plataforma registra todos los eventos de acceso de usuarios y las acciones de exportación de datos en un registro de auditoría accesible para el cliente? (15) ¿Cuál es la política de retención de datos y el proceso de eliminación cuando un cliente termina el contrato?
Preguntas sobre gestión de vulnerabilidades y respuesta a incidentes: (16) ¿Cuál es el proceso del proveedor para la distribución de parches de seguridad y cuál es el tiempo típico desde la divulgación de una vulnerabilidad hasta la disponibilidad del parche?
(17) ¿El proveedor ha completado una prueba de penetración por terceros en los últimos 12 meses, y está disponible el resumen ejecutivo de los hallazgos? (18) ¿El proveedor tiene publicada una política de divulgación de vulnerabilidades y un contacto de seguridad dedicado?
(19) ¿Cuál es el SLA de respuesta a incidentes del proveedor si se detecta una brecha de seguridad que afecte a los datos de clientes? (20) ¿El proveedor posee certificaciones de seguridad relevantes (ISO 27001, SOC 2 Tipo II) que cubran la infraestructura de la plataforma OEE?
Al evaluar las respuestas de los proveedores al cuestionario de seguridad, busque especificidad en lugar de afirmaciones genéricas.
Un proveedor que responde a "¿Los datos están cifrados en tránsito?" con "sí, usamos cifrado estándar de la industria" es menos creíble que uno que responde "sí, todas las comunicaciones usan TLS 1.3 con fijación de certificados en clientes móviles." Las afirmaciones positivas vagas son fáciles de hacer
las afirmaciones técnicas específicas son más difíciles de fabricar y más fáciles de verificar. Considere ciertas respuestas como bloqueos que requieren resolución antes de aprobar el despliegue. Estos incluyen: comunicación de red bidireccional desde los sistemas OT hacia la nube del proveedor (crea una superficie de ataque entrante)
falta de soporte de MFA para el acceso administrativo (inaceptable para sistemas conectados a OT) almacenamiento de datos en una jurisdicción que entra en conflicto con sus requisitos de soberanía de datos ausencia de pruebas de penetración por terceros en los últimos 18 meses y ausencia de un proceso documentado de respuesta a incidentes.
Estos no son puntos de negociación, son líneas base de seguridad que requiere una gestión responsable de la seguridad en redes OT. Incorpore los requisitos de seguridad que los proveedores deben cumplir en el contrato de compra antes de firmarlo.
Incluya cláusulas específicas que cubran: requisitos de notificación si el proveedor detecta un incidente de seguridad que afecte sus datos el derecho a realizar su propia evaluación de seguridad de la plataforma anualmente la obligación del proveedor de aplicar parches a vulnerabilidades críticas en un plazo de 30 días
y el derecho del cliente a rescindir el contrato sin penalización si el proveedor no cumple con los compromisos de seguridad. Los requisitos de seguridad que no están en el contrato son sugerencias, los requisitos de seguridad contractuales son obligaciones que crean recursos legales si se violan.
Iniciar sesión
Blog
