Ciberseguridad IEC 62443 para sistemas de control y automatización industrial (IACS) en la industria de generación energética

Resumen

El propósito de la gestión de la seguridad cibernética de control está diseñado específicamente para guiar el desarrollo de componentes IACS para que sean seguros desde el diseño y se rijan por un sistema de gestión de seguridad centrado en OT/IACS que tenga políticas, procedimientos, revisiones periódicas y políticas específicas, requisitos que inculcan las mejores prácticas. IEC 62443 está ganando popularidad y muchos países están adoptando la colección en lo que rápidamente se está convirtiendo en un conjunto global de estándares. En la era de la globalización y de los mercados altamente competitivos, el mundo exige más automatización. Esto, a su vez, aumenta el riesgo de sufrir ciberamenazas. Por lo tanto, los requisitos de seguridad cibernética y la implementación de IEC 62443 son la necesidad del momento. IEC 62443 son una serie de estándares para la gestión de la seguridad cibernética del control, que aprovecha informes técnicos, información relacionada y define el proceso de implementación de sistemas seguros de control y automatización industrial (Industrial Automation and Control Systems, IACS, por sus siglas en inglés) que deben completar el ecosistema IACS y describir cómo los profesionales de seguridad, los integradores de sistemas y el control Los fabricantes de sistemas deben interactuar y garantizar la seguridad y protección de sus instalaciones y componentes.

Palabras claves: Ciberseguridad, automatización, seguridad funcional, activos, gestión, confiabilidad.

Introducción

Hay dos tipos de ingeniero. El profesional con visión de futuro que busca constantemente nuevas tecnologías que los beneficien a ellos y, en última instancia, a la organización. El otro tipo es el ingeniero del “ahora”, contento con usar lo que sabe y le resulta difícil probar nuevas tecnologías, ya sea por desafíos de especificaciones o por el espíritu de la empresa.

Estas dos mentalidades pronto necesitarán pensar en IEC 62243 a medida que el estándar se desarrolle gradualmente y comience a ser considerado en el espacio público. Si bien no todas las secciones de IEC 62443 han pasado la revisión por pares y algunas no han entrado en la etapa de desarrollo, las empresas deben comenzar a investigar cómo estos estándares afectarán el funcionamiento y el desarrollo de la marca y la estructura de la empresa.

Los IACS en instalaciones de generación de energía y otras son vulnerables a incidentes de ciberseguridad, se utilizan para operar una amplia gama de aplicaciones industriales, incluida la infraestructura crítica. En la tendencia actual de las cuatro revoluciones industriales (Industria 4.0), el objetivo del IIoT es permitir la optimización, el ahorro de costes y nuevas oportunidades de negocio en diferentes ámbitos. Se espera que IIoT introduzca avances significativos en la optimización de la toma de decisiones, las operaciones y las colaboraciones entre una gran cantidad de sistemas de control cada vez más autónomos. Como resultado, se deben implementar contramedidas y el operador de la instalación debe tener confianza en que estas contramedidas son suficientes y se realizan correctamente. El riesgo debe ser aceptable para todos los sistemas, incluidos los existentes y posiblemente obsoletos. Debido a la gran cantidad de paquetes y sistemas en los paquetes, se requiere un enfoque basado en estándares. Los IACS se utilizan para operar una amplia gama de aplicaciones industriales, incluida la infraestructura crítica.

Estos estándares para sistemas de control y automatización industrial están evolucionando y el estándar IEC 62443 se está convirtiendo en el enfoque preferido para muchos. Con la creciente convergencia entre Tecnología de la información (Information Technology, TI, por sus siglas en inglés) y Tecnología operacional (Operational technology, OT, por sus siglas en inglés) , el IoT industrial se está expandiendo. Cada vez hay más redes interconectadas independientemente de su ubicación geográfica. Además, las redes cerradas ya no están aisladas y se transforman rápidamente en redes conectadas a redes de oficina y a la nube. Estos introducen múltiples riesgos para las empresas y afectan a todo el ecosistema IACS, incluidos los propietarios de activos, operadores y proveedores.

Algunos de los desafíos clave que las industrias enfrentan inherentemente:

• Muchos sistemas de control carecen de mecanismos básicos de protección (Autorización, Auditoría, Validación de Entradas…etc.), ya que no fueron diseñados pensando en la seguridad.

• Se desarrollan protocolos industriales para redes confiables con confiabilidad y disponibilidad como principales prioridades.

• Las tecnologías emergentes, como la medición inteligente, la informática móvil y la tecnología inalámbrica, etc., exponen a los dispositivos industriales a un riesgo cada vez mayor de sufrir un ciberataque.

La implementación de IEC 62443 es beneficiosa para que las organizaciones aborden sus riesgos de ciberseguridad industrial. En un lenguaje sencillo, este estándar segmenta las redes en zonas y despliega varias barreras (conductos) para permitir un mejor control del acceso y la seguridad dentro de las redes de sistemas de control utilizando interfaces (canales) bien definidas. Proporciona una terminología común para la seguridad IACS, un sistema de gestión de seguridad específico para la automatización industrial, orientación sobre la arquitectura de seguridad de la red industrial y define los requisitos de seguridad en todo el sistema y durante todo el ciclo de vida de los componentes. Por lo tanto, los propietarios de activos a nivel mundial están adoptando esta opción para proteger sus activos industriales.

Los desafíos son que se trata de un estándar genérico para todos los componentes industriales y que aún no está finalizado. Verificar la conformidad con todo el conjunto de normas IEC 62443 es muy costoso y algunas partes pueden ser irrelevantes para determinadas industrias. La norma también hace referencia a niveles de seguridad (Security level, SL, por sus siglas en inglés), pero puede resultar difícil definir el objetivo correcto para los diferentes sistemas. Actualmente la norma define qué hacer, pero no detalla completamente cómo hacerlo.

Se construyeron muchas empresas de generación de energía, lo que obligó a mejorar los procesos de negocio e involucrar a muchos recursos humanos. Será más difícil gestionar activos que no sean sólo equipos físicos sino también humanos en ellos. Los gerentes y empleados deberían poder ver un vínculo entre la estrategia de una organización, las actividades que emplea día a día y los indicadores de éxito que utiliza.

Mirar hacia abajo en esta “línea de visión” muestra cómo se cumplen los objetivos organizacionales y mirar hacia arriba en esta “línea de visión” muestra por qué se llevan a cabo las actividades. Las capacidades operativas representan habilidades organizativas que permiten a una empresa ganarse la vida y, por lo general, lo hacen obteniendo una ventaja competitiva a través de procesos mejorados que reducen los costos de la empresa. Promover la transformación de las empresas y mejorar sus capacidades operativas son las tareas más importantes de las empresas globales. De modo que la gestión de activos no sólo se mide por el cumplimiento de las normas ISO 55001, sino que también se apoya claramente en la tecnología de la información y podría integrarse un flujo de entrada-proceso-salida que esté conectado entre los datos, las aplicaciones y las tecnologías de apoyo y las dimensiones de la gestión del rendimiento.

El concepto de gestión de activos es desarrollado por el Instituto de Gestión de Activos (IAM, por sus siglas en inglés). La gestión de activos permite a una organización obtener valor de los activos en el logro de sus objetivos organizacionales. Hay seis componentes de la gestión de activos que consisten en estrategia y planificación, toma de decisiones de gestión de activos, entrega del ciclo de vida, información de activos, organización y personas y riesgo y revisión en la Figura 1, el modelo conceptual de gestión de activos de IAM. En la industria de generación de energía, el componente de entrega del ciclo de vida en la gestión de activos es el principal foco de trabajo en el que muchos procesos de negocio deben gestionarse respaldados por datos e información de activos precisos. La organización utiliza un sistema de gestión de activos para dirigir, coordinar y controlar las actividades de gestión de activos. La Figura 2 es la relación entre los elementos clave de un sistema de gestión de activos, junto con las cláusulas relacionadas en la norma ISO 55001, además de lo relacionado con la ciberseguridad del sistema enfocado en la norma IEC 62443, es decir, viendo todo como un todo completamente relacionado entero.

El Instituto de Anatomía de la Gestión de Activos alineó dos de ellos en el mapa de temas de la lista de verificación con la tabla de cláusulas. Para gestionar el desempeño actual y futuro de los activos, se puede requerir una variedad de medidas de desempeño, incluidas medidas de seguimiento para monitorear el desempeño pasado (por ejemplo, para incidentes, fallas). & defecto) y medidas líderes (proceso) para predecir el desempeño futuro con el fin de evitar incidentes y fallas. El monitoreo puede generar grandes cantidades de datos, lo que impactará en el sistema de información de las organizaciones. Debido a que hay muchos procesos de negocio entre los campos involucrados y muchos datos ingresados y emitidos como resultado de un proceso de entrada y salida, la empresa debe describir su totalidad en un marco de diseño integrado que sea más maduro y que haga que la implementación de ISO 55001 sea efectiva y eficiente.

Figura 3, que es un marco general que contiene una metodología y un conjunto de herramientas de apoyo que brindan un enfoque integral para la planificación, diseño, implementación y gestión a través del Método de Desarrollo de Arquitectura. Este modelo es una definición de arquitectura comúnmente utilizada en el mundo de TI. La arquitectura es la organización fundamental de un sistema incorporada en sus componentes, sus relaciones entre sí y con el entorno, y el principio que guía su diseño y evolución.

IEC 62443 no está destinado únicamente a atacar a los piratas informáticos y al malware en su red. Está diseñado para ser un espíritu integral de procedimientos y controles de todos los niveles de la organización, desde el hardware y los usuarios finales hasta las políticas y los registros de activos. Se trata de comprender qué hardware y qué interacciones tienen, pero la parte más importante del estándar es cómo reconocer una amenaza, cómo informarla y, lo más importante, cómo responder y recuperarse.

El público objetivo de esta práctica recomendada pretende incluir todos los elementos (personas, procesos y tecnología) que participan en garantizar que la seguridad cibernética sea atendida en el IACS (propietario de activos, integrador de sistemas, proveedor de productos, proveedor de servicios, autoridad de cumplimiento). ). Esta práctica recomendada aclara las responsabilidades compartidas entre estas partes y describe quién realiza las actividades, quién debe participar y los insumos y resultados esperados.

El propietario del activo (operador) debe contar con un sistema de gestión de seguridad cibernética antes de iniciar un proyecto de yacimiento petrolífero. Los requisitos para un CSMS también se definen en IEC 62443-2-1 e ISO 27001. La ciberseguridad se implementa como una combinación de tecnología, procesos y personas, como se ilustra en la Figura 3. Esta práctica recomendada se centra en la tecnología y los procesos. A lo largo del documento se utiliza el concepto de nivel de seguridad para agrupar requisitos técnicos. El concepto de nivel de madurez, descrito en IEC62443-2-4, procesos grupales y requisitos organizacionales.

Los comités IEC62443 planean publicar un nuevo estándar para el nivel de protección (PL, por sus siglas en inglés).

El objetivo es definir SCC y hacer un mapeo en comparación con los requisitos de IEC62443-2-1, IEC62443-2-4 e IEC62443-3-3.

La implementación técnica y la configuración en el IACS y cómo se opera, mantiene e implementa la solución IACS se reflejarán en el nivel de protección (PL). El nivel de protección es una metodología para evaluar la protección de las plantas en operación. La metodología incluye la evaluación de las capacidades técnicas y los procesos relacionados en una evaluación combinada. Los PL combinan la evaluación de medidas técnicas y organizativas.

CSMS incluye, por ejemplo, programas para reevaluar continuamente los riesgos. Los Niveles de Seguridad se crean para clasificar grupos de activos, con respecto a zonas de seguridad. Para cada zona de seguridad se asigna un nivel de seguridad objetivo SL (objetivo). El SL (objetivo) suele ser el resultado de una evaluación de riesgos de esa zona. SL (objetivo) describe la efectividad que deben alcanzar las contramedidas aplicadas para asegurar adecuadamente la zona. El nivel de seguridad SL alcanzado (logrado) de una zona es una propiedad dinámica que normalmente se degrada con el tiempo, a medida que las amenazas emergentes y las tecnologías en evolución hacen que las contramedidas existentes sean relativamente menos seguras, a menos que se sigan procedimientos de mantenimiento y actualización. SL (capacidad) es el nivel de seguridad que una contramedida o dispositivo/sistema específico puede proporcionar a una zona de seguridad.

Las amenazas a la ciberseguridad en la industria energética representan riesgos inaceptables para los equipos rotativos, las operaciones confiables y la seguridad pública y de los empleados.

El objetivo es que para un tiempo determinado SL (alcanzado) ≥ SL (objetivo), para cada zona de seguridad definida en el sistema. Un ciclo de vida del nivel de seguridad tiene como objetivo cumplir continuamente este objetivo, utilizando reevaluaciones recurrentes y evaluaciones específicas para cambios en el sistema relacionados con la seguridad, por ejemplo, cambio de proceso, nueva vulnerabilidad detectada, parche de software de dispositivos.

El modelo de referencia IACS utilizado en estándar es de 5 niveles, influenciado por la Arquitectura de Referencia Empresarial de Purdue (Purdue Enterprise Reference Architecture, PERA, por sus siglas en inglés), como se muestra en la Figura 4. Las capas 1-2 generalmente comprenden la red OT, que generalmente se divide en varias zonas de seguridad según la criticidad, las capas 3-4 comprenden la Red informática. Como puede verse, las diferentes capas interactúan directamente sólo a través de la jerarquía. Los niveles más bajos suelen tener limitaciones de tiempo real, pero cuanto más alto es el nivel, más largos se vuelven los ciclos.

La mayoría de los IACS serán vulnerables a al menos algún riesgo de seguridad cibernética. Incluso cuando el IACS no es programable o está físicamente separado de otras redes, habrá riesgos de seguridad cibernética derivados, por ejemplo, de actividades realizadas durante el mantenimiento, actualizaciones de software, soporte de proveedores o acceso físico no autorizado, etc.

El titular de la responsabilidad deberá aplicar recursos para gestionar los riesgos de seguridad cibernética a fin de desarrollar competencias en el tema, desarrollar sistemas de gestión adecuados y seleccionar y gestionar contramedidas técnicas y organizativas de seguridad cibernética apropiadas.

Se debe considerar la cantidad y el tipo de sistemas vulnerables a ataques y las posibles consecuencias que podrían tenerse al decidir cuántos recursos se deben aplicar para garantizar que se implemente un enfoque proporcionado.

Sólo se puede lograr una gestión adecuada de los riesgos de ciberseguridad si la definición de los requisitos de las contramedidas y la gestión continua de las contramedidas se completan de forma sistemática. Se debe implementar un CSMS para el IACS definido. Esto debería incorporarse al sistema de gestión más amplio del sitio.

La estructura del CSMS no necesita ser diferente a la de cualquier otro sistema de gestión y podría adoptar varias formas, por ejemplo:

• Como se describe en normas relevantes como IEC 62443 e ISO 27001;

• la estructura de las actividades de gestión presentada en IEC 61511;

• la estructura de planificar/hacer/verificar/actuar de los sistemas generales de gestión.

De manera similar, los aspectos técnicos de la gestión de la seguridad cibernética no necesitan ser diferentes de ninguna disciplina técnica, por ejemplo, en la forma en que se ejecutan los proyectos de ingeniería o en la forma en que se mantienen, modifican y desmantelan los activos. Cualquiera que sea la forma de CSMS que se adopte, se deben abordar los siguientes principios de seguridad cibernética. Los documentos del CSMS deben mantenerse para que sean precisos (es decir, actualizados y sensibles a las amenazas cambiantes/métodos de ataque a medida que surgen con el tiempo), adecuados para su propósito y específicos del sitio al establecer qué se debe hacer, por quién y cuándo; no es necesario incluir la repetición de orientaciones cuando se pueda hacer referencia a ellas.

El propósito de este paso es identificar el alcance de la IACS y registrarlo en un formato que pueda usarse para la evaluación de riesgos y la gestión continua de la seguridad cibernética, es decir, un dibujo de red simple de la IACS y los datos asociados.

Para defender un sistema, primero es importante saber qué es necesario defender. La evaluación de riesgos, la definición de las contramedidas requeridas y la gestión continua de las contramedidas sólo se pueden lograr si se comprende y documenta todo el alcance del SIGC.

El límite de la IACS debe definirse para incluir todos los activos de la IACS (computadoras y otros dispositivos, etc. y las redes de conexión) asociados con las consecuencias de accidentes mayores o pérdida de elementos esenciales (Loss of Essential Service, LES, por sus siglas en inglés). Al hacerlo, se deben determinar los límites y todos los puntos de entrada/salida lógicos (es decir, conexión de red) hacia/desde el IACS.

Los activos de IACS que se incluirán en el alcance de IACS podrían incluir, entre otros:

• BPCS, incluidos, entre otros, DCS, PLC, SCADA, HMI/ interfaces de operador, activos remotos y cualquier otro controlador programable similar utilizado para el control de procesos en tiempo real o la reducción del riesgo de integridad baja.

• SIS dentro del alcance de BS EN 61511 y otros sistemas de protección/mitigación críticos para la seguridad. Incluye solucionadores lógicos, activos remotos, HMI/interfaces de operador y otros activos similares utilizados para la reducción de riesgos de plantas de procesos activos en tiempo real.

• ECS, incluidos sistemas de control eléctrico o adquisición de datos, HMI/interfaces de operador, variadores, sistemas de protección, etc.

• Sensores, actuadores u otros dispositivos similares de plantas de proceso/sistemas eléctricos. Tenga en cuenta que aquellos que están conectados únicamente mediante E/S discretas (es decir, no mediante red) están dentro del alcance del IACS, pero podrían considerarse parte del sistema de control asociado a los efectos de la evaluación de riesgos de seguridad cibernética y la aplicación de contramedidas.

• Activos que respaldan BPCS, SIS y ECS, incluidos historiadores de datos, controladores de dominio, estaciones de trabajo de ingeniería, estaciones de aplicaciones (por ejemplo, administradores de recetas, activos, control avanzado) y activos de infraestructura de red como conmutadores, enrutadores, cortafuegos, etc. por ejemplo, interfaces de operador), se implementan en entornos de máquinas virtuales y se deben incluir tanto los activos del servidor como los del cliente.

• Todas las conexiones de red dentro del IACS (tanto permanentes como temporales) entre todos los activos del IACS y los otros sistemas, incluida la identificación de los protocolos que se utilizan (por ejemplo, TCP/IP sobre Ethernet, serie sobre RS485, propietario, bus de campo, redes de instrumentos inalámbricos, etc...)

• Todas las conexiones de red (tanto permanentes como temporales) a sistemas fuera de los límites de IACS. Esto debe incluir la consideración de cualquier conexión realizada a otras redes externas, como redes corporativas o de terceros, acceso telefónico/externo y cualquier conexión inalámbrica utilizada dentro del IACS.

Una vez que se hayan identificado todos los activos de IACS, se deben organizar en zonas y conductos de acuerdo con IEC/TS 62443-1-1. Las zonas deben definirse en una estructura jerárquica tal que se pueda lograr una arquitectura defensiva, es decir, conexiones a sistemas externos en niveles superiores de la jerarquía y zonas de control y seguridad más críticas en niveles inferiores de la jerarquía (por lo tanto, menos susceptibles a las amenazas cibernéticas de los sistemas externos).

La agrupación de activos en zonas debería minimizar la necesidad de comunicaciones de datos en tiempo real entre las zonas, es decir, cada zona debería ser autosuficiente en la medida de lo posible, para facilitar la aplicación de las contramedidas (por ejemplo, segregación de la red) sin comprometer las necesidades operativas. y minimizar las rutas de comunicación que abarcan la red IACS.

IEC 62443-2-1 Ed. 1 e IEC 62443-2-4 contienen orientación sobre el contenido y el desarrollo de un CSMS para una organización que posee o presta servicios a un IACS. Los estándares consisten principalmente en políticas y procedimientos que formarán parte del CSMS y sugerencias sobre cómo podrían desarrollarse.

Los elementos del CSMS con respecto al propietario del SIGC se dividen en tres categorías principales, la primera se centra en el análisis de riesgos, la segunda (y más grande) se centra en abordar los riesgos y la tercera aborda el cumplimiento y la mejora continua del CSMS.

Los elementos que se centran en el análisis de riesgos proporcionan requisitos sobre, por ejemplo, que se debe seleccionar una metodología de evaluación de riesgos, que una evaluación de riesgos utilizando esa metodología debe ser ejecutada y documentada por personal capacitado y que debe haber una estrategia para la reevaluación.

IEC 62443-2-3 es la parte del estándar que proporciona orientación sobre la gestión segura de parches. Todos los activos deben monitorearse con respecto a las versiones actuales y los parches disponibles, instalarse y verificarse en un sistema de prueba, crear copias de seguridad del sistema original antes de aplicar el parche y posiblemente detener las operaciones mientras se aplica el parche. Los activos pueden llegar a un punto en el tiempo en el que ya no cuentan con el soporte del proveedor del producto, es decir, obsolescencia del software/activos. En tales casos, no se lanzarán nuevos parches para el activo, independientemente de las vulnerabilidades o errores descubiertos.

Con el proceso completo de gestión de parches tanto por parte del proveedor como del propietario del activo, un parche de software tiene un ciclo de vida que contiene varios estados, que incluyen prueba, aprobación y lanzamiento desde la perspectiva del proveedor del producto hasta prueba interna, autorización y liberación interna por parte del propietario del activo.

En consecuencia, se deben definir zonas (en parte) para incluir activos donde se requerirán las mismas contramedidas de ciberseguridad. Es posible que sea necesario ajustar la definición de zona después de la evaluación de riesgos o la definición de contramedidas como parte de un proceso iterativo.

Una vez identificadas las zonas, se pueden definir conductos donde haya comunicación entre zonas:

• Conductos internos, es decir, conexiones de comunicación entre zonas IACS.

• Conductos externos, es decir, conexiones de comunicación a sistemas externos fuera de los límites identificados del IACS.

• No se deben definir conductos dentro de una zona individual.

• Los conductos deben incluir cualquier conexión de red que no esté físicamente contenida dentro de una zona, por ejemplo, conexiones inalámbricas.

• Los conductos deben incluir comunicaciones fuera de la red entre zonas, por ejemplo utilizando medios o dispositivos portátiles (como medios USB, computadoras portátiles) que se utilizan para permitir la transferencia de datos entre zonas.

Para la mayoría de los sitios donde hay al menos una conexión externa (por ejemplo, a la red corporativa), se espera que normalmente haya al menos una zona del sistema de control, una zona del sistema de seguridad y una zona de información de la planta, como se muestra en las Figuras 5, 6. y 7.

IDS (NIDS) e IDS de host (HIDS). NIDS se implementa más comúnmente como un dispositivo separado, por ejemplo, conectado a un puerto de duplicación en un enrutador de red o integrado en un enrutador o firewall. NIDS verifica todos los datos de la red en busca de patrones de ataque conocidos o comportamientos inesperados. HIDS se instala como software en un host y puede verificar los registros, el tráfico de red y el sistema de archivos en busca de indicaciones de intrusiones completadas o en curso. Una variante especial de IDS también previene un intento de intrusión, por ejemplo, bloqueando el tráfico de red relacionado con un intento de intrusión detectado. Hay varios inconvenientes del IDS, principalmente relacionados con el costo de aplicarlo a todas las subredes y hosts, el costo de monitoreo y el costo de manejar falsos positivos.

Los escáneres de vulnerabilidades proporcionan medios para fortalecer el sistema y pueden usarse para detectar: desviaciones de las políticas de seguridad, malas configuraciones y fallas de software. Normalmente, este tipo de exploraciones se deben realizar al reevaluar el SL (logrado) para un IACS. Sin embargo, la exploración en sí puede tener un impacto negativo en el rendimiento del IACS, lo que implica que, idealmente, la exploración debería realizarse primero en un entorno de laboratorio para evaluar que el impacto de la exploración no interferirá con las operaciones regulares. Alternativamente, se podría realizar un análisis de vulnerabilidad durante una parada de mantenimiento planificada del proceso.

Las herramientas HCM se pueden utilizar para editar de forma remota las configuraciones predeterminadas del host con respecto al software disponible, así como el acceso de los usuarios. En IACS esto no se usa ampliamente debido a la falta de estandarización de dichos sistemas con respecto a la diversidad de hosts. Los sistemas operativos se analizan en el estándar, especialmente se menciona que los RTOS tienen posibilidades y capacidades limitadas para contrarrestar las amenazas a la ciberseguridad.

Como los controladores DCS y los PLC, en general se ejecutan en RTOS, estos dispositivos, por su naturaleza, no pueden funcionar sin una conectividad de red que los convierte en una de las partes más vulnerables de un IACS. Estos sistemas monitorean y controlan procesos físicos reales. La recomendación es mantenerlos en redes verdaderamente aisladas. Esto probablemente será cierto en las primeras adaptaciones al IIoT, con la separación de la funcionalidad en tiempo real para el control y la supervisión crítica de la recopilación de información con respecto al análisis. En una perspectiva más amplia, los dispositivos IIoT podrían ser parte de un IACS como un componente crítico en tiempo real, proporcionando retroalimentación de medición o control de procesos.

El concepto de zonas de seguridad es central en IEC 62443. Dado un sistema IIoT heterogéneo que contiene numerosos dispositivos y servicios interconectados que también utilizan tecnologías de nube, uno puede plantearse la pregunta de si la idea de zonificación sigue siendo válida. Considerando el escenario brownfield, donde los dispositivos o servicios se introducen en una zona de seguridad, y esos dispositivos tienen conectividad de red con otras zonas menos protegidas, eso al menos hará que la zona sea más susceptible a los ataques. Sin embargo, si los componentes utilizados para controlar un proceso crítico todavía están aislados en una zona separada y los dispositivos o servicios IIoT utilizados para monitorear el proceso crítico se mantienen en otra red, la división en zonas de seguridad claramente proporciona seguridad adicional.

Conclusión

IEC 62443 es un estándar bien conocido y ampliamente utilizado dentro de la automatización industrial. Describe los requisitos y las mejores prácticas para el desarrollo, integración y evaluación de componentes y sistemas relacionados con un IACS en materia de ciberseguridad. El surgimiento del paradigma IIoT añade una nueva dimensión a considerar en comparación con los IACS tradicionales. Dada la complejidad esperada de tales sistemas, nuestro objetivo era realizar un análisis de los estándares IEC 62443 y evaluar su aplicabilidad con respecto al IIoT. Varias partes de IEC 62443 ya son adecuadas para su uso en el contexto de sistemas IIoT. Sin embargo, una serie de conceptos descritos en la norma pueden resultar difíciles de cumplir, entre los que se incluyen específicamente:

• I. Los límites de las zonas de seguridad serán más difíciles de retener debido a las características dinámicas de un sistema IIoT.

• II. La comunicación a través de límites de zona será un requisito para que muchos dispositivos y servicios IIoT puedan proporcionar algún valor, algo que actualmente el estándar desaconseja.

• III. Para las actualizaciones de software, se necesitará un nivel significativo de automatización de las actualizaciones para los dispositivos y servicios IIoT. Actualmente no se describe en la norma si dicha automatización puede admitirse y cómo.

En IEC62443-4-2 se describen los requisitos de los componentes, de forma similar a los requisitos del sistema. Se clasifican en cuatro categorías:

• (1) Requisitos de la Aplicación de Software (SAR);

• (2) Requisitos de dispositivos integrados (EDR);

• (3) Requisitos del dispositivo host (HDR);

• (4) Requisitos del dispositivo de red (NDR)

Es común que los requisitos sean los mismos para todo tipo de componentes y, por lo tanto, se expresen únicamente como requisitos generales de los componentes. Teniendo en cuenta el paradigma IIoT, en el que las rutas de comunicación no se limitan a redes aisladas, es evidente la necesidad de utilizar seguridad de extremo a extremo. Están surgiendo varios métodos criptográficos que tienen un costo relativamente bajo en términos de utilización computacional y de ancho de banda, lo que podría permitir el uso de seguridad de extremo a extremo como estándar en los componentes de IACS. Para algunos dispositivos con restricciones, la seguridad de extremo a extremo aún puede resultar demasiado costosa en lo que respecta al consumo de recursos.

En tales casos, se pueden utilizar nodos de borde específicos para proporcionar funciones de seguridad para una colección de dispositivos restringidos. Debido a la naturaleza heterogénea de un sistema IACS, las herramientas HCM actuales no son adecuadas ya que normalmente apuntan a un solo tipo de sistema operativo. Para un sistema IIoT, la diversidad de dispositivos será un problema aún mayor, al mismo tiempo que la necesidad de una gestión eficiente y centralizada es de gran importancia. Posiblemente partes de esta gestión se ejecuten automáticamente en un sistema IIoT.

Referencias

• [1] S. Al-Rubaye, E. Kadhum, Q. Ni, and A. Anpalagan. 2019. Industrial Internet of Things Driven by SDN Platform for Smart Grid Resiliency. IEEE Internet of Things Journal 6, 1 (Feb 2019), 267–277. https://doi.org/10.1109/JIOT.2017.2734903

• [2] Hugh Boyes, Bil Hallaq, Joe Cunningham, and Tim Watson. 2018. The industrial internet of things (IIoT): An analysis framework. Computers in Industry 101, June (2018), 1–12. https://doi.org/10.1016/j.compind.2018.04.015

• [3] IEC 62443 2009-2018. IEC 62443 Security for Industrial Automation and Control Systems. Standard. Internation Electrotechnical Commission, Geneva, CH.

• [4] Robert M Lee, Michael J Assante, and Tim Conway. 2016. Analysis of the Cyber Attack on the Ukrainian Power Grid. Technical Report. SANS.

• [5] S. Raza, H. Shafagh, K. Hewage, R. Hummen, and T.Voigt. 2013. Lithe: Lightweight Secure CoAP for the Internet of Things. IEEE Sensors Journal 13, 10 (Oct 2013), 3711–3720. https://doi.org/10.1109/JSEN.2013.2277656

• [6] The Institute of Asset Management 2012 The IAM Competences Framework Part II Guide using Asset Management, Competence Requir. Framew.

• [7] British Standards Institution 2014 ISO 55001 Asset Management Systems Requirements (Geneva:BSI Standard) p viii

• [8] Lo S C, Chen N, Iso A, and Ieee I E C 2017 Agile Process - Create Architecture Description through Agile Architecture Framework, Int. Conf. Softw. Eng. Res. Pract IEEE 42010.

Glenda Gutiérrez Capriles

Desde el año 2001, cuenta con más de 27 años de experiencia como gerencia de operaciones, consultora, diseñadora, instructora y conferencista en el área de confiabilidad y mantenimiento en América y Europa, en diversos sectores industriales de petróleo, gas, químico, petroquímico, refinería, nuevas tecnologías emergentes, alimentos y bebidas, y minería, de Venezuela, Argentina, México, Reino Unido, Estados Unidos, China, Alemania, Países Bajos, Italia, Egipto, Japón y Corea.

Ha sido autora de artículos técnicos en México, Argentina, Polonia, Estados Unidos y Venezuela. Tuvo el honor de ser entrevistada en la 1ª edición del Journal of Asset Management PMM Learning, España, y en la edición 2012 de la revista Pump Engineer, Europa.