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

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

 

TAP Devices, Siemens TAP 104

Few months ago, I wrote about how port mirroring is an allied to capture and analyze network traffic. You can access to the article clicking here. There are a lot of reasons to use it, such as identify communications, troubleshooting tasks, use of IDS/IPS systems, and so on. But port mirroring is not the only one, we can use TAP devices. However, as I said several times, we must use specialized equipment for these environments, in particular industrial ones. Today I will talk about Siemens TAP 104.

Siemens TAP 104 is a hardware device that can be installed between two devices to gather a copy of data traffic on Ethernet based networks. Once the collected frames are stored, we can visualize them with a network analyzer tool to identify the information that we are looking for. The TAP device does not affect to the communication that pass through it.

Siemens TAP 104

It has four RJ-45 ports. Two to connect the segments that we want to monitor and two more to connect the systems to collect the frames. It operates in a fault-free mode even when the power is off.

One use case can be as the picture below shows. For example, we can be interested to identify issues between the HMI and the S7-1500 PLC. The traffic will be gathered by Grassmarlin tool that can be downloaded from here. I wrote about it more than a year and half. You can find the article clicking here.

Siemens TAP 104

Following the concept of the previous picture, this time, I have replicated this scenario in small testbed. In the picture below you can identify different devices, such as Fortinet Fortigate Rugged 90D, Fortinet Fortiswitch 112D-PoE, Siemens PLC S7-1200, Siemens HMI, Siemens TAP 104 and a laptop. As you can see, the TAP is just in the middle of the Fortigate switch and the PLC. Each communication from and to them, is replicated to the first RJ-45 port, where the laptop is connected and running Wireshark packet analyzer.

Testbed Lab

Testbed Lab

Once the traffic is gathered, we can open it with an analyzrer. Below we can see the information available from LLDP protocol as system description, IP management address, and so on.

LLDP Wireshark

But if we are looking for information, we can see the values of sending and receiving from and to the devices.  In the picture below you can see the field “Function: GetMultiVariables”

S7 Communication Wireshark

And then displaying the field “Response Set-ValueList”  we can see the values 84 and 16, the same that appears in the HMI.

S7 Communication Wireshark

Today, with Siemens TAP 104, we see other way to gather network traffic to identify possible issues in our industrial communications where it is mandatory not to introduce additional latencies that may affect them. In general, it is very common to do it using Port Mirroring configurations, but as we have seen, there are others. Either Port Mirroring or TAP devices, we can find them a helpful resource for different use cases such as troubleshooting, anomalies, security problems and much more. Always with specialized equipment.

That is all for now, see you next time!

Edorta

Specialised products, FortiSwitch Rugged 112-D PoE

As I said several times, the industrial communications trend to Ethernet Technology for the advantages that it provides. However, this is not similar to affirm that everything will can communicate by frames or packets. There are many scenarios where serial protocols are being used because is not possible to update to Ethernet. For example, migrate to it requires to change cabling, reconfigure devices, deploy new networking equipment, programming changes, and many other measures. But if we can, we must deploy networking devices according to these harsh environments. Today, I will show one that can be used for its capabilities, Fortinet FortiSwitch Ruuged 112D-PoE.

It has 8 GE RJ-45 ports and 4 more GE SFP slots. It can be necessary for those situations when you need to connect devices by optical fiber. It is widespread used because permits more than 100 meters, or less, and does not affect electromagnetic interferences in comparison with unshielded twisted pair Ethernet cabling. It supports fiber single mode, multimode and long haul single mode with LC connector

FortiSwitch Rugged 112D-PoE

This switch can be used to connect PLCs, HMIs, or other device that communicates by industrial based Ethernet Protocols such as PROFINET, Ethernet/IP, Modbus/TCP, and so on. It has redundant power input terminals in the range from 44 to 57V DC to give service for PoE ports if needed.

FortiSwitch Rugged 112D-PoE

There are not any fans to cool itself to prevent damages. It is so important for those dusty places where can affect the operation stopping them if it is excessive. The switch can work in a temperature range from -40 to 75º C (-40 – 167º F) and can be mounted in DIN rail or wall depending your rack or facility. Related to the atmosphere, it tolerates up to 5-95% of non-condensing humidity.

FortiSwitch Rugged 112D-PoE

As you know, the lifecycle of industrial components and systems are higher in comparison with IT world. In this way, Fortinet affirm this switch has a mean time between failures (MTBF) more than 25 years. For this, it is capable to work in OT scenarios.

When you connect to its web interface you can see the dashboard where you can identify different information.

FortiSwitch Rugged 112D-PoE Menu

As you can see on the left, you will find a menu from where you can configure different features. For example, authenticate user to a LDAP server, port mirror ports, syslog server, and so on.

FortiSwitch Rugged 112D-PoE Authenticatio

FortiSwitch Rugged 112D-PoE Port Mirror

FortiSwitch Rugged 112D-PoE Logs

It operates at Layer 2 but you can get more Layer 3 capabilities if you connect it to a Fortinet Fortigate unit. Furthermore, you can manage your Fortiswitch from Fortigate console by FortiLink protocol. You will not find all the features, but you can configure VLAN interfaces, switch on and switch off ports, enable or disable PoE, and others.

FortiSwitch Rugged 112D-PoE and Fortigate Rugged 90D

Even though Ethernet technology give us a lot of improvements not always we will be able to implement them in own facilities in particular when they are working for 24 hours a day, 7 days a week, 365 days a year. It requires a very big effort in time, knowledge and obviously, budget .

Depending the activity, availability, probably, we will only get time on Christmas, Easter Week or summer Holidays, to do everything we need. In addition to that, be sure that you meet with others employees such as maintenance technicians that they have to do tasks relative to keep on good state of operation of our infrastructures. And as you know, they have more priority.

In spite of this, either it is possible to update or deploy a new facility we need to know which are the devices available that meet the requirements that we need. In the same way, industrial and automation control system vendors have been working to deploy new products for Cybersecurity purposes; the Cybersecurity product manufactures have developed industrial networking equipment. One of them, is Fortinet FortiSwitch Rugged 112D-PoE that I have shown. All features can be found by clicking here.

Other choice to find the best solution for our needs.

See you next time!

Regards

Edorta

Device Whitelisting

Today I would like to start by apologizing because this is my first post in English. English is not my mother tongue so be sure that I can make some grammar, vocabulary or expression mistakes. Last year I finished with more than 52000 visitors and I decided for this 2018 try to write some articles in this language, in particular to come to English-speaking people. Having said this, let’s make a start!

A lot has been written about if USB ports have to be turned on in industrial environments and the threat that they might suppose for them. In particular, pen drives and other storage devices. Obviously, this is true and somebody may think “Ok, block them and the problem will disappear”. Yes, but depending on the scenarios it cannot be possible to do. The theory crashes with the reality, once again. Why? Few questions…

  1. How do you access to data stored in systems located on isolated facilities?
  2. What do you do if recover a system without network connection is needed?
  3. How do you install a new software version if the network is not routed and cannot access to other like DMZ?
  4. What happens if the software requires a license USB device?
  5. If you have a backup system, what do you do if you have to recover a system and the network connection is not available? And if this is possible, are you going to download several gigabytes from that server across the OT network?
  6. If you have a software distribution system, how do you deploy software that cannot be packetized?
  7. Are you going to trust totally on these backup systems and do not have an Emergency Plan to storage configurations, programs, software or firmware in an external USB Hard Disc Drive?

For these and further questions are that the USB devices have, can and must be used at industrial environments with multiple purposes. However, we must take measures to prevent any incorrect use and be the source of incidents by negligence, spread up malware, steal information, infect a system, and so on. In consequence, the USB port in the majority of cases have to be switched on.

Obviously, the first step should be raise awareness to all the personnel involved, or related, with OT tasks, but everybody knows that this is not enough. We need technical tools.

Consequently, as we must live with our “enemy” because we need him, we have to decide how to control him, and reduce the risk that somebody, or something, cause damages in our facilities.

One measure is to decide which USB device we will use for maintenance, operational, recovery or any other justified reason to be plugged on to own systems. For example, HMI, engineering workstations, programming laptops, etc. Others, or any similar as mobile phones, pen drives, are forbidden. Then, either via software or endpoint security solution, permit or deny mount them on these systems.

Today I will talk about how to do this using Symantec Embeeded Security : Critical System Solution” in 7.1 version. In other posts, I mentioned how USB Control and Application Whitelisting works.

On this occasion I have created the following scenario.

USB Whitelisting Scenario v1

As you can see, we have “Management Console” installed on a PC with Windows XP OS. From there, we connect to the SES:CSP Server to set up Application Whitelistng Policies. Finally, a Programming Laptop used to connect to PLCs and other devices located in OT environments.

We connect to the server from XP PC and open the selected policy named “AUTH_USB_win_whitelisting_sbp v7.1.0 r136 – Whitelisitng”

USB_POLICY_01

Open “Device Control Rules” we are able to block, or not.

USB_POLICY_02

If we check “Block USB devices” a new window is opened.

USB_POLICY_03

From there we can “whitelist” the devices. Clicking on “Add” we can choose between those we have connected or if we want to specify them manually.

USB_POLICY_04

In this case our device appears as follow:

USB_POLICY_05

Now we are ready to save changes and apply onto the programming station.

USB_POLICY_06

As you can see the device can be mounted and the files be accessed in function on the application policies.

USB_POLICY_07

But if other USB stored devices are plugged, they will not be mounted and visible on the explorer. A log will be created as follow.

USB_POLICY_08

The green “information” logs are related to the right device.

The use of USB devices as pen or hard disc drives sometimes are not only useful, are necessary. All depends on the activity, the context or the criticality of the systems. They give us the flexibility to transfer files, configurations or any information, especially in those moments when we cannot do it across the network. For example, have a second repository to storage a copy of everything we need to recover an equipment, something important in the context of Emergency or Disaster Recovery Plans. Furthermore, the data transfer using USB can be higher than network interface cards, probably 10/100 Mbps, so we can do our tasks faster than if we wait to download everything from a server.

In any case, we must control the USB ports because they can be our allied or our enemy. We must do not forget that in case of unauthorized USB is plugged, the execution, read or write can be submitted to application whitelist policies.

That´s all, Thanks a lot, see you again!

Edorta