Safety, Parte I

En materia de Ciberseguridad vemos constantemente la comparativa de prioridades entre lo que pretende proteger la tradicional en entornos IT y la industrial. Esto es la llamada Confidencialidad, Integridad y Disponibilidad en la primera, y Disponibilidad, Integridad y Confidencialidad, en la segunda.

Lo cierto es que existen otros aspectos que son y podrán ser más importantes que el mero hecho de mantener la actividad de nuestras operaciones. Sean las que sean. Obviamente si lo vemos desde la perspectiva del negocio, no hay lugar a dudas, la “Disponibilidad” es lo primero.

Una de ellas es la Seguridad Funcional, esto es, lo que conocemos como “Safety”. Si bien en castellano lo agrupamos todo bajo el término “Seguridad” en inglés se establece una clara diferencia entre “Security” y “Safety”.

Cada máquina o instalación requiere de un estudio previo para determinar las posibles situaciones que podrían presentar, en primer lugar, un peligro para operarios o técnicos y también medio ambiente y la propia maquinaria. Esto comienza antes que cualquier otra medida de “Seguridad” tradicional.

Entre esas situaciones podríamos citar:

  • La violación de una condición.
  • Apertura de accesos físicos a piezas en movimiento.
  • Ingleso a una zona con riesgo de atrapamiento o lesión.
  • Una variable crítica que supera un valor máximo.
  • Intento de ejecución de una acción no autorizada.
  • Una orden de un operador.

Dichas medidas las podemos localizar tanto para prevenir como a mitigar los efectos, y dependiendo del entorno en cuestión, se alcanzará por unos medios o por otros tal y como muestra la imagen siguiente.

Safety

Para ello se ha de realizar un análisis de riesgos para analizar todas las posibles situaciones de peligro que dicha máquina o instalación puede provocar para personas, medio ambiente y los elementos físicos y establecer la probabilidad de que dicho fallo se produzca. A partir de aquí, se han de determinar qué, cuáles o cuántos elementos (controladores, relés, sensores, etc.) van a ser necesarios para impedir que esto ocurra. Esto son los denominados SIS, Safety Instrumented System. Es decir, establecer cuáles van ser las medidas correctoras para reducir los riesgos hasta hacerlo algo tolerable.

Cada despliegue de sistema “Safety” es individual para cada máquina o instalación. El SIF, Safety Instrumented Function son las acciones que tiene que tomar el controlador para las “Salidas” del todo el sistema Safety a partir del estado de las entradas, para esa instalación concreta y mantener así el entorno bajo seguridad.

Como decía, para el diseño de un sistema Safety ha de hacerse un “Análisis de Riesgos”. Hay que identificar todos los riesgos potenciales y decidir cuál de esos riesgos requieren un sistema Safety y por tanto definir un SIF en consecuencia.

Sin embargo, un sistema Safety también tiene probabilidad de fallar, bien sea un sensor, un actuador o un “Logic Solver”. Por tanto, se ha de definir el concepto de PFD, Probability of Failure on Demand (Probabilidad de Fallo Demandado) y PLr (Required Performance Level) y contrastarlo con los requisitos “Safety” identificados. Por ello se definen dos aproximaciones, una el SIL (Safety Integrity Level) y PL (Performance Level), las cuales establecen la probabilidad de que ocurra un evento peligros y de si ésta puede reducirse uno o varios niveles.

En el caso de Performance Level quedaría de la siguiente manera, donde:

  1. S = La gravedad de la lesión
    1. S1 = Lesión leve
    2. S2 = Lesiones graves incluyendo la muerte
  2. F = Frecuencia o y/o duración de la exposición a peligros
    1. F1 = Rara vez o a menudo y/o corta duración de la exposición
    2. F2 = Exposición frecuente a continua y/o de larga duración
  3. P = Posibilidad de evitar el peligro
    1. P 1= Posible bajo ciertas condiciones
    2. P2 = Apenas posible

En resumen, se puede decir que hay que hacer un análisis de riesgos y en función del mismo determinar el nivel de seguridad exigible al controlador. Acto seguido se debe establecer el controlador para que cumpla con ese nivel de seguridad (es decir su PFD adecuado) y finalmente hay que demostrar que se cumple, es decir que una entidad reconocida lo certifique. Finalmente, llevar a cabo una operación y mantenimiento dentro del ciclo de vida tanto del conjunto de medidas Safety como del sistema en que está instalado. En general el proceso sería:

  • Análisis de Riesgos.
  • Implementación.
  • Verificación.
  • Certificación
  • Operación y mantenimiento.

El despliegue de estos equipos está regulado por estándares, normativa o legislación, los cuales pueden aplicarse a un ámbito en cuestión, esto es, maquinaria o procesos y también específicos del sector como el ferroviario, automoción, nuclear, etc. Algunas de ellas son:

  • UNE-EN ISO 13849-1
  • UNE-EN IEC 61511
  • UNE-EN IEC 61508
  • MIL-STD -882D, 882E
  • UNE-EN 50126, 50128, 50129, 50155, 50159
  • ISO 26262
  • IEC-50156

También hay que tener en cuenta el alcance geográfico como puede ser europeo, internacional o normativa específica de países, algo a tener en considerar si dicha maquinaria será, o pueda ser, desplazada entre posibles localizaciones que una empresa tenga en continentes o países distintos. Debemos recordar que cualquier modificación o cambio de la maquinaria puede requerir un nuevo estudio o certificación dependiendo del cambio realizado.

Asociado a estos aspectos, hay que diferenciar entre lo que el estándar IEC 62443 define como SL (Security Level) y lo que pueda llegar a ser el SIL o PL. Por un lado una cosa es definir el nivel de protección desde el punto de vista de la Ciberseguridad, esto es SL, donde protegemos los accesos, la información contenida en los sistemas de control, credenciales, y por otro la protección a las personas, medio ambiente o las instalaciones. Son conceptos distintos. En el primero protegemos a las máquinas de las personas y en el segundo protegemos a las personas de las máquinas.

Hasta aquí una brevísima introducción al término “Safety” y recordar que…. SAFETY FIRST”

No vemos en la siguiente!!

 

CPU Protection, Part II

In addition to my last post where I talked about CPU protection (click here to access), today I will write about how we can detect if protection is enabled on a S7-300. If not, we could connect to the PLC (CPU or communications module), upload the program, and modify it. After this, download it again.

Other actions that could be accomplished are establishing new passwords on FCs, FBs, etc. When a legitimate user would want to access to read or write them, he/she could not do it because would not know the configured password.

S7Scan tool can help us to get this information, CPU Protection. We have to take a look at “Module Protection” section. There, we can see if this is set up. In the figure below, it is not.

Well, what can we do? As I said we could be online and inspect the program, its configuration and upload it.

On the other hand, if “Module Protection” is configured as on the picture below, we will not be able to do it.

A password will be requested in two ways. Firstly, if we want to access to a Block or Function after we are online.

And secondly, if we want to upload the program. See the area where indicates “<introducir contraseña> that means <introduce your password>

This is an example on how these features can help us introducing new controls. Are they all effective as we expect? Well this is another question… During this work I found there is a limitation of eight characters long.

Apart from this, we know that passwords can be cracked by specific software or stored in plain text. Configure a password it is not a silver bullet to protect access. We have to implement other security measures and try to stop an intrusion, deliberate action or similar, before it reaches the objective.

We can not trust the security device by its own features because they could not be as robust as they should be. Industrial components, devices or systems have been designed to be robust, simple, reliable, safe, etc. not secure. Security is relatively new, since attacks have been carried out or vulnerabilities have been discovered and published.

Thanks again, I will see you in the next!

Having said this, I hope you have enjoined this post!

To be continued…

Stay tuned!

CPU Protection, Part I

To alter the normal operation of a system it is necessary to get access. For this reason we have to configure all available features to prevent that unauthorized people or software could carry out any action over them. However, we must not forget that security measures can obstruct the recovery of an equipment if do not define clear processes to get it back if something goes wrong or simply beaks down.

Two years ago, I wrote about some controls over Siemens S7-1200 PLCs. You can access it by clicking here. But today I will talk about other.

One of these features is to configure online control access to PLC CPUs. Not to protect the program and the content stored in it. Why is this important? Because when we connect any device to ethernet networks we are increasing the attack and exposure surface. Accordingly, to that, there are more possibilities to suffer any intentional or unintentional action that could affect to our OT devices.

With this feature we can set up passwords to restrict the access to functions and memory areas. In general, in level 1 hardware configuration can be read and modified by anybody; Level 2, read access do not need any password but if you want to change some parameter you will need to type a password; and finally, Level 3, without a password you cannot modify some several parameters. Obviously in both cases there are conditions and exceptions that you can do. For further information please visit “Virtual Library” and locate the following document named “Security with SIMATIC controllers” in SIEMENS area.

After several years in the Industrial Cybersecurity field, in most cases I have not seen this feature implemented that can be used to hamper unsolicited actions on process controllers. If we do not restrict access to anybody, they could upload the program, modify functions and other parametrizations and download it to the PLC again. After that, who knows what will happen if this occur. Other scenario could be the theft of intellectual property by the third parties that can participate in a project during a commissioning phase.

It does not matter which controller we are using, Siemens, OMRON, B&R, Schneider, or any other. The message is to request, identify or consider if this kind of feature is available and apply it to bring more security, to end devices. Of course, without introducing potential factors that could compromise the normal operation.

We know, there are scenarios where it could be difficult to start up some controls and invest more time to find compensatory measures instead of applying them natively. Obviously, if the device count with it.

In addition to that, keep in mind that a password or any other similar measure, could by cracked, but at least, we have applied one more step to reinforce the Defense in Depth concept that we must implement to protect our industrial environments.

Having said this, I hope you have enjoined this post!

To be continued…

Stay tuned!