Conpot, Honeypot para ICS (Parte II)

Continuando la entrada anterior hoy vamos con esas pruebas que he hecho contra Conpot y de cómo éste se ha comportado.

A continuación veremos lo sucedido cuando he accedido por el puerto 80 desde un navegador.

conpot_07

A partir de aquí los log que revelan nuestro acceso.

conpot_08

Hasta aquí podríamos interpretarlo como algo relativamente común. Pero en el ejemplo que sigue requiere conocimientos técnicos y una buena dosis de premeditación y alevosía. Si desde otro equipo ejecutamos un escáner para detectar servicios sobre la IP ejecutando conpot:

conpot_10

Como podemos comprobar el honeypot recoge información como el tipo de paquete, datos del contenido del mismo, IP de origen, etc.

conpot_11

¿Un equipo enviando un paquete a un Honeypot bajo protocolo S7comm? Esto chirría un poco…

 

Otra de las posibilidades que tenemos es ejecutar alguno de los escáneres disponibles en Metaesploit en auxiliary/scanner/scada

conpot_12

Aquí detectaremos el servicio de Modbus en lugar de S7comm.

conpot_13

conpot_14

Finalmente otras de las pruebas que hice fué sobre SNMP. Desde Metaesploit lancé una enumeración mediante este protocolo.

conpot_16

Y sus respectivos logs.

conpot_15

También podríamos cambiar un OID de SNMP. Por ejemplo la dirección de correo:

conpot_17

Y registro de ello.

conpot_18

Como podemos comprobar Conpot puede ser de gran ayuda para detectar comportamientos anómalos en nuestra red y que vayan dirigidos específicamente a nuestros sistemas de control. Obviamente esta es una Prueba de Concepto y cara a su despliegue en nuestras instalaciones deberemos personalizarla para dar una mayor credibilidad en los resultados.

Con el creciente aumento de las amenazas y publicaciones de vulnerabilidades que afectan a entornos con estos equipos, tener un Honeypot que simule uno de ellos es necesario cara a localizar posibles brechas de seguridad. Obviamente trabajamos para no tenerlas y minimizar los riesgos, pero no estamos exentos de que algo, o alguien, pueda acceder a nuestra red y lleve a cabo algún tipo de acción malintencionada. Para esos casos, aquí tenemos un aliado.

Como es lógico, esta herramienta no nos protege de nuestras vulnerabilidades, pero sí nos avisa. El uso más común será detectar tráfico y comportamientos fuera de lo común en este tipo de redes pero no estaría de más poner uno en la red de oficinas. No sea cosa que el enemigo nos venga por ahí.  También nos puede ayudar cara a la realización de auditorias detectando posibles actividades no conocidas en las instalaciones de nuestros clientes y que puedan poner en peligro la disponibilidad de sus instalaciones.

En mi caso he utilizado una máquina virtual pero hay quién lo ha instalado en una RasperryPi, lo cual ya veis los recursos técnicos y económicos que requiere…

Aquí os dejo un enlace del SANS donde encontraréis una guía sobre cómo diseñar e implementar un Honeypot en un entorno SCADA.

Enlace

En fin, espero que os haya gustado la entrada de hoy. Como siempre, os invito a dejar vuestros comentarios.

Un saludo!

Conpot, Honeypot para ICS (Parte I)

Saber las técnicas que emplean los atacantes contra nuestras infraestructuras y sistemas es clave para saber cómo protegernos. Nos da una idea de los métodos, vías, lugares y procedimientos que siguen para alcanzar sus propósitos y desvelar vulnerabilidades, errores en configuraciones, políticas de seguridad mal implementadas y un largo etcétera.

Para ello, una de las estrategias que podemos seguir en la instalación de los que conocemos como “Honeypot” o “Tarro de miel” en la lengua de Cervantes. Un Honeypot es un equipo o software cuya finalidad es atraer a los atacantes simulando ser un equipo vulnerable registrando la actividad llevada a cabo sobre él. Tras un análisis posterior, u online,  podremos obtener información sobre los distintos puntos enumerados en el párrafo anterior.

Con la llegada de protocolos basados en Ethernet y servicios basados en TCP/IP en las comunicaciones industriales, la exposición que han sufrido los Sistemas de Control Industrial ha ido en aumento. Esto provoca que haya que adoptar nuevas medidas de seguridad que antes no se contemplaban. Prueba de ello es el paso de estrategias como el “Air gap” a la “Defensa en profundidad”. Dichos sistemas no están exentos de poseer vulnerabilidades que permitan a un atacante llevar a cabo algún tipo de acción que los comprometa, o deniegue su servicio aprovechándose de recursos hardware más limitados. Pero ojo, sin olvidarnos de las estaciones que los gobiernan. PCs con sistemas operativos tradicionales de los que, por un lado pueden no tener soporte, y que si lo tienen no cuentan con los últimos parches; y por otro, software a veces innecesario y si lo es, también no está a la última versión.

Es por esto que hoy hablaremos de un Honeypot para Sistemas de Control Industrial, Conpot. Conpot, como indica la página web del proyecto, es un servidor interactivo de Sistemas de Control Industrial diseñado para ser fácil de desplegar, modificar e implementar, proporcionando un amplio rango de protocolos que permiten construir tu propio entorno capaz de convencer a tu “adversario” de que está frente un enorme y complejo sistema industrial. Para mejorar las capacidades de engaño también se proporciona la capacidad de simular una HMI personalizable y ampliar así la superficie de ataque. El tiempo de respuesta de los servicios también puede ser alterado para imitar el comportamiento de un equipo frente a un aumento de la carga y consumo de recursos. Gracias a una completa pila de protocolos, Conpot puede ser accesible por HMI reales o ampliado el hardware real. Finalmente, todo ello bajo el amparo de Honeynet Project

A continuación os dejo el video presentación:

En el siguiente ejemplo he instalado Conpot en una distribución Kali Linux 2016.1, aunque podremos utilizar la que más nos guste aunque primero debemos resolver algunas dependencias. En mi caso he tomado las requeridas para Ubuntu 14.04 LTS y Debian.

Para empezar añadí los repositorios de la versión Kali 2.0 para poder instalar los paquetes snmp-mibs-downloader que con los que vienen por defecto para 2016.1 no lo hace. Entiendo que al ser “non-free” o los instalamos a mano o recurrimos a otras vías como ésta. Entre una cosa y otra al final el fichero  /etc/apt/sources.list quedó con el siguiente contenido:

deb http://http.kali.org/kali kali-rolling main non-free contrib

deb-src http://http.kali.org/kali kali-rolling main non-free contrib

deb http://http.kali.org/kali sana main non-free contrib

deb http://security.kali.org/kali-security sana/updates main contrib non-free

Luego resolveremos las siguientes dependencias:

apt-get install git cython python python-dev python-pip build-essential libxml2-dev libxslt1-dev libevent-dev snmp-mibs-downloader sqlite sqlite3 libsmi2ldbl libsmi2ldbl python-pip libmysqlclient-dev python-mysqldb pkg-config libvirt-dev smistrip 

Actualizamos otros mediante pip.

pip install –upgrade gevent pysnmp lxml bottle jinja2 beautifulsoup4 requests sphinx libtaxii xlrd crc16 

E instalamos, si no lo tenemos ya: 

pip install modbus-tk

pip install argparse 

Es posible que sólo debamos actualizarlos.

Para instalar Conpot podremos hacerlo también con pip

pip install conpot

En mi caso he descargado el software desde:

https://github.com/mushorg/conpot 

e instalado manualmente. 

Descomprimimos el fichero y mediante el siguiente comando lo instalamos:

python setup.py install 

Los distintos ficheros y directorios los encontraremos en:

conpot_01

Para su funcionamiento se cuenta con un fichero de configuración nombrado conpot.cfg donde podremos definir, entre otros, algunos parámetros como por ejemplo cambiar la dirección MAC en la interfaz de red que elijamos, o indicar un servidor Syslog para consolidad todos los logs generados en un servidor y así poder llevar a cabo las labores de análisis forense. Al fin y al cabo esta es una de las funciones para las que está pensado, ¿no?

 

Luego, dentro de las carpetas “templates”  encontraremos los distintos escenarios que nos vienen por defecto y que podremos simular.

conpot_02

Para mi ejemplo voy a utilizar el “default” que simula un PLC S7-200, con acceso vía HTTP, Modbus, s7comm y SNMP. A continuación indico el enlace donde se detallan las configuraciones que podremos hacer sobre los mismos bajo este “template”.

Enlace

Esta herramienta también nos da la posibilidad de hacer de un HMI accesible por HTTP y que nuestro Honeypot lo represente, bien creando una nosotros o copiándola de otra ya creada (hmi_crawler). Las instrucciones las podemos encontrar aquí:

Enlace

Como decía, en el siguiente caso he utilizado el template “default”. Sin embargo he cambiado algunos  parámetros dentro del fichero “template.xml” para darle un toque más personal.

conpot_03

conpot_04

Para que sean visibles vía web deberemos editar el fichero index.html dentro de templates/default/http/htdos e incluir los valores que acabamos de configurar.

conpot_05

Para “lanzar” el honeypot ejecutaremos:

conpot –t default conpot_06

También podemos ver los sockets abiertos:

conpot_09

A partir de aquí lo que hagamos contra nuestro equipo ficticio quedará registrado en un fichero denominado conpor.log o bien en uno distinto mediante el parámetro –l. 

Hasta aquí la entrada de hoy. Para la próxima mostraré los efectos de distintas acciones sobre el honeypot y los resultados obtenidos.

Lo dicho, nos vemos en la próxima, por ahora a instalar conpot y familiarizarse con su capacidades.

Un saludo!

Vectores de ataque sobre ICS

Siguiendo con el tema de las Amenazas sobre Sistemas de Control y Automatización Industrial que podéis encontrar en “Amenazas sobre ICS (Parte I)” y “Amenazas sobre ICS (Parte II)” en esta ocasión voy a hablar sobre los vectores de ataque. Éstos se sitúan dentro de las intencionadas ya que tiene un origen humano y además requieren de una mayor o menor planificación.

Comencemos:

  • Manipulación de las comunicaciones

Se basa principalmente en la captura de tráfico, inyección de paquetes, tramas, modificación de la información, etc. Existen varias formas entre ellas el ya tan clásico Man in the Middle (MITM). Algunos de los protocolos de comunicación industrial no disponen de controles de autenticación o integridad de mensajes por lo que es posible alterarlos y modificar sus contenidos. Dependiendo de qué modifiquemos podremos cambiar parámetros en los equipos finales, interferir en su funcionamiento y con ello sufrir consecuencias más o menos graves.

  • Destrucción física

La destrucción física puede incluir tanto de infraestructuras como los dispositivos que las componen. Lo que se busca básicamente es el sabotaje, bien de forma directa mediante la rotura o por un medio que permita la re programación y alterar su funcionamiento.

Destrucción fisica

  • Phishing

Este es un viejo amigo bastante conocido. Por recordar, lo definiremos como la técnica de ingeniería social que busca hacerse con información relevante o sensible  suplantando la identidad de una persona u organización de confianza para el individuo a atacar. El interés que busca puede ser muy diverso, desde hacerse con información de algún proyecto o prototipo hasta credenciales de administradores o ingenieros de proceso pasando por detalles sobre equipamiento.

  • Malware

El malware en cualquiera de sus versiones (troyanos, gusanos, rootkits, etc.) pueden tener una gran variedad de propósitos desde la denegación de servicio, pivoting, escalada de privilegios, sabotaje, y un larguísimo etcétera. Obviamente los resultados podrán ser igualmente diversos. Por ejemplo, la inundación de la red con tráfico broadcast, captura de tráfico o actividad del equipo, escaneo de host y servicios, cambio de parámetros y configuraciones, etc. A su vez, esta información puede ser enviada a lo que conocemos como “Comand and Control, C&C” para su explotación y llevar a cabo distintas opciones. Estas comunicaciones muchas veces son cifradas bajo protocolos y servicios normalmente abiertos según entornos como TCP 80, 8080, 443, 21 o UDP 53, 123, entre otros posibles.

Los ejemplos más claros en entornos industriales los más conocidos son Stuxnet y Duqu, aunque también podemos tener otros como Havex, BlackEnergy 2, Conficker, NightDragon entre otros afines.

Kaspersky_Lab_infographics_stuxnet_5_victims_eng_final-10-254008

  • Robo

Mediante este vector, como es lógico, nos encontramos con la sustracción de información. La que más suele interesar son las relacionadas con la actividad de las instalaciones, o la propia empresa. Podemos hablar de ficheros de configuración que contengan datos sobre dispositivos, sistemas, parámetros, referencia sobre los propios equipos y actividad.

Pero no todo se refiere al ámbito lógico, también está lo físico. El hurto del propio equipamiento existe, por ejemplo elementos de recogida de datos, PCs de monitorización, cableado y otras tantas cosas que puedan ser atrayentes para los amigos de lo  ajeno.

  • Spam

No hablamos que desde un sistema dentro de una instalación o entorno industrial deba poderse acceder al correo electrónico de los empleados, que obviamente no debe permitirse. Sino del uso incorrecto del mismo.

Hablamos que un usuario emplee la cuenta de correo corporativa para darse de alta en páginas web que a posteriori le hagan llegar mensajes no solicitados conteniendo publicidad y referencia a sitios web con contenido malicioso. Si accede, podría instalársele algún tipo de malware y a partir de ahí, pues… También puede contemplarse el recabado de información como otras cuentas de correo para luego enviarles más correos de este tipo y proseguir con la campaña.

  • Escalado de privilegios

Aprovechando un “bug”, error, o adjetivo similar de una aplicación o sistema operativo, un atacante podría llevar a cabo tareas que inicialmente un usuario no está autorizado o bien heredar los permisos de otro.

Un ejemplo lo tenemos en siguiente enlace, aquí. Parece que Siemens siempre está en boca de todos, pero hay otros muchos como estos:

Enlace 1

Enlace 2

Enlace 3

Acceso

  • Repetición

Este tipo de ataques consisten en el reenvío de tráfico que ha sido capturado con anterioridad o generado intencionadamente mediante software. Además, aprovechando la falta de métodos de seguridad implementados en distintos protocolos como Modbus, los paquetes pueden ser modificados para provocar comportamientos distintos a la operativa normal, con los daños que eso pueda acarrear. Este vector está relacionado, como es lógico, con el punto “Manipulación de las comunicaciones”.

  • Spoofing

El spoofing consiste en suplantar la identidad de los actores que pueden intervenir en una comunicación. Existen varias técnicas, dependiendo del nivel en el que hagamos la suplantación, por ejemplo ARP spoofing, direcciones MAC; IP spoofing, direcciones IP; DNS spoofing, dominios; email spoofing, direcciones de correo electrónico; en fin todo aquello que pueda ser sustituido por otro distinto al original. Si bien éstas provienen del mundo IT, en el OT también podernos encontrarnos con algunas de ellas. Como hemos mencionado en el punto anterior, algunos protocolos de comunicación industrial no poseen medidas de seguridad que eviten o detecten este tipo de ataques.

  • Inyección de código

La inyección de código consiste en aprovechar esos “bugs” de programación presentes en las aplicaciones o sistemas operativos con para poder llevar a cabo distintos tipo de acciones. Alguna de ellas puede ser la obtención de información, la denegación de servicio, la apertura de una sesión contra un equipo concreto, pero dependiendo del código inyectado y la vulnerabilidad los resultados pueden ser muchos otros.

Dentro de los entornos industriales, es común la existencia de elementos HMI en los cuales se instalan distintas aplicaciones para el control de los autómatas, u otros elementos. Éstas pueden presentar fallos de programación y por tanto permitir estos ataques. De ahí que resulte elemental instalar sólo el software estrictamente necesario.

  • Denegación de servicio

Si bien ya lo hemos nombrado anteriormente, una denegación de servicio consiste en impedir que un sistema pueda ofrecer un determinado servicio para el que está destinado. Como origen podemos hablar tanto de las debilidades que puedan afectar a aplicaciones que prestan dicho servicio y por otro aquellas relacionadas con las comunicaciones. Por poner un ejemplo, en el primero de ellos podríamos hablar de que esa aplicación pueda “bloquearse” bajo unas determinadas condiciones de procesamiento y por otro que un PLC no pueda procesar varias comunicaciones simultáneas ya que los recursos hardware de los que dispone no sean suficientes y por tanto pueda bloquearse. Por experiencia, esto último, puede resultar muy común cuando lanzamos ciertos escaneos de vulnerabilidades sobre dispositivos de campo.

dos-attack-acunetix

  • Ingeniería Social

Básicamente lo podríamos resumir como la técnica de no sólo obtener información de un individuo sino además conseguir que haga aquello que de otra manera no haría. Según diría Kevin Mitnick Se basa en 4 principios básicos:

  1. Todos queremos ayudar.
  2. El primer movimiento es siempre de confianza hacia el otro.
  3. No nos gusta decir No.
  4. A todos nos gusta que nos alaben

Las  técnicas empleadas pueden comprender desde plantear un problema o una necesidad para que, dentro de ese ánimo colaborativo, revelar o dar pistas sobre nuestras infraestructuras o componentes en ellas instaladas.

De esta manera hemos enumerado los posibles vectores de ataques que pueden de los que pueden ser objeto los Sistemas de Control y Automatización Industrial, siempre desde un punto de vista intencionado. Para ello deberemos de implementar distintas medidas técnicas y cumplir con unas políticas de seguridad previamente establecidas y de obligado cumplimiento. Pero sobre todo, concienciar a las personas que tengan contacto con la operativa, mantenimiento y despliegue de estas instalaciones sobre las amenazas y el creciente aumento de éstas . No podremos estar seguros al 100% pero sí reducir los riesgos hasta unos niveles aceptables.

No quisiera finalizar sin hacer referencia a dos frases que bien pueden encajar con la idea que aquí se busca:

“Una cadena es tan fuerte como su eslabón más débil” 

“Sólo se salva del peligro quién vigila incluso cuando está seguro”

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

Amenazas sobre ICS (Parte II)

Hace unos días hablaba de las amenazas que afectan a los Sistemas de Automatización y Control Industrial, tratando en concreto las de carácter no intencionado. En la entrada de hoy abordaremos las restantes, esto es, las que van dirigidas expresamente hacia ellos, las intencionadas.

A diferencia de las anteriores éstas tienen un origen humano, bien directa o indirectamente por medio de la creación de código o software.

Para ellas podemos definir 6 grandes grupos, como son:

  1. Empleados descontentos
  2. Individuos / Pequeños grupos / Hacktivistas
  3. Competencia
  4. Grupos Criminales
  5. Terroristas
  6. Servicios de Inteligencia / Gobiernos

EMPLEADOS DESCONTENTOS

Los empleados descontentos, o también llamados en la lengua de Shakespeare “Insiders”, son la fuente de amenazas más importante, y común, para los sistemas de control y automatización. El personal interno dispone de toda la información sobre ellos y en consecuencia el conocimiento sobre su operación, configuración, funcionamiento, criticidad, componentes, debilidades, etc.

No obstante, también se debe tener presente a los antiguos empleados que, aunque ya no disponen de acceso a las instalaciones y dispositivos, sí pueden tener conocimiento de la operativa, infraestructuras, accesibilidad remota si la hubiera, etc. Debido a este hecho, podrían en un momento dado, llevar a cabo acciones desde fuera de la organización que sean ejecutadas de forma exitosa como por ejemplo un DoS. Enlace.

INDIVIDUOS / PEQUEÑOS GRUPOS / HACKTIVISMO 

Dentro de este grupo incluímos a personas que actúan de forma individual o conjunto reducido de ellas movidos principalmente por un afán de notoriedad o protagonismo. Su fin último no es poner en peligro al proceso industrial y la organización que está detrás, sino su propia publicidad y reconocimiento. También podremos encontrarnos a los denominados “Script Kiddies” que iniciándose en el manejo de herramientas de libre distribución pueden producir algunos daños.

Por otro lado tendríamos grupos tales como Anonymous, LulzSec, GhostSecurity que llevan a cabo ataques o acciones contra objetivos concretos. Generalmente se trata de ataques del tipo DoS o DDoS, sin embargo también podremos encontrarnos con la publicación de información, previa intrusión en sistemas.

COMPETENCIA 

Las compañías rivales si algo desean saber son los movimientos de la competencia para poder tomar las medidas necesarias y alcanzar una ventaja frente a otras empresas del sector. Toda información sobre funcionamiento, políticas, estrategias, inversiones, es bien recibida. Incluso pueden llegar a recurrir a grupos criminales que lleven a cabo sabotajes contra intereses o infraestructuras con tal de perjudicar su imagen. No podemos eludir el denominado espionaje industrial que nada tiene que ver con este punto pero que puede ayudar en lo que a la recolección de información se refiere. Enlace. Enlace.

GRUPOS CRIMINALES 

Los grupos criminales atacan los sistemas de control para chantajear a la industria y pedir dinero a cambio de no revelar información sensible. Otra de los movimientos consiste amenazar con dejar sin control a los operarios legítimos o exigir un monto económico a cambio de devolver el control sobre los sistemas. Hay que tener en cuenta que dependiendo de las instalaciones las consecuencias pueden llegar a ser bastante graves, no sólo a la población civil sino a la ecología.

TERRORISTAS 

Hasta hace no hace mucho se consideraba a los grupos terroristas no suponían una amenaza a nivel lógico, pero sí a nivel físico. Las amenazas de esta índole se basan en la destrucción de las infraestructuras, principalmente las críticas, con el objetivo de desestabilizar el funcionamiento de un país por motivos políticos, religiosos, o sociales. Sin embargo grupos como Estado Islámico ya disponen de fieles dedicados a llevar su guerra por medio de acciones a través de Internet (Link) (Link). Tal es el caso del denominado Cybercalifato.

SERVICIOS DE INTELIGENCIA EXTRANJEROS / GOBIERNOS 

No es ninguna novedad, ni ningún secreto que los servicios de inteligencia de distintos países realizan actividades de espionaje y captura de información dentro y fuera de sus fronteras.  ¿Qué se puede decir a estas alturas de la NSA, verdad?. No sólo poseen recursos tecnológicos, económicos y legislativos, sino también la inmunidad y protección de otros estados aliados que persigan el mismo objetivo. Link.

En fin, como podemos comprobar son varios los principales focos de amenazas a las que todo Sistema de Control y Automatización puede llegar a enfrentarse, lo cual no quiere decir que vayan a darse necesariamente. Pero haberlas, las hay. Todos somos conscientes que la seguridad al 100 % no existe y de lo que se trata es reducir los riesgos, minimizando nuestra exposición y debilidades.

Podemos representar que:

Riesgo = Amenaza x Vulnerabilidad x Impacto

Con la entrada XXXXXXXXX y la de hoy hemos abordado la primera de las variables, tanto en su origen no intencionado como intencionado.

El impacto dependerá en gran medida de la actividad a la que se dedique la instalación ya que, no será lo mismo si hablamos de una estación eléctrica que deje sin luz “sólo” a una población de 250.000 personas; una refinería que provoque un desastre ecológico por derrame de combustible o una fábrica que deba de para su producción por ejemplo por 24 horas.

Sin embargo en lo referente a las vulnerabilidades ya hay que considerar algún punto más que lo dejaremos para futuras entradas así como los distintos vectores de ataque.

Espero que haya sido de vuestro agrado, nos vemos en la siguiente.

Un saludo!

Virtual Patching en funcionamiento (Parte I)

Siguiendo con el tema de Virtual Patching ahora toca ver cómo funciona y los beneficios que puede aportarnos.

Para ello he creado un entorno con dos PCs interconectados por medio de un Fortinet Fortigate Rugged 60D configurándolo con motores Antivirus, IDS/IPS y Control de Aplicación. La parte de firewall la he dejado con un “permit any any any” (IP origen, destino y puerto, respectivamente) Hay que recordar que cada una de ellos lo podemos configurar en dos modos, “Monitor” o “Block”. Con el primero, en caso de que se detecte algún patrón que puda quedar recogido dentro de las reglas y firmas, no se tomará ninguna acción, sólo se registrará el evento y se dejará pasar. En cambio con “Block”, valga la redundancia se bloqueará y la amenaza será paralizada.

Luego, estas características han de aplicarse, o no, a las reglas de Firewall en él configuradas.

En cada uno de estos PCs he virtualizado un total de 3 máquinas.

Una con Kali Linux desde la cual simularemos la actividad de un atacante. Lanzaremos un escaneo de puertos con Nmap, escáner de vulnerabilidades con Nessus, intento de intrusión con Metaesploit y Armitage y por último copiar en un recurso de red el fichero EICAR.

Otra con un Windows XP vulnerable, el objetivo. Se ha elegido este ya que posee vulnerabilidades que para un ejemplo pueden ser fácilmente explotables. Aparte porque su uso en entornos industriales y o vida prolongada es aún bastante común.

Por último un Fortinet FotiManager con funciones FortiAnalyzer desde donde gestionaremos el equipo Fortigate Rugged 60D. Lo he querido utilizar ya que con un despliegue de varios equipos resulta aconsejable no sólo por la gestión centralizada sino porque nos permite almacenar los logs, analizar tráfico, sacar informes, ver registros, etc.

Todo queda resumido de la siguiente manera:

 

Esquema 01

En la imagen siguiente se muestra cómo el equipo Fortigate bloquea un total de 9965 amenazas catalogadas en un total de 1993 incidentes, provenientes de la IP XX.XX.XX.15 de la máquina Kali Linux. Esto es debido a que la aplicación Nmap envía sucesivamente paquetes para que en función de las respuestas obtenidas se pueda determinar si un equipo está activo, o no, puertos abiertos; versiones de aplicaciones, servicios; etc.

Para conocer un poco más recomiendo la siguiente lectura, pincha aquí.

Imagen 01

En esta otra se puede ver que el equipo destino tiene la IP XX.XX.XX.17.

Imagen 02

En la siguiente imagen se muestra las “sondas” enviadas desde el equipo Kali Linux identificando alguna aplicación que otra:

Imagen 03

Como se puede apreciar éstas han sido bloqueadas no pudiéndose obtener datos sobre el equipo objetivo, el XP. Esto mitigaría la etapa inicial de recolección de información que un atacante llevaría a cabo y poder, a partir de ahí, realizar otro tipo de acciones sobre nuestros sistemas.

Obviamente habría que configurar las reglas del firewall del modo más restrictivo posible y sobre el tráfico que dejamos pasar aplicar el análisis de los motores Antivirus, IPS y Control de Aplicación. Sin embargo para este ejemplo se ha querido dejar así para ver el comportamiento de la aplicación Nmap y qué es lo que sucede si no empleamos un cortafuego. Pero como como digo, siempre, siempre, siempre, ha de restringirse el tráfico sólo al estrictamente permitido por medio de estos firewalls.

Esto es todo por hoy, pero os debo las siguientes entradas sobre escáner de Vulnerabilidades, Metaesploit y EICAR Test File.

No s vemos en la próxima, y como siempre digo, se agradece cualquier comentario al respecto.

Muchas gracias!

Ciberseguridad Industrial, breve introducción…

Cuando hablamos de Ciberseguridad, generalmente lo hacemos desde el punto de vista tradicional de los entornos IT. Esto es, proteger de ciberamenazas, ciberdelincuentes, y demás términos de similar índole; la información contenida dentro de los sistemas información interconectados por medio de redes de comunicaciones de mayor o menor alcance. El objeto principal de custodia aquí es la información. Ésta puede venir de muy diversas maneras y formatos, desde un documento, hasta los registros en una Base de Datos, pasando por comprometedores correos electrónicos que por una razón u otra no interesa que salgan a luz.

Como decía, esto es el mundo IT. Ahora bien, ¿qué ocurre con los entornos OT? Aquí el principal activo no es la información sino la disponibilidad de las infraestructuras y la continuidad operacional de las instalaciones. Aquí los equipos a proteger no serán los servidores de ficheros, Bases de Datos, correo electrónico; sino los sistemas de Control y Automatización (IACS); Supervisión, Control y Adquisición de Datos (SCADA); Sensores, Actuadores, Autómatas Programables, etc. Aquí ya no es si se pierde o se compromete un dato; es qué pasa si las instalaciones dejan de funcionar por tal o cual motivo.

Así pues las “Operational Technologies”, o Tecnologías de Operación son los términos con los que nos referimos al conjunto de dispositivos, funcionalidades y procesos que participan en el desarrollo de la actividad de un determinado sector. Su indisponibilidad puede provocar no sólo un impacto significativo a la empresa que las posee y al entorno donde ésta pueda estar ubicada.

¿Por qué esto es así? Los Sistemas de Control y Automatización Industrial están presentes no sólo en fábricas de producción en serie de un determinado producto sino también en lo que conocemos como Infraestructuras Críticas. Entendiendo por estas últimas:

“Las infraestructuras estratégicas (es decir, aquellas que proporcionan servicios esenciales) cuyo funcionamiento es indispensable y no permite soluciones alternativas, por lo que su perturbación o destrucción tendría un grave impacto sobre los servicios esenciales”. 

Dentro de la Legislación española se han definido 12 sectores estratégicos, los cuales son:

  1. Administración.
  2. Agua.
  3. Alimentación.
  4. Energía.
  5. Espacio.
  6. Industria Química.
  7. Industria Nuclear.
  8. Instalaciones de Investigación.
  9. Salud.
  10. Sistema Financiero y Tributario.
  11. Tecnologías de la Información y las Comunicaciones (TIC).
  12. Transporte.

Una indisponibilidad de una cadena de montaje como la que puede ser la del sector de la Automoción puede generar una pérdida económica de equis miles o millones de euros; sin embargo si esto sucede en una central nuclear las consecuencias pueden ser bien distintas. No sólo por la pérdida de servicio eléctrico sino por el impacto que puede tener sobre la población civil y medioambiental.

Así pues podríamos definir algunas posibles consecuencias:

  1. Reducción o pérdida de la producción.
  2. Daños en el equipamiento.
  3. Lesiones de personas.
  4. Liberación, desvío o robo de materiales peligrosos (tóxicos, combustibles, etc.)
  5. Daños ambientales.
  6. Violación de normativa y legislación vigente.
  7. Contaminación de productos y entornos.
  8. Responsabilidades legales, penales o civiles.
  9. Pérdida de información confidencial o de propiedad intelectual.
  10. Pérdida de imagen o de la confianza.

Estas consecuencias tendrán su origen en algún tipo de incidencia. Éstas podrán ser catalogadas como no intencionadas, esto es, fallo o anomalía natural en los dispositivos; o bien, de carácter intencionado, es decir por la acción hostil de un software o actividad humana sobre los equipos. A continuación se citan alguna de ellas:

  1. Denegación de Servicio en los servicios activos en las redes de control o causando cuellos de botella a la hora de transferir información.
  1. Cambios no autorizados realizados en instrucciones de programas en PLCs, RTUs, DCS o controladores SCADA, parámetros de alarmas, ejecución de comandos no autorizados en equipos de control que lleguen a dañar el propio equipo, paradas no contempladas en procesos o incluso deshabilitar el equipo de control.
  1. Falsificación de información y visualización incorrecta a los operadores encargados de controlar el sistema.
  1. Modificación de software, configuración y parámetros de sistemas.
  1. Introducción en el sistema de malware (por ejemplo virus, gusanos, troyanos).

 

Así pues urge la necesidad de proteger los procesos, dispositivos y elementos que intervienen en todos procesos de automatización y control, de esos riesgos y amenazas de las que pueden ser objeto.

Como todo elemento tecnológico pueden disponer de errores en su diseño, programación o instalación; poseyendo vulnerabilidades y “bugs” que faciliten enormemente el éxito de las operaciones.

El gusano Stuxnet hizo abrir los ojos a muchas Naciones y empresas en los distintos sector de los riesgos que corrían si no tomaban las precauciones necesarias y sin duda supuso un antes y un después:

Stuxnet

Pero no ha sido el único, tiene otros hermanos con igual mala leche como Duqu, DragonFly, Havex, Black Energy, etc. y seguirán apareciendo más en los próximos meses. Esto va en aumento…

¿Quién puede tener interés en atacar esto tipo de entornos? Las respuestas pueden ser muy distintas, desde empleados descontentos, empresas de la competencia, grupos Hacktivistas, terroristas y delincuencia organizada, Agencias de Inteligencia, Gobiernos, etc. Obviamente hay un móvil y una razón por la cual llevar a cabo dichos propósitos.

Como contramedida a estos riesgos en materia de Infraestructuras Críticas existe por un lado el CNPIC (Centro Nacional de Protección de Infraestructuras Críticas), cuyo objetivo es  impulsar, coordinar y supervisar todas las actividades que tiene encomendadas la Secretaría de Estado de Seguridad del Ministerio del Interior en relación con la protección de las infraestructuras críticas españolas según la Ley 8/2011 y Real Decreto 704/2011

Además de ello existen otros organismos de carácter público y privado encargados de llevar a cabo distintas acciones sobre este ámbito. Algunos de ellos son:

España:

INCIBE, Instituto de Ciberseguridad de España.

CCI, Centro de Ciberseguridad Industrial

A nivel Europeo:

ENISA, European Union Agency for Network and Information Security

EE.UU:

ICS-CERT, Industrial Control System Cyber Emergency Response Team.

Así pues ya tenemos na primera aproximación a lo que conocemos como “Ciberseguridad Industrial” e iremos desarrollando en artículos sucesivos. Todo es empezar…

Un saludo.