Archivo de la categoría: Bastionado

Controlando nuestros Proveedores, Parte I.

Posted on por
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

 

¿Por qué es necesario NGFW en entornos ICS/SCADA?

Posted on por
8
Anuncios

Como he hablado en otras ocasiones el primer paso para securizar un entorno de control y automatización es separarlo del de IT mediante un dispositivo de seguridad perimetral. Luego, ya dentro del propio entorno OT, es necesario segmentar la misma en áreas más pequeñas con el fin de que si se produce un anomalía o incidente, éste no se propague al resto y ponga en peligro la disponibilidad total, o parcial, de las instalaciones.

El dispositivo estrella para este tipo de tareas es el firewall. Los cortafuegos tradicionales (L2, L3, L4) han quedado ineficaces ante el creciente y diversificado aumento de amenazas, vulnerabilidades y vectores de ataque. Surgen entonces los NGFW (Next Generation Firewall) que además de las características típicas incorporan otras como motores Antivirus, IDS/IPS, Control de Aplicación, Filtrado Web y DPI (Deep Packet Inspection).

A continuación, indico algunos enlaces de artículos relacionados a este respecto.

  1. Defensa en Profundidad, breve repaso.
  2. Defensa en profundidad OT
  3. Separar y Segmentar, primeros pasos para reducir riesgos…
  4. Virtual Patching en funcionamiento (Parte I)
  5. Virtual Patching en funcionamiento (Parte II)
  6. Virtual Patching en funcionamiento (Parte III)

En la entrada de hoy vamos a ver la necesidad de este tipo de dispositivos NGFW en detrimento de los tradicionales. Para ello me voy a basar en el software utilizado en la entrada “Simulador de protocolo ModBus”, creado el siguiente entorno.

La idea es representar dos supuestos entornos; uno IT (de Oficinas) y uno OT (de automatización). En este último he simulado un equipo cliente ModBus el cual será el “objetivo” de las acciones a realizar. Por otro lado, en parte de IT/OT, situaré el posible “atacante” (Kali Linux) junto con un equipo legítimo (Maestro Modbus). He decidido especificar IT/OT para cubrir dos supuestos. Cuando me refiero a “IT”, represento el concepto de “Separación” y con “OT” el de “Segmentación”. De esta manera cubrimos las posibles acciones llevadas a cabo desde la propia red de Control como desde otra ajena a éstas como puede ser la de «Oficinas» o Internet si consideramos equipos accesibles remotamente. En cualquiera de los casos, ambos están separados por un equipo Fortinet FortiWifi60D con una versión de FortiOS 5.2.8. Habrá que piense que esta versión ya tiene un tiempo y que las hay más nuevas. Tiene razón, pero hay una explicación. Las actualizaciones en equipos industriales, se producen en intervalos de tiempo superiores si lo comparamos contra entornos IT con lo que es muy común encontrarse no con las últimas. Además de esto, no debemos olvidar el uso de equipamiento acorde a la actividad que vamos a realizar. Lo correcto sería emplear, por ejemplo uno de la serie Fortinet Fortigate Rugged.

Así pues, el esclavo queda configurado como sigue:

Por otro lado, el firewall permite el tráfico según la siguiente regla.

Como se puede apreciar sólo se deja pasar el protocolo “ModBus” (TCP-502), entre la red 172.30.123.0/24 y el destino “Esclavo_MODBUS” (172.20.123.200). Lo suyo sería dejar pasar sólo aquellos equipos que lo necesiten. Aparte de ser un entorno de laboratorio, en la vida real, es probable que alguien se pueda configurar manualmente la IP de un equipo legítimo, la infección de uno de ellos o las conexiones vengan de redes configuradas con DHCP con lo que se abra a todo su rango. No es descabellado. Lo dicho, cobra especial importancia la correcta configuración de las reglas del firewall.

Según lo anterior el resultado de una conexión legítima al esclavo sería la siguiente:Y el Master recogería estos resultados:

Considerando las características de ModBus que no posee ninguna medida de seguridad nativa, un atacante podría con alguna herramienta poder leer o escribir datos. Para este caso he utilizado mbtget, la cual podéis encontrar aquí.

Así pues leeremos los siguientes registros:

O escribir, por ejemplo, “12345” en la primera entrada.

Y… oh sorpresa! el usuario legítimo lo vería….

Con ello vemos que los Firewall tradicionales no son del todo efectivos para este tipo de entornos y protocolos. Vamos a proceder a configurar el “Perfil de Seguridad”, término que emplea Fortinet para definir las características de seguridad adicionales y que son definidos en cada una de las reglas. Estos perfiles pueden ser ajustados según necesidades. En el siguiente ejemplo optamos por activar en “Modo Monitor” de la característica “IPS” con lo que operaría como un IDS (Intrusion Detection System) en lugar de un IPS (Intrusion Prevention System) :

Aún podríamos llevar a cabo una escritura con el valor “55555” en el esclavo desde el equipo atacante, ya que sólo detectaríamos tal acción:

Generaríamos el siguiente log en el Firewall.

Y también, hacer una lectura:

Como vemos en los logs del Firewall, en la columna “Action” vemos como figura “detected”. El tráfico se ha detectado pero no se ha cortado.

Sin embargo, si cambiamos el perfil IPS y esta vez lo reconfiguramos como “Block”

El atacante se encontrará que no podrá llevar a cabo la escritura. Por ejemplo modificando el primer campo con el valor “8888”. Se produce un “timeout”.

Y el correspondiente log en el Firewall:

Aquí ya vemos cómo en la columna “Action” ya consta como “Dropped”.

Idem con la lectura:

Mientras tanto el cliente legítimo sigue funcionando con total normalidad.

En el día de hoy hemos comprobado la funcionalidad IDS/IPS para este equipo del fabricante Fortinet, sin embargo, no es la única que debemos aplicar. Hay que apoyarse en otras como Antivirus, Control de Aplicación y filtrado Web. Esto debe mantenerse bajo cualquier circunstancia, también cuando estos firewalls se empleen para establecer VPN y acceder a éstos de forma remota.

Adicionalmente, conviene que los logs generados, se consoliden en un servidor para poder ser almacenados y analizados bien para llevar a cabo una monitorización del estado de la seguridad por medio de un SIEM, como para realizar labores de forénsica en caso de ser necesario. Fortinet cuenta con algunos productos específicos como FortiAnalyzer o FortiManager, que aunque sea este último una herramienta de gestión incorpora algunas funcionalidades de gestión de logs. Este tipo de soluciones deben de contemplarse desde el inicio de los proyectos. Hemos de tener una visión más allá del despliegue inicial ya que todo lo que instalemos luego hay que administrarlo por lo que a la hora de elegir tal o cual producto, esto también ha de considerarse.

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

Control de USBs en entornos OT

Posted on por
Anuncios

Una de las medidas que debe estar presente cara al bastionado de nuestros sistemas, como no podía ser de otra manera, es el control de dispositivos USB. Si bien, en general, su uso hay que regularlo, en entornos industriales o Infraestructuras Críticas los riesgos son mayores. Como ya hemos comentado en otras ocasiones, los ciclos de vida, de equipos PC con funciones tipo  HMI, Workstations de Ingeniería, etc. son mayores. Esto les obliga a mantener en la mayoría de los casos Sistemas Operativos fuera de soporte, y exentos de actualizaciones. Además, dependiendo del sector y actividad, el software que interactúa con los distintos elementos de las instalaciones puede haber sido hecho “a medida” del cliente o producto, y cuyo desarrollador garantiza su uso sólo bajo ese entorno, y no en caso de instalar parches o actualizaciones. Que si ya lo del parcheo es difícil de implementar si además tenemos esta condición, pues ya ni os cuento.

En cualquiera de los casos, sin poder instalar parches y sin soporte por parte del fabricante el riesgo al que están expuestos nuestros sistemas es considerablemente alto.

Por tanto, para salvar este escoyo, las alternativas son principalmente son dos. O llevamos a cabo la actualización del sistema a uno superior con la correspondiente inversión de tiempo y dinero; o, utilizamos una solución de tipo “Endpoint” que aparte de limitar su uso nos proporcione otras funcionalidades.

Además, la proliferación de dispositivos que emplean el conector USB ha ido en aumento. Ya no es el clásico “pen drive” que puede contener un malware o un software portable. Ya desde hace tiempo tenemos otros muchos como Smartphones, reproductores de música, “USBHacks”, son desde los cuales podemos lanzar todo tipo de tareas.

Dentro de los entornos de automatización y control el ejemplo más archiconocido lo tenemos con Stuxnet.

 

Luego en el año 2013 saltaba la noticia que, “al parecer”, se quiso espiar a los miembros de la cumbre del G20 por medio de la entrega gratuita de memorias y cables USB para la carga de dispositivos móviles.

Y para terminar el malware que afectó a una Central Nuclear alemana y de cómo había infectado algunos equipos.

Tomando como ejemplo el equipo con Windows 7 Professional de las entradas:

Whitelisting en SCI (Parte I)

Whitelisting en SCI (Parte II)

Puesto que está aplicada una política de “Whitelisting”, si conectásemos una memoria USB con un software y lo quisiéramos ejecutar, podríamos ver el contenido pero no ejecutar nada ya que dicha política nos lo impide. Esto es, la memoria USB es detectada y se puede acceder pero como los ejecutables en él almacenados no están autorizados en la Lista Blanca, no se pueden utilizar. En cambio si hubiéramos querido abrir un fichero con un software que sí está dado de alta en ellas, podríamos verlo.

Sin embargo sin esta protección, el ejecutable hubiera sido ejecutado. Por ello resulta necesario llevar una estrategia de control y restricción de su uso. Ahora bien, ¿cómo hacerlo? En este caso he vuelto a utilizar Symantec Embedded Security: Critical System Protection

Deberemos dirigirnos a la política de “Prevention” ya que vamos a limitar una operación. Dentro  de “Advanced Policy Settings” seleccionaremos “Global Policy options”.

Dentro de ella en “General Settings” buscaremos “Block External Storage Devices” y marcaremos la casilla. Al mismo tiempo podremos seleccionar 3 variantes que pudieran ser de utilidad según entornos.

Sin embargo una vez activado este control ya no podríamos tener acceso al mismo.

Y sobre todo, el registro en consola para su consulta y seguimiento:

Como hemos visto en las capturas anteriores, este “bloqueo” puede ser configurable en lo que a lectura y escritura se refiere. Aquí hemos visto la manera más drástica, a partir de aquí ya podremos ir autorizando excepciones en caso de ser necesario.

Esta funcionalidad es especialmente interesante no sólo en equipos que controlen instalaciones sino en también en departamentos de soporte o mantenimiento. En ellos suelen existir equipos portátiles (ver aquí y aquí) para configurar, parametrizar o diagnosticar PLCs, Robots, etc. por medio del software correspondiente. A menudo es necesario intercambiar algún tipo de información por medio de estos dispositivos ya que puede no disponerse, o no estar autorizado, el acceso a ciertos recursos de red. Para ello podremos habilitar el bloqueo y llegado el momento deshabilitarlo. No obstante es conveniente disponer de algunos “pen drive” para uso específico y así gestionar esta necesidad de forma controlada.

Lo dicho, cuidado con los dichosos USB que aunque necesario también son el origen de muchos disgustos…

Un saludo!