LLDP, pros y contras de la difusión de información en redes PROFINET

Como hemos dicho en anteriores ocasiones, la evolución de las comunicaciones industriales tiende a basarse sobre tecnología Ethernet en detrimento, en muchos casos no en todos, de las comunicaciones serie. Esto va a traer consigo muchas ventajas, pero también algunos inconvenientes. Por ejemplo, será necesario el despliegue de distintas medidas que reduzcan el riesgo de que algo, o alguien, pueda atentar de manera voluntaria o involuntaria contra la disponibilidad de las instalaciones. Y es que, a mayor interconexión, mayor grado de exposición.

El estándar en estos casos es PROFINET, evolución del extendido PROFIBUS. Según sea su implementación encontraremos distintas funciones PROFISAFE, PROFIENERGY, PROFINET-MRP, etc. Sin embargo, este protocolo no viene solo, sino que también hace uso de otros para su funcionamiento, entre ellos LLDP. Si, parece que no, pero sí.

LLDP, Link Layer Discovery Protocol, es un protocolo empleado por dispositivos de red para anunciar información propia a otros equipos y dispositivos. Viene definido por el IEE 802.1AB. Su funcionamiento es muy similar al propietario de Cisco CDP, Cisco Discovery Protocol. Todos los dispositivos PROFINET lo soportan y es empleado para identificar, comprobar y mantener la topología de una red PROFINET, aparte de obtener información de diagnóstico si algo cambia. Otro de los usos es facilitar la puesta en marcha, tanto en un funcionamiento normal como en caso de fallo de algún equipo siendo necesario su sustitución. Las operaciones a este respecto se realizan de forma automática y sin necesidad de herramientas tipo software, lo cual simplifica y agiliza la forma en la que un equipo es reemplazado, minimizando la pérdida de disponibilidad.

Para ello los dispostivos PROFINET envían de forma cíclica esta información. Sin embargo  desde el punto de vista de la seguridad…

Haciendo un uso legítimo,  todo son facilidades. Sin embargo, cara a la realización de una auditoría o pentesting en entornos industriales que empleen PROFINET, LLDP se convierte en una fuente de información muy, muy buena.  Las tramas LLDP son enviadas a la dirección multicast 01:80:c200:00e. Los switches, por defecto, inundarán estas tramas por todos los puertos con lo que si conectamos nuestro Wireshark en alguna boca que encontremos libre… Seremos capaces de obtener toda esta información que se anuncia.

Empecemos por lo sencillo, aquí va una captura de un switch del fabricante HP…

LLDP_01

Como podemos comprobar podemos ver el nombre, boca del switch a la que estoy conectado, versión del Firmware, Hardware, etc. etc.

¿Ahora bien que pasa con equipos industriales? ¿Qué información podemos extraer? Veamos algunos ejemplos.

En la siguiente imagen podemos ver la que anuncia un switch SIEMENS. Allí podemos ver que estamos conectados al puerto 1, modelo X208, funciones MRP, IP de administración, etc.

LLDP_02

En la siguiente captura veremos el tráfico referente a un autómata S7-300 a lque nos hemos conectado a una de sus interfaces disponibles en su CPU.

LLDP_03

Como podemos ver aquí ya la información disponible es algo distinta, aunque se mantienen algunos campos como Chassis Subtype, Time to Live, etc. Sin embargo, algunos de los que no están por ejemplo el referente a MRP, protocolo utilizado en  switches para detectar bucles en topologías en anillo. Aprovecho para dejaros el link a una entrada que escribí hace un tiempo. Pincha aquí.

Como último ejemplo pondremos la trama esta vez de un módulo de comunicaciones CP del mismo PLC S7-300 que citaba anteriormente.

LLDP_04

Sin duda la información que vemo en cuanto a cantidad y calidad es muy importante. Si vemos habla de CP 343, propia de estos PLCs, con lo que ya sabemos el modelo que se trata. Como información extra podríamos ver de qué modelo de Firmware 3.2.23.

A partir de aquí habría que investigar si existe alguna vulnerabilidad conocida. En este caso no afecta, pero si la versión hubiera sido algo inferior, desde luego que sí. Un ejemplo de ellas, las podemos encontrar aquí:

Vulnerabilidad en módulos de comunicaciones SIEMENS.

Múltiples vulnerabilidades en módulos SIMATIC CP 343-1/CP 443-1 y CPU SIMATIC S7-300/S7-400 de Siemens

Como podemos comprobar LLDP puede ser un gran aliado en tareas de mantenimiento, puesta a punto o reducción del tiempo en caso de avería ya que simplifica todas las tareas asociadas para restaurar la operatividad. Sin embargo, surge el problema de qué hacer al publicitarse tanta información que luego, pueda hacerse un mal uso de ella. Se me ocurren varios usos, pero mejor no dar ideas.

Sin duda, desde un punto de auditoría o pentesting, LLDP será un gran recurso para una fase inicial de “Information Gathering”, pero como digo, en malas manos…

El problema aquí es que el propio protocolo PROFINET necesita de LLDP por lo que su uso debe ser permitido ya que se requiere bien para el funcionamiento como para reducir el tiempo de indisponibilidad por fallo. Cisco en alguno de sus recomendaciones deshabilitar CDP o LLDP para los equipos finales. Obviamente éstos no lo necesitar para su funcionamiento, pero en Controladores sí.

Puesto que debemos convivir con él, una de la alternativa es el bloqueo de puertos, bien de forma física como lógica.

Phisical Block Switch Port Siemens

No quiero decir con esto que gracias a LLDP nuestras redes PROFINET van a estar en peligro (que también), sino que existen protocolos que para su uso requieren de la difusión de información que aunque no queramos publicarla, debemos de hacerlo para aprovecharnos de las ventajas que éstos ofrecen en el mantenimiento, operación y garantía de disponibilidad.

¡Un saludo, nos vemos en la siguiente!

Edorta

 

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 29/10/17.

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

 

ICSSPLOIT, paro de PLCs S7-300 y S7-400

Hola de nuevo. Siguiendo en la línea de herramientas orientadas a redes industriales, hoy le toca turno a ICSSPLOIT.

ICSSPLOIT es un framework dirigido a sistemas y protocolos de control industrial que puede sernos de utilidad en tareas como auditorías y labores de pentesting. Escrito en Python, presenta un aspecto similar al Metasploit, conservando la interfaz y la forma de interacción. Se trata de un software Open Source pudiéndolo descargar desde su sitio en Github. Allí podremos ver el conjunto de scanners, exploits, protocolos y clientes que soporta, y que esperemos vaya creciendo con el tiempo. Veamos un resumen.

Funcionalidades ICSSPLOIT_01

La herramienta viene preparada para Kali Linux incluyendo lo necesario para su funcionamiento. Sin embargo, si algo nos faltase, podríamos mirar su fichero “requirements” y llevar a cabo la instalación de los paquetes mediante:

pip install -r requirements

Así pues qué mejor manera que verla en acción con un ejemplo. En otras entradas he trabajado con simuladores pero en esta ocasión lo haré con un PLC Siemens S7-300 real. Por supuesto, en un entorno de laboratorio. Por si fuera poco, además lo haré en formato vídeo. Una novedad que he querido introducir gracias al creciente número de visitas que ha ido teniendo el blog. Así pues, a continuación, veremos cómo llevar a “STOP” tanto la CPU como el una tarjeta CP del autómata para luego revertir el proceso. Todo de forma remota. Ahí va!

 

Como decía, también es válido para los S7-400. A continuación muestro la captura con Wireshark sobre los paquetes enviados y recibidos. Comentar que el PLC tiene IP 192.168.0.1 y el PC 192.168.0.100 .

PLC A STOP_01

Y su arranque:

PLC A START_01

Hasta aquí la entrada de hoy. Corta, pero que con el vídeo espero haya sido ilustrativa y hayamos descubierto esta nueva herramienta que sin duda va a ser de mucha utilidad para los profesionales de la seguridad. En sucesivas entradas iremos descubriendo nuevas funcionalidad, poco a poco.

¡Un saludo, nos vemos en la siguiente!

Edorta

Puerto espejo, un aliado a veces olvidado.

Como hemos hablado en otras ocasiones, poco a poco se va extendiendo el uso de protocolos industriales basados en tecnología Ethernet en lugar de los tradicionales serie. Esto, si bien permite otra manera de interconexión, también abre nuevas posibilidades en la denominada Industria 4.0. Sin embargo, obliga a tomar cierto tipo de medidas en cuanto a Ciberseguridad se refiere ya que los dispositivos y sistemas que intervienen en los procesos de control y automatización no sólo comienzan a estar más expuestos sino que son susceptibles de sufrir los mismos problemas con ciertos agravantes.

No obstante, aunque se trate de comunicaciones Ethernet, los equipos de networking industrial no sólo conservan funcionalidades tradicionales, sino además otras propias de estos entornos como MRP en contraposición a STP, Spanning Tree Protocol.

Una que puede sernos de mucha utilidad, sin menospreciar a otras tantas, es la de “Port Mirroring” o Puerto Espejo. Esto es, la capacidad de un Switch para poder replicar el tráfico que pasa por dos o más puertos y enviarlo por un tercero. Para entender mejor este concepto haré un repaso sobre cómo funciona un switch. Aunque sea algo bastante obvio para Técnicos de Comunicaciones o Administradores, seguramente no lo sea tanto para otros de Mantenimiento o Ingenieros de Procesos.

Esquema_01

Pongamos un ejemplo con dos equipos llamados “HMI” y “PLC”. Para comunicarse el equipo “HMI” con el “PLC” deberá conocer la IP del de “destino” y, al darse cuenta que está dentro de su misma red, deberá obtener entonces la MAC de éste. Para ello echará mano del protocolo ARP. El protocolo ARP permite conocer la dirección MAC de un equipo a partir de una IP conocida. Por tanto, si “HMI” no la tiene almacenada en su caché ARP  deberá realizar un ARP request. Es decir, preguntará a toda su red sobre cuál es la MAC del equipo con IP XXX.XXX.XXX.XXX. En este caso la dirección MAC de destino será ff:ff:ff:ff:ff:ff, un broadcast de capa 2. Todos los equipos la recibirán y la procesarán pero sólo el que tenga la IP por la cual se pregunta contestará con un ARP Replydiciendo “–La MAC de la IP XXX.XXX.XXX.XXX es XX:XX:XX:XX:XX:XX. Conocida por “HMI” tanto la IP y MAC de “destino”, se producirá la comunicación. Si por el motivo que sea no se conocen algunos de estos campos, la comunicación no se produce.

Así pues, un Switch, a diferencia, de los Hubs introduce un nivel de “inteligencia”. Un switch contiene una tabla, denominada CAM (Content-Addresseable Memory) en la cual se incluyen las direcciones MAC de cada uno de los equipos conectados a los distintos puertos del switch. Para realizar las tareas de conmutación, acudirá a ella para saber por cuál de ellos deberá enviar el tráfico en función de la MAC de destino. Esta asignación de direcciones MAC podrá hacerse de forma dinámica o manual. La forma manual implica que el administrador asigne a cada puerto del switch la MAC del equipo conectado; mientras que la forma dinámica se basa en que por cada trama que ingrese por cada boca del switch, éste mirará la MAC de origen y la incluirá en la CAM. Pasado cierto tiempo, si no se recibe tráfico se borrará dicho registro. Así, a la hora de efectuar la comunicación, los switches se fijarán en la MAC de destino, consultarán dicha tabla para saber por qué puerto deben enviarla y la “despacharán”.

Ahora bien, si por distintas razones necesitásemos conocer el tráfico que pasa en entre “HMI” y “PLC”, no podríamos conseguirlo ya que el switch sólo conmuta el tráfico por los puertos involucrados. Aquí es donde aparece el concepto de “Port Mirroring” o “Puerto Espejo”. Mediante esta funcionalidad lo que conseguimos es que el switch haga una copia de dicho tráfico y lo envíe por un tercer puerto. ¿Con qué finalidad? Por ejemplo, si en este último conectamos un analizador de tráfico, podremos estudiar todo aquello que suceda entre “HMI” y “PLC” y detectar posibles anomalías sin interferir entre el flujo de comunicaciones. Obviamente el switch tiene que tener esta capacidad para hacerlo, sino… no hay nada que hacer.

Si bien las tasas de transferencia en entornos OT son menores que en entornos IT, esto no quita que debamos tener presente algunas consideraciones. Por ejemplo, si las comunicaciones son Full-Duplex (enviar y recibir a la vez) y el enlace es de 100 Mbps, el tráfico que puede llegar a recibir un equipo es de 200 Mbps, 100 Mbps para enviar y otros 100 Mbps para recibir. Si el enlace del puerto espejo es también a 100 Mbps el consumo de ancho de banda entre “HMI” y “PLC” no puede ser superior al 50%, ya que estaríamos superando la capacidad del mismo. O bien, que sea de una velocidad inferior, por ejemplo, a 10 Mbps. En esos casos, el switch descartaría paquetes con lo que el tráfico capturado no se correspondería con la realidad. Aparte, claro está, de la carga computacional que supone para la CPU del propio switch la copia de las tramas. A esto hay que sumar otras limitaciones que cada fabricante pueda considerar en sus productos.

Sin duda es un buen recurso, pero como comento, hay que tener en cuenta algunos aspectos técnicos.

A continuación, pondré ejemplos sobre su implementación en equipos. En la siguiente imagen se muestra una captura de la configuración de un switch Mikrotik RouterBoard 260GS, el cual dispone de 5 puertos RJ-45 10/100/1000 + 1 SFP.

config Mikrotik RouterBoard_01

Según cómo está configurado, estaríamos haciendo una copia del tráfico tanto saliente como entrante del puerto 1 que es dónde en teoría habría conectado un PLC y la enviaríamos por el puerto 2 donde conectaríamos un sniffer que lo recogería para un posterior análisis. Un clásico de este tipo de funciones es el archiconocido Wireshark. También podríamos seleccionar sólo uno de los sentidos, o bien el saliente o entrante según sean nuestras necesidades.

Captura Wireshark_01

Lo cierto es que ese dispositivo resulta de mucha utilidad ya que por su pequeño formato puede ser utilizado en tareas sobre equipos finales como supervisión, diagnóstico, troubleshooting, etc. Aparte, al disponer de un módulo SFP podremos conectarlo a enlaces de fibra o par de cobre.

Ya sobre equipos de red tradicionales, podemos poner un ejemplo con switches Cisco. La funcionalidad la recoge este fabricante como puerto SPAN (Switched Port Analyzer). Aquí las posibilidades, como es lógico, son mayores y pasamos a la interfaz de consola. Podéis encontrar más información en este enlace.

Hasta ahora hemos visto switches “tradicionales”, sin embargo otros específicos de entornos OT también poseen esta funcionalidad como los muestra SIEMENS en este enlace y de donde se extraen las siguientes imágenes.

SIEMENS_Port_Mirroring_01

SIEMENS_Port_Mirroring_02

Sin embargo esto no es exclusivo de equipos de networking. Por ejemplo, el fabricante Fortinet la incluye en sus dispositivos. A continuación se muestran capturas sobre un FortiWifi 60D con versión de FortiOS 5.4.5. Como podemos ver la forma de acceder a ella es a través del apartado de “Interfaces”.

Fortigate SPAN_01

En mi caso “HW_SW_01”, y ya en su configuración veremos el campo correspondiente:

Fortigate SPAN_02

Como vemos el criterio es similar, interfaz a monitorizar y a hacia cuál queremos enviar la copia de los paquetes. Haciendo una prueba, he conectado en el puerto “internal1” un servidor Modbus (10.10.10.100) y desde el puerto “internal2” (10.10.10.200) el cliente desde cual hacer las lecturas. Finalmente, un equipo con Wireshark en el puerto “internal3” donde capturar el tráfico.

Wireshark_Modbus_01

Un caso de uso podría ser en un equipo donde se le aplique una estrategia de “Virtual Patching” y necesitemos saber qué es lo que está sucediendo desde, hacia, él. Hace tiempo escribí a este respecto, os dejo los enlaces:

Hasta aquí la entrada de hoy con la que espero hayáis podido descubrir una nueva funcionalidad de vuestros equipos. Puede que escondida, pero seguro de utilidad en un futuro. Las aplicaciones pueden ser varias, espero poder escribir sobre alguna de ellas. Sólo falta tiempo.

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

Edorta

Proveedores Externos, posible punto de entrada… 

Como bien sabemos la seguridad no es algo que se acaba con la implementación de un conjunto de medidas técnicas y la definición de unas políticas que prevengan que algo o alguien cause un daño en nuestra organización. En el caso concreto de los entornos industriales, esto además puede repercutir no sólo en un punto de vista lógico sino además afectar en los elementos físicos de las instalaciones.

A la hora de llevar a cabo un proyecto se ha de realizar un análisis de riesgos que evalúe y cuantifique el nivel en el que una organización está expuesta a sufrir un incidente de seguridad considerando, entre otros, las amenazas, vectores de ataque y vulnerabilidades. Sin embargo, estos aspectos pueden cambiar con el paso del tiempo, en particular las vulnerabilidades ya que, como podemos comprobar, la aparición de nuevas es algo continuo. Por tanto, los niveles que resultan satisfactorios a día de, un año después pueden no serlo, siendo la ciberseguridad  un proceso vivo que debe revisarse y ajustarse.

Una de las circunstancias a las que nos vamos a enfrentar, y que muchas veces nos olvidamos, es la existencia de gran cantidad de proveedores dentro de las organizaciones industriales. Las mismas recurren a productos y servicios especializados de terceros que luego deben ser soportados durante su ciclo de vida y garantizar así un respaldo en caso de incidencias.

Para poder llevar a cabo las respectivas tareas, los técnicos de estos proveedores deberán en algún momento, conectarse a la red de operación. Y esto presenta un problema, ya que:

  1. En muchas ocasiones contarán con un software propietario con licencias asignadas a ese equipo dificultando, o no siendo posible, reasignarlas a otro de la propia organización.
  1. Por supuesto al ser un equipo de un tercero no sabemos el estado de actualización del sistema operativo.
  1. Como no, desconocimiento del uso responsable, o no, que se le ha dado por parte de su propietario o usuario.
  1. Puesto que se tratarán de equipos portátiles para disponer de movilidad para llevarlos a tal o cual cliente, vaya uno a saber a qué otras redes han estado conectados.
  1. Y ya para rematar, como no puede ser de otra manera, usuario con permisos de administración y contraseñas de dominio público para que sea quien sea el que lo utilice, lo pueda hacer con total libertad.

Con todo lo dicho, ¿vamos a dejar conectarse a nuestra red equipos sobre el que no tenemos control o bien desconocemos el estado de actualización, limpieza, software instalado, etc? ¿Cómo encaja esta situación dentro de nuestras políticas? Y por si fuera poco, ¿si encima estos técnicos vienen del extranjero? ¿qué hacemos?

Indudablemente esto es una situación a la que deberemos hacer frente y necesariamente contemplarla dentro de nuestras políticas. Esto es, la gestión de los proveedores.

A este respecto deberemos tener en cuenta dos aspectos. Por un el administrativo y por otro, la solución técnica.

Desde el punto administrativo la organización deberá establecer un proceso donde se regule qué hay que hacer cuando un proveedor deba conectarse a nuestra red OT.

La primera de ellas es realizar un análisis de riesgos de este proveedor con lo que habrá que identificar:

  1. Necesidad justificada de la acción.
  2. Alcance de trabajos.
  3. Activos sobre los cuales se va a actuar.
  4. Información técnica sobre las intervenciones.
  5. Duración estimada.
  6. Recursos empleados.
  7. Manera en la que afecta a la organización.
  8. Análisis del impacto que tiene para la organización en caso de producirse un error y cómo afecta a aspectos tales como financiero, operativo, clientes y trabajadores.
  9. Representación gráfica tanto del riesgo existente como del residual si el primero no puede ser reducido o mitigado.

Otra de la información que tenemos que recoger son las necesidades de comunicación que van a tener. Esto es, direcciones IP, servicios, protocolos, etc. Esto mismo puede ser reflejado en un documento para que los administradores de los firewalls deban configurar los permisos correspondientes. Aquí dependerá de cada cual, pero importante valorar funcionalidades de los mismos en materia de:

  1. Portal Cautivo.
  2. Validación de reglas según validación de usuarios.
  3. Limitación temporal de permisos.
  4. Perfiles de seguridad concretos según labores a realizar.
  5. Otros.

Ya por último es importante considerar los acuerdos de confidencialidad y muy especialmente de responsabilidad. En cada intervención, por mucho que se planifique y se reduzcan las posibilidades de sufrir un incidente, el riesgo está. Por tanto, conviene acordar si fruto de esa intervención se deriva un error que afecte a la actividad de la instalación, y a su vez, un perjuicio económico a la empresa en cuestión.  ¿Quién las asume?

Una de las acciones que también debe  contemplarse, o deben realizarse, es hacer  un escáner de vulnerabilidades para conocer qué o cuáles pueden estar afectando al equipo de nuestro proveedor. Esto nos va a permitir exigir que antes de llevar a cabo cualquier trabajo deba actualizar los equipos o corregir las desviaciones antes de efectuar la conexión a nuestra red.

En el artículo de hoy hemos hecho una aproximación desde el punto de vista de que exista una VLAN dedicada a empresas externas donde toda comunicación contra otra red debe pasar por un Firewall (NGFW, Next Generation Firewall). Sin embargo, puede ocurrir que esta estrategia no sea efectiva dependiendo de la arquitectura y equipos que componen nuestras redes. Puede haber situaciones que sea necesario que los proveedores deban conectarse físicamente a la red control. Veamos la imagen siguiente:

El PLC tiene por un lado una tarjeta de comunicaciones que conecta con la red 192.168.1.0/24, y luego la propia de su CPU con el 192.168.10.0/24. Según el esquema inicial donde nuestro proveedor lo hace desde el entorno de oficinas debiendo pasar por los firewalls  de “Separación” y por el de “Segmentación”, no podría llegar a las interfaces de la red 192.168.10.0/24 ya que el PLC puede no tener la capacidad de llevar cabo el enrutamiento entre ambas. Sí que podríamos llegar a él por la red 192.168.1.0/24 y a través del software de configuración poder ver el resto de interfaces, pero si lo que queremos es llegar directamente a los sensores o actuadores de la periferia 192.168.10.0/24 que controla, por ejemplo por HTTP, S7, ModbusTCP, FTP, o cualquier otro (sea seguro, o no) seguramente no podamos hacerlo por esa falta de capacidad.

Por tanto, he aquí un problema añadido y es que, ¿Dejamos conectar a ese proveedor su PC y que se efectúen las comunicaciones en Capa 2? ¿Cuáles son los riesgos a los que nos enfrentamos si no tenemos ningún cortafuegos que filtre las comunicaciones? ¿Cómo hacemos frente a estas situaciones?

Bueno pues estas y otras cuestiones trataremos de ir resolviéndolas poco a poco en nuevas entradas.

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

Edorta

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 03/08/17.

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

 

Un breve repaso a definiciones de malware

Como hemos dicho en otras entradas, la proliferación de equipamiento industrial en redes basadas en tecnología Ethernet ha ido en aumento al igual que el grado de exposición frente a actividades maliciosas. Tal es el caso del malware algo que, si bien ya estábamos acostumbrados en entornos IT, su presencia en entornos industriales no sólo está haciéndose mayor sino que su desarrollo está siendo dirigido hacia este tipo de dispositivos. Además, cobra especial importancia cuando los equipos con Sistemas Operativos Windows no sólo no están parcheados sino que además no cuentan con herramientas protección. Aquí podemos entrar en un debate donde encontraremos detractores y defensores sobre la seguridad que ofrecen este tipo de productos, los anitvirus. En cualquier caso convendría realizarse algunas preguntas y que para nada son todas las que podrían ser.

  1. ¿Ofrecen los antivirus del mercado firmas para malware dirigido a Sistemas de Control Industrial?

IRONGATE

  1. Considerando el ciclo de vida mayor de los equipos en comparación con entornos IT, ¿Ofrecen soporte a Sistemas Operativos como Windows 2000 y XP presentes aún en entornos OT?
  1. Todo equipo tiene una parte software y otra hardware. Teniendo en cuenta que estos Sistemas Operativos poseen recursos como CPU, memoria, etc. mucho menor de lo actual. ¿qué impacto tiene la carga computacional cuando se lleva a cabo un análisis de equipo?
  1. Según lo anterior, ¿podrían verse afectadas en un momento dado las aplicaciones que interactúan con los equipos de campo y que cuyo funcionamiento debe garantizarse?
  1. A diferencia de entornos de oficinas donde, como norma general, diariamente existe una ventana de tiempo para poder llevar cabo ciertas acciones, ¿qué ocurre en los casos de 24 X 7 X 365?

Crashoverride portada

Cuestiones aparte, lo que si es cierto es que muchas veces los técnicos, ingenieros de procesos o de mantenimiento, que interactúan en última instancia con el equipamiento potencialmente infectable, no sólo no son conscientes de los riesgos sino además de las diferencias que existen entre los tipos demalware. Por tanto, si una entidad emite una información sobre tal o cual campaña o bien se emite un boletín con las características del “bicho” es más que probable que estas personas entiendan poco, o nada, de todo cuanto ahí se documenta. ¿Porqué? Porque hasta ahora no había esa necesidad. Estos profesionales deben de saber de automatismos, sensores, actuadores, relés, motores, neumática, hidráulica, robots, etc. etc. La ciberseguridad no era una prioridad, hasta ahora. Por tanto, al hablar de Troyanos, Rootkits, Gusanos, o cualquier otro, estamos hablando de algo que pueden no saber interpretar, ni en su particularidad ni en su contexto pero que afecta a los equipos que sí son de su responsabilidad.

Así pues, veía necesario hacer un pequeño resumen de los principales tipos para hacernos una idea de una manera sencilla y sin entrar en muchos detalles, de lo que dicha documentación trata de contarnos. Vamos pues.

Droppers

Es software que permite la instalación de malware sobre un objetivo determinado. Esta acción puede hacerse bien en una sola fase, por ejemplo, el malware viene embebido dentro de un fichero; o bien en dos fases. Esto es, el “dropper” descarga una pieza de software desde un servidor y a continuación se produce la infección.

Rootkits

Estas “herramientas” tratarán de encubrir procesos o servicios que están llevando algún tipo de actividad maliciosa, como puede ser permitir acceso remoto a un atacante. Esto se puede conseguir ofreciendo información falsa sobre las tareas que se están ejecutando y pretender hacer ver que todo está correcto cuando en realidad el equipo está comprometido.

Adware y Spyware

El “Adware” se trata de software publicitario que genelaralmente se presenta en los navegadores web como añadidos con una funcionalidad concreta siendo muy comunes en aplicaciones gratuitas. En algunas ocasiones pueden contener algún tipo de software tipo “Spyware” con el fin de recolectar cierto tipo de información del usuario o del equipo sobre el cual se instala.

Gusanos

La función principal de los gusanos es la de replicarse a sí mismo y conseguir extenderse. Las dos vías más comunes es hacerlo por la red o bien por otro medio como las memorias USB. Pueden operar de forma independiente, aunque a menudo son usados conjuntamente con algún otro módulo. Por ejemplo, el gusano se propaga y dicho módulo infecta al equipo vulnerable. Un ejemplo lo tenemos con el malware Wannacry que tanto oímos hablar no hace mucho tiempo.

Troyanos

Se trata de malware cuyo principal propósito es dar acceso remoto a un sistema para actuar en él en un momento dado. Aparte de abrir una puerta trasera, podrán  incorporar otras funcionalidades como captura de pulsaciones de teclas para posteriormente enviarlos a un host remoto, o incluso un rootkit para pasar desapercibido.

Ransomware

¿Qué se puede decir de este tipo de malware con todo lo que ha acontecido con “Wannacry”?  En cualquiera de los casos debemos de decir que el objetivo de este tipo de malware es impedir el acceso a ficheros y solicitar un rescate para permitir su acceso de nuevo. La principal vía es el cifrado de los mismos, y posterior aviso de que la operación se ha llevado a cabo. Una vez efectuado el pago, el atacante envía la clave para proceder a su descifrado y así recuperar la información.

wannacry_05-1024x774

Hasta qui he querido dar una definición muy muy breve de los principales tipos de malware y que a menudo podremos encontrar en aquellos informes que puedan aparecer relativos a incidentes en entornos industriales. La entrada de hoy puede parecer muy “light” para aquellos que provengan del mundo IT, pero en este caso ha he pretendido dirigirla a personas relacionadas más con las Tecnologías de Operación que, generalmente, no están relacionadas con este tipo de términos.

Dicho lo cual, hasta aquí la entrada de hoy que, aunque descafeinada para algunos, espero sea el punto de partida para otros, que seguro deberán familiarizarse cada vez más con estos u otros tecnicismos.

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

Edorta.