Controlando nuestros Proveedores, Parte I.

Anuncios

Hace unos días hablaba acerca de la necesidad de gestionar los proveedores externos e incluirlos en nuestras políticas de seguridad, claro está, orientadas a su actividad. Muy particularmente en grandes corporaciones, éstas se ven obligadas adquirir a terceros equipos, productos y servicios especializados para la actividad de la misma. Luego, cara a garantizar una respuesta o asesoramiento, firman contratos de soporte con el fin de obtener ayuda en caso de ser necesario. Como veíamos en la entrada “Proveedores Externos, posible punto de entrada…” ha de establecerse un procedimiento tanto administrativo como técnico que regule cómo han de conectarse y qué requisitos deben reunir sus equipos antes, durante y después de conectarse a nuestra red de control.

A diferencia del post que citaba anteriormente, hoy hablaré sobre cómo podemos controlar técnicamente dichos equipos. Es un ejemplo, obviamente no dará respuesta a todas las necesidades ni a todas las casuísticas que sin duda serán muy particulares dependiendo de tecnologías, industrias, equipos, actividad, o cualquier otro factor.

El objetivo será llevar a cabo un control sobre el PC de un proveedor que necesariamente ha de conectarse, sí o sí, a nuestra red OT para llevar a cabo tareas de soporte o mantenimiento. Estos PC contendrán el software necesario sin embargo, no tendremos ni su control, ni conocimiento alguno del estado de actualización de sistema operativo, aplicaciones; firmas antivirus (si las hubiera); vulnerabilidades; etc. etc. Habrá quien piense que una alternativa pueda ser instalar las herramientas en PCs de la propia organización sobre los que sí tendríamos aquello que ahora nos falta. No le quito razón, sin embargo, la realidad nos muestra una serie de inconvenientes:

  1. Coste de licenciamiento de Software. ¿Nueva instalación, nueva licencia? ¿reasignación de licencias?
  2. Necesidad de probar aplicaciones en PCs de la organización para garantizar pleno funcionamiento.
  3. Dada el ciclo de vida mayor, probabilidad de uso en Sistemas Operativos con distintas versiones.
  4. Desarrollo de herramientas a medida y bajo condiciones concretas, diferentes a los empleados en la organización.

Por tanto, con todo en contra, lo que sí podríamos hacer es obligar a nuestros proveedores a cumplir nuestras normativas y marcarles las vías de cómo hacerlo. De hecho, es algo que las políticas de seguridad deben contemplar. Me refiero a que una vez implementadas todas las herramientas y medidas, todo nueva sistema, instalación o equipo debe cumplir con aquello especificado para el nuevo “ciberseguro” escenario. Para algo lo hemos hecho, ¿no?

Para ello emplearemos la aplicación endpoint FortiClient de Fortinet con el que podremos identificar y remediar equipos vulnerables, o comprometidos, reduciendo así la superficie de ataque. Luego podremos integrarlo en otras soluciones del mismo fabricante, aspecto que no abordaremos en este post.

Para la Prueba de Concepto he creado el siguiente ejemplo:

Como vemos en la figura, un proveedor ha de conectarse a la red Control para llevar a cabo determinadas tareas. Tiene dedicada una VLAN con un direccionamiento 192.168.254.0/24 a la que deberán conectarse todos los equipos de proveedores. Así pues, todas las comunicaciones deberán pasar por el Firewall (NGFW) que bien podría ser el de Separación o de Segmentación dependiendo de cómo tenga definida la arquitectura la organización. Luego, en función de cómo configuremos el mismo, dejaremos pasar el tráfico necesario hacia la red 192.168.0.0/24, esto es, la de Control.

Para ello emplearé la versión 5.4.4 de FortiClient y un equipo FortiGate 61E con FortiOS 5.4.5.

Lo primero que deberemos hacer será definir una subred, VLAN para nuestros proveedores y que el Gateway, por ejemplo, sea el Fortigate.

En ella deberemos habilitar por un lado la detección de Dispositivos y el control de acceso basado en Forticlient. Ni qué decir que desde la red de proveedores no puede existir la posibilidad de acceso a los Firewalls….

El siguiente paso será definir qué Aplicaciones vamos a dejar permitir ejecutar a los proveedores en sus equipos. Para ello deberemos ir a “Security Profiles – Application Control” y definir uno con los parámetros que creamos convenientes. Os dejo dos entradas que os pueden orientar en las que hablaba de esto mismo:

Con ello listo, iremos a “Security Profiles – FortiClient Profiles” y crearemos el que a posteriori será el que se aplicará sobre los endpoints.

Allí deberemos especificar algunos parámetros como: la red sobre la que se aplicará, en nuestro caso la 192.168.254.0/24, “LAB_RED PROVEEDORES”; acción en caso de no cumplimiento, “Block – Warning – Auto-update”; el tipo de dispositivo, “ALL”; Versión mínima del software FortiClient, “5.4.1”; comportamiento del motor Antivirus, “Realtime Protection, Up-to-date signatures”; y por último el perfil de Firewall de Aplicación, el que hemos definido anteriormente, “LAB_APP-CONTROL_S7”.

Aquí quizás puede llevarnos a confusión el concepto de Control de Aplicación, pero que en este caso se aplica de dos maneras distintas. Una cosa es el Control de Aplicación que se  ejecuta sobre las aplicaciones del PC y que lo regula en el endpoint FortiClient; y otro distinto el que podemos aplicar sobre el tráfico de red en cada una de las reglas configuradas y definidas dentro de la columna “Security Profiles”.

Si en estos instantes alguien quisiera acceder a algún recursos de la red no podría ya que no cumple con los requisitos. Si por ejemplo abriésemos un navegador y pretenderíamos navegar aparecería el siguiente mensaje:

La instalación del endpoint es sencilla. Lo único que tendremos que tener en cuenta es realizar una instalación completa, en lugar de sólo la funcionalidad de VPN. Una vez finalizada se comenzará a descargar los distintos componentes.

Si abrimos el cliente veremos una pantalla con los distintos apartados del endpoint.  Si nos fijamos a “Firewall de Aplicación” veremos los “Overrides” autorizados relacionados con el protocolo S7.

Hasta aquí hemos visto la manera en la que configuramos, de forma resumida, todo lo necesario para comenzar a ejercer el control del que hablábamos. Con todo listo, será en la próxima entrada, cuando comprobemos los resultados y por tanto su eficiencia.

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

Edorta

 

Robots, pero no .txt…

Anuncios

Cuando nos referimos a los entornos industriales generalmente lo hacemos con la vista puesta en PLCs, HMIs, sistemas SCADA, sensores, actuadores, etc. Si embargo, hay otros que también están presentes y que a veces pasan desapercibidos. Los robots.

Éstos son capaces no sólo de llevar a cabo tareas repetitivas de forma rápida y precisa , sino reemplazar la labor de una persona, tanto por capacidad como por ahorro en tiempo y dinero. Un tema este que desde hace tiempo está siendo objeto de debates ya que muchos puestos de trabajo podrían peligrar si no se regulariza su uso a corto plazo. Esto cobra más fuerza si tenemos en cuenta los avances tecnológicos que han derivado en lo que conocemos como «Robótica Colaborativa». Brazos robotizados capaces, no sólo de imitar la labor de operadores tradicionales, sino la de trabajar junto a ellos garantizándose, por supuesto, medidas de seguridad necesarias para prevenir cualquier daño.

Este vídeo habla por si mismo:

Sin embargo en el día de hoy no me voy a centrar en este tipo de robots sino en otros de mayor tamaño presentes en sectores como la industria manufacturera, logística o más concretamente, la automoción. De un tiempo a esta parte se viene hablando que, al igual que otros dispositivos, los robots pueden ser blanco de ataques con unas u otras consecuencias dependiendo de las vulnerabilidades y debilidades que puedan presentar.

En el día de hoy haremos un repaso por sus componentes principales para entender mejor qué partes podrían verse afectadas llegado el caso.

Como decía, de forma genérica, un robot de estas características está compuesto por:

1.- Brazo robótico

Es el componente más visible. A él le asociamos la palabra «Robot» y al que podríamos definir como un manipulador multipropósito reprogramable capaz de mover piezas, materiales y herramientas en diversas trayectorias. Controlado automáticamente, podrá estar compuesto por 3 o más ejes que permiten llevar a cabo los distintos movimientos con el fin de realizar una o varias tareas concretas. En sus extremos podrán disponer de herramientas intercambiables como pinzas, agarres, sensores o cualquier otro tipo según necesidades.

2.- Controlador:

Es dispositivo que gobierna al robot. En él podemos identificar dos subsistemas denominados «módulos» que se encargarán de actuar sobre distintas áreas del mismo. Dependiendo de fabricantes y modelos, esto puede cambiar en cuanto a formatos o arquitecturas, pero en general podremos encontrarnos con:

  • Módulos de Potencia

Encargado de regular la alimentación eléctrica que necesitan tanto el resto de módulos como los servos que mueven los ejes y hacen desplazar al robot por las trayectorias y puntos definidos. Contará con un interruptor principal y otros accionamientos, que estarán en comunicación con los sistemas de seguridad y maniobra para, en caso necesario, suspender el suministro.

  • Módulo de Control

Contará con el computador principal que gobernará el sistema. En él podremos localizar distintos elementos como el mecanismo de paro de emergencia, selector de modo de operación (Manual/Automático), conexiones con otros módulos, leds de estado, etc. También será capaz de gestionar las seguridad en lo que a «Safety» se refiere, recibiendo las señales de sensores o mecanismos que permitirá el paro del robot en caso de error o accidente. Dispondrá de interfaces de entrada y salida de tal manera que los técnicos o ingenieros puedan llevar a cabo la carga de la configuración y parametrización así como otros elementos tipo PLCs, HMIs, vinculados a procesos.

3.- Consola Hombre-Máquina:

Es una unidad conectada al módulo de control con el que se podrá operar el robot. Se trata de pequeñas consolas dotadas con una pantalla, teclado, joystick y accionador de emergencia con el fin de manipular y ajustar parámetros en el brazo robótico de forma manual. Por esta razón, y con el fin de evitar accidentes contra personas,  cuentan con sistemas que obligan, por ejemplo,  a tener presionados simultáneamente dos pulsadores para poder manipularlo. Están dotados de sistemas operativos embebidos, como Windows CE .NET en el caso del fabricante  ABB para su componente Flexpendant. Esto permite la programación «online» a diferencia como veremos más adelante de otra «offline».

4.- Programación:

Como resulta evidente al robot hay que parametrizarlo y configurarlo para que realice los movimientos y tareas para los que ha sido pensado. Si bien desde la consola manual pueden llevarse a cabo ciertas tareas, a ésta se le reservan más a la precisión o corrección. El resto de labores se editarán en software destinado a tal efecto como puede ser KUKA.WorkVisual del fabricante KUKA, o RobotStudio en ABB.

Desde este software se llevará a cabo lo relativo a la parametrización de los programas que se ejecuten en el robot, movimientos, coordenadas, estados, etc. para luego desde ahí volcarlo al Controlador por alguna de sus interfaces. Estas tareas podrán hacerse, como hemos visto, tanto de forma «online» y «offline» para que cada programador u operador emplee según necesidades.

Sin embargo, los robots no están solos. Éstos se integran con otros dispositivos como son los autómatas. Los casos de uso a los que me he enfrentado hasta la fecha, han sido en los que un PLC ve a un robot como un «esclavo». Es decir, el autómata ordenará al controlador del robot la ejecución de tal o cual programa según sea necesario. Finalizado, retroinformará para proseguir con las tareas tanto de forma autónoma como de forma conjunta con otros. Obviamente esto no es sencillo ya que entran en juego multitud de señales y medidas, como pueden ser las enviadas por los sensores; detectores de posición; finalización de trabajo antes de comenzar movimientos en otros robots; petición de acceso a una determinada área; respetar tiempos de espera, etc. Pero sobre todo, la implementación de medidas «Safety» y evitar así los temidos accidentes. Según sea el modelo de autómata empleado, éstos podrán incluir estas funcionalidades en sus CPUs o sino depender de otros dedicados a tal efecto. Aparte de estos mecanismos como pulsadores de emergencia, sensórica, barreras de protección, o perímetros restringidos, el propio robot permite que en modo de operación manual puedan establecerse límites y supervisión  en cuanto a velocidad y movimientos. Finalmente para que todo esta interacción sea posible es necesario el uso de buses de campo que permitan la comunicación entre los distintos elementos.

Con la entrada de hoy se pretende arrojar un poco más de información sobre qué elementos componen estos sistemas y la manera en que se comportan. Especialmente cuando no hace demasiado tiempo la firma TrendMicro ha publicado un informe sobre los posibles ataques a los que pueden estar expuestos los robots y las consecuencias que pueden tener, tanto para el proceso como a las personas.

En cualquier caso, espero que en la entrada del día de hoy pueda servir para entender  de forma sencilla algo más sobre estos equipos.

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

Edorta

Control de Aplicación en entornos ICS/SCADA, Parte II

Anuncios

Hoy vamos a continuar con lo que adelantábamos en la entrada “Control de Aplicación en entornos ICS/SCADA, Parte I” poniendo algunos ejemplos sobre cómo esta funcionalidad en los NGFW puede ayudar a detectar, o prevenir, cierto tipo de actividades.

En ella proponía el siguiente entorno:

En la red 192.168.0.0/24 tendremos un PLC (en este caso un Siemens S7-300 emulado con la aplicación Snap7) con IP 192.168.0.65/24 accesible desde una Workstation, 192.168.0.100/24, destinada a labores propias del entorno. Por otro lado, la red 10.10.10.0/24 donde existe una DMZ, y en ella, un servidor SCADA con IP 10.10.10.101/24. Por último, la Red de Oficinas bajo un direccionamiento 192.168.1.0/24, donde a priori no debiera haber ningún tipo de software de Control.

Como NGFW he empleado un Fortinet FortiWifi 60D, el cual tiene instalada una versión FortiOS 5.4.2. Cabe recordar que en esta versión hay que habilitar las firmas “Industrial” ya que por defecto no vienen activadas.

En “Firewall de Segmentación OT-OT” hemos creado el siguiente perfil «Control de Aplicación» para las comunicaciones entre el servidor SCADA  y la red de Control. Como se puede ver, se bloquearán todas las aplicaciones incluidas dentro de la categoría ”Industrial”. Sin embargo, se hará uso de “Application Overrides” para permitir sólo aquellos protocolos y operaciones propias de nuestras instalaciones. Dicho sea de paso, han tenido que ser identificadas con anterioridad. No obstante, y aunque no es necesario indicarlo explícitamente, se impedirá la parada de PLC, algo reservado sólo a nivel local, no por red.

Fortinet define varios controles sobre el tráfico. Estos son Allow, Monitor, Block y Quarantine. Para conocer las diferencias os dejo el enlace en la página Web del fabricante, pincha aquí.

Ahora bien, en “Firewall  Separación IT-OT”, no habrá excepciones de ningún tipo, absolutamente todo se bloquea. Se entiende que no debe existir ningún software que necesite acceder a la red de control y mucho menos que realice operaciones de lectura o escritura sobre variables, bloques de memoria, funciones, etc.

Respecto a las reglas de Firewall, para este laboratorio he sido bastante “laxo”. Puesto que la intención es destacar el uso de esta funcionalidad, he permitido las comunicaciones entre todas las redes y puertos, siendo el “Control de Aplicación” el único que autoriza o deniega el paso de paquetes. Como todos sabemos, no debiera ser así en un entorno real.

Como hemos dicho anteriormente una de las tareas que no pueden llevarse a cabo desde el servidor es ejecutar la orden de paro de los PLCs. Si lo haríamos, esto sería lo que ocurriría.

Como vemos se genera un log donde se refleja la aplicación identificada y la acción tomada.

Pero siguiendo con el esquema, veremos ahora lo que sucede si alguien desde el entorno de oficinas quisiera obtener alguna información. Los ejemplos siguientes se han hecho con una distribución Kali Linux y aplicaciones Plcscan y script S7-info para Nmap. 

El ambas, el resultado sería el siguiente, siendo el de Plcscan el realizado a las 19:23:34 mientas que Nmap a las 19:25:12 en adelante.

Así pues, el resultado por parte del supuesto atacante quedaría:

Como vemos los escaneos no arrojan ninguna información.  En cambio, si aplicásemos el mismo sensor de “Application Control” para las comunicaciones entre el servidor SCADA y el PLC el resultado sería bien distinto:

Como podemos ver, aquí sí se muestra información ya que las las operaciones que realizan ambas aplicaciones concuerdan con los protocolos y operaciones permitidas, al igual que el servidor SCADA. De esta manera, se podrían extraer datos sobre los equipos para luego seguir con fases más avanzadas o dirigir, somo es lógico, el ataque sobre el fabricante en cuestión.

El “Control de Aplicaciones” puede ser de gran utilidad, sino necesario. Obviamente su configuración y parametrización requiere de una labor que puede resultar costosa en tiempo ya que hay que definir claramente el tráfico que atraviesa por nuestra red. No sólo en lo que se refiere a IPs y puertos, sino también a aquellas aplicaciones que generan el tráfico de Operación, Control y Monitorización. No obstante, no debiera ser la única. Para ser más completos, además habría de acompañarlo de otras como IPS y Antivirus, funcionalidades que ya disponemos. Algo que también resultaría interesante según entornos y necesidades es la consolidación de logs en servidores, tanto para su almacenamiento (Syslog Server) como correlación (SIEM).

Ya por último un factor que no podemos olvidar es que todas estas medidas pueden introducir una latencia en las comunicaciones debido a la carga computacional que requiere el análisis en tiempo real. Según fabricantes, dispositivos y modelos puede variar con lo que dependiendo de nuestra arquitectura, comunicaciones (TCP/IP, RT o IRT), sistemas, etc. es algo que debemos tener presente en cualquiera de los casos.

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

Edorta.