Español | English
rss facebook linkedin Twitter

Un par de opiniones (parte 1)

Cuando se habla de la seguridad de los sistemas de control, hay un par de cosas con las que no estoy de acuerdo en cómo se abordan y de las que se habla en términos demasiado generales. Esta semana publicamos la primera y la semana que viene la segunda.


1. Sistemas tiempo real y determinismo

En la mayoría de los sistemas reales, no es necesario el determinismo. Y dentro de los sistemas que lo necesiten, la necesidad de tiempo real estará restringida a unas partes concretas.


Si un sistema de control lo consideramos como una superposición de capas, sólo la primera capa (la que interacciona directamente con el sistema físico) es la que puede tener mayor necesidad de velocidad y determinismo.


En un sistema de control podemos encontrar muchas aplicaciones de soporte y gestión cuyas necesidades de transferencia y procesado de la información deben ser tenidas en cuenta. Podemos encontrar aplicaciones de gestión de producción, calidad, eficiencia, trazabilidad, mantenimiento, control estadístico, gestión de stocks....


Estos paquetes de software se han integrado dentro de los sistemas de control para poder obtener los datos necesarios (inputs) directamente del sistema y enviar sus resultados.


Anteriormente se tomaban "a mano" (escritura de los datos en formato papel o electrónico) y luego se introducían en la aplicación correspondiente, para obtener o mantener una información que luego se empleaba utilizar en la operación del sistema.


La información que manejan estas aplicaciones puede dividirse en tres categorías:

  • Información necesaria para producir un bien (o prestar un servicio)
  • Información sobre la capacidad de producir un bien o prestar un servicio
  • Información sobre el estado actual de la producción del bien o prestación del servicio (sería la imagen del proceso)

En principio todo esto podría tratarse como un sistema de información puramente IT.


La amenaza es la interconexión con la parte puramente productiva y que los canales de lectura de información sean empleados para afectar negativamente al sistema.


Si nos centramos en un SCADA, considerándolo el nivel más alto desde el cual podemos ejecutar una orden sobre el proceso productivo, nos encontramos con que un operario no está continuamente realizando operaciones sobre la interfaz, ni tampoco los procesos o servicios de procesado de información del SCADA requieren una alta frecuencia ni determinismo y pequeños retardos son perfectamente asumibles (siempre y cuando el SCADA esté bien hecho y no asuma funciones que no debiera tener. Por ejemplo, realizar el enlace entre dos plc's para una sincronización de operaciones dependientes (pero sí que podríamos usar el SCADA para intercambiar información no esencial, que puede mejorar el comportamiento del sistema pero que debe ser prescindible). Una conexión entre dos plc's para sincronizarse o realizar una operación conjuntamente, requiere una conexión física directa a través de una red exclusiva de plc’s o a través de entradas/salidas.


Lo que si es necesario es que las comunicaciones sean fiables y las órdenes dadas se ejecuten (la información que muestra el SCADA está actualizada y la escritura se realiza).


En un SCADA tendremos:

  • imagen de proceso (a partir de los datos suministrados por drivers de comunicaciones)
  • interfaz gráfica
  • gestión de eventos
  • comunicaciones con otras aplicaciones (conexiones a bases de datos, envío de información a través de ficheros de texto plano o xml)

El tiempo total desde que se produce un cambio en el sistema físico hasta que una acción se ejecuta en respuesta a ese cambio físico se descompone en:

1- detección del cambio en el sensor

2- transferencia de información desde el sensor hasta el procesador
3- cálculo de la respuesta:
  • directamente en el procesador (toda situación que pueda conceptualizarse y calcularse directamente debe realizarse a este nivel, a pesar de que un SCADA tiene gran capacidad de programación y pueda ser más "agradable" de utilizar).
  • o envío de la información al SCADA, visualización por parte del operador, cálculo de la respuesta en la mente del operador, operación en el SCADA y envío al procesador (en un SCADA también podemos dar órdenes para el inicio, pausa y/o fin de operaciones de acuerdo a una planificación establecida y no como respuesta a un evento físico.

4- envío de órdenes desde el procesador a las salidas
5- ejecución de la orden en el accionamiento físico

Si consideramos la variabilidad del tiempo de respuesta cuando incluimos el factor humano y la parte física del sistema, vemos que no debiera existir tanta exigencia.


Con los avances en la sensorización, en los procesadores y en las comunicaciones, el factor de velocidad de transferencia de información ha dejado de ser tan determinante.


En un SCADA deben estudiarse las diferentes señales que tenemos y la dinámica asociada de las variable físicas para definir los ciclos de lectura y ajustar el tráfico de la red a las necesidades reales. En mi opinión, un SCADA (excluyendo la parte de drivers de conexión) también podría analizarse con métodos de IT.


En conclusión, lo realmente importante es realizar una segmentación física adecuada de las redes y sólo estudiar de manera especial la parte específica de "comunicaciones industriales": no encriptadas y con protocolos que pueden encontrarse fácilmente en internet.


La semana que viene: 2. Un ciber-ataque puede causar daños en las instalaciones e incluso a las personas.



Diego López
S21sec labs

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login