Archivo de la categoría: Bastionado

CPU Protection, Part I

Posted on por

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.

Siemens Security with SIMATIC Controller Guide

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!

 

 

Medidas nativas de seguridad en SCI, Siemens S7-1200

Posted on por

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.

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.

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

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

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

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.

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”.

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.

Ventana de asignación de contraseñas.

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.

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

Controlando nuestros Proveedores, Parte II.

Posted on por

Hola de nuevo. Siguiendo con la entrada anterior “Controlando nuestros Proveedores, Parte I” en el día de hoy vamos a ver la manera en cómo trabaja el binomio FortiGate + FortiClient.

Si bien la protección es en tiempo real, al hacer un análisis antivirus vemos la forma en la que detecta malware según la base de firmas del fabricante. Para ver su funcionamiento he dejado en el escritorio un fichero de EICAR.

No obstante, para que no fuese un típico ejemplo, también tenía una carpeta con el software incluido en el repositorio Pengowin y que desde aquí, dicho sea de paso, recomiendo dicho proyecto.

Viendo los logs:

en total fueron 55 detecciones:

Para terminar la desinfección es posible que se solicite un reinicio del sistema.

Como se puede ver, también en el escritorio tenía el simulador del protocolo S7 de SIEMENS, Snap7 del que hablaba en la entrada “Snap7 suite de PLCs y comunicaciones Siemens”. Al ejecutar el cliente para hacer una lectura del supuesto PLC, esto es “clientdemo.exe”, como el protocolo “ICMP” y “S7 Protocol” no están permitidos vemos su bloqueo, al igual que otros relacionados con el sistema operativo.

Si actualizásemos el perfil del control de aplicación correspondiente, ya podríamos acceder al mismo, en la IP 192.168.0.1.

También disponemos de un “Filtro Web”, funcionalidad que no he utilizado pero también útil si necesitamos tener acceso a una interfaz Web. ¡Ojo! Hablo de equipos locales, no accesos a Internet.

Como decía en el post anterior es compatible con los “Security Profiles” configurables en cada una de las reglas del Firewall, con lo que a nivel de red también podríamos ejercer un control adicional. Configurar los perfiles de qué se puede ejecutar, o no, en un PC puede llegar a ser complejo y laborioso en función de cada proveedor. Con lo que llegado el momento, podríamos llegar a ser más permisivos en este sentido en cuanto a consentir toda la categoría “Industrial” o “Servicios de RED” y denegar “Botnet”, “Game”, “P2P”, etc. y luego apoyarnos en reglas y “Security Profiles” como indicaba en las entradas:

También destacar la visibilidad que podemos tener desde el Fortigate a la hora de monitorizar los FortiClients conectados y de si cumplen, o no, con las políticas establecidas. Para ello deberemos ir a “Monitor – FortiClient Monitor”.

Ya por último comentar que en este caso hemos hecho uso de un Firewall Fortigate para la gestión de los endpoint. Sin embargo, Fortinet dispone de un producto específico para la gestión de este software denominada FortiClientEMS (Enterprise Management Server) con lo que podremos realizar un control centralizado y una gestión más pormenorizada de todos ellos.  Aquí os dejo un video presentación y enlaces con información al respecto.

Integración de Fortigate y FortiClientEMS.

Como hemos visto nuestros proveedores pueden ser no sólo un punto de entrada sino también el origen de un problema mucho mayor. Los habrá que sean estrictos con el uso de sus equipos sin embargo, esto no es razón para pensar que nada malo pueda suceder. Los entornos industriales no son para nada similares a los de Oficina o IT tradicionales. Los ciclos de vida son mayores con lo que la posibilidad de encontrarnos con Sistemas Operativos y Hardware viejo u obsoleto, es bastante común. Con ello, falta de soporte del fabricante y vulnerabilidades incapaces de corregir, y aun existiendo parches, según actividad de la compañía, desarrollos de software propios, o cierre, hacen que muchas veces sea inviable. A esto hay que sumar la existencia de empresas proveedoras de servicios que necesitan conectarse a nuestras instalaciones para llevar a cabo las tareas para las cuales han sido contratadas, y que no hace posible desplegar su software sobre otro equipo de la organización en el que sí tenemos control y conocimiento de su estado.

Con esta entrega hemos visto cómo con los NGFW FortiGate y endpoint FortiClient podemos llevar a cabo un control y permitir qué equipos de terceros puedan conectarse a nuestra red. De esta manera reducimos los riesgos  de que algo, o alguien, pueda comprometer la disponibilidad de nuestras instalaciones. No pretende ser un manual, ni mucho menos, sino una visión sobre de qué manera podemos ejercer dicho control y supervisión.

Obviamente existen en el mercado otros fabricantes, con otras soluciones que de igual manera puedan satisfacer nuestras necesidades, pero resulta interesante ver esta en concreto por su integración junto con el hardware de red. Como hemos visto, desde hace relativamente poco tiempo, los fabricantes de equipos de control y automatización tipo SIEMENS, Phoenix Contact, entre otros, incluyen ya características relacionadas con la Ciberseguridad, cosa con los equipos más antiguos o bien, o no disponen o son débiles. Por tanto, delegar en la electrónica de red y seguridad perimetral aspectos de la seguridad sigue siendo un hecho que durará por mucho tiempo ya que la renovación de PLCs, Robots, o cualquier otro por motivos puramente de seguridad, no es una razón de peso o prioridad.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta