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.


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


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.


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, 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!


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!


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!


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!


  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


  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!