CIBERSEGURIDAD Y SEGURIDAD DE PROCESOS

A lo largo de las últimas décadas, la práctica del control industrial ha evolucionado hacia sistemas de mayor interactividad y facilidad de utilización. Para ello, la interconectividad de sistemas ha sido clave. Hoy en día, la práctica totalidad de las plantas de procesos disponen de sistemas de control automático que, a menudo, se imbrican en los diversos niveles de digitalización de la compañía: desde el nivel de campo (instrumentos, actuadores, relés…) hasta el más alto nivel de servidores corporativos.

T al como es una constante en la mayor parte de actividades humanas, estas mejoras han generado un riesgo. En este caso, el de ser víctimas de un ataque malintencionado que altere el funcionamiento previsto del sistema de control automático de la planta y pueda, por tanto, provocar daños materiales, a la calidad del producto o, en el límite, un accidente con daños potenciales a las personas, el medio ambiente y los activos. De esta forma, recientemente se ha desarrollado la nueva disciplina de la ciberseguridad, encaminada a proteger los sistemas informáticos de este tipo de ataques. A su vez, la seguridad de procesos intenta prevenir o mitigar la ocurrencia de eventos que comporten la pérdida de control de materias peligrosas o fuentes de energía. Por lo tanto, existe un ámbito de interacción entre esta disciplina y la ciberseguridad: la prevención y mitigación de escenarios de riesgos de proceso causados por ciberataques. Conviene, en primer lugar, introducir algunos conceptos básicos: • La Real Academia Española define peligro como “riesgo o contingencia inminente de que suceda algún mal.” El concepto queda suficientemente claro, pero para poder analizarlo desde un punto de vista técnico necesitamos algo más de rigor. • El daño o consecuencia es la magnitud del perjuicio causado por un escenario accidental (se trata del “mal” en la definición de la Real Academia). En función del tipo de escenario que se esté analizando, el daño puede ser personal, medio ambiental o material. • La probabilidad es una medida matemática de la mayor o menor verosimilitud que atribuimos a un escenario accidental. Normalmente es un número real comprendido entre cero y uno, ambos incluidos. Así, por ejemplo, un evento prácticamente seguro recibirá una probabilidad próxima a la unidad, mientras que a uno que consideramos prácticamente imposible le asignaremos una probabilidad próxima a cero. • De una forma matemática estricta, definimos el riesgo como la esperanza matemática de daño. Más simplificadamente, el riesgo es el producto de la probabilidad por el daño:

Riesgo = probabilidad × daño

Queda claro que estas definiciones no quedan limitadas al mundo de la seguridad de procesos ni de la ciberseguridad. Cualquier tipo de evento que pueda causar un daño (financiero, de calidad de producto…) admite el mismo tratamiento. En este contexto, el creciente caudal de noticias relativas a ciberataques pone claramente de manifiesto que ni la probabilidad ni el daño son nulos. Así, por ejemplo, el gigante de la alimentación Mondelez International reportó la disminución del 3% de sus ventas del segundo trimestre de 2017, mientras que Reckitt Benckiser anunció 110 millones de libras esterlinas de pérdidas en el mismo periodo. En ambos casos, por razón del virus ‘Petya’ (fuente: Financial Times). En la mayor parte de los casos publicados, el daño es meramente económico. Sin embargo, cabe también preguntarse cuáles podrían ser las consecuencias de un posible ciberataque con finalidad de causar daño a las personas o el medio ambiente. En este sentido, son numerosos los ejemplos de accidentes y cuasi-accidentes perfectamente documentados cuya causa inicial fue un fallo del sistema automático de control. Aunque en su momento estos fallos fueron no provocados, debe considerarse la posibilidad de que en un futuro puedan llegar a serlo.

A título de ejemplo, cerca de las 4: 00 de la mañana del 28 de marzo de 1979 se pararon las bombas primarias de alimentación del circuito secundario de la Central Nuclear de Three Mile Island (TMI; Harrisburg, Pennsylvania, USA) a causa de una avería mecánica o eléctrica. Esto impidió la evacuación de calor del sistema primario en los generadores de vapor. Aunque los sistemas de control pararon inmediatamente la turbina y el reactor, la presión en la vasija de éste empezó a aumentar rápidamente dado que el circuito secundario era incapaz de evacuar el calor residual generado. Para evitar que esa presión llegase a ser excesiva, la válvula de alivio de presión (situada en la tapa del presurizador) se abrió. La válvula debía cerrarse al disminuir la presión, aunque por un fallo no lo hizo. Las señales que llegaban al operador no indicaron que la válvula seguía abierta, aunque debieron haberlo mostrado. En consecuencia, la válvula abierta causó que la presión continuara disminuyendo en el sistema. Después de toda una secuencia de eventos, al cabo de unos 130 minutos del suceso iniciador, la parte superior del reactor quedó sin refrigeración, con lo que el circonio de las vainas de los elementos combustibles reaccionó con el vapor de agua, generando hidrógeno. Este hidrógeno explotó, exponiendo elementos de combustible al agua de refrigeración. Finalmente, una parte del núcleo se fundió, dejando una masa de combustible que posteriormente hubo de ser retirada. La limpieza del reactor fue un proyecto con una duración de 14 años y un coste total de cerca de 975 millones de dólares. No existe ni la más mínima sospecha de que el accidente en TMI fuera debido a un ciberataque; de hecho, internet ni siquiera existía en esa fecha. No obstante, hoy en día debemos plantearnos si un accidente de este tipo podría haber sido provocado… Y la respuesta es que sí, salvo que se adopten las medidas adecuadas para prevenirlo. El suceso iniciador del accidente fue el paro de las bombas del circuito secundario (que podría haber sido provocado), mientras que el suceso fue escalando debido a que los operadores tomaron decisiones erróneas basadas en la información equívoca facilitada por el sistema de control (que también podría haber sido manipulado). La válvula de seguridad del presionador no pudo haber sido actuada por un ciberataque, pero la indicación incorrecta de que permaneció abierta sí lo pudo haber sido. El mensaje que debemos extraer de una consideración de este tipo es que necesitamos poder determinar y medir cómo de vulnerable es nuestro proceso frente a un ciberataque ya que, obviamente, las consecuencias potenciales no serás las mismas en una central nuclear que una embotelladora de agua mineral. Por su parte, el riesgo, cualquiera que sea su tipo, debe gestionarse siempre en las fases que quedan esquematizadas en la figura adjunta.

Respuesta legal y normativa

Obviamente, los legisladores no pueden permanecer ajenos a un riesgo potencial, deben regularlo. Así, el Parlamento Europeo y el Consejo promulgaron el 6 de julio de 2016 la Directiva (UE) 2016/1148, relativa a las medidas destinadas a garantizar un elevado nivel común de seguridad de las redes y sistemas de información en la Unión. Esta Directiva requiere a los estados miembros a identificar los servicios críticos que podrían ser víctimas de ciberataques y crear las estructuras adecuadas para hacerles frente. La Directiva fue complementada en 2018 por el Reglamento de Ejecución (UE) 2018/151 de la Comisión, de 30 de enero de 2018, por el que se establecen normas para la aplicación de la Directiva (UE)

LOS PROCESOS NO SE PUEDEN CONTROLAR CORRECTAMENTE A MENOS QUE LOS COMPONENTES INDIVIDUALES PRESENTEN UN FUNCIONAMIENTO FIABLE

2016/1148 del Parlamento Europeo y del Consejo en lo que respecta a la especificación de los elementos que han de tener en cuenta los proveedores de servicios digitales para gestionar los riesgos existentes para la seguridad de las redes y sistemas de información, así como de los parámetros para determinar si un incidente tiene un impacto significativo. En el momento de redactar esta nota (junio de 2018), la Directiva está pendiente de trasposición al ordenamiento jurídico español. Por otra parte, desde hace ya algunos años diversos organismos han ido publicando normas técnicas para hacer frente al riesgo de ciberataques. En el presente documento analizaremos, aunque sea brevemente, la familia de normas ISA/ IEC 62443, que es heredera de la ISA-99. Ambos organismos ( la International Electrotechnical Commission y la International Society for Automation) tienen una larga tradición en el ámbito de la automatización y la seguridad. La figura adjunta muestra un resumen esquemático del alcance de esta familia de normas. Debe destacarse que estas normas muestran un notable paralelismo con la más conocida norma IEC EN 61508, que estandariza la seguridad funcional. Se establece de esta forma un nuevo paralelismo entre la ciberseguridad y la seguridad de procesos. Así, la norma ISA/IEC 62443 define los llamados “Security Levels” ( SL), o niveles de robustez del sistema de control automático frente a ciberataques (de la misma forma que la IEC EN 61508 define los “Safety Integrity Levels” o SIL como grados de robustez frente a fallos no provocados).

Ejemplo de herramienta de evaluación de riesgos

Los Process Hazard Analysis (PHA) son una familia ampliamente extendida de métodos de identificación de peligros y análisis de riesgos. Probablemente el miembro más popular es el análisis funcional de operabilidad o HAZOP (de la expresión inglesa “Hazard and Operability Study”). Recientemente se ha desarrollado una extensión de este método, especialmente adaptada a la identificación de riesgos relacionados con ciberataques. Una de las figuras adjuntas muestra un esquema de este método. Como puede comprobarse en ella, el PHA de seguridad es, en esencia, un estudio HAZOP en el que, además, nos planteamos si las causas o salvaguardas son robustas o no frente a un ciberataque. Así, por ejemplo, si la causa es del tipo “fallo del lazo de control de temperatura del reactor”, concluiremos que es vulnerable a un ciberataque. Por el contrario, si la causa es “carga de catalizador equivocado al reactor por error humano”, concluiremos que la causa no es vulnerable a un ciberataque. Análogamente, las salvaguardas podrían ser vulnerables o no. Una salvaguarda del tipo “alarma de alta presión con actuación por el operador” o “función instrumentada de seguridad que corta el vapor por alta presión” son vulnerables, mientras que una del tipo “disco de ruptura” no lo es.

OTRO DE LOS ASPECTOS QUE MÁS HA EVOLUCIONADO ES LA INTERFASE ENTRE EL OPERADOR Y EL INSTRUMENTO

Si identificamos un escenario peligroso ( es decir, uno con consecuencias para la seguridad de las personas, del medio ambiente o de los activos) para el que tanto la causa como todas las salvaguardas son vulnerables a un ciberataque, tendremos que admitir que este escenario podría ser generado externamente, a consecuencia de un ciberataque. En este caso, deberemos determinar el SL correspondiente, normalmente en función de la magnitud de las consecuencias. La equivalencia entre magnitud de consecuencias y SL se establece mediante una matriz similar a las matrices de riesgo empleadas habitualmente en los HAZOP convencionales. Una vez completado el PHA de seguridad, se obtiene una lista de escenarios potenciales, y de los SL requeridos para protegerlos. Ésta es la información de partida para las fases posteriores del ciclo de vida del riesgo; fundamentalmente, para el diseño o verificación del sistema de control, de tal manera que cumpla el SL exigido, de acuerdo con la norma ISA/IEC 62443.