Controlando nuestros Proveedores, Parte II.

Hola de nuevo. Siguiendo con la entrada anterior “Controlando nuestros Proveedores, Parte I” en el día de hoy vamos a ver la manera en cómo trabaja el binomio FortiGate + FortiClient.

Si bien la protección es en tiempo real, al hacer un análisis antivirus vemos la forma en la que detecta malware según la base de firmas del fabricante. Para ver su funcionamiento he dejado en el escritorio un fichero de EICAR.

Escritorio Proveedor_01

No obstante, para que no fuese un típico ejemplo, también tenía una carpeta con el software incluido en el repositorio Pengowin y que desde aquí, dicho sea de paso, recomiendo dicho proyecto.

Aviso de virus_01

Viendo los logs:

Logs de Virus_01

en total fueron 55 detecciones:

Registro de Virus_02

Para terminar la desinfección es posible que se solicite un reinicio del sistema.

Captura_02_Tras Finalizar AV

Como se puede ver, también en el escritorio tenía el simulador del protocolo S7 de SIEMENS, Snap7 del que hablaba en la entrada “Snap7 suite de PLCs y comunicaciones Siemens”. Al ejecutar el cliente para hacer una lectura del supuesto PLC, esto es “clientdemo.exe”, como el protocolo “ICMP” y “S7 Protocol” no están permitidos vemos su bloqueo, al igual que otros relacionados con el sistema operativo.

Aplicaciones Bloqueadas_02

Si actualizásemos el perfil del control de aplicación correspondiente, ya podríamos acceder al mismo, en la IP 192.168.0.1.

Cliente SNAP7_01

También disponemos de un “Filtro Web”, funcionalidad que no he utilizado pero también útil si necesitamos tener acceso a una interfaz Web. ¡Ojo! Hablo de equipos locales, no accesos a Internet.

Como decía en el post anterior es compatible con los “Security Profiles” configurables en cada una de las reglas del Firewall, con lo que a nivel de red también podríamos ejercer un control adicional. Configurar los perfiles de qué se puede ejecutar, o no, en un PC puede llegar a ser complejo y laborioso en función de cada proveedor. Con lo que llegado el momento, podríamos llegar a ser más permisivos en este sentido en cuanto a consentir toda la categoría “Industrial” o “Servicios de RED” y denegar “Botnet”, “Game”, “P2P”, etc. y luego apoyarnos en reglas y “Security Profiles” como indicaba en las entradas:

También destacar la visibilidad que podemos tener desde el Fortigate a la hora de monitorizar los FortiClients conectados y de si cumplen, o no, con las políticas establecidas. Para ello deberemos ir a “Monitor – FortiClient Monitor”.

Forticlient Monitor_01

Ya por último comentar que en este caso hemos hecho uso de un Firewall Fortigate para la gestión de los endpoint. Sin embargo, Fortinet dispone de un producto específico para la gestión de este software denominada FortiClientEMS (Enterprise Management Server) con lo que podremos realizar un control centralizado y una gestión más pormenorizada de todos ellos.  Aquí os dejo un video presentación y enlaces con información al respecto.

Integración de Fortigate y FortiClientEMS.

Como hemos visto nuestros proveedores pueden ser no sólo un punto de entrada sino también el origen de un problema mucho mayor. Los habrá que sean estrictos con el uso de sus equipos sin embargo, esto no es razón para pensar que nada malo pueda suceder. Los entornos industriales no son para nada similares a los de Oficina o IT tradicionales. Los ciclos de vida son mayores con lo que la posibilidad de encontrarnos con Sistemas Operativos y Hardware viejo u obsoleto, es bastante común. Con ello, falta de soporte del fabricante y vulnerabilidades incapaces de corregir, y aun existiendo parches, según actividad de la compañía, desarrollos de software propios, o cierre, hacen que muchas veces sea inviable. A esto hay que sumar la existencia de empresas proveedoras de servicios que necesitan conectarse a nuestras instalaciones para llevar a cabo las tareas para las cuales han sido contratadas, y que no hace posible desplegar su software sobre otro equipo de la organización en el que sí tenemos control y conocimiento de su estado.

Con esta entrega hemos visto cómo con los NGFW FortiGate y endpoint FortiClient podemos llevar a cabo un control y permitir qué equipos de terceros puedan conectarse a nuestra red. De esta manera reducimos los riesgos  de que algo, o alguien, pueda comprometer la disponibilidad de nuestras instalaciones. No pretende ser un manual, ni mucho menos, sino una visión sobre de qué manera podemos ejercer dicho control y supervisión.

Obviamente existen en el mercado otros fabricantes, con otras soluciones que de igual manera puedan satisfacer nuestras necesidades, pero resulta interesante ver esta en concreto por su integración junto con el hardware de red. Como hemos visto, desde hace relativamente poco tiempo, los fabricantes de equipos de control y automatización tipo SIEMENS, Phoenix Contact, entre otros, incluyen ya características relacionadas con la Ciberseguridad, cosa con los equipos más antiguos o bien, o no disponen o son débiles. Por tanto, delegar en la electrónica de red y seguridad perimetral aspectos de la seguridad sigue siendo un hecho que durará por mucho tiempo ya que la renovación de PLCs, Robots, o cualquier otro por motivos puramente de seguridad, no es una razón de peso o prioridad.

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

Edorta

 

Controlando nuestros Proveedores, Parte I.

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?

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.

separacion_01

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.

arquitectura

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:

esclavo_01

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

config_forti_01

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:log_forti_01Y el Master recogería estos resultados:

master_01

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:

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

kali_02

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

master_02

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) :

config_forti_02

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:

kali_03

Generaríamos el siguiente log en el Firewall.

kali_07

Y también, hacer una lectura:

kali_04

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.

log_forti_04

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

ips_02

config_forti_03

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”.

kali_05

Y el correspondiente log en el Firewall:

log_forti_05

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

Idem con la lectura:

kali_06

log_forti_06

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

master_03

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 SCI

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.

 

Stuxnet_01

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.

SCSP_19

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”.

SCSP_17

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.

SCSP_18

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

SCSP_20

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

SCSP_21

SCSP_22

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!

Whitelisting en SCI (Parte II)

Siguiendo con la entrada “Whitelisting en SCI (Parte I)”, comencemos con los ejemplos.

El equipo con Windows XP tiene una versión de Adobe Reader vulnerable y queremos impedir su ejecución. Para ello deberemos dar de alta la aplicación en la política e incorporarla en la “Sandbox” de denegación. Este proceso lo podemos hacer de dos maneras. El servidor puede recolectar las aplicaciones instaladas en los equipos y a partir de ahí seleccionarla y configurarla. En la imagen siguiente podemos ver aplicaciones (SIMATIC, Siemens Step7, etc.) instaladas sólo en el equipo con Windows 7 sin embargo estamos configurando la política del Windows XP (Prueba_XP_sym……).

SCSP_10

La segunda, es hacerlo de forma manual indicando el ejecutable concreto, pudiendo también indicarla a través de un “Explorador” seleccionando la IP del equipo y navegar en su árbol de archivos, c:\Program Files\ …..

SCSP_11

En cualquiera de los casos, ya con la aplicación denegada:

SCSP_12

Tendríamos el siguiente mensaje:

SCSP_13

Luego tendríamos el correspondiente log en el servidor de gestión:

SCSP_14

Ahora en el Windows 7, vamos a aplicar una política con estrategia “Whitelisting” la más restrictiva de todas, o decimos que es lo que se puede ejecutar o no hay manera. Por ejemplo hemos querido abrir Google Chrome y…

SCSP_15

O incluso al ir a borrar el ejecutable “agent”, no ha sido posible…

SCSP_16

Al igual que deshabilitamos los servicios, bloqueamos puertos, controlamos permisos de usuarios, y llevamos a cabo otras tantas medidas, limitar el uso de las aplicaciones a las estrictamente necesarias es otro paso que debemos dar. Al igual que los Sistemas Operativos, éstas también poseen vulnerabilidades que deben ser corregidas bien mediante la aplicación de parches o su actualización, y por tanto es necesario controlarlas.

Obviamente el primer paso es no instalar nada que no se vaya a utilizar, pero una vez justificado su uso e instalada deberemos controlarlas.

Las distintas herramientas nos ofrecen otras opciones que amplían el bastionado, pero que no se han contemplado en el presente artículo.

Otro de los aspectos que debemos mirar de cerca es la consulta de los logs que pudieran generarse. No nos sirve de nada ejercer un control férreo si luego no realizamos un seguimiento. Las amenazas evolucionan, y pueden afectar a las aplicaciones que legítimamente deben utilizarse.

Lo que sí deberemos tener presente, muy pero que muy presente, es a la hora de desplegar esta solución, que los equipos no estén infectados. Con estas herramientas no sólo controlamos las aplicaciones, sino también los procesos del sistema. Si un malware ha infectado un software o el propio sistema operativo comprometiendo un proceso y lo incorporamos a nuestra “Lista Blanca”, la herramienta no nos sirve de nada. El “bicho” seguirá ejecutándose libremente. Mucho ojo con esto.

En resumen con esta entrada de hoy hemos visto (conceptualmente hablando) la manera de evitar la ejecución de aplicaciones que por una razón u otra no queremos que se utilicen en alguno de nuestros equipos.

A continuación os dejo el enlace del Centro de Ayuda de la versión 6.5.1 donde podréis encontrar más información al respecto.

Un saludo nos vemos en la próxima!

Whitelisting en SCI (Parte I)

En diciembre de 2015 el ICS-CERT publicaba un documento sobre las 7 estrategias que pueden ser implementadas para contrarrestar las debilidades más comunes en los sistemas de control industrial. El resumen y enlace lo podéis encontrar aquí.

Hoy vamos a hablar sobre la primera de ellas, “Application Whitelisting (AWL), o “Listas Blancas de Aplicaciones”. Veamos de qué se trata.

AWL ofrece un enfoque distinto respecto a la seguridad de un host más allá de un HIDS/HIPS, antivirus u otras tecnologías basadas en “Lista Negras”, o “Blacklists”. Una solución este tipo, compara el objeto monitorizado contra una lista de lo que es conocido como “malo”, no permitiéndose ejecutar. Esto presenta dos problemas; uno, que la “Lista Negra” debe ser actualizada periódicamente, lo cual conlleva una labor de administración importante; y la segunda, que no hay forma de detectar ataques “zero-days”. O bien, no estén disponibles aún las actualizaciones de las que sí se conozcan.

Por el contrario una “Lista Blanca” crea una lista de lo que es conocido como “bueno” y le aplica un criterio simple: si no está en la lista, se bloquea.

Las soluciones basadas en “Listas Blancas” emplean esta lógica sobre aplicaciones y ficheros de un equipo tipo PC, Thin Client o cualquier otro dotado con un Sistema Operativo compatible. Por ejemplo, si un malware consigue vencer el perímetro de seguridad, y encontrar la forma de llegar a un equipo éste evitará su ejecución puesto que no se encuentra en su lista blanca. No lo “mata” pero lo “frena”. También puede ser empleado para prevenir la instalación de software autorizado en el sistema.

Los distintos antivirus dependen de continuas actualizaciones de sus firmas. A medida que éstas aumentan, y con toda certeza, la demanda de recursos también. Esto sobre hardware relativamente nuevo puede no llegar a ser un problema pero en entornos industriales donde el ciclo de vida es mucho mayor, puede afectar al rendimiento del equipo. Eso hablando de Sistemas Operativos que aún tienen soporte y del que existan productos comerciales compatibles.

Para el caso de estos Sistemas Operativos “legacy”, AWL es una buena solución ya que al no disponer de parches o actualizaciones, si un malware quisiera aprovechar una de ellas, y al no estar definido en la lista, no podría ejecutarse o realizar cambios en el sistema. Aparte, aunque las hubiera, tampoco sería necesario (aunque si aconsejable), su instalación (previa descarga, testeo y evaluación, claro) ya que sólo sería necesario actualizar las AWL cuando lo hagan las aplicaciones.

A diferencia de los de los antivirus los cuales pueden registrar un aumento en el uso de CPU o memoria en el momento de lleva a cabo el análisis, con AWL puede definirse un comportamiento base después de la instalación puesto que éste se mantiene relativamente estable durante su operación.

AWL se ubica dentro de las estrategias de Hardening de sistemas, como por ejemplo HMI, estaciones de trabajo u otro tipo de equipos involucrados en las áreas de automatización. No obstante, algunos fabricantes de este tipo de soluciones han incorporado más funcionalidades a las propias del control de aplicaciones, como pueden ser el control de dispositivos USB (fuente de infección y propagación), reporting con mayor y menor detalle de eventos en el sistema, creación dinámica de las Listas, Sandboxing, etc.

En el siguiente enlace podréis encontrar un informe sobre algunos aspectos adicionales sobre “Whitelisting” elaborado por el ICS-CERT. Enlace.

La administración puede efectuarse en modo Stand-Alone, esto es actuando sobre el agente o bien de forma centralizada desde un servidor.

Para esta entrada he elegido Symantec Embedded Security: Critical System Protection una solución que va orientada en esta línea.

En mi caso he desplegado el siguiente entorno virtual simulando distintos entornos:

Escenario 01

El esquema lo he “decorado” con supuestos equipos conectado, aunque lo relevante aquí son los PC que quedan definidos de la siguiente manera:

Windows 2012 R2: 192.168.10.254/24

Windows XP: 192.168.10.10/24

Windows 7: 192.168.10.20/24

Windows 2000: 192.168.10.30/24

La solución cuenta con 3 componentes principales; el software del servidor de gestión; el cliente pesado (consola), para conectarse al servidor de gestión; y el agente que se instala en los equipos finales. Para el ejemplo he utilizado la versión 6.5.1 para todos los componentes, excepto para el Windows 2000 que ha sido la 5.2.4 por temas de compatibilidad. Además de esto, conviene resaltar algunas consideraciones más:

El servidor para  su funcionamiento requiere de una base de datos. Dependiendo del número de equipos podremos que ésta resida en el mismo o en uno dedicado. Para esta ocasión he seleccionado la “Express”, no recomendable para un entorno de producción.

SCSP_01

SCSP_01

Los puertos empleados, importante si estamos detrás de un Firewall, son:

SCSP_02

En lo referente a los agentes comentar el error que surge en sistemas operativos Windows 7 Professional ya que éstos requieren de un controlador firmado. En mi caso he aplicado los parches correspondientes y no ha habido más problemas. Más información aqui.

SCSP_23

La instalación de los “Agentes” no es compleja. A lo largo del proceso habrá que definir el tipo de administración; funcionalidad IDS, IPS (o ambas); IP del servidor; certificado para el cifrado de las comunicaciones.

SCSP_05

SCSP_06

A partir de aquí a través del cliente pesado nos logueamos en el servidor y podremos ver nuestros equipos.

SCSP_04

Desde la consola central tendremos varias pestañas, en “Home” localizaremos información básica.

SCSP_07

Aquí conviene destacar dos conceptos importantes en “Prevention” y “Detection”. “Prevention” hace referencia a aquello que se permite, o no, esto es aplicaciones (Whitelisting), Usuarios que pueden hacer cambios, Sandboxing, etc. Mientras que “Detection” hace referencia a todo aquello que se registra o notifica, como si un usuario se ha logueado incorrectamente, intento de cambio en un registro, de conexión por red, etc. En cada equipo deberá aplicarse una política de cada. Cada una de ellas se podrá (y deberá) configurar según las características del equipo, con lo que se deberá permitir o no. En el caso de las de “Whitelisting” la herramienta emplea distintas “Sandboxes” predefinidas, aunque podremos crear las nuestras propias.

SCSP_08jpg

Por defecto la herramienta viene con un conjunto de políticas hechas, las cuales podremos copiar y ajustar según nuestras necesidades. Para ello se definen tres estrategias “Basic”, “Hardened” y “Protected Whitelisting”.

SCSP_09

Con esta entrada de hoy hemos hecho una introducción a un software de Whitelisting para bastionar nuestros sistemas, en concreto bajo sistemas operativos Windows, aunque la compatibilidad del producto se extiende a Linux también.

En entras sucesivas iremos descubriendo más información al respecto.

Nos vemos en la siguiente!!

Virtual Patching en funcionamiento (Parte III)

Bueno, aquí seguimos com el tema del Virtual Patching. Antes de seguir los dejo los enlaces de las 3 entradas anteriores para estar al tanto del tema que nos concierne.

1.- Parches y Virtual Patching

2.- Virtual Patching en funcionamiento (ParteI)

3.- Virtual Patching en funcionamiento (Parte II)

Siguiendo con la última entrada, si no contásemos con el dispositivo Fortigate, un atacante podría haber localizado nuestra vulnerabilidad y lanzar un “exploit” para poder aprovecharse de ella. Esto puede llevarse a cabo con el framework “Metaesploit” destinado a ese fin y con la ayuda de la GUI “Armitage” para un entorno más amigable.

Arrancaríamos la aplicación “Armitage” desde nuestra distribución Kali y seguiríamos los siguientes pasos:

Dar de alta al equipo con su dirección IP que ya la conoceríamos de los pasos anteriores:

Metaesploit 01

Se realiza un escaneo para detectar puertos abiertos y posterior detección del Sistema Operativo:

Metaesploit 02

Ahora se trata de localizar posibles ataques en función de los resultados obtenidos con anterioridad.

Metaesploit 03

A partir de ahí se localiza la vulnerabilidad descubierta con el escáner “Nessus”.

Metaesploit 04

La ejecutamos y comprometemos el objetivo.

Metaesploit 05

Y una vez hecho esto, ya tendríamos nuestro equipo bajo control. Como vemos en la figura siguiente el icono del XP ha cambiado tornándose de color rojo y unos rayos.

Metaesploit 06

Con el equipo comprometido, podríamos hacernos con el control del Windows XP mediante un visor VNC aún sin tenerlo instalado. El exploit genera un proceso en nuestro equipo Kali, al cual nos conectamos ejecutando el comando:

#vncviewer 127.0.0.1:[identificador]

Metaesploit 07

Esto resulta especialmente grave ya que la tener acceso a la interfaz gráfica podríamos realizar alguna serie de cambios y modificaciones sobre las aplicaciones que estarían corriendo en esos instantes.

También, si lo deseásemos, podríamos hacernos con una consola remota tal y como aparece en la parte inferior y otras muchas acciones:

Metaesploit 08

Sin embargo, si configurásemos el motor IDS/IPS para que bloquee en lugar de monitorizar. Esto es:

Metaesploit 09

Y lanzamos de nuevo el ataque veríamos que éste no tiene éxito:

Metaesploit 10

Metaesploit 11

Y los logs generados indicarían el bloqueo:

Metaesploit 12

Así pues queda claro la importancia de no sólo parchear nuestros equipos, sino además en el supuesto de que por distintas razones no podríamos llevarlo a cabo, la obligación de tener que tomar las medidas necesarias.

En entornos industriales podemos ver el esta situación de una forma más habitual que en entornos IT tradicionales ya que por un lado los ciclos de vida de los PCs industriales son mayores y por otro, dada la criticidad de las instalaciones gobernadas por éstos muchas veces no sea aconsejable instalar algún tipo de software tipo “Endpoint” que los bastione con funcionalidades Host IPS, Antivirus y Firewall.

Espero que el ejemplo haya sido de utilidad para tomar conciencia de esta situación y de las medidas que debemos tomar para securizar nuestros equipos.

Así pues nos vemos en la siguiente entrada, no sin antes invitaros a dejar vuestros comentarios. Desde ya muchas gracias.

Un saludo!!