La CiberSeguridad es un problema complejo, muy complicado por tener cuatro dominios técnicos (TI, empresa, control de procesos y sistemas de seguridad) con diferentes propósitos, objetivos y posibles peligros y riesgos, y con frecuencia con personal diferente involucrado. Estas son algunas de las consideraciones para realizar la evaluación de seguridad requerida en la Cláusula 8.2.4 de la nueva Segunda Edición de la norma IEC 61511-1: 2016 para sistemas instrumentados de seguridad (SIS). Algunas de las consideraciones también se aplican a los sistemas de seguridad no SIS y a los sistemas de control industrial y automatización (ICAS) más amplios.
El propósito del SIS es garantizar que fabricamos productos de manera segura. En su mayor parte, no está involucrado en cómo se controla el proceso o cómo la información de proceso y producción normalmente se recopila o manipula fuera del SIS, solo si el proceso excede los límites de seguridad. Tenemos algunas preocupaciones secundarias de que el sistema de seguridad no afecta la producción a través de viajes espurios excesivos o altas tasas de mantenimiento.
Los amplios dominios cibernéticos se ilustran conceptualmente en la Figura 1, donde se puede ver que el SIS está esencialmente integrado en el sistema IACS y, en general, se considera parte de él. Es importante comprender el papel que desempeña el SIS en el IACS para comprender cómo podría ocurrir un ataque cibernético en un SIS, y qué consecuencias cibernéticas podrían realizarse físicamente y conducir a una condición peligrosa.
Figura 1: Los dominios cibernéticos
El sistema instrumentado de seguridad (SIS) está integrado en el sistema de control industrial y automatización (ICAS) junto con el sistema del sistema de control de procesos básico (BPCS), donde está sujeto a la misma variedad de amenazas cibernéticas.
Cuando salió la primera edición de IEC 61511-1 hace unos 14 años (y ANSI/ISA S84: 1996 antes), las preocupaciones de CiberSeguridad y las amenazas cibernéticas no fueron muy bien reconocidas en las industrias de procesos. El estándar 61511-1 2003 1st Edition sí reconoció posibles amenazas de seguridad para SIS. Estas amenazas se debieron principalmente al acceso inadvertido o no autorizado y a los cambios que afectaron la integridad de la seguridad del SIS. Los cambios no autorizados o mal administrados han sido reconocidos durante mucho tiempo como un peligro para la seguridad (por ejemplo, Flixborough, 1974), lo que condujo a la gestión actual de las regulaciones de la Gestión del Cambio (MOC).
Las preocupaciones de seguridad en ese momento (y todavía son preocupaciones hoy en día) fueron principalmente el acceso físico no autorizado (por ejemplo, armarios bloqueados, control de acceso a edificios, etc.), acceso a programación (por ejemplo, cerraduras, paneles de programación y computadoras, dongles, etc.) y controles de contraseña. La mayoría de las amenazas de seguridad se consideraban internas, por ejemplo, cambios inadvertidos, no autorizados y/o indocumentados, problemas causados a empleados descontentos, etc.
El reciente avance rápido de la tecnología del sistema de control digital, los avances en el poder de cómputo y la interconexión del mundo a través de Internet, intranets, inalámbricas y ahora, Internet of Things (IoT) e Industrial IoT (IIoT) han abierto una caja de oportunidades de Pandora, pero también desatan al lobo grande y malo en forma de amenazas crecientes de ciberseguridad.
Una diferencia clave en las amenazas de seguridad actuales y lo que estaba en la 1ra. Edición 61511-1 es que ahora hemos pasado de una arena pequeña (su empresa) que incluía amenazas internas, físicas a una arena de amenazas mucho más grande (el mundo) que puede incluir tanto amenazas físicas internas como amenazas de ciberseguridad externas, en gran medida invisibles, potencialmente provenientes de todo el mundo.
Requisitos de evaluación de seguridad de la segunda edición
IEC-61511-1 2nd Edition reconoció la creciente amenaza de ciberataques para SIS y agregó requisitos adicionales para ayudar a reducir el riesgo. El cumplimiento de la nueva IEC-61511-1 Segunda edición de 2016 exigirá que el SIS cuente con una evaluación de seguridad (Cláusula 8.2.4) y que el diseño del SIS sea tal que brinde la resistencia necesaria contra los riesgos de seguridad identificados (Cláusula 11.2.12). La cláusula 8.2.4 detalla un esbozo general de lo que se debe lograr en una evaluación de seguridad, pero no mucho sobre lo esencial de la evaluación. La metodología básica es una forma de reduccionismo: desglosar el dominio SIS en piezas de equipo más pequeñas, analizar las vulnerabilidades del equipo, evaluar las protecciones existentes que limitan la exposición de las vulnerabilidades a una brecha de seguridad física o ciberataque, proporcionar protecciones adicionales para reducir el riesgo a un nivel aceptable en función de los criterios de riesgo corporativo, y documentar la evaluación de riesgos. Al utilizar una metodología de reducción, se debe tener cuidado para no perder las amenazas a nivel del sistema.
El proceso general de evaluación de riesgos es similar a un proceso de riesgos y evaluación de riesgos (H&SE). En algunos casos, un ataque cibernético en el IACS podría iniciar una causa similar en efecto a una falla del equipo o error humano en un proceso H&SE, donde otras capas de protección (suponiendo que algunas de ellas no hayan sido derrotadas en el proceso del ciberataque) entrarán en juego para llevar el proceso a un estado seguro. Una capa estándar de análisis de protección (LOPA) evitaría la realización de esta amenaza cibernética en un peligro. En este caso, la capacidad del SIS para resistir la derrota de la función de seguridad SIS puede ser primordial para lograr un estado seguro de la planta.
Dominio cibernético SIS
Filosóficamente, el SIS se entiende mejor en el contexto de las capas de protección, donde el SIS es equivalente a una a tres capas de protección independientes (IPL) que protegen contra los peligros identificados determinados por un análisis de riesgo del proceso. La Figura 2 ilustra un ciberataque en el SIS donde un ciberataque en el sistema de control de proceso básico (BPCS) podría iniciar una causa equivalente a una falla normal del equipo o un error humano. Este mismo ataque podría llevar a la derrota de la alarma IPL, si está en el BPCS y el atacante tiene suficiente habilidad para manipular el BPCS.
Si el SIS está diseñado para proteger contra esa causa iniciadora particular, debe cumplir su función como una IPL y llevar el proceso a un estado seguro. Pero si el ataque también se dirige al SIS, la derrota de la función instrumentada de seguridad (SIF) que protege contra la causa de iniciación de BPCS también podría vencer las IPL para ese peligro, dejando la protección a las IPL mecánicas.
Figura 2: un vector de amenaza cibernética
Un ciberataque en el sistema de control de proceso básico (BPCS) que parece una falla normal del equipo o un error humano podría vencer a la capa de protección independiente de la alarma (IPL). Si el ataque también se dirige al SIS, la derrota de la función del instrumento de seguridad (SIF) también podría vencer las IPL para ese peligro, dejando la protección a los IPL mecánicos.
Si el ataque cibernético inicial se dirigió estrictamente al SIS y no al BPCS, la función de seguridad del SIS podría ser derrotada, dejando una falla peligrosa latente en el SIS. El ataque cibernético del SIS también podría iniciar un viaje espurio (uno o muchos), causando un incidente de seguridad o interrumpiendo la producción. Si los reinicios de software se utilizan en el SIS (frente a restablecimientos de campo), el ciberataque puede reiniciar automáticamente el SIF y volver a disparar más tarde, lo que lleva a una condición peligrosa.
Estos ciberataques SIS pueden ser manifiestos, por ejemplo, junto con un ataque cibernético simultáneo en el BPCS, o encubiertos al derrotar la función de seguridad del SIS mientras se espera una demanda de seguridad normal o un ciberataque posterior en el BPCS. Es importante darse cuenta de que el SIS generalmente no es la única IPL (s) que protege contra los peligros, que debe considerarse en cualquier evaluación de riesgos, y que el principal riesgo que nos preocupa es la realización física de un peligro.
También es importante comprender cómo se puede vencer a un SIS para proporcionar protección contra esos eventos. Por ejemplo, algunas de las formas en que un SIS/SIF puede ser vencido están colocando las funciones de seguridad en derivación sin que el operador esté consciente, colocando el solucionador lógico en un bucle infinito, cambiando los puntos de ajuste de disparo y alarma, desconectando la salida de la lógica, simulando las entradas, forzando las salidas, etc. Esta comprensión puede conducir a diseños de SIS que, además del esquema de protección de Zonas/Conductos, pueden ayudar a proteger contra los modos de falla específicos resultantes de un ciberataque.
Pasos de la evaluación de seguridad IEC-61511-1
Para realizar una evaluación de seguridad según el nuevo estándar IEC-61511-1, una de las primeras cosas que debe hacer es establecer el límite exterior del SIS en evaluación. Cuando se utilizan las zonas/conductos en el concepto de protección ISA/IEC-62443: 2010 e ISA TR84.00.09 (Figuras 3 y 4), los límites de zona del SIS son los límites para la evaluación de seguridad. Esto es algo similar en concepto a los nodos en un HAZOP. Una alternativa al HAZOP, el enfoque descendente sería utilizar un modo de falla y un análisis de efecto (FMEA), un enfoque ascendente, y observar cómo el sistema podría no lograr su propósito dado un evento de seguridad. O usa una combinación de ambos métodos para cubrir todas tus bases.
La evaluación de seguridad requiere una descripción de todos los dispositivos cubiertos. Estas descripciones de dispositivos deben incluir una lista de todas las versiones de hardware y software, incluidos los submódulos del dispositivo, para la gestión del cambio. Hay un viejo dicho famoso que el autor inventó esta mañana, y es: «Si no sabes lo que tienes, no puedes proteger lo que tienes».
Se debe identificar la información crítica de seguridad (por ejemplo, el punto de ajuste de alarma y disparo, parámetros del dispositivo de campo, parámetros de comunicación, etc.) dentro de los dispositivos y el sistema para permitir la detección de cambios no autorizados en los parámetros críticos para la seguridad. La descripción debe incluir todas las conexiones a otros dispositivos dentro del SIS, a dispositivos fuera del límite del SIS y a todos los dispositivos utilizados para fines no operativos (terminales de programación, conexiones de actualización, comunicadores de dispositivos de campo, equipos de calibración, sistemas de gestión de activos (AMS), cualquier conexión con el mundo exterior ya sea que estén activos o no, etc.). Esto debería incluir conexiones cableadas que pueden verse influenciadas por un ataque cibernético y cualquier conexión que ayude a proporcionar protección contra ataques cibernéticos (por ejemplo, un interruptor de habilitación de derivación con cable).
Figura 3: definir los límites
Un primer paso en una evaluación de seguridad bajo la nueva norma IEC-61511-1 es establecer el límite exterior del sistema instrumentado de seguridad (SIS) bajo evaluación. Cuando se utilizan las zonas/conductos en el concepto de protección ISA/IEC-62443: 2010 e ISA TR84.00.09, los límites de zona del SIS son los límites para la evaluación de seguridad.
Deben enumerarse las vulnerabilidades cibernéticas conocidas para cada dispositivo. Como parte de la generación de esta lista, las vulnerabilidades cibernéticas conocidas se deben analizar con el fabricante del dispositivo e investigar dentro de la industria. También se deben enumerar las vulnerabilidades de seguridad física para cada dispositivo y para el sistema en su conjunto. Hay software comercial disponible para hacer que este esfuerzo de inventario sea más fácil y ayudar a automatizar el monitoreo de cambios no autorizados y posibles problemas de seguridad.
Desarrollar una descripción de las amenazas de seguridad identificadas que podrían explotar las vulnerabilidades de los equipos enumerados y dar como resultado eventos de seguridad (incluidos ataques intencionales en el hardware, programas de aplicaciones y software del sistema operativo relacionado, así como eventos no deseados como resultado de un error humano). En este tipo de evaluación de riesgos es importante comprender los vectores de amenazas de seguridad (por ejemplo, cómo entra la amenaza en el sistema (puntos de acceso), cómo se accede al punto, la naturaleza del ataque, cualquier condición que facilite el vector de amenaza, el dispositivo o camino que toma el vector de amenaza para propagarse a través del sistema para llegar a un punto para una realización física en una condición peligrosa o indeseable que ocurra, y lo que es necesario que resulte en un incidente de seguridad).
Deben enumerarse los métodos para evitar que el vector de amenaza llegue a la vulnerabilidad del dispositivo y los métodos para mitigar el ataque cibernético o, en el peor de los casos, para recuperarse del ataque. También es importante tener en cuenta cómo estas intrusiones/amenazas cibernéticas podrían detectarse en el sistema, incluso si el sistema repelió con éxito el ataque, ya que pueden ser pruebas de su sistema.
Los ciberataques exitosos que conducen a una consecuencia de seguridad deberían investigarse tal como lo haría un accidente. Los ciberataques o intrusiones no exitosas deben tratarse como cuasi accidentes y deben investigarse adecuadamente para garantizar que la protección cibernética del sistema funcionó correctamente y la falla del ataque fue por diseño más bien una cuestión de buena suerte.
Debe determinarse una descripción de las posibles consecuencias de los eventos de seguridad y la probabilidad de tales eventos. Tenga en cuenta que IEC 61511-1 no define qué es un «evento de seguridad» y, por lo tanto, la definición de la consecuencia es un poco nebulosa. Un ciberataque exitoso podría verse como una consecuencia del personal de seguridad cibernética, pero para crear un peligro para la seguridad, debe haber una realización física del evento de seguridad que lleve a una propagación del efecto en un incidente.
Figura 4: Analice las amenazas
Al dividir el plano de zona/conducto del sistema de control de alto nivel (Figura 3) en un dibujo de zona de nivel del sistema SIS, se ilustran puntos de acceso secundarios como bases de datos de puntos de calibración, sistema de gestión de activos (AMS), Windows, etc. en el sistema SIS de nivel.
Un ciberataque exitoso en un dispositivo o sistema es una consecuencia intermedia (una causa inicial o la derrota de un sistema de seguridad) en una cadena de riesgo que puede incluir otras IPL que podrían proteger contra el peligro del proceso de desarrollo. Esta perspectiva conecta muchos de los efectos de un ciberataque en nuestros sistemas de seguridad y control de procesos en nuestra metodología de evaluación de riesgos de proceso normal (Figura 2).
Se requiere una determinación de la probabilidad del evento de seguridad, lo que nos lleva potencialmente al mismo marasmo que tenemos en las frecuencias de causa iniciadora de HAZOP/LOPA y las tasas de falla del equipo SIS. Simplemente no tenemos suficiente información para determinar la probabilidad de un tipo específico de ataque cibernético (no aleatorio) o una violación de seguridad (error sistemático) que ocurre en un sistema en particular, o las tasas de falla del equipo de protección para repeler el ciberataque, o las tasas de falla de hardware del equipo de protección. Parece probable que la incertidumbre para determinar la probabilidad sea alta, lo que lleva a un diseño conservador, o peor aún, no habrá una base de ingeniería sólida para aceptar dicho cálculo de probabilidad. ISA TR84.00.09: 2017 Apéndice D proporciona algunos ejemplos de cálculos.
Es necesario considerar varias fases del ciclo de vida, como el diseño, la implementación, la puesta en marcha, la operación y el mantenimiento, en la evaluación de seguridad. Al igual que sus contrapartes de seguridad de procesos, HAZOP/LOPA, una evaluación de seguridad SIS debe ocurrir durante las diversas fases del ciclo de vida de seguridad basado en un plan de gestión de riesgos general para mitigar los posibles riesgos de seguridad.
Una vez que los riesgos han sido determinados, se deben identificar los requisitos para medidas adicionales de reducción de riesgos para reducir el riesgo por debajo de los criterios de riesgo corporativo. Se debe incluir una descripción de cómo se logrará la reducción del riesgo en la evaluación de seguridad.
Hay varias notas de importancia en la Cláusula 8.2.4. La nota 1 señala la guía de seguridad del SIS que se proporciona en el informe técnico y las normas ISA TR84.00.09, ISO/IEC 27001: 2001 e IEC-62443: 2010. ISO/IEC 27001: 2001 es un estándar de seguridad cibernética de TI de propósito general, mientras que IEC-62443: 2010 es un estándar que cubre seguridad cibernética para sistemas de automatización y control industrial. El informe técnico de ISA TR84.00.09 cubre la ciberseguridad y el ciclo de vida de la seguridad funcional. Cabe señalar que este informe técnico es sustancialmente más largo que el estándar IEC 61511-1.
La guía de seguridad proporcionada en el estándar ISA/IEC 62443: 2010 y el informe técnico ISA TR84.00.09 abogan por dividir el IACS en agrupaciones lógicas de hardware llamadas zonas, y las rutas de comunicación o interfaces entre zonas, llamadas conductos, para controlar la interacción entre el varias zonas. Esto tiene la ventaja de poder controlar las rutas que un vector de amenaza cibernética puede propagar a través de un sistema y de poder aislar lógicamente el sistema en caso de que sea atacado, lo que permite que el sistema mitigue el ataque o continúe funcionando. Parte, o funcionar hasta que el sistema pueda apagarse de manera segura.
La división de ICSC en zonas lógicas también proporciona una base para seleccionar límites de evaluación de seguridad SIS. Esta disposición de Zonas y Conductos se puede documentar fácilmente conceptualmente, y la Figura 3 ilustra un dibujo conceptual de conducto/zona (está un poco ocupado y muestra más que las zonas y conductos simples). Tenga en cuenta que el sistema de control y SIS se pueden dividir en varias zonas para sistemas más grandes. La Figura 3 también muestra una zona del SIS delineada.
La Cláusula 8.2.4, Nota 2 dice que la información y el control de las condiciones de contorno necesarias para la evaluación del riesgo de seguridad generalmente residen con el propietario/compañía operadora de una instalación, no con el proveedor. Como todas las evaluaciones de riesgos, la carga recae en el propietario/operador para realizar la evaluación de riesgos e implementar los resultados de la evaluación. Esto no exime al equipo o proveedor de software de la obligación de proporcionar un entorno de seguridad cibernética segura para sus equipos, ni de notificar de inmediato al propietario/operador del equipo cuando se ha identificado una vulnerabilidad de seguridad cibernética o se ha detectado una infracción cibernética de sus equipos. El propietario/operador tiene la obligación inversa.
La nota 3 establece que la evaluación de riesgos de seguridad SIS se puede incluir en una evaluación de riesgos de seguridad de automatización de procesos general. Esta es una consideración razonable, pero existen diferencias filosóficas en los propósitos de los diferentes sistemas, sus vulnerabilidades y los puntos de acceso. El propósito del sistema de control es mantener el proceso dentro de límites de operación seguros mientras se hace un producto de calidad de manera eficiente. El propósito del sistema SIS es no permitir que el proceso exceda el límite de operación segura, con un mínimo de viajes espurios y mantenimiento. Ciertamente, hay una superposición entre los sistemas que debe abordarse en el plan general de riesgos.
La nota 4 es importante porque establece que la evaluación del riesgo de seguridad del SIS puede enfocarse desde una SIF individual a todas las SIF en SIS o dentro de una empresa, nuevas y existentes. Una empresa debe tener un plan de evaluación de riesgos que cubra la evaluación de las ciberamenazas del SIS y cómo se ajusta al plan de evaluación de riesgos de seguridad del proceso. Obviamente, se debe realizar una evaluación de seguridad SIS inicial para cumplir con IEC-61511 2nd Edition; sin embargo, aunque no es obligatorio, realizar una evaluación de seguridad en el SIS IEC-61511 1st Edition existente se consideraría una buena práctica de ingeniería.
Una vez que se haya realizado la evaluación inicial de seguridad y se haya actualizado el SIS desde una perspectiva de protección de seguridad, se deberán realizar evaluaciones de seguridad posteriores bajo Gestión de Cambio (MOC) para nuevas instalaciones, para SIF adiciones a equipos existentes y para SIS cambios de diseño o configuración. La evaluación de seguridad también debería revisarse cuando se hayan identificado nuevas vulnerabilidades de seguridad que puedan afectar al SIS en la industria o el fabricante del equipo; después de una auditoria de seguridad si se han encontrado deficiencias; o cuando se revalida la evaluación de seguridad (nominalmente cada tres años o menos).
Documentación de seguridad de SIS
Se deberán desarrollar tipos de documentación adicionales para permitir que el equipo de evaluación de seguridad realice una evaluación de seguridad, documentar el estado de seguridad actual del sistema, mantener la base de datos de información crítica de seguridad y poder realizar auditorias continuas y periódicas contra cambios no autorizados.
Muchas compañías tienen dibujos de arquitectura de sistema de alto nivel de sus sistemas de control y seguridad que podrían adaptarse a zonas y dibujos de conductos. Es probable que el sorteo de nivel superior tenga que dividirse en sorteos de nivel medio e inferior, como zonas individuales y dibujos de equipo, para mostrar todos los puntos de acceso, equipo y medidas de protección, además de tener espacio para la información necesaria para una evaluación de riesgos de seguridad. La Figura 4 ilustra un desglose de la zona de IACS / dibujo de conductos de alto nivel en solo un dibujo de zona de nivel de sistema SIS. Esta figura también ilustra puntos de acceso secundarios (por ejemplo, bases de datos de puntos de calibración, AMS, Windows, etc.) a nivel del sistema SIS.
Por lo general, será necesario realizar un mayor desglose del dibujo SIS de zona/conducto para los planos de seguridad del equipo, que ilustraría una pieza individual de equipo SIS o una agrupación lógica de equipos desglosados en módulos individuales si el diseño es modular, documentando los números de modelo, Números de serie y versión de hardware y software, puntos de acceso de equipos, protecciones identificadas y otra información para realizar una evaluación de seguridad y para ayudar a mantener la base de datos de información de seguridad. Gran parte de este esfuerzo debe realizarlo a nivel de ingeniería personas que estén familiarizadas con las piezas individuales del equipo y sus preocupaciones de seguridad, y luego revisadas por el equipo de evaluación de seguridad (de lo contrario, esta evaluación será tan larga y aburrida como muchas otras). HAZOP se ha convertido).
Aunque no siempre se menciona, los ciberataques exitosos que no sean interrupciones al azar dependen del conocimiento del sistema que se va a atacar, sus protecciones y el proceso bajo control. Para conocer el sistema de destino, generalmente se requiere un reconocimiento de ese sistema, tal vez más de uno. Esto puede ocurrir a través de medios cibernéticos y puede significar ataques menores exitosos, débiles y/o fallidos en el sistema para recopilar información del proceso de la empresa e IACS y conocer qué protecciones cibernéticas existentes existen en el sistema.
Los esfuerzos indirectos para recopilar información de proceso también pueden incluir reconocimiento cibernético en los sistemas informáticos potencialmente menos seguros de la planta, como bases de datos de dibujo, descripciones de procesos, narrativas de procesos, procedimientos operativos estándar, bases de datos HAZOP/LOPA, base de datos de calibración, sistema de gestión de activos (AMS), base de datos de PSV, etc.
Incluso tiene que haber preocupación por la información en papel (generamos una gran cantidad de documentos no controlados sobre el proceso para nuestros HAZOP y LOPA). Es obvio que hay muchas puertas (puntos de acceso) en nuestro sistema que deben analizarse, controlarse o cerrarse para garantizar que cubrimos todas nuestras bases de seguridad.
Conclusiones
Es una buena práctica de ingeniería en esta época de amenazas cibernéticas y otras amenazas a la seguridad realizar una evaluación de seguridad en el sistema IACS, que incluye SIS y no SIS. Para cumplir con IEC-61511-1 2nd Edition Cláusula 8.2.4, se debe realizar una evaluación de seguridad en el SIS y cualquier diseño de SIS nuevo o revisado debe tener la resistencia necesaria contra los riesgos de seguridad identificados (Cláusula 11.2.12).
La mayoría de los consultores SIS más importantes, como Kenexis, AeSolutions, Exida, WisePlant, etc., ofrecen servicios competentes de CiberSeguridad para ayudarlo, pero le corresponde al propietario/operador tener la experiencia interna para poder hacer esta evaluación, o para menos involucrarse completamente en este esfuerzo para comprender qué componentes del sistema SIS están en riesgo; cuáles son los vectores de amenaza de seguridad; cuáles son las vulnerabilidades del sistema; cómo limitar el acceso al sistema, los flujos de las vías internas y las vulnerabilidades de los sistemas y los componentes a los vectores de amenazas; cómo minimizar las amenazas de seguridad; y cómo recuperar la seguridad, si es necesario. Cuanto mejor entienda sus sistemas SIS e IACS desde una perspectiva de seguridad, mayores serán las posibilidades de que esté preparado para repeler cualquier ataque de seguridad. Una evaluación de seguridad SIS integral es un buen paso hacia adelante.
Fuente: Para ver la publicación original visite Aquí
Get Involved & Participate!
Comments