“DoS Policy” más allá del filtrado tradicional

Como hemos comentado en otras ocasiones la separación y segmentación de los entornos IT y OT es la primera medida técnica que debemos tomar. Es necesario definir los perímetros y qué comunicaciones deben permitirse entre uno y otro lado. Para conseguirlo, empleamos Cortafuegos aunque con características adicionales que han dado lugar a los conocidos NGFW. Sin embargo, también podemos contar con otras adicionales, en este caso, para evitar denegaciones de servicio, DoS.

La primera acción que debemos hacer es identificar el tráfico. Definir qué comunicaciones existen en nuestro entorno de control y automatización. Luego, permitirlas en función del criterio que más se ajuste ya sea por IPs, interfaces, servicios, subredes, aplicaciones, protocolos o cualquier otro. Sin embargo, una vez hecho esto y teniendo que claro “qué si y qué no”, también es importante identificar posibles anomalías dentro del mismo pudiendo afectar al funcionamiento del, o los equipos, destino.

Una de las acciones con las que podríamos afectar a las comunicaciones de este ámbito es introduciendo tráfico adicional. Sea este Broadcast, Multicast o Unicast los efectos podrán ser unos u otros ya que dependerá si la electrónica de red lo replica por todos los puertos o sólo por aquél que está dirigido al destinatario.

Si nos referimos a los equipos de control, sabemos que éstos tienen un ciclo de vida mayor con lo que es muy común encontrarnos con equipos antiguos con una capacidad para gestionar comunicaciones mucho más limitada que los equipos actuales. Ante un exceso de tráfico, aunque esté dirigido a un puerto de destino permitido, éstos podrían dejar de responder perdiendo así visibilidad y control.

Hay que tener presente que una denegación de servicio puede no venir exclusivamente de medidas claramente intencionadas. También puede hacerse por un error o mala parametrización de sistemas. Un caso lo podríamos encontrar en los escáneres de vulnerabilidades. Si no los configuramos correctamente y no los ejecutamos acorde a los equipos finales podríamos llegar a comprobar vulnerabilidades de sistemas operativos Windows, Linux, etc. sobre autómatas o controladores que, lógicamente, no los empleen o podrían no hacerlo. Aparte de que los resultados no tendrían sentido, podría desembocar en posibles bloqueos en módulos de comunicaciones, tiempos de respuesta tardíos, entre otros.

Para emular una situación de esta índole he elaborado una Prueba de Concepto empleando el simulador Snap7 y equipos virtuales. No obstante, la prueba fue realizada sobre dos autómatas Siemens S7-400 y S7-300 y los resultados fueron la pérdida de visibilidad desde el servidor que los gestionaba. Los equipos no eran capaces de manipular tanto tráfico. Por supuesto, en un entorno de laboratorio.

La misma sigue el siguiente esquema:

Desde un equipo con una distribución Kali Linux realizamos una inundación de tráfico por medio de la herramienta hping3, efectuando peticiones TCP SYN contra el puerto TCP 102, que es el empleado por el fabricante Siemens. Dicho equipo tendrá una IP 192.168.100.20, mientras que el PLC virtualizado 192.168.20.10.

root@kali:~# hping3 –flood -p 102 -S 192.168.20.10

Antes de realizar dicha operación podremos comprobar que el consumo de CPU como de memoria es bajo dada la ausencia de sesiones.

Sin embargo, una vez comenzado el envío de paquetes el consumo de recursos va en aumento:

Si en ese momento decidiésemos conectarnos a dicho PLC simulando un servidor, HMI, etc. veríamos que no sería posible y cómo la propia herramienta muestra un mensaje en la parte inferior de la captura “ISO: An error occurred during…”

En este sentido fabricantes como Fortinet introducen una funcionalidad denominada “IPv4 DoS Policy” que nos va a permitir atajar que, algo o alguien, de una manera intencionada, o no, pueda generar un exceso de tráfico que desemboque en una pérdida de visibilidad o control sobre equipos finales.

En la imagen siguiente podemos ver los distintos parámetros que podemos definir y parametrizar según sea nuestra necesidad.

 

Deberemos indicar la interfaz de entrada por dónde esperaremos el tráfico en cuestión, ya sea física o lógica; direcciones IP de origen y destino y servicios. A continuación, hemos de identificar las características a nivel de capa 3 y/o 4 que queremos habilitar y los respectivos umbrales de cada uno de ellos. Este es un trabajo que hemos realizar con cautela ya que nos obliga a tener una estimación acerca de los valores tolerables y qué se escapa de un normal comportamiento. No tenemos porqué habilitar todas las opciones, sino aquellas que consideremos que nos pueden ser de utilidad o tengan sentido dependiendo de la ubicación y exposición del cortafuegos. Finalmente, una de las opciones que sí resulta conveniente habilitar es la opción de registro ya que nos va a permitir disponer de información al respecto, como se puede ver en la imagen siguiente.

Cuando hablamos de cortafuegos, generalmente nos viene a la mente la opción de permitir o denegar tráfico y sobre él aplicarle controles adicionales como Antivirus, IDS/IPS, entre otros. Es cierto, ese su principal cometido. Sin embargo, podemos encontrar funcionalidades que, sin penalizar el rendimiento, pueda ayudar a identificar anomalías de aquél que estamos dejando pasar.

La primera tarea es decidir qué debemos autorizar y qué no. Esto nos va obligar a conocer qué comunicaciones establecen nuestros equipos de control y sistemas asociados. A menudo partiremos de un desconocimiento total ya que nos enfrentaremos a entornos conmutados o enrutados donde no se ha documentado dicha información y obviamente no existen elementos de seguridad perimetral. Si queremos filtrarlas deberemos identificarlas, y entender el por qué deben producirse, o no. No todo lo que veamos debe ser permitido. Probablemente ni tan siquiera los propios usuarios de las instalaciones lo sepan. Es una labor que puede complicarse según sean los escenarios, pero que en cualquier caso, ha de realizarse.

Un buen recurso pueden ser los “Puerto Espejo” o dispositivos como el Siemens TAP  104, que nos ayudarán a replicar tráfico de red y que pueda ser colectado y analizado a posteriori.

Hasta aquí la entrada de hoy.

¡Un saludo nos vemos en la próxima!

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 14/09/18.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. Registrando eventos en sistemas de control para mejorar la seguridad
  2. Fuzzing y testing en sistemas de control industrial
  3. Defensa Activa e Inteligencia: Threat Intelligence en los entornos industriales
  4. WPA3, la mayor actualización de seguridad en redes Wi-Fi desde hace más de una década
  5. Amenazas emergentes en sistemas de control industrial
  6. Defensa activa e inteligencia: de la teoría a la práctica
  7. Mitigando problemas de disponibilidad en la industria
  8. Tendencias en la industria, mejoras en la ciberseguridad
  9. Auditorías en comunicaciones inalámbricas industriales.
  10. Monitorizando redes y eventos en SCI: más información, más seguridad
  11. Zonas y conductos, protegiendo nuestra red industrial
  12. Honeypot, una herramienta para conocer al enemigo
  13. Entendiendo el tráfico de red industrial, disectores y Lua y Kaitai
  14. Acceso seguro a los SCI: doble factor y accesos externos
  15. Tú reportas, ellos actúan.
  16. Automatización de bajo conste.
  17. El valor de los indicadores de compromiso en la industria.
  18. Gestión de parches en Sistemas de Control.
  19. Introducción a los sistemas embebidos.
  20. Seguridad Industrial 2017 en cifras.
  21. Convergencia TI-TO.
  22. Retos y riesgos de ciberseguridad y privacidad en IoT.
  23. Iniciativas y y mejores prácticas de seguridad en IoT.
  24. 46 métricas para mejorar la ciberresiliencia en un servicio esencial.
  25. Diseño y configuración de IPS, IDS y SIEM en Sistemas de Control Industrial.
  26. Cómo evaluar mi nivel de capacidades en Ciberseguridad según C4V.
  27. Los conocimientos del personal de seguridad industrial.
  28. Ciberseguridad en las comunicaciones inalámbricas en Entornos Industriales
  29. SNMP, ¿es tan simple como el nombre indica?
  30. Cortafuegos transparentes, ladrillos de cristal.
  31. PRP y HSR: Protocolos redundantes.
  32. Robots y drones en la Industria 4.0.
  33. Hardware Hacking en Sistemas de Control Industrial.
  34. CrashOverride: El malware para SCI ataca de nuevo.
  35. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  36. Asegurando la virtualización de tus sistema de control.
  37. Gestión de credenciales en sistemas de control.
  38. Prevención de intrusos y gestión de eventos para sistemas de control.
  39. Insider, las dos caras del empleado.
  40. Amenazas emergentes en entornos industriales.
  41. Honeypots Industriales.
  42. Gestionar el riesgo de los proveedores como propio.
  43. Seguridad en protocolos industriales – Smart Grid
  44. Criptografía para reforzar la ciberseguridad en entornos industriales.
  45. Características y seguridad en PROFINET.
  46. Analizadores de red en Sistemas de Control.
  47. Seguridad Industrial 2016 en cifras.
  48. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  49. Inventario de activos y gestión de la seguridad SCI.
  50. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  51. Protocolos Industriales: Herramientas de Seguridad.
  52. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  53. Atrapando sombras en la industria.
  54. Cyber Kill Chain en Sistemas de Control Industrial.
  55. DDOS de actualidad: IoT y los DNS de Dyn.
  56. Seguridad en BlueTooth: Fortalezas y debilidades.
  57. ZigBee en el laboratorio.
  58. Thinking in Big (Data) y la seguridad industrial.
  59. Seguridad desde abajo: dispositivos finales a escena.
  60. Familia de malware en la industria.
  61. Protegiéndose de BlackEnergy: Detectando anomalías.
  62. Seguridad en Comunicaciones ZigBee.
  63. BlackEnergy y los Sistemas Críticos.
  64. Desmontando Modbus.
  65. Safety y security: juntos pero no revueltos.
  66. BMS: Edificios inteligentes, ¿y seguros?
  67. Seguridad industrial 2015 en cifras.
  68. Un SCADA en la ciudad.
  69. Aplicando seguridad en WirelessHart.
  70. Sistemas de control de software libre.
  71. Arquitecturas de seguridad en la nube para la industria.
  72. Las aplicaciones de control se hacen mayores.
  73. Mi SCADA en las nubes.
  74. Evolucionando la comunicación en la industria.
  75. La Ciberseguridad en la Industria 4.0.
  76. Divide y vencerás: Segmentación al rescate.
  77. Monitorización de amenazas en SCADA.
  78. Evolucionando la infraestructura de red en SCI.
  79. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  80. El consumo eléctrico bajo control.
  81. Buenas prácticas de configuración en la red inteligente.
  82. Disciplina militar en Control Industrial: OPSEC.
  83. Auditorias en sistemas de control.
  84. Amenazas en los Sistemas de Control Industrial.
  85. Certificaciones de seguridad en sistemas de control.
  86. La evolución de los dispositivos en los sistemas de control industrial.
  87. Estándares de ciberseguridad en las redes inteligentes.
  88. BYOD en entornos industriales.
  89. IEC 62443: Evolución de la ISA 99.
  90. La seguridad de los coches inteligentes a examen.
  91. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  92. Herramientas TI que evolucionan para TO.
  93. La evolución del software en los sistemas de control industrial.
  94. Diferencias entre TI y TO.
  95. Normativas de seguridad en sistemas de control.
  96. Identificación de sistemas de control industrial.
  97. Problemática de los antivirus en entornos industriales.
  98. Seguridad en Protocolos de Sistemas de Control Industrial.
  99. Del Air Gap a la Segmentación en ICS.
  100. Guía de seguridad de Sistemas de Control Industrial.
  101. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  102. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  103. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

Main differences between IT & OT Cybersecurity

In February, I had the opportunity to give a conference about the key differences between OT and IT Cybersecurity, at IndusSec 2018 Industrial Cybersecurity Congress. It is reasonable that IT security professionals want to introduce in OT cybersecurity, but in my opinion, there are a lot of differences between both. So, in this case, I will translate onto English the main ideas to reach English speakers.

The first one is related to the objectives and priorities. I am sure that when we do not know how to do something, we ask somebody who knows or can give us some valuable information. OT cybersecurity is newer in comparison with IT cybersecurity, so it is reasonable to focus on IT cybersecurity standards and best practices to secure industrial environments. However, it cannot be a right decision. I do not want to say that we cannot apply them. We can, but do not apply them in the same way. Why? Because the objectives and priorities are different. In IT environments, the objective is to protect the “Data” but in OT environment is the “Process”. In order to prioritize, in IT is the “confidentiality” instead of “availability” of an OT environment. So, if both have different objectives and priorities, we must use standards according to each one. IEC 624443 and NIST 800-82r2 instead of ISO 27000.

CIA vs IACSecondly, IT technologies use either Ethernet or TCP/IP to communicate to other systems. It is something that nobody discusses. Nevertheless, in OT environments the presence of protocols based on serial communications is very high, such as Profibus or Interbus. Beside this, migrate to Ethernet technology requires changing the cabling, something that cannot be done if the facilities work 24×7, new communication modules, industrial network design, and so on.

Other key factor, is the latency. In IT networks, we can assume up to 150ms for traffic in real time, but in Industrial Ethernet based networks it is not acceptable. For example, for Real Time (RT) Communications this value is under 10ms and for Isochronous Real Time (IRT) is 1ms. According to this, when we deploy firewalls to filter traffic we have to consider them because each one introduces latency more or less depending on the controls applied. This is, L4 filtering, antivirus, application control and IDS/IPS policies, operation mode (flow or proxy), CPU load, memory use, and so on. Consequently, in some environments, we cannot deploy firewalls as the standards recommend. We do not forget that there are protocols which are able to work in Layer 2, so they cannot be reachable from/to other subnets.

Thirdly, there are the patches. In OT, the equipment lifecycle is bigger in comparison to IT, so it is more likely that we will have either legacy or end of support systems without patches available. So, how can we patch these systems? But if we can get them from the vendor, we will have to decide when we will apply them. Not always can be possible because they can be linked to a reboot, stop or maintenance mode. And of course, affecting to the availability, something that we must ensure.

Patches and Updates

Fourthly, we want to talk about antivirus. In the same way of the previous paragraph we must keep in mind that one thing is the operating system and other is the software installed. If the operating system is too old, probably there will not be capable software for it, such as Microsoft Windows 2000 or XP. But in the best case, when we have compatibility and can use them on our HMI, maybe this solution cannot give us the protection that we are looking for. The antivirus are firm based tools, and if the malware is specific to ICS probably the signature cannot exist. This is, what happened with Irongate, malware discovered by FireEye security company. As they said, this malware was not identified by any of the Antivirus software available on Virustotal website. This invites to keep in mind that even though we have an antivirus on our industrial PC, probably, it cannot be as efficient as we need because they are not prepared for industrial threats.

IRONGATE

Finally, I would like to mention a key aspect, and it is not related to technical features. I will refer to human factor. Until now, the auditors, consultants, networks and system administrators, integrators and other IT technicians talked the same language. If one of them talked about virtualization, databases, software and particular in security devices such as firewalls, intrusion detection/prevention systems, everybody understands each other. But since a few years ago this has been changing because there is other environment to protect, OT.

It has other kind of profiles such us maintenance technicians, process engineers and production managers. We should join them to our work groups, committees and meetings to share with us their knowledge, experience, priorities and needs and vice versa. Until now, IT teams did not know about PLCs, HMIs, RTUs, industrial communication latencies… and OT teams did not know about Endpoint software, next generation firewalls, deep packet inspection, communication ports… Everybody knows about what they have to manage or control. This is, IT teams know about, operating systems, software, routing, switching, and OT teams about, automation, pneumatic, hydraulic, sensors, actuators, etc.

So, if we want to ensure the availability on shop floors, plants, or critical infrastructures, we must know all related to facilities, ICS, systems. The industrial cybersecurity is not a task of either IT or OT people.  It is a shared responsibility, where it joins the best of two worlds, Information and Operation Technologies.

So we have to change from this point of view:

IT and OT Teams_01

To:

IT and OT TEams_02

In my opinion, the obvious conclusion is that we cannot evaluate with same criteria both environments. As I said, if we have different priorities, different objectives, we must apply different approaches to reach our goals. This is, protect the industrial environments. In addition, even though we talk about the same technologies in both scenarios, the characteristics, features or deployment can be very different too. The latencies can be unacceptable, ineffective, require a change of point of view or the risk that we introduce is higher in comparison with that one we want to mitigate.

It will not be easy, because we will have some difficulties and barriers that have to overcome.

See you in the next post, thanks for your time.

Best regards.

Edorta

Question last slide

 

 

Presentación Check Point 1200R Rugged Appliance

Una de las características que presentan los entornos industriales, o aquellos donde estén presentes los sistemas de control y automatización, es lo hostil que puede ser el medio en cuanto polvo, humedad, temperatura, se refiere. Con la necesidad de tomar medidas en materia de ciberseguridad, los equipos deben de poseen una serie de características, aparte de las funcionales, que cumplan con estos requisitos de robustez, tolerancia a fallos, entre otras. Conscientes de esta situación, los fabricantes de soluciones de seguridad perimetral y redes han sacado al mercado productos para cubrir esta necesidad con más o menos gama dependiendo del fabricante. Hoy hablaremos del equipo 1200R del fabricante CheckPoint.

Como podemos comprobar posee un diseño rugerizado soportando un rango de temperatura entre -40 y 75 ºC con un índice de humedad sin condensación entre 20 y 90%. Al igual que otros, no posee un ventilador para su refrigeración, importante para aquellos espacios con gran cantidad de polvo en el ambiente. Pose un total de 6 puertos para comunicar equipos; 4 LAN, 1 WAN y 1 DMZ, pudiendo los dos últimos ser utilizados a través de módulos SFP como fibra óptica. También un puerto serie para comunicación por consola.

Tendremos la opción de alimentarlo bien por un bornero en la parte frontal o con una fuente tradicional a un enchufe a 220V por la zona posterior. Importante tener en cuenta que la que se suministra opera entre 0-40ºC lo cual supone una diferencia notable con respecto al del propio equipo.

En la zona posterior nos encontraremos con un slot para introducir una tarjeta SD-HC y ser utilizada como almacén de logs. El fabricante ofrece una de 32GB de capacidad con lo que, al menos, hasta esta cantidad estaremos cubiertos.

Cara a la instalación, tendremos la opción de colocar un soporte para carril DIN y montarlo en aquellos espacios que así lo requieran.

Sin embargo, conviene prestar atención si nuestra opción sea la de alimentarlo con la fuente de alimentación a 220 V ya que el espacio entre equipo y armario puede no ser el suficiente para el que ocupa el conector.

El equipo trae consigo la posibilidad de ser administrado tanto de forma centralizada a través de una consola de administración, o local vía web. En mi caso he elegido esta opción, para su puesta en marcha inicial. Para ello habrá que conectarse a l puerto LAN 1 e introducir la IP que viene por defecto, 192.168.1.1. Luego seguiremos el asistente para su configuración inicial.

 

 

Luego deberemos de llevar a cabo la actualización sistema y los servicios que trae consigo el propio equipo. Aquí al hacerlo a la versión de Firmware R77.20.75 como podemos apreciar la apariencia cambia.

Hasta aquí la presentación de este equipo que al igual que otros puede ser empleado para técnicas de Virtual Patching, protección de conjunto de equipos, o acceso remoto seguro. En futuras entradas veremos más del funcionamiento y cómo podremos proteger tanto nuestro entornos industriales como nuestras infraestructuras críticas.

Un abrazo!

Edorta

Virtual Library, UPDATED!

Hello everyone!

This time I want to announce the update of the “Virtual Library”. As you know, this webpage is a collection of publications, articles and papers related to Industrial Cybersecurity; protection of Industrial and Automation Control Systems; Industry 4.0; and similar topics.

In this case, I have re ordered the webpage. Now, you can find two tabs named “Empresas” and “Organizaciones, Instituciones”. In the first case, “Empresas” you will find mainly publications and articles written by Cybersecurity Companies, Consultancy firms, and others. In the second tab “Organismos, Instituciones” you will find similar documents divulged by Gubernamental Institutions, non-profit organisations, National Agencies, and so on.

I hope you find them interesting and useful!

See you!

Edorta

Medidas nativas de seguridad en SCI, Siemens S7-1200

Uno de los principales focos dentro de un proyecto para reducir los riesgos en un entorno de control y automatización, son los equipos basados en arquitectura PC. Éstos por sus características y, condiciones, presentan deficiencias en materia de seguridad. Bien porque resulta muy complejo o no se pueden implementar las medidas que las corrigen. Esto se agrava ya que desde ellos se actúa sobre equipos de campo pudiéndose  alterar parámetros, conseguir accesos no autorizados, según marcas y modelos. Sin embargo, los distintos fabricantes de sistemas de control y automatización han ido desarrollando distintas medidas que minimizan, o impiden, que una acción malintencionada o accidental tenga éxito. Hoy hablaremos de algunas que nos podemos encontraren el autómata S7-1200 del fabricante SIEMENS.

Como he comentado en anteriores entradas, la estrategia recomendada para reducir los riesgos en nuestros entornos industriales es la Defensa en Profundidad. La misma, nos proporciona la capacidad de establecer distintos niveles de protección que dificulten el avance de todo aquello que pueda afectar a la disponibilidad del proceso.

Cuando hablamos de proteger el equipo final, mayoritariamente se habla de los equipos basados en arquitectura PC (HMI, Workstations, ertc.) que controlan los equipos de instrumentación y control. Éstos debido a que en muchas ocasiones, poseen sistemas operativos fuera de soporte; aplicaciones con desarrollo específico que dificulta o imposibilita la aplicación de parches; pérdida de soporte en caso de manipulación; elevado coste de migración a plataformas más actuales; entre otras muchas razones, los convierte en objetivo para realizar alguna acción concreta.

Por tanto, es sobre ellos en los que recae la mayoría de las medidas a tomar tales como el bastionado basado en “Whitelisting” de aplicación; control de dispositivos USB; Anitvirus; control de acceso; etc.

Sin embargo, también debemos destacar la labor de los fabricantes de control y automatización cara implementar medidas de seguridad sobre este tipo de dispositivos y que resulta crucial cara a alcanzar una protección lo más completa posible a todos los niveles.

Hoy voy a hablar de algunas que acompañan al PLC del fabricante SIEMENS en su modelo S7-1200.

Por ejemplo, el mismo tiene una interfaz web, la cual viene deshabilitada por defecto, y que podremos habilitar desde según necesidades.

Si deseamos el acceso por este medio podremos hacerlo mediante “HTTPS” en lugar de la tradicional “HTTP” evitando así el envío de credenciales en claro.

Configuración interfaz Web HTTPS PLC Siemens S7-1200

Otra de las capacidades que podremos tener es la definición de usuarios y permisos. De esta manera podremos indicar qué podrá ser visible, o no, a partir de las credenciales de acceso. No todo el personal tiene porqué estar al mismo nivel de información de la red de control. No es lo mismo la responsabilidad de un Operador cara para verificar si un PLC está funcionando; a un Técnico de Mantenimiento que debe además de comprobar otros indicadores, realizar cambios sobre él. Dichos permisos pueden ser seleccionados desde la columna “Nivel de Acceso” de la imagen siguiente.

Definición de usuarios PLC Siemens S7-1200

Y a su vez desde las opciones desde el siguiente menú.

Definición de permisos de usuarios PLC Siemens S7-1200

A partir de aquí, si accedemos a la interfaz sin haber introducido ningún tipo de credencial obtendremos la imagen siguiente.

Interfaz Web PLC Siemens S7-1200

Sin embargo, si en la esquina superior izquierda introducimos el usuario/contraseña de “admin”, la apariencia será bien distinta.

Interfaz Web PLC Siemens S7-1200

Como podemos comprobar de manera inmediata, con “admin” podemos parar la CPU, prueba de encendido de leds, estado de variables entre otras, que podremos encontrar en el menú de la parte izquierda.

No obstante, además del acceso web, también podremos definir el tipo de acceso al PLC tanto para lectura como por escritura, incluso considerando el tipo de equipo como un HMI.

Control de acceso PLC Siemens S7-1200

Otra de las funcionalidades a es la protección del Know-How. SIEMENS dirige esta capa de protección cara a salvaguardar la propiedad intelectual y acceso de los bloques que componen un programa protegiéndolos de modificaciones o copia.

A continuación, se muestra una imagen de la creación de un bloque con nombre “TEST_KNOW-How”.

Creación de bloque en PLC Siemens S7-1200

Luego mediante “botón derecho” podemos acceder a dicha protección. Con la primera de ellas protegeríamos el contenido de dicho bloque mediante la aplicación de un algoritmo que impide su visualización. Con la protección contra escritura, poder visualizarlo, en cambio si deseásemos realizar cualquier cambio, requeriría de una contraseña como en el caso anterior.

Protección de Know How, cambios y copia en PLC Siemens S7-1200

Ventana de asignación de contraseñas.

Definición de contraseñas PLC Siemens S7-1200

Finalmente, la tercera medida, evitaría la copia de este bloque pudiendo asociarlo al número de serie de la “Memory Card” o al de la “CPU” evitando así que pueda ser válido en otro equipo o medio de almacenamiento.

Control contra copia PLC Siemens S7-1200

Cuando se aborda las medidas de seguridad a implementar cara a proteger un entorno de control y automatización, se habla principalmente de medidas tanto a nivel de red como de equipos basados en arquitectura PC. Sin embargo, debemos de considerar que los equipos de control también disponen de algunas, que como es lógico no encontraremos en los modelos más viejos por no haber sido una necesidad.

También es cierto que, como todo, hay que buscar un equilibrio. Con cada medida estamos introduciendo una barrera, tanto para lo malo como para lo bueno. Quiero decir, que si la premisa es garantizar la disponibilidad debemos ser capaces de recuperarnos en el menor tiempo posible, por lo que es necesario definir claramente un proceso tanto de gestión de contraseñas como de procedimientos en los que éstas intervengan. Si no lo hacemos, podemos encontrarnos con no saber qué credenciales introducir llegado el momento.

Espero haya sido de vuestro agrado.

Un saludo!

Edorta