Ciberseguridad OT | Ciberseguridad en Sistemas de Control Industrial
Diseño e Implementación de Sistemas de Control Ciberseguros
Revisión: 1.0 (Julio 2024) - Tiempo de despliegue: 90 Minutos | Conozca las acciones pertinentes que debe tomar para que su sistema de control sea ciberseguro, ya sea contra violaciones casuales o contra violaciones intencionadas por parte de personas internas o externas.
En el mundo actual el diseño e implementación de los Sistemas de Control Industrial debe cambiar. Deben diseñarse pensando, no solo en la productividad de las operaciones, sino también pensadas en la seguridad de las personas (safety) y en la protección contra las amenazas de ciberseguridad (security).
Este cambio en el diseño de los sistemas de control es propiciado principalmente por la convergencia entre el mundo de IT y OT, buscando la productividad operativa de las plantas. Debemos recordar que el objetivo de la Industria 4.0 es la productividad operacional, pero también hay que cuidar en estas nuevas implementaciones, los riesgos que una planta ahora tiene al estar interconectada; por lo tanto, la Industria 4.0 también sugiere hacerlo mediante una gestión de riesgos adecuada (Risk Management).
Nuevos dispositivos de control han aparecido en la industria tratando de resolver problemas operativos e incrementando la productividad en las máquinas y líneas de producción, pero si no se implementan adecuadamente, ponen a la industria en riesgos. Estos nuevos dispositivos utilizan la tecnología de Internet Industrial de las Cosas (IIoT), por lo que los ingenieros de control ahora deben tener cuidado en la programación y configuración de estos nuevos dispositivos para bajar la posibilidad de que sea atacada la infraestructura donde estos se conectan.
Ya estamos entrando en una era donde tiene que cambiar el diseño de los sistemas de control tradicionales; mientras más incorporemos tecnología disruptiva a los procesos industriales, los ingenieros de control deben aprender a diseñar e implementar estos nuevos sistemas. Tecnologías como IIoT, Realidad Aumentada, Realidad Virtual, Gemelos Digitales, Inteligencia Artificial dan pauta a los nuevos Sistemas de Control Ciber-Físicos.
¿Esto me resulta útil?
Conocer los estándares de Ciberseguridad como el IEC/ISA 62443 es útil e importante para los Ingenieros de Control actuales. Si siguen los lineamientos del estándar en sus implementaciones, no solo entregaran proyectos productivos, sino también ciberseguros. Es un hecho que pronto, los usuarios finales tienen que cambiar sus especificaciones de control y automatización para incorporar el tema de protección de ciberseguridad. Los Integradores de Sistemas y OEM´s deberán ser capacitados en el estándar IEC/ISA 62443 para poder responder a las necesidades de los usuarios y cumplir con sus expectativas de Ciberseguridad.
En esta aplicación aprenderán las bases para proteger los Sistemas de Control Industrial, no importando la complejidad de este sistema. De hecho, desde la aplicación más sencilla de control se deben tomar las acciones pertinentes para su seguridad contra violaciones casuales, por personas que no quieren hacer un daño y solo se equivocaron en cierto procedimiento; pero también contra violaciones intencionales por personas internas o externas que tienen la intención de hacer daño.
¿Necesita ayuda?
Si necesita ayuda con alguna aplicación o tiene comentarios acerca del Innovation Center, por favor contáctenos.
¿Cómo puedo hacer que funcione?
Studio 5000 Software
FactoryTalk View
FactoryTalk Security
Stratix Switches
Conocimientos requeridos
Conocimiento en FactoryTalk Security
Conocimiento en Configuración de Switches Administrables
Paso 1: Identifique la arquitectura de control que se quiere proteger.
Nos basaremos en la arquitectura de la imagen Paso 1.1 como ejemplo. Debido a que no vamos a hacer un análisis de riesgo de Ciberseguridad, se supone la protección más básica de cumplimiento. Nuestra solución consistirá en sugerir los cambios pertinentes para cumplir con las medidas necesarias para la protección SL1 – Security Level 1 de acuerdo con ISA/IEC 62443.
Imagen Paso 1.1
Nos basaremos en una aplicación ejemplo de un patín de sistema de manejo de un quemador (BMS) que el fabricante u OEM entregará a su usuario final que lo va a integrar en su sistema de control de la planta. Para este tipo de aplicaciones, se debe cuidar la seguridad (safety), pero en la actualidad se debe cuidar la Ciberseguridad (security).
La arquitectura de control para proteger puede parecerse a la mostrada en la imagen Paso 1.2.
Imagen Paso 1.2
Paso 2: Entender el significado de los niveles de ciberseguridad (SL – Security Levels)
IEC 62443 _4.2 define SL en términos de cuatro niveles diferentes (1, 2, 3, 4), cada uno con un aumento de nivel de protección (Imagen Paso 2). SL 0 se define como sin requisitos de protección necesaria.
Una protección SL1 para el patín de BMS, solo protegería contra violación casual, sin querer hacer un daño a la operación; solo protegería contra errores humanos cuando intervienen con la operación y mantenimiento del patín.
Protecciones SL2 en adelante, protegerían al patín de BMS contra violaciones intencionales con el objetivo de causar daño a la operación. Un análisis de ciberseguridad deberá determinar qué nivel de protección necesitará el patín cuando esté instalado en la infraestructura de usuario final, dependiendo del impacto que podría sufrir el usuario en términos de su operación, en términos financieros y de seguridad a su personal en la planta.
Imagen Paso 2
Paso 3: Encontrar los requerimientos fundamentales de protección en el estándar IEC/ISA 62443 – 3.3 en el anexo B para cumplir con SL1.
Nota: Para una aplicación BMS podría ser obvio que, deberíamos cumplir con niveles de ciberseguridad mayores debido a que es un equipo sensible que, si lo atacan, puede tener repercusiones en la seguridad al personal de planta y/o, pérdidas financieras.
Un sistema ciberseguro de control debe cumplir con 7 requisitos fundamentales (Foundational Requirements – FR´s):
FR 1 - Control de Identificación y Autenticación.
FR 2 - Control de uso del equipo de control.
FR 3 - Integridad del Sistema
FR 4 - Confidencialidad de Datos.
FR 5 - Flujo de Datos restringido.
FR 6 - Respuesta oportuna a Eventos.
FR 7 - Disponibilidad del recurso.
Listado parcial de los 7 requerimientos fundamentales (imagen Paso 3.1) encontrados en el anexo B del estándar IEC/ISA 62443 – 3.3.
Imagen Paso 3.1
Paso 4: Encontrar todos los requisitos del sistema para cada uno de los requerimientos fundamentales de acuerdo con el SL de diseño.
En nuestro caso SL1 (imagen Paso 4.1).
De esta manera, encontramos que debemos cumplir con 38 requisitos de diseño del sistema de control para cumplir con SL1.
FR 1 - Control de Identificación y Autenticación. 10 requisitos del sistema.
FR 2 - Control de uso del equipo de control. 8 requisitos del sistema.
FR 3 - Integridad del Sistema. 6 requisitos del sistema.
FR 4 - Confidencialidad de Datos. 2 requisitos del sistema.
FR 5 - Flujo de Datos restringido. 4 requisitos del sistema.
FR 6 - Respuesta oportuna a Eventos. 1 requisito del sistema.
FR 7 - Disponibilidad del recurso. 7 requisitos del sistema.
Imagen Paso 4.1
Paso 5: Implementar las configuraciones en el sistema de control para cumplir con los requisitos de cada requerimiento fundamental con las herramientas de software y/o hardware apropiados.
De acuerdo con la complejidad o la simplicidad de nuestro sistema de control, se deberán pasar por el listado de los requisitos da cada requerimiento fundamental e implementar aquellos que aplique para nuestro sistema en cuestión o alcance - EUC (Equipment Under Consideration).
Recordemos nuestra arquitectura que queremos proteger (imagen Paso 5.1)
Imagen Paso 5.1
Para comenzar, tenemos que:
Realizar un inventario del hardware (y su revisión de firmware) y de software que tiene la arquitectura de control.
Identificar las posibles vulnerabilidades de los productos y software que se usaran en la arquitectura de control.
Tomar nota y leer las sugerencias del proveedor de aquellas vulnerabilidades encontradas y sus recomendaciones de las medidas de protección que podamos implementar durante el procedimiento de ciberseguridad de nuestra arquitectura.
NOTA: Cabe mencionar de nuevo que, para este ejemplo no vamos a realizar un análisis de Ciber riesgo, ni tampoco de vulnerabilidades. Estos análisis son muy importantes que se deberían hacer en todos los casos. Solo nos enfocaremos en el proceso de implementación de ciberseguridad de la arquitectura anterior con un nivel de protección SL1.
Considerar los requisitos de diseño del Requerimiento Fundamental FR-1 (Control de Identificación y Autenticación).
De acuerdo con las tablas de cumplimiento en el anexo B de la IEC/ISA 62443 – 3.3.; para el Security Level 1 (SL1) se deberán cumplir con los siguientes requisitos o los que aplique de acuerdo con la complejidad del EUC (Equipment Under Consideration). Serían los siguientes 10 requisitos:
SR1.1 Identificación y Autenticación de Humanos
SR1.3 Gestión de Cuentas
SR1.4 Gestión de Identificadores
SR1.5 Gestión de Autenticadores
SR1.6 Gestión de Acceso Inalambrico
SR1.7 Autenticación con clave fortalecida
SR1.10 Retroalimientación de Autenticación
SR1.11 Intentos de logeos con falla
SR1.12 Notificación de uso del sistema
SR1.13 Acceso por redes no confiables
En nuestra arquitectura, podemos suponer (dejarlo claro en la documentación) que no hay acceso inalámbrico, ni por otras redes no confiables, por lo que los requerimientos SR1.6 y SR1.13 simplemente no aplican (NA).
Para asegurar la arquitectura ejemplo, debemos configurar el servicio de FactoryTalk Security para poder cumplir con todos los requerimientos anteriores:
Configurar adecuadamente las políticas del sistema, políticas de productos, así como los identificadores y autenticación de usuarios humanos (imagen Paso 5.1.1 y imagen Paso 5.1.2).
Imagen Paso 5.1.1
Imagen Paso 5.1.2
Asegurarse en fortalecer las claves de autenticación para cumplir con SR1.7 (Imagen Paso 5.1.3).
Imagen Paso 5.1.3
Así como los intentos de inicio de sesión para cumplir con SR1.11 (imagen Paso 5.1.4).
Imagen Paso 5.1.4
Y configurar adecuadamente el uso del sistema y todo se tenga registrado en un logging file para cumplir con SR1.12 (imagen Paso 5.1.5).
Considerar los requisitos de diseño del Requerimiento Fundamental FR-2 (Control de Uso).
De acuerdo con las tablas de cumplimiento en el anexo B de la IEC/ISA 62443 – 3.3.; para el Security Level 1 (SL1) se deberán cumplir con los siguientes requisitos o los que aplique de acuerdo con la complejidad del EUC (Equipment Under Consideration). Serían los siguientes 8 requisitos:
SR2.1 Reforzamiento de Autorización
SR2.2 Control de Uso Inalambrico
SR2.3 Control de Uso de Dispositivos portatiles
SR2.4 Código Movil
SR2.5 Bloqueo de Sesiones
SR2.8 Eventos Auditables
SR2.9 Capacidad de Almacenamiento de Auditoria
SR2.10 Respuesta de fallas de almacenamiento de Auditoria
Si en nuestra arquitectura no habrá comunicación inalámbrica ni dispositivos portátiles, los requerimientos SR2.2, SR2.3, SR2.4 simplemente no aplican (NA)
Para el cumplimiento de los demás requerimientos, se deberá poner mucha atención en las configuraciones de las políticas del sistema (imagen Paso 5.2.1).
Imagen Paso 5.2.1
Así como del uso del sistema en su totalidad, con todas las aplicaciones que se usan en la arquitectura (imagen Paso 5.2.2).
NOTA: Para todas las aplicaciones de control que necesitan protección en ciberseguridad, es mandatorio la configuración adecuada del FactoryTalk Security.
Considerar los requisitos de diseño del Requerimiento Fundamental FR-3 (Integridad del Sistema), FR-4 (Confidencialidad de Datos) y FR-5 (Flujo de Datos restringidos).
Para estos requisitos, cada implementador tiene varias opciones para cumplir con ellos, depende de su experiencia y de la familiaridad de las herramientas que proponga. Lo importante es cumplir con los requisitos con técnicas adecuadas y se puedan demostrar que se están cumpliendo con los requisitos.
Para el Security Level SL1 se deben cumplir con los siguientes requisitos:
SR3.1 Integridad de Comunicación
SR3.2 Protección de Código Malicioso
SR3.3 Verificación de funcionalidad de Seguridad
SR3.4 Integridad de Software e Información
SR3.5 Validación de Entrada
SR3.6 Salida Deterministica
SR4.1 Confidencialidad de la información
SR4.3 Uso de Criptografía
SR5.1 Segmentación de red
SR5.2 Protección de límites de zona
SR5.3 Restricción de comunicaciones de persona a persona
SR5.4 Particionamiento de aplicaciones
En este ejemplo daremos una serie de posibles recomendaciones; no son las únicas, ni tampoco estamos diciendo que de esta manera se deben de realizar todas las implementaciones ya que es decisión del implementador.
Para cumplir con SR3.2 y SR3.3, es recomendable asegurar los componentes de control y HMI con ciertas restricciones como la que se muestra en la imagen Paso 5.3.1.
Imagen Paso 5.3.1
Para la protección de HMI debemos usar un antivirus, por ejemplo, Symantec Endpoint Protection.
El protocolo CIP Safety ayuda a nuestra arquitectura para cumplir con el SR3.1 (Comunicación Integra).
Para cumplir con SR4.1 se pueden asegurar rutinas críticas del controlador para que solo sean vistas y/o modificadas por usuarios confiables, así como las variables críticas de control evitar el acceso externo si es necesario para mantener el nivel de seguridad (imagen Paso 5.3.2).
Imagen Paso 5.3.1
Para cumplir con SR4.3 – Uso de Critografía, evaluar si es necesario implementar la tecnología CIP Security a este nivel y si no se implementa, deberá ser considerado en un nivel superior; cuando el patín del BMS sea conectado a la infraestructura del usuario final.
Para cumplir con SR3.4, SR5.1, SR5.2, SR5.3 y SR5.4, se deberá cambiar el switch de ethernet por un switch administrable y configurarlo para segmentar la red, proteger los límites de esta zona (BMS), restringir comunicaciones de otras aplicaciones que no sean las del propio sistema, etc.
En nuestro ejemplo consideramos un Stratix 5400, en donde debemos considerar las siguientes configuraciones:
Considerar los requisitos de diseño del Requerimiento Fundamental FR-6 (Respuesta Oportuna de eventos), y FR-7 (Disponibilidad de Recursos).
Estos dos requerimientos fundamentales tienen que ver con la respuesta y recuperación como lo indica el marco de referencia NIST y, son muy importantes porque pueden preveer grandes perdidas aún cuando el sistema sea atacado. Si tomamos medidas planeadas desde el diseño, tendremos un sistema más resiliente y las pérdidas podrían ser minimas.
Para el Security Level SL1 se deben cumplir con los siguientes requisitos:
SR6.1 Accesibilidad de registro de auditoria
SR7.1 Protección de Denegación de servicios
SR7.2 Gestión de Recursos
SR7.3 Respaldo del Sistema de Control
SR7.4 Recuperación del Sistema de Control
SR7.6 Configuración de Redes y Seguridad
SR7.7 Funcionalidad minima
Para cumplir con SR6.1 – Accesibilidad de registro de auditoría y SR7.3 – (Respaldo del Sistema de Control), se deberá:
Verificar un espacio de memoria adecuado para el registro de auditoría.
Tener políticas escritas y ser seguidas por el usuario para respaldo de configuraciones de los equipos (Programa de Control, HMI Displays, Stratix Configuration) para hacerlo de manera manual.
Configurar el switch administrable Stratix 5400 para aceptar una conexión fuera de la VLAN exclusiva (conducto) para acceso del registro de auditoría del BMS que está en el Panel PC ASEM 6300 y/o respaldo de aplicación y datos del FTView si el respaldo es hecho automáticamente afuera de la zona del BMS.
También configurar otra conexión (conducto) para el respaldo del control principal (GuardLogix) para cumplir con el respaldo automático fuera de la zona BMS.
Paso 6: Documentación del proceso de Diseño y Validación.
La documentación del proceso de diseño es muy importante debido a que demuestra que se siguieron los pasos de implementación del estándar IEC/ISA 62443, así mismo se documenta las acciones requeridas para proteger el control por el usuario final, y ser implementadas cuando este sistema se integre a la infraestructura de control de la planta.
La validación de ciberseguridad del sistema también es importante; como cualquier otro proyecto de gestión de riesgo, se deberá validar el diseño ciberseguro por una compañía tercera que entregue documentación de las pruebas hechas y valide de acuerdo con el Security Level de diseño.
Con este modelo de diseño basado en el estándar IEC/ISA 62443 – 3.3 pasamos de una Arquitectura de Control Vulnerable a una Arquitectura de Control Protegida Security Level 1 (imagen Paso 6.1).
Imagen Paso 6.1
¡Suscríbase!
Reciba directamente en su correo nuevos lanzamientos de aplicaciones y otras novedades del Innovation Center
