Sistemas de Paro de Emergencia Inmerso en DCS: Efectos Colaterales a Considerar

Robin MCCrea-Sleele,
Premier consulting service TÜA FSExpert
InTech México Automatización,
Edición Abril  – Julio 2007

INTRODUCCION

Antes de someterse a una nuevo medicamento sabemos que debemos analizar los factores secundarios que en ocasiones pueden hacernos enfermar aún más que la misma enfermedad que pretendemos tratar en primer lugar.

Estos mismos principios aplican a nuestros procesos de seguridad. Después de todo estamos protegiendo la vida, el ambiente y la producción. Los beneficios potenciales provenientes de un sistema instrumentado de seguridad (SIS) inmenso en un sistema de control distribuido (DCS) que a primera vista sonaría atractivo, estarían sobrevaluados n su instante si son al costo de la seguridad.

Ha habido enormes cantidades de campañas publicitarias de supuesta integración sin parche, facilidades para sincronización del tiempo, eliminación de lectura a mapa de datos, interfaz a operadores y repuestos comunes.

La apertura a la conectividad es grandiosa hasta toparse con un sabotaje o la amenaza de un ataque cibernético a la seguridad. Las herramientas graficas modernas e interfaces comunes son realmente amigables, hasta que interfiere el factor humano con la seguridad. Las causas comunes y los errores sistemáticos pueden incrementarse hasta el punto de comprometer la seguridad

Los bloques funcionales para procesos de seguros están a la defensa en el fondo. Las capas de protección independientes (IPL, “Independent protection Layers”) deben ser eso, independientemente. Para cumplir con este requisito, las IPL’s deben encontrarse libres de  causas comunes y errores sistemáticos de diseño.

Los Sistemas Instrumentados de Seguridad inmersos en el DCS pueden obtener la certificación de separación y no interferencia “funcional”. Sin embargo, ¿Podrán probar independencia al efecto de reclamar crédito por el DCS como un IPL?

Las implicaciones de no haber permitido crédito para el lazo o alarmas en el DCS como en IPL no son en lo más mínimo triviales. Además de comprometer la seguridad debido a causas comunes, si la meta SIL(x) de una Función Instrumentada Segura (SIF, “Safety Instrument Function”) fue asignada asumiendo el riesgo de reducción de crédito para la DCS como un IPL, la implementación con un SIS inmerso en el DCS requerirá un SIL(X+1). Esto significa mayor requerimiento en la redundancia de la instrumentación de campo, con el correspondiente incremento en los costos iniciales del proyecto, mayores costos de mantenimiento y pruebas.

Así que, ¿Cuáles son los beneficios de un SIS inmerso en el DCS una vez que hemos comprometido la seguridad e incrementado los costos del proyecto, así también los costos del ciclo de vida?, ¿Vale la pena incrementar el riesgo?

Un pasatiempo de proveedores no debería comprometer el objetivo principal de una planta. La seguridad y la productividad son primero… y segundo… y tercero.

Usted puede obtener una integración inteligente y una interface segura con programas y equipos DCS / SIS individuales, independientes y diversos, sin efectos colaterales, al mismo tiempo que mantiene su objetivo principal de seguridad en proceso y productividad a menores costos en el ciclo de vida.

DÓNDE PONER UN LÍMITE

Algunos proveedores ofrecen diferentes grados de integración y soluciones. La pregunta es cómo proveer un control integrado y soluciones seguras con funcionalidad avanzada y productividad, sin comprometer la seguridad. Así que ¿Dónde poner el límite?

La respuesta puede descansar en la reciente encuesta “Zoomerang” para empresas que operan plantas procesadoras químicas, de gas y petróleo realizada por Invensys.

La respuesta a la encuesta reveló que el 78% de los 200 encuestados se apegaban a la estricta separación de seguridad y control para protección y seguridad.

Adicionalmente, 74% de los encuestados indicó que las capas de protección independiente (lPL) son críticas y el 66% opinó que las causas comunes son su mayor preocupación. En la misma encuesta, solo 8% indicó que la “diversidad” no era motivo de preocupación, mientras que el 89% de los usuarios comentó que su capacidad de realizar la mejor elección en clase eran importantes ambas la seguridad y el control.

Los resultados de esta encuesta, combinados con una serie de discusiones profundas con una mayor cantidad de usuarios finales de industrias procesadoras alrededor del mundo, indica claramente que la mayoría de los usuarios finales marcó el límite al momento de mantener las capas independientes de protección y diversidad entre su seguridad y los sistemas de control de proceso.

Así que adivinen cuál es la peor pesadilla para un gerente de planta “Un Sistema Instrumentado de Seguridad en el DCS, donde un malicioso cyber agresor sea capaz de penetrar los muros de protección (“firewalls”) del sistema de control conectados a la red local LAN o al WAN Corporativo, que pueda invalidar el 515 y que utilice el DCS para volar la planta”

LA IMPORTANCIA DE LAS CAPAS INDEPENDIENTES DE PROTECCIÓN (LPL)

Todo el fundamento del concepto de “Defensa Profunda (03)” y “Capas de Protección Independientes (lPL)” en el corazón de todos los estándares de seguridad (incluyendo lEC 61508 así como lEC 61511), es que cada capa de. Protección, Incluyendo ambas control y seguridad, debería ser completamente Independiente.

Algunas de las razones para este requerimiento básico son eliminar falla~ comunes minimizar errores sistemáticos y proveer seguridad contra acceso Involuntario, sabotaje y ataques cibernéticos. Fusionar dos capas de protección es un incidente seguro que estará esperando a que suceda.

El Proceso de seguridad se basa en una defensa profunda y en la separación de los sistemas de control y seguridad operando de manera independiente. Cada IPL está diseñado para proteger independientemente contra los peligros pa~a los cuales fueron diseñados a salvaguardar.

Una de las funciones principales de los DCS es el reducir el número de demandas del 515. Una demanda en el 515 implica que el sistema de control falló en no mantener el proceso en el rango de seguridad y que el proceso ahora dependería del 515 para protegerse contra los peligros.

La definición del lEC 61411 -1 sobre operación en modo de demanda en el proceso industrial demuestra la intención del requerimiento de total independencia de las capas protectoras del BPCS (“Basic Process Control Systems”) y 515

NORMA LEC 61411-1, CAPÍTULO 3.2.43.1

Modo de Demanda en la Función Instrumentada de Seguridad donde una acción específica (por ejemplo, el cierre de una válvula) se lleva a cabo respondiendo a condiciones del proceso u otras demandas. En el caso de una falla peligrosa de la función instrumentada de seguridad, un daño potencial solo ocurriría en el caso de una falla en el proceso o el BPCS.

En esencia, la función de los IPL’s es tal que un daño potencial solo ocurriría en caso que ambos BPCS y 515 fallen.

Esto nos da pie a plantearnos el siguiente escenario: Si el BPCS y 515 están integrados de manera que ambos fallaran simultáneamente debido a cé!usas comunes o fallas sistemáticas, la operación estaría efectivamente en “modo·continuo”, con la combinación de DCS/SIS funcionando como un sistema de control crítico. En este caso, todo el objetivo de la capa de protección 515 estaría perdido.

Un estudio realizado recientemente por la Universidad de Ingenieria Civil de Berkeley en California, reportó que la Corp. de Ingenieros encargados de construir y supervisar los diques contra huracanes empezaron a cambiar su cultura de seguridad a eficiencia a mediados de 1970. El huracán Katrina descubrió los problemas de diseño sistemáticos de ingeniería 30 años después. En la industria de procesamiento, las ramificaciones de las tentaciones por “cruzar la barda” fusionando las IPL’s solo sería descubierto en caso de un desastre químico mayor que pudiera ocurrir en el futuro.

Aquéllos usuarios de la industria procesadora que se encuentren en la encrucijada deberían comprender las ramificaciones potenciales que implica comprometer la seguridad fusionando capas de protección independientes.

Mantener estas capas independientes es claramente el camino hacia cero compromisos, el camino que reducirá el riesgo a un nivel tan bajo como la práctica lo permita (ALARp, “A Level As Low As Reasonably Practicable”).

INTERPRETACION DE LOS ESTÁNDARES DE SEGURIDAD

La Cláusula 11.2.4 del lEC 61511-1 afirma que el BPCS (Basic Process Control System) deberá ser diseñando para estar separado e independiente hasta el punto que la integridad y funcionalidad del 515 no se vea comprometida.

Muchos proveedores de automatización pareciera que han selectivamente interpretado este párrafo para decir que los estándares no requieren separación física o diversidad.

De cualquier manera, otra sección del mismo estándar lEC 61511-1 en la cláusula 9.5 indica los requerimientos para prevenir causas comunes, modo común y fallas dependientes. La cláusula 9.5.2 indica que la evaluación deberá considerar (a) independencia entre las capas de protección, (b) diversidad entre las capas de protección, (c) separación física entre las capas de protección y (d) causas comunes de fallos entre las capas de protección y las BPCS.

La pregunta es ¿Cómo ajustarse a la cláusula 11.2.4 sin una separación física y diversidad? lEC 61508 e lEC 61511 saben que es virtualmente imposible evaluar el índice de fallas de un programa y más aún no pueden cuantificar la meta objetivo para fallas sistemáticas

Intentar solucionar el problema de la separación y diversidad con una gran confiabilidad y auto diagnóstico no es definitivamente la aproximación correcta. Enfocarse únicamente en el PFD reduce el criterio a la confiabilidad de la ingeniería, lo cual no puede conseguir seguridad por si misma. Los errores sistemáticos, errores de causa común y errores de software, conforman un componente integral de la valoración global de seguridad. .’

La parte 1 del ISA TR84.00.04 está diseñada para ser una guía en la interpretación e implementación del lEC 61511. Este reporte técnico tiene muchas búenas recomendaciones incluyendo la sección 4F del anexo F, donde indica la separación física y diversas del SIS como el elemento que ha servido bien a la industria y como la manera de virtualmente eliminar fallas de modo común.

Aunque nadie reta las ventajas de la separación física y la diversidad, el problema, para algunos, parece haber caído a “Cuan lejos puedo empujar la interpretación de las normas?”. Sub dimensionar el diseño de sus sistemas para cumplimiento de párrafos selectivos mientras se ignora la intención de la normativa, no conduce a proveer un ambiento seguro de trabajo a través de las mejores practicas de ingeniería.

La diferencia entre tomar decisión “basada en riesgo” e “informada sobre riesgo” es que los números solo debieran usarse como una aportación para tomar una decisión, más que una medida absoluta. La “Defensa a fondo” debería ser la piedra angular de cualquier diseño de sistema de seguridad.

Como usuario con responsabilidad en la seguridad del sistema, uno no debería cegarse por nueva terminología de mercado tal como “la funcionalidad integral separa seguridad y control”

La separación física y la diversidad son las únicas maneras de garantizar la completa independencia de las capas de protección. Mezclar control y seguridad solo agrava el problema y el riesgo. Comprometer la seguridad para lograr flexibilidad en el diseño o un menor costo es una falta de conciencia.

¿ES SUFICIENTE UN CERTIFICADO TÜV?

Algunos pueden creen que se pueden esconder tras un certificado de cumplimiento. Sin embargo, la responsabilidad final recae sobre la gerencia operacional de la planta. No sobre el proveedor.

Los estándares de seguridad internacional requieren que los fabricantes cumplan con los documentos del SIS a la norma IEC61508. Un certificado de cumplimiento TÜV tiene grandes beneficios, pero como usuario ¿es eso todo lo que necesita? La gran mayoría de practicantes y las empresas con plantas operativas dirían que aunque esencial, la certificación de producto no debería ser el único criterio.

El cumplimiento de todas las fases de seguridad del lEC 61511, la asignación de los requerimientos de seguridad a todos las capas independientes de protección, así como la verificación, validación, auditorias y manejo del cambio son solo algunos de los requisitos para una implementación satisfactoria para la reducción de riesgos.

La certificación de un tercero en cuanto al cumplimiento del PLC de alta integridad SIS, validaría el diseño y la “seguridad ante fallas” idónea para ser usada en una función instrumentada de seguridad hasta el límite SIL determinado. No dice nada acerca de la vulnerabilidad ante disparos en falso, el cual es un problema que el usuario final debe evaluar basándose en las aplicaciones específicas.

Además, y extremadamente crítica, es el hecho que cuando un PLC de alta integridad SIS recibe la certificación, esta es realizada de manera bien aislada, con una revisión adicional de las comunicaciones de seguridad al equipo exterior y protección contra interferencia con la integridad de las funciones de seguridad.

Para los sistemas en los que el PLC SIS está inmerso en la plataforma de control del sistema (DCS), la certificación validará la no interferencia de las fallas en el DCS para que no afecten las funciones del SIS. ¿Es esto suficiente? Bien, pues el primer problema es que la certificación no hace nada para evitar las causas comunes de fallas en el SIS y DCS, las cuales están basadas en la misma plataforma del software / hardware.

Ninguna dice algo respecto a los errores sistemáticos inherentes al usar la misma plataforma para SIS y DCS. La certificación básicamente valida la “separación funcional” y la no interferencia de las fallas del sistema de control en el SIS, muros de protección (“firewalls”) y protección de acceso basados en palabras claves.

¿Qué hay acerca de la independencia de las capas de protección en la planta? Esto no forma parte del certificado del PLC del SIS. Esta es una responsabilidad de la empresa operadora de la planta.

Cumplir con los requerimientos de “separación funcional” del lEC 61511 es suficiente para la obtención de la certificación TÜV, pero cuando el SIS está inmerso en el sistema de control, esto elimina el crédito que pudo obtenerse del DCS

como una capa de protección independiente (IPL). Una capa de protección independiente necesita ser justamente eso, independiente

Si un error de causa común puede afectar ambos el DCS y el SIS, entonces no se puede dar crédito al sistema de control como una capa de protección.

Por lo tanto, a pesar que una certificación TÜV para cierto límite de capacidad SIL para un PLC SIS valida su uso en una función separada, una gran precaución necesita ser tomada en cuenta en la implantación global de una solución que utiliza una plataforma común DCS-SIS de acuerdo a los requerimientos de planta para reducción de riesgos.

Un reciente estudio realizado por una empresa de refinación y corporación de energía de clase mundial, determinó en la revisión realizada a la certificación TÜV del SIS inmerso en el DCS, que aunque sin interferencia, la separación de BPCS-SIS no sería satisfactoriamente adecuada como una IPL. Esta compañía concluyó que debido a la existencia de rastros de comunicación comunes por ambos equipos BPCS y SIS en el mismo medio, no se puede dar crédito al BPCS como una capa de protección independiente.

CRÉDITOS PARA CAPAS DE PROTECCIÓN INDEPENDIENTES (LPL)

En las etapas iniciales de diseño  del SIS, los daños son identificados y los requisitos de seguridad se asignan a cada capa de protección. Los análisis de las capas de protección (LOPA, “Layer Of Protection Análisis”) es una de las metodologías más populares usadas para determinar el SIL en cada función instrumentada de seguridad (SIF).

LOPA da crédito a todas las capas de protección independientes disponibles (IPL) que califican en los requerimientos de la norma lEC 61511 . Durante la evaluación de LOPA, el DCS es considerado en diversas ocasiones como un IPL y el máximo crédito disponible en estándares es tomado (10-1 or RRF= 10).

Tomando un factor de riesgo reducido (RRF) de 10 en los DCS como un IPL tiene un peso considerable en los requerimientos finales SIL para el SIF. Un sistema de control que califica como una IPL reducirá sustancialmente el índice de demandas del SIS. De hecho, el SIL del SIF será una sola orden de mayor magnitud si el DCS no-califica como un IPL.

Considerando lo mencionado arriba, durante la fase de diseño de pormenores del SIS, es muy importante verificar las asunciones realizadas durante la fase de asignación del SIL.

Por ejemplo, cuando un estudio LOPA determina la necesidad de una función instrumentada de seguridad SIL2, basado en el crédito tomado para todas las IPL’s incluyendo una RRF de 10 para el sistema de control, la fase de verificación debe asegurarse que todos las asunciones sigan vigentes. Si de alguna manera el PLC

SIS se encuentra inmerso en la misma plataforma de hardware/software que el DCS entonces el sistema de control no calificaría más como un IPL y el crédito del RRF sería nulo. Como consecuencia, los requerimientos del SIF se verían incrementados en una magnitud a un SIL 3.

Una certificación TÜV para un PLC SIS inmerso en una plataforma DCS valida la separación funcional y la no interferencia del sistema de control en las funciones de seguridad. No obstante no se puede dar crédito al DCS como una capa de protección independiente (IPL) y los potenciales requerimientos de todas las SIL se incrementarían de manera real. Una planta con requerimientos de funciones instrumentadas de seguridad SIL 1 Y SIL 2 acabarían por requerir SIL 2 Y SIL 3. Esto significa un incremento en costos de instalación, mantenimiento y pruebas.

Lo peor de todo es que si durante el LOPA se requiriera un SIL 3 con crédito para el DCS como un IPL, usando un PLC SIS inmerso al DCS, se volvería en un requerimiento de un SIL 4, lo cual significaría volver a la mesa de diseño.

ASUNTOS DE CYBER-SEGURIDAD

De todos es bien sabido cómo los piratas cibernéticos (“hackers”), virus y otros programas troyanos, gusanos, etc. Pueden penetrar los muros de protección (“firewalls”), romper los accesos de seguridad y en general crear estragos en el sistema de una computadora.

La vulnerabilidad  de un sistema de seguridad “inmerso” a un sistema de control que sucesivamente se encuentra conectado a un sitio LAN y/o WAN Corporativa es exponencialmente incrementada.

Los procesos de monitoreo remoto, así como los diagnósticos remotos, mantenimiento y la administración de recursos a través de la conexión de red se han vuelto herramientas operativas muy eficientes.

Sin embargo, los muros y sistemas de protección de acceso son solo otro reto para los piratas. Con el tiempo y poniendo atención son eventualmente rotos. Los sistemas de seguridad necesitan ser asegurados como una última línea de defensa.

Una planta computarizada de tratamiento de desperdicios en QueElnsland, Australia, fue pirateada por un individuo que trabajó para el contratista que instaló el sistema y estaba furioso ante el rechazo a una vacante de trabajo.

El pirata de la red desvió millones de galones de material residual en los ductos y ríos.

Los empleados con acceso a información, empleados disgustados, piratas cibernéticos y terroristas, .son toda una amenaza a la industria de procesamiento. La empresa Media Corp News Asia reportó en Octubre 4 de 2005 que 500 piratas en NorCorea contaron con un programa de entrenamiento militar de cinco años con el objetivo de penetrar los sistemas de Sur Corea, Estados Unidos y Japón.

Incluso múltiples muros (“firewalls”) y sistemas de detección de intrusos no son suficientes. Todos los sistemas son vulnerables. No hay tal cosa como la absoluta seguridad, solo capas de protección.

LA SOLUCIÓN: INTEGRACIÓN INTELIGENTE

Las supuestas ventajas de integración total, la eliminación de cartografía así como los bajos costos de hardware y entrenamiento al usar una plataforma embebida común se pagan con el costo de la seguridad. De hecho, los costos del ciclo de vida son más elevados, desde el punto de vista económico, de seguridad personal, el medio ambiente y la comunidad.

Una preocupación adicional es la administración en el largo plazo de un SIS inmerso, donde las actividades del día a día se convierten más predecibles y menos flexibles que en sistemas independiente ·y diversos. La validación en la gerencia del cambio conlleva a procesos más complicados de mayor envergadura. Esta aproximación a la solución deseada, ciertamente conlleva demasiados contratiempos.

Es más seguro, otorgar un requerimiento SIL menor e implantar a menor costo la separación física y diversa en los sistemas de control y seguridad con una integración inteligente al nivel de la información, configuración, administración de activos e interfaz de operación. Todas las capacidades de diagnóstico de campo, administración de activos (incluyendo pruebas parciales), pueden ser implementadas efectivamente a través de una integración inteligente. La escala está fuertemente inclinada en contra de tratar de mezclar la seguridad y el control en la misma plataforma.

0
Compartir:

Dejar un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.