¿Cómo aumentan los desafíos de la ciberseguridad debido a la Industria 4.0?
Frank Ruedisueli
Bureau Veritas
José Javier Leandro Gómez
Ingeniero de integridad CEng
MEI Chartered Energy Engineer
MBA
La cuarta revolución industrial o Industria 4.0, es el siguiente paso después de la automatización de la industria por ordenador que ocurrió durante las últimas cinco décadas. Esta nueva revolución está impulsada por palabras de moda como IIoT (Internet industrial de las cosas), ciberseguridad, big data, A.I. (inteligencia artificial) o gemelos digitales. No importa cómo una instalación química se haga "más inteligente", todas estas tecnologías tienen dos cosas en común: todo está impulsado por datos y requiere hiperconectividad. Y precisamente este es el próximo desafío para la ciberseguridad dentro de estos entornos industriales.
1. INTRODUCCIÓN
1.1. Antecendentes
La Industria 4.0 es fundamental para impulsar los procesos y el sector químico no puede quedarse atrás. Además, la industria química también contribuye a casi cualquier otra cadena de suministro de fabricación, por tanto, esta mejora afectará a muchos otros sectores. La mejora del producto, la rentabilidad y las optimizaciones comerciales son algunos de los impulsores clave de esta transformación digital. Razones de más para esperar que esta tendencia continúe. Pero de nuevo, ¿qué pasa con la ciberseguridad?
Tradicionalmente, los sistemas de control industrial (ICS) o la tecnología operativa (OT) estaban estrictamente separados de las redes de TI de la empresa. El modelo de Purdue encontró demasiadas instalaciones y describe una red en capas y bien segmentada. Una de las principales razones por las que esto es tan importante es el hecho de que muchos componentes de ICS, como los controladores de automatización, los PLC y los sistemas SCADA, no se diseñaron teniendo en cuenta la seguridad. La mayor necesidad era crear un equipo robusto y fiable, y la seguridad se quedó en un segundo plano. Por supuesto, la ciberseguridad es más que la segmentación de la red. Normas como IEC 62443 definen cómo se puede utilizar un sistema de gestión de ciberseguridad para gestionar los riesgos de ciberseguridad a niveles aceptables. Incluso ahora podemos debatir si la actual seguridad tradicional ya es lo suficientemente madura como para resistir un ataque cibernético como el ransomware. Desafortunadamente, vemos muchos ejemplos que demuestran lo contrario.
Además de estos desafíos, las iniciativas de Industria 4.0 avanzan hacia la hiperconectividad, lo que da como resultado una mayor exposición de las redes OT, el uso de servicios de TI más genéricos, la conectividad en la nube y "bypasses" de los modelos de referencia segmentados tradicionales. Esto no es necesariamente algo malo si la ciberseguridad no es una nueva ocurrencia. ¿Aprendimos las lecciones del pasado o volveremos a cometer los mismos errores?
1.2. Explicación de los Casos
No siempre es obvio que los dispositivos IIoT crean nuevos desafíos de ciberseguridad ya que, a primera vista, a menudo parecen estar perfectamente protegidos. Además, muchos proveedores de IIoT reconocen la necesidad de ciberseguridad y ofrecen dispositivos más seguros y capaces. Sin embargo, cuando se implementan de manera deficiente o se mantienen de manera inadecuada, aún pueden presentar un riesgo desconocido. Por lo tanto, estos riesgos cibernéticos se podrían dividir generalmente en dos tipos, la solución IIoT en sí y la implementación de la solución.
Las siguientes secciones exponen dos casos reales encontrados en una misma planta química. Por razones de confidencialidad, algunos datos han sido omitidos o variados. Como los dispositivos IIoT en cuestión no son el problema principal, tampoco se divulgan. Ambos casos fueron encontrados en una planta industrial química con sede en el norte de Europa. La instalación en sí tiene más de 12 años, sin embargo, en los últimos años se han realizado varias modificaciones y ampliaciones donde se han instalado nuevos sensores, PLC y maquinaria de diferentes fabricantes y proveedores. Las soluciones IIoT formaron parte de estas nuevas instalaciones.
2. CASO DE USO 1: DIAGNÓSTICO EN LA NUBE
En el primer ejemplo, se implementa una solución para recopilar datos de varios instrumentos OT. Un llamado "Edge device” o dispositivo perimetral ubicado en el borde de la red, recopila datos del proceso y de diagnóstico de los instrumentos y luego los envía a una aplicación en la nube para su análisis. Tanto el usuario final como el proveedor pueden hacer uso de esta plataforma en la nube para realizar un mantenimiento basado en la condición (CBM), o realizar algunas labores de mantenimiento o soporte remoto.
El dispositivo perimetral se instaló en la red a través de dos conexiones de red independientes (Dual Homed), una conexión con la red de TI para comunicarse con la nube y una segunda conexión con la red de OT para recopilar la información de los instrumentos de OT. La conexión a la nube también estaba protegida por un túnel VPN seguro y encriptado. Además, el propio dispositivo perimetral se configuró para enviar solo datos desde la red OT a la nube, el tráfico a la red OT no es posible.
Figura 1-1: Configuración del Caso 1
A primera vista, parece una solución adecuada, segura y bien segmentada. Sin embargo, cuando el dispositivo se dibuja en el diagrama de red completo, es obvio que tiene el potencial de crear un “bypass” entre las redes OT y TI. Durante una revisión detallada y un escaneo de red en la red de TI, se expuso un servicio de administración para configurar el dispositivo perimetral. Esto no lo sabía el usuario final y esta conexión estaba disponible para cualquier persona en la red de TI. También quedó claro que la contraseña para este acceso a la configuración del “Edge device” no se cambió y se mantuvo la contraseña predeterminada, que es fácil de recuperar a través de los manuales del proveedor. Además, el dispositivo perimetral también ejecutaba un firmware desactualizado que incluía algunos problemas de seguridad. Todos estos hechos juntos proporcionan un vector de ataque previamente desconocido en el ”Edge computing”. Esto implica que un pirata informático podría potencialmente atacar el dispositivo perimetral, iniciar sesión con las credenciales predeterminadas, obtener más privilegios al explotar las vulnerabilidades conocidas del firmware antiguo y acceder a la red OT.
Figura 1-2: Configuración del Caso 1
Tenga en cuenta que este problema de seguridad no estaba disponible a través de la nube ya que esa parte aún estaba protegida por la VPN. Sin embargo, debido a que el dispositivo perimetral no se instaló en una zona de red protegida, como una DMZ IT/OT protegida por un firewall, esta configuración proporcionó un posible bypass para saltar de la red de TI al entorno de OT. Este problema se descubrió al realizar una evaluación del modelo de amenazas (“Threat Modeling”) en combinación con una evaluación de vulnerabilidades. Estos enfoques se describen con más detalle en las siguientes secciones.
3. CASO DE USO 2: GATEWAY DE ACCESO REMOTO
El segundo ejemplo es sobre un “Gateway” de acceso remoto. Este es un dispositivo de comunicación que proporciona acceso remoto y datos de diagnóstico a un proveedor externo. En este caso era parte del contrato de servicio que venía con una maquinaria pesada instalada en la planta. El proveedor utiliza el acceso remoto para el mantenimiento y la resolución de problemas operativos en remoto. Los beneficios para el usuario final son evidentes, menos tiempo de inactividad y reducción de los costes de mantenimiento.
El proveedor también configuró e instaló la puerta de enlace de acceso remoto en cooperación con el equipo de mantenimiento de la planta. EL Gateway crea una conexión de red segura con el proveedor mediante un túnel VPN con las tecnologías de cifrado más potentes disponibles.
Figura 1-3: Configuración del Caso 2
Nuevamente, también esta configuración parecía muy segura. Si bien el túnel VPN en sí mismo es seguro y está protegido, la forma en que se configuró introdujo múltiples problemas de seguridad.
El primer problema se refería a la exposición remota. Como el Gateway necesita conectividad bidireccional desde y hacia la red del proveedor, el cortafuegos necesitaba permitir este tráfico. Sin embargo, debido a razones desconocidas, el firewall no estaba restringido a permitir solo el tráfico VPN de ese proveedor específico, sino que permitía todo tipo de tráfico y desde cualquier lugar de Internet. Lo más probable es que esto pueda explicarse por el hecho de que no se prestó mucha atención a la ciberseguridad durante la instalación y puesta en marcha del sistema completo, donde el Gateway de acceso remoto era solo una pequeña parte de la entrega.
Durante la puesta en marcha del equipo, se produjeron muchos problemas y fallos, lo que fue obligando al equipo de suministrador a ir “relajando” las reglas del cortafuegos como parte de la solución de problemas.
Posteriormente, estos ajustes a menudo permanecen para siempre. De todos modos, no es raro que los dispositivos IIoT lleguen directamente a Internet y eventualmente se puedan encontrar en Shodan, un motor de búsqueda específico para dispositivos conectados (Referencia 1).
El segundo problema fue la propia configuración del Gateway. Como esto era parte del alcance del proveedor, ese proveedor también era responsable del mantenimiento de la seguridad y la configuración de este dispositivo. Como todo el tráfico al Gateway estaba encriptado por la VPN, el usuario final no tenía idea de lo que el proveedor podía hacer en este dispositivo. Después de la investigación, quedó claro que el proveedor podía actualizar la configuración y proporcionarse muchos más privilegios de los necesarios.
Finalmente, la función del Gateway era proporcionar acceso remoto solo a los equipos mantenidos por ese proveedor. Sin embargo, debido a su mala implementación, el Gateway también podría acceder directa o indirectamente a muchos otros equipos. Además, debido a la falta de segmentación de múltiples conexiones de red, teóricamente era posible conectarse a casi toda la red OT.
Figura 1-4: Configuración del Caso 2
En este caso específico, el proveedor no hizo ningún daño, ya que no tenía malas intenciones, pero esta configuración creó una ruta de ataque real desde la red del proveedor hasta la red del usuario final. Estos ataques a la cadena de suministro a menudo se ignoran, pero podrían tener el potencial de proporcionar un fácil acceso a una red que, de otro modo, estaría bien protegida. Estos problemas se descubrieron al realizar una revisión del diseño basada en los documentos de instalación, los diagramas de red y la información del sistema, como se explica en las siguientes secciones.
4. SOLUCIÓN
Lo más importante es incorporar inmediatamente la ciberseguridad durante el proceso de diseño de estas nuevas soluciones, especialmente cuando se trata de IIoT u otra conectividad remota. Esto no solo es aplicable para nuevas instalaciones sino también para ampliaciones o modificaciones. Por supuesto, es más fácil decirlo que hacerlo. La red OT no siempre es adecuada para incorporar todos los requisitos técnicos y, al mismo tiempo, puede faltar la experiencia técnica. Además, dado que la mayoría de estas soluciones están impulsadas por el negocio o las operaciones, es posible que pasen por alto las implicaciones de ciberseguridad durante la fase del proyecto. Finalmente, es posible que ya existan muchas implementaciones diferentes de IIoT que brindan todo tipo de conectividad en una instalación en fase de mantenimiento o, a veces, incluso son desconocidas para el usuario final. En las siguientes secciones se describen dos posibles enfoques que brindan una solución a estos problemas.
4.1. Revisión de Diseño y Modelado de Amenazas
En una revisión de toda la documentación de diseño relevante y disponible. Se revisa y analiza con el propietario técnico, el arquitecto de la solución y/o el proveedor. Es importante notar que este enfoque es posible tanto para instalaciones nuevas (CAPEX) como para instalaciones existentes (OPEX). Especialmente para estos últimos, también es posible complementar esta información con visitas físicas a la planta y revisiones de configuración. El beneficio de una revisión de diseño es que el diseño de seguridad se puede verificar con las políticas de seguridad de la empresa, los estándares industriales y las mejores prácticas organizacionales o de la industria. Los defectos de diseño descubiertos, las infracciones de políticas o las desviaciones de estas mejores prácticas podrían mitigarse.
Con el modelado de tratamiento se usa la misma información de diseño, pero esta evaluación sigue un enfoque diferente, utilizando la mentalidad de un hacker. Es una metodología estructurada para mapear las amenazas de todas las posibles rutas de ataque sobre el tema en cuestión. Durante una sesión interactiva, se crea un diagrama que proporciona una imagen completa de la superficie de ataque y si se requieren mitigaciones adicionales.
Las revisiones de diseño y las evaluaciones de modelos de amenazas no solo se realizan en sistemas existentes sino también, en función de documentos de diseño, en nuevos sistemas o expansiones de sistemas. Ambos ejemplos de casos de uso se descubrieron durante estas evaluaciones.
4.2. Pruebas de Vulnerabilidad y Penetración
Una evaluación de vulnerabilidad y prueba de penetración, comúnmente abreviada como VA/PT, va un paso más allá y es una evaluación técnica más detallada. El objetivo es buscar vulnerabilidades desconocidas y probar si se pueden explotar. Esto también ilustrará cuáles podrían ser las consecuencias de un determinado problema de ciberseguridad y qué significaría para la organización.
Estas pruebas VA/PT brindan información detallada sobre la resiliencia de la ciberseguridad existente en la instalación y qué tipo de mejoras podrían ser necesarias. Sin embargo, estas evaluaciones son más intrusivas y es bien sabido que los sistemas OT más antiguos podrían tener problemas de fiabilidad con este ensayo. Un sistema crítico podría incluso dejar de funcionar mientras se analiza en busca de vulnerabilidades. Por lo tanto, generalmente no se recomienda ejecutar estas pruebas en un entorno OT en vivo.
Al mismo tiempo, existen algunas técnicas, como el escaneo pasivo, que todavía se pueden usar de manera segura. Alternativamente, al seleccionar cuidadosamente el alcance de los derechos o hacer uso de dispositivos de repuesto, la prueba de penetración intrusiva aún se puede realizar sin ningún impacto en el proceso de producción. Por supuesto, esto requiere un enfoque muy específico, adaptado a los sistemas OT y los sistemas en el alcance. Otra buena oportunidad es hacer que la prueba VA/PT forme parte de los procesos de instalación, prueba y puesta en marcha, como parte de las pruebas de aceptación en fábrica (FAT) y las pruebas de aceptación en la planta (SAT). Esto podría ser aplicable para nuevos sistemas o expansiones de sistemas.
Los resultados de la evaluación se pueden utilizar para tomar medidas para cerrar las brechas de seguridad y reducir el riesgo en su organización. En relación con el primer caso de uso, una prueba de penetración podría investigar si la ruta de ataque asumida es realmente factible para un atacante. Los resultados podrían determinar la solución final de mitigación de la seguridad.
5. CONCLUSIÓN Y EL CAMINO A SEGUIR
Se espera que la tendencia Industria 4.0 e IIoT continúe los próximos años para todos los sectores, incluido el sector químico. Esto será impulsado principalmente por los beneficios comerciales y operativos. Esta solución será perfecta para aumentar la competitivas de nuestra planta, siempre que la ciberseguridad no sea la gran olvidada. Es importante incluir el diseño de seguridad y los costes operativos directamente en el caso comercial de estas iniciativas inteligentes y verificar su impacto en la postura de ciberseguridad de OT. La revisión del diseño de seguridad interna y externa podría ayudar en esta etapa. Para las soluciones y los sistemas existentes, existen múltiples enfoques para revisar y verificar el estado de seguridad actual, lo que brinda la oportunidad de resolver de manera proactiva los posibles problemas antes de que generen un impacto en el negocio. El objetivo final sigue siendo lograr una producción segura, fiable y rentable, así como gestionar el riesgo de la ciberseguridad a un nivel aceptable para respaldar esos objetivos.
6. REFERENCIAS
- https://www.secura.com/services/information-technology/vapt
- https://www.secura.com/services/operational-technology/threat-modeling
- https://shodan.io
