Revisión de la relevancia de la DMZ industrial (iDMZ)

¿Qué sabor del modelo de Purdue debería seguir?

Si ingresa el término «Modelo Purdue» en su motor de búsqueda favorito, las imágenes resultantes variarán considerablemente. Casi no hay mejor manera de suscitar una conversación sobre seguridad de tecnología operativa (OT) que comenzar a debatir qué pertenece al nivel 1 o al nivel 3 del modelo.

Incluso podría encontrar algunos diagramas que ubican las interfaces hombre-máquina del operador en el nivel 3. En particular, la publicación original de 1990 define la «consola del operador» como una entidad de nivel 1. Lo único en lo que parecemos estar de acuerdo es que el Nivel 0 es el proceso físico y el Nivel 4 es la empresa, aunque estoy seguro de que puede encontrar algunos diagramas que se desvían incluso de este entendimiento.

El modelo de Purdue fue introducido originalmente por Teodoro J Williams hace más de 30 años. Dada su antigüedad y el ritmo y el alcance del cambio tecnológico, incluidas tendencias como las redes definidas por software, el Internet industrial de las cosas (IIoT), por ejemplo, del borde a la nube y la capa física avanzada, es natural que algunas personas estén empezando a cuestionar si el Modelo Purdue está muerto. Pero no puede eludir una conversación sobre seguridad cibernética de OT o una presentación de solución sin encontrarse con ella.

Aunque el modelo de Purdue ha existido durante décadas, la comunidad de seguridad de OT continúa aprovechando su simplicidad y creando modelos de ciberseguridad que se superponen con su concepto. Aun así, el modelo de Purdue que los expertos en seguridad de OT y los proveedores analizan hoy no es el modelo de Purdue de su abuelo, excepto por el nombre.

Algunos se refieren a ISA95 y al modelo de Purdue indistintamente. La confusión se puede entender comparando los resultados de la imagen de la búsqueda «ISA95» con su búsqueda anterior de diagramas «Modelo Purdue». ISA95 se basó en los conceptos del Modelo Purdue y los formalizó aún más en 2000, menos desde el punto de vista de la seguridad y más desde el punto de vista de la integración de la información, para estandarizar la interfaz de ERP y MES. (Veinte años después, llamamos a esta interfaz “transformación digital”).

Hablando con franqueza, el estándar ISA95 se centra más en la definición de interfaces empresariales, y ni ISA95 ni el modelo Purdue se concibieron originalmente como arquitecturas de seguridad. Por ejemplo, no encontrará requisitos para principios de seguridad cibernética como «segmentación de red» y «protección perimetral». El estándar ISA95 también clasifica los niveles según los horizontes de tiempo, pero las empresas de fabricación modernas están tomando decisiones relacionadas con el negocio más rápido que nunca, reduciendo los horizontes de tiempo y su relevancia para definir zonas de arquitectura.

El problema con las diversas fuentes de información y la confusión es que, por lo general, obligan a los propietarios de activos a elegir un sabor único del Modelo Purdue impulsado por sus relaciones con los proveedores. Es posible que obtener los números de modelo de Purdue correctos en realidad no mejore su postura de seguridad, pero puede generar una forma para que la comunidad comparta ideas. Lo que es más importante que los números son las interfaces de los límites y el control de las funciones que viven en cada nivel. No se obsesione con seleccionar el sabor “correcto” del Modelo Purdue, ¡porque no hay ninguno! Es un marco general, no una arquitectura de referencia de ciberseguridad.

¿Debe tener una DMZ industrial de nivel 3.5 (iDMZ)?

Él mayoría de las amenazas a los sistemas de control industrial (SCI) continúan originándose en TI/la empresa, lo que ha sembrado la desconfianza de OT en las conexiones directas de TI. Por el contrario, los equipos de TI tienen una desconfianza similar hacia las conexiones OT directas debido a entornos heredados y vulnerabilidades sin parches. El iDMZ ayuda a ambos equipos a evitar conexiones directas y establecer intercambios de datos confiables. Considere la iDMZ como otra barrera para frenar la propagación lateral de los atacantes en las redes OT, ya sea a través de ataques de teclado activos o malware automatizado.

El modelo original de Purdue y el estándar ISA95 omiten el concepto de una barrera iDMZ entre la empresa y el sitio, debido al enfoque del estándar en las interfaces funcionales y no en la ciberseguridad. Sin embargo, en la práctica, las iDMZ se implementan de forma rutinaria y se clasifican como Nivel 3.5. Se debe tener cuidado con cualquier diagrama que clasifique el Nivel 3 como iDMZ. Una iDMZ correctamente implementada debe diferenciarse claramente de la red de planta de supervisión más enfocada operativamente. La iDMZ no tiene funciones o aplicaciones operativas directas. Permanece vigente únicamente para mejorar la seguridad y la segmentación de la red.

La iDMZ es donde se produce la convergencia (o colisión) de TI y OT. Como transformación digital, IIoT y Industria 4.0 iniciativas llevan a las organizaciones a hacer converger los datos de proceso con el análisis en la nube, esta interfaz de seguridad crítica de TI y TO a menudo se pasa por alto. Por supuesto, la convergencia TI-OT no es una excusa para crear una red plana. La convergencia de datos de TI y TO se puede lograr de manera segura y eficiente con una segmentación adecuada a través de una iDMZ segura. con ese fin, evite las redes planas que conectan datos OT directamente a la capa empresarial.

Un problema común con esta convergencia es que la capa límite se convierte en «tierra de nadie» sin una responsabilidad clara para la higiene y el monitoreo de la seguridad cibernética. Los equipos de OT generalmente trazarán la línea al sur de la iDMZ, a menudo controlando su propio firewall de límite de OT y asumiendo que TI administra, protege y monitorea todo lo anterior. Y los equipos de TI tienen suficientes vulnerabilidades, detecciones y alertas para responder en la red empresarial que rara vez considerarán o investigarán en esta iDMZ aislada. Es imperativo asignar una responsabilidad clara para la seguridad de iDMZ. Mi recomendación aquí es que un subequipo de seguridad de TI dedicado debe ser consciente de sus riesgos, preocupaciones e importancia.

Es mejor pensar en iDMZ como una zona de seguridad en lugar de una zona de aplicación. En lugar de pensar en casos de uso de aplicaciones para determinar sus necesidades de una iDMZ, es mejor determinar si los principios de seguridad de implementar una iDMZ mejorarán su postura de seguridad. Luego, determine qué casos de uso de aplicaciones o soluciones le permitirán proteger las políticas para esta zona límite.

Algunos componentes típicos que puede encontrar en iDMZ incluyen puertas de enlace de acceso remoto, servidores de administración de parches o paneles de seguridad de red OT. Al pasar datos de OT a TI, la mejor práctica sería seguir un modelo pub-sub, donde los dispositivos de OT y IIoT se publican en iDMZ y los motores de análisis o lagos de datos se suscriben desde la fuente iDMZ.

Aplique una mentalidad de confianza cero a su iDMZ

La arquitectura Zero Trust también se puede aplicar dentro de iDMZ. De hecho, es un ejemplo perfecto de una red pequeña donde los conceptos de confianza cero pueden imponerse y aplicarse a la empresa en general. Cada transacción, inicio de sesión, servicio y descarga dentro de iDMZ debe abordarse desde la mentalidad de «nunca confíe, siempre verifique». Supervise meticulosamente los nodos iDMZ en busca de cambios. Cualquier cambio aquí representa un mal actor, un movimiento lateral o configuraciones incorrectas que pueden conducir a vulnerabilidades y exposiciones más graves.

Zero Trust no es una excusa para evitar construir un perímetro sólido y seguir una segmentación de red adecuada. Si aplicamos la mentalidad de «suponer una infracción» a cada capa sucesiva de la arquitectura, construiremos capas y capas de protección en lugar de pasarlas por alto. Los sistemas ICS tienen límites físicos reales y podemos protegerlos de las amenazas utilizando estos límites para nuestro beneficio.

Principios generales de seguridad para implementar una iDMZ

Hay algunas características de OT que podemos usar para nuestro beneficio para el monitoreo de ciberseguridad en iDMZ. Primero, lo que entra y sale de este límite debe permanecer bastante estático a lo largo del tiempo. Las conexiones recién aprobadas deben ser validadas por los equipos de TI y OT en conjunto, no de forma aislada por iniciativas de transformación digital. En segundo lugar, lo que vive dentro de este límite debería cambiar con poca frecuencia y en un horizonte de tiempo mucho más largo que las redes de TI tradicionales. Cualquier nuevo activo y usuario debe ser recibido con sospecha.

Se recomienda a los propietarios de activos que sigan algunos principios para la transferencia de datos a través de los límites de TI y OT:

• En general, se prefiere el tráfico ascendente en el modelo de Purdue. Pero muchos casos de uso de tráfico inverso no se pueden evitar, como el acceso remoto o la transferencia de archivos de parches.
• El tráfico fluye solo de un nivel al siguiente. No pase por alto los niveles. Todo el tráfico de TI primero debe terminar en iDMZ en lugar de pasar por alto y establecer una conexión directa con OT.
• Deshabilite las conexiones de Internet y correo electrónico desde los nodos iDMZ. Limite el vector directo de phishing al deshabilitar el correo electrónico de los nodos iDMZ. En algunos casos, puede aprobar un servidor SMTP para notificaciones de correo electrónico salientes pero no para correos electrónicos entrantes.
• Si es posible, deshabilite o no permita el uso de medios extraíbles en sus sistemas OT. Los medios extraíbles siguen siendo una de las principales fuentes de infección para las redes OT; sin duda, la fuente más obvia de eludir el concepto de seguridad de la iDMZ por completo. Si no es posible deshabilitarlo por completo, las estaciones de escaneo dedicadas, las definiciones de políticas de grupo y la capacitación del usuario pueden ayudar a limitar los riesgos.

Identificación y bloqueo de amenazas OT mediante la implementación de las mejores prácticas en su iDMZ

Seguir los principios básicos mencionados anteriormente sentará las bases para un límite iDMZ defendible que pueda proteger su infraestructura de TI de las redes OT «inseguras». Estos principios también protegerán su infraestructura OT de las amenazas que surgen de la empresa tradicional, que con frecuencia se propagan lateralmente. Para construir sobre esta base, podemos continuar aprovechando la naturaleza estática de la interfaz TI-TO con capacidades activas de defensa y monitoreo.

Siga estas 10 mejores prácticas para mejorar la ciberseguridad de su iDMZ:

1. Refuerce la configuración del punto final de acuerdo con una política de confianza. Siga una mejor práctica como la Puntos de referencia de la CEI. Esto incluye eliminar servicios innecesarios y bloquear Internet o correo electrónico. Aplique controles de acceso basados ​​en roles y privilegios mínimos, y luego reduzca el uso de cuentas administrativas tanto como sea posible. El endurecimiento también debe incluir la gestión de vulnerabilidades y la aplicación regular de parches.
2. Supervise los cambios en su entorno iDMZ. Estos activos deben permanecer en su estado confiable y reforzado. Las desviaciones de este estado de cumplimiento podrían indicar configuraciones incorrectas no deseadas o actividad maliciosa.
3. Haga un inventario de las conexiones persistentes de entrada y salida. Lo que entra y sale de la iDMZ debería permanecer estático durante largos períodos de tiempo. Identifique y agregue puntos finales, puertos y servicios específicos a la lista de entidades permitidas. Use soluciones de detección de cambios en tiempo real para monitorear activamente y notificar a los equipos de seguridad de TI o OT sobre cualquier cambio no planificado.
4. Implementar listas de permitidos para software y servicios. Los cambios conocidos y aprobados se pueden validar automáticamente al integrar su lista de permitidos con los sistemas de administración de configuración. La creación de obstáculos adicionales para los cambios en esta zona puede generar puntos débiles con los usuarios finales, pero es necesario para proteger la integridad de la iDMZ.
5. Auditar y terminar los puntos de entrada y salida temporales. Esto incluye sesiones de acceso remoto que se han dejado abiertas más allá de la ventana de su política de seguridad. Aún mejor, busca un solución que finaliza automáticamente las sesiones después de un período de tiempo específico.
6. Identificar y alertar sobre movimientos laterales sospechosos. Esté atento a los dispositivos no autorizados y controle meticulosamente los privilegios elevados y los derechos de acceso administrativo. El monitoreo del movimiento lateral proporcionará una metodología de detección temprana.
7. Audite regularmente la configuración del firewall, tanto hacia el norte como hacia el sur, para evitar cambios en la configuración. Las soluciones seguras de administración de la configuración pueden ayudar a transformar las dolorosas auditorías en un monitoreo continuo del cumplimiento.
8. Agregue registros de OT y alimente a los equipos de búsqueda de amenazas de seguridad con eventos de interés: los dispositivos de OT y sus componentes de TI conectados (por ejemplo, computadoras, conmutadores, firewalls) dentro de los niveles más bajos del modelo de Purdue generan eventos de seguridad de interés que rara vez se registran o investigan. El registro de estos eventos y registros se vuelve invaluable para respaldar los esfuerzos de respuesta a incidentes. Busque herramientas de agregación y correlación de registros que puedan minimizar el parloteo ruidoso de algunos de estos dispositivos heredados antes de que se introduzcan en tecnologías sofisticadas de búsqueda de amenazas de SOC.
9. Aprende de un tarro de miel. Hay muchas alternativas a considerar, incluyendo un solo honeypot dentro de su iDMZ a un honeypot iDMZ completo o incluso una red OT de honeypot más allá de su iDMZ. Los honeypots brindan análisis de amenazas en vivo y detección de alerta temprana en lugar de protección pasiva. ofertas comerciales que puede ser muy útil para este propósito.
10. Considere implementar varias redes iDMZ. Compartir una iDMZ común en muchos sitios geográficos puede introducir una única entrada a múltiples redes OT.

Nota: Esta lista no es exhaustiva, y también se deben aplicar otras mejores prácticas e higiene de ciberseguridad general a iDMZ, que incluyen, entre otros, la administración regular de parches, la administración de vulnerabilidades, las soluciones antivirus, la copia de seguridad y la recuperación, y más.

Clausura

La iDMZ sigue siendo un método de segmentación relevante y útil para proteger su tecnología operativa y la tecnología de la información entre sí, así como para interrumpir el movimiento lateral de atacantes y malware. La creación de esta zona de barrera permite a una organización inventariar y volver a evaluar las sesiones de entrada y salida y los intercambios de datos. Las organizaciones pueden aprovechar las características estáticas de esta interfaz, creando y haciendo cumplir «listas permitidas» y monitoreando las desviaciones de un estado conocido y confiable.