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!

Virtual Patching en funcionamiento (Parte II)

Siguiendo la entrada anterior Virtual Patching en funcionamiento (Parte I) vamos a seguir viendo los efectos del Virtual Patching pero en el caso frente a un escáner de vulnerabilidades.

Lo que vamos a hacer es lanzar uno desde una máquina virtual con Kali Linux hacia un Windows XP vulnerable. ¿Por qué un XP? Porque este sistema operativo está aún muy presente en muchos equipos en entornos industriales y debido al largo ciclo de vida de las estaciones o instalaciones que gobiernan, siguen funcionando a pleno rendimiento. Sin embargo, como sabemos ya no hay soporte y muchos de ellos no están parcheados, lo cual les convierte en un objetivo muy apetecible a malware y usuarios malintencionados. Ni qué hablar de Windows 2000 que también los he visto… Buenos, el esquema era el siguiente:

Esquema 01

Como decía, en el post anterior trataba los resultados tras hacer un escaneo con Nmap. Ahora toca pasar a la siguiente etapa dentro de una supuesta intrusión, o auditoría. Encontrar vulnerabilidades para ser explotadas. Para ello se utiliza un escáner que en nuestro será “Nessus”, pudiendo encontrarse otros como OpenVAS y Nexpose.

Kali Linux no lo trae por defecto, así que lo hemos descargado de la página del producto, obtenido el código correspondiente, instalado y actualizado los plugins. Luego creamos el proyecto y definimos los perfiles que queremos utilizar. En mi caso he dejado sólo los relacionados con plataformas Windows para que sea algo más rápido. No obstante os dejo otro de mis post donde hablaba de la metodología del Pentesting. Lo podéis encontrar aquí.

Nessus 01

Por otro lado la configuración de reglas en el Fortinet Fortigate Rugged 60D quedaría como sigue:

Nessus 02

Como se puede ver se permite todo el tráfico entre las interfaces “Wan1” y “Wan2”, pero se someterá a los motores Antivirus, Control de Aplicación e IDS/IPS. Lo sé, lo sé, habría que restringir el tráfico sólo al imprescindible pero para la prueba lo dejaré así. En la vida real, ni se os ocurra hacer esto. En el caso de este último, el IDS, se ha configurado para que bloquee “Block” todo aquél tráfico que coincida con alguna de las reglas en él definidas.

Tras lanzar el escáner vemos que el resultado es el siguiente. El Fortigate ha bloqueado los paquetes desde el escáner:Nessus 03

Si a continuación hacemos un reporte de las vulnerabilidades encontradas vemos que sólo se han encontrado un total de 8 de nivel informativo.

Nessus 04

Así pues el supuesto atacante apenas podría haber obtenido información del objetivo, con lo que tendría más complicado a la hora de lanzar un exploit concreto cara a aprovechar una vulnerabilidad. Aunque no se aprecie en la imagen, los datos ofrecidos no son relevantes cara a este fin, la intrusión. En cambio, si deshabilitamos dicha protección, esto es:

Nessus 05

Y lanzamos de nuevo el escáner, el resultado sería bien distinto:

Nessus 06

Aquí veremos que sí se obtienen datos sobre el equipo con Windows XP y por tanto sería exitoso el ataque como el que se podría llevar a cabo en el punto siguiente. Entre ellas hay un total de 3 vulnerabilidades “Critical”, 2 “Medium”, y 20 “Info” destacando entre ellas la que figura a continuación.

34477 (1) – MS08-067: Microsoft Windows Server Service Crafted RPC Request Handling Remote 

Code Execution (958644) (uncredentialed check) 

Synopsis

Arbitrary code can be executed on the remote host due to a flaw in the ‘Server’ service.

Description

The remote host is vulnerable to a buffer overrun in the ‘Server’

service that may allow an attacker to execute arbitrary code on the remote host with the ‘System’ privileges.

See Also

http://technet.microsoft.com/en-us/security/bulletin/ms08-067

Solution

Microsoft has released a set of patches for Windows 2000, XP, 2003, Vista and 2008.

Risk Factor

Critical

CVSS Base Score

10.0 (CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C)

CVSS Temporal Score

8.7 (CVSS2#E:H/RL:OF/RC:C)

STIG SeverityI

References 

BID 31874

CVE CVE-2008-4250

XREF OSVDB:49243

XREF MSFT:MS08-067

XREF IAVA:2008-A-0081

XREF CWE:94

Exploitable with

CANVAS (true)Core Impact (true)Metasploit (true)

Plugin Information:

Publication date: 2008/10/23, Modification date: 2015/06/18

Hosts

XX.XX.XX.17 (tcp/445)

Queda bastante claro la funcionalidad de estos motores. A pesar de no restringir el tráfico mediante reglas de firewall tradicionales y dejar pasar todo, algo que obviamente NO DEBE HACERSE BAJO NINGÚN CONCEPTO, nos proporcionan un grado de protección evidente.

En este ejemplo lo hemos hecho sobre un Windows XP vulnerable, pero esto también podríamos emplearlo como elemento de seguridad perimetral sobre Sistemas de Control y Automatización Industrial u otros dispositivos con capacidades limitadas para la implementación de medidas de seguridad. Su protección en este caso radicaría en el Fortigate Rugged 60.

Así hemos terminado por hoy. En la próxima entrada veremos cómo comprometer el Windows XP mediante Metaesploit gracias a la vulnerabilidad anterior.

Como en otras ocasiones os animo a que dejéis vuestro comentario, tanto si es positivo como si no lo es. Todo sirve para mejorar.

Lo dicho, un saludo, nos vemos en la próxima!!

Cuando VLANs y Firewalls no son suficientes

Como comentaba en la entrada anterior, hace poco terminé el curso sobre Ciberseguridad en Sistemas de Control y Automatización Industrial impartido por el Instituto Nacional de Ciberseguriad (INCIBE) antes, INTECO.

Dentro de su contenido, en uno de sus módulos se trataba el tema de los incidentes de seguridad sobre dichos sistemas, analizando desde los posibles objetivos potenciales hasta las deficiencias técnicas, pasando por controles de acceso físico pobres o incluso nulos.

Entre esos puntos se apuntaba como orígenes a la red corporativa y a cortafuegos perimetrales mal configurados. En el primero de ellos, se explicaba que tanto los sistemas empresariales como industriales comparten la misma infraestructura de comunicaciones  permitiendo  llevar ataques desde la red corporativa a la de control aprovechando alguna vulnerabilidad en aquéllos. En lo referente a los cortafuegos perimetrales, se comentaban las malas configuraciones sobre ciertos protocolos y también, no considerar el sentido de las conexiones. Como ejemplo se hablaba de una intrusión en los sistemas de control, la ejecución de un “payload” en ellos e iniciar una conexión a un equipo remoto empleando un puerto abierto en el firewall.

Partiendo de la base que ninguna red es igual ya que las necesidades y usos pueden ser bien distintos, en la entrada de hoy voy a hablar de dos aspectos que afectan a las ideas descritas en los apartados anteriores.

Por mi experiencia, es muy común que equipos corporativos convivan con los de control dentro del mismo switch. Por ejemplo, en una cadena de producción tenemos un PC donde  ejecutamos distintas aplicaciones relacionadas con el proceso de fabricación, mientras que en otros puertos tenemos los autómatas que controlan la maquinaria (robots, sensores, válvulas, etc.). También puede ocurrir que existan incluso puntos de acceso inalábricos para aquellos dispositivos no cableados tipo PDAs industriales, lectores de códigos de barras, PCs portátiles de personal de mantenimiento, etc. ¡Y posiblemente todo dentro de la misma VLAN! Resultaría costosísimo, o incluso inviable, implementar dos o tres infraestructuras paralelas para separar físicamente todo el tráfico, así que la realidad es que unos y otros deben “viajar” por el mismo equipo y por la misma red, aunque separados lógicamente mediante el uso deVLANs.

Por otro lado, debemos pensar que a la hora de interconectarlo todo, no se puede implementar cortafuegos por cada enlace, subred, equipo, etc. para regular el tráfico a permitir o denegar. Si bien la inversión, condiciona en gran medida la solución tecnológica a utilizar (salvo que sobre el dinero, que viendo los tiempos que corren es poco probable…), debemos pensar,  en lo a la parte técnica se refiere, que los switches nos pueden ofrecer una serie de ventajas que, a veces, los cortafuegos no lo hacen. Por ejemplo, mayor densidad de puertos y uso de módulos SFP para distintos medios físicos como cable y fibra óptica. También es cierto que los cortafuegos realizan tareas que no hacen los switches. Unos no  son mejores que los otros, sino que cada cual hace su papel y se complementan.

A estas ideas debemos sumar también la implantación de medidas que garanticen una alta disponibilidad de los servicios prestados, con lo que aparte de equipos de comunicaciones, de seguridad, control, automatización, etc. debemos disponerlo todo de tal manera que en caso de producirse un fallo, la red pueda seguir funcionando sin que esto suponga un impacto en la calidad del servicio ofrecido.

Como bien dice el refrán “Una imagen vale más que mil palabras”  he creado un escenario para tratar de entender mejor lo dicho. He utilizado la aplicación de Cisco Systems, Packettracer, utilizada para la preparación de las certificaciones CCNA y CCNP, entre otras.

Basándome en los criterios de este post, aquí os dejo la topología:

Topología

Para explicarlo empezaremos de izquierda a derecha.

Tenemos el equipo “Switch Acceso” (Switch L2) al que se conectan por un lado los autómatas PLC-01 y PLC-02, y por otro un PC que pueda ser utilizado para la ejecución de aplicaciones relacionadas con la actividad industrial. También se ha incluido una impresora, como un elemento de red más que pueda ser utilizado para la impresión de algunos documentos, órdenes de montaje, códigos de barras para temas logísticos, etc.

Para segmentar el tráfico, los PLCs,  el PC y la impresora se han situado en VLANs distintas. PLC-01 y PLC-02 en la VLAN 10 con direccionamiento 192.168.10.0 /24; y PC-01 y Printer0 en la VLAN 20, y red 192.168.20.0/24. Como puerta de enlace será la primera IP de ambas redes, la .1.

Dado que es un entorno de alta disponibilidad, se ha configurado en los switches “sw-core-01” y “sw-core-02” (Ambos multicapa o L3) interfaces virtuales para cada una de las VLANs, y en ellas, el protocolo HSRP, aunque también hubiera servido VRRP. Si no sabéis o queréis refrescar los conceptos de interfaces virtuales o dejo un link a un artículo que publiqué hace un tiempo, aquí.

Luego tenemos los cortafuegos, que filtrarán el tráfico entre la red de servidores donde se sitúa el servidor de SCADA, Historiadores, etc y el resto. Esta red tiene un direccionamiento 192.168.254.0/24, y está en la VLAN 254. También está configurado HSRP.

No he dibujado la red corporativa como oficinas ya que no viene por ahí el problema de seguridad que quiero explicar, pero de existir, deberían colgar de cada uno de los nodos del firewall, como lo están las dibujadas.

Como podréis ver los cortafuegos tiene un enlace entre sí. Todo tiene una explicación.

Al igual que en los equipos de red tenemos HSRP, VRRP y GLBP para implementar alta disponibilidad, los cortafuegos tienen los suyos también. Lo que se hace es una topología tipo “Activo-Pasivo” o “Activo-Activo”. La primera de ellas, sería equiparable al comportamiento de HSRP y VRRP, donde uno de los nodos soporta todo el tráfico, el “Master”, mientras que el otro está de respaldo, el “Backup”. En caso de que el “Master” falle, el “Backup” entra en funcionamiento. El modo “Activo-Activo” es aquél en el que ambos nodos funcionan a la par, proporcionando no sólo una alta disponibilidad, ya que si uno falla el otro asume su rol, sino que además existe un balanceo de carga ya que se puede repartir el tráfico entre ambos.

En cualquiera de los dos casos, ambos nodos deben tener un enlace donde compartir una tabla con las conexiones que tiene abiertas, ya que si el nodo “Master” falla, el de “Backup” debe seguir permitiéndolas. Si no existiese este enlace y el nodo de “Backup” no tuviese dicha tabla, cuando uno de los equipos finales volviesen a generar tráfico de una sesión ya establecida, las cortarían.

Por no estar hablando siempre de Cisco, Juniper tiene su protocolo NSRP. Os dejo algunos enlaces pero si buscáis en por ahí  encontraréis un montón de información al respecto.

 Link 1

Link 2

Link 3

Fortinet también tiene soluciones similares. Os dejo más links:

Link 1

Link 2

Link 3

Vale, tenemos el PC y la impresora en una VLAN; y los PLCs en otra de tal manera que a nivel de capa 2 los tenemos “aislados” y cada uno en su propio dominio de broadcast. Mismo criterio con los servidores. Sin embargo, los equipos PLC no están todo lo protegidos que debieran.

¿Por qué? Porque si nos fijamos el PC-01 a pesar de estar en una VLAN distinta de los PLCs puede llegar a ellos sin problemas. Vamos a abrir un navegador del PC-01 y la IP del PLC-01.

Configuración Autómata

¿Por qué? Sencillo. Cuando abrimos el navegador el tráfico llega al switch sw-core-01. Como éste tiene acceso a la VLAN donde está la dirección IP de destino, la 192.168.10.100, es el propio switch el que lo envía por la interfaz de la VLAN 10 ya que están ambas en el mismo equipo. La 10 y la 20.  Podríamos cambiar manualmente el enrutamiento para que fuese todo al tráfico hacia el firewall y éste lo descartase, pero tampoco tiene mucho sentido hacerlo “subir” hasta ahí para luego descartarlo  y ocupar un ancho de banda por poco que sea, nos puede resultar necesario, especialmente a los PLC en su comunicación con el servidor SCADA.

 Por tanto, hay una cosa que es clara y es que tenemos que filtrar el tráfico para evitar que ningún equipo de la red 192.168.20.0/24 pueda llegar a la 192.168.10.0/24. Sin embargo, sí que tenemos que permitir el tráfico desde la red 192.168.20.0/24 a cualquier otro equipo de la red.

Así que, ¿qué alternativa tenemos? La alternativa son las ACL, Access List. Pero esto lo dejamos para la siguiente entrada.

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

Crónica de Curso «Ciberseguridad en IACS»

En esta ocasión la cosa no va a ir de temas técnicos sino más bien, va a ser una crónica de un curso que he realizado recientemente. Ha sido la primera edición, con lo que me parece positivo dar a conocerla para que más gente se anime y se haga eco de los nuevos cursos que están por venir, así más y más profesionales sigamos formándonos en distintas áreas .

El curos en cuestión se ha denominado bajo el nombre “Curso Avanzado de de Ciberseguridad y Sistemas de Control y Automatización Industrial” y ha sido impartido por INCIBE (Instituto Nacional de Ciberseguridad; lo que era antes INTECO”) vía ONLINE.

Llevo 4 años presando servicios como Técnico/Administrador de Redes y Seguridad en una fábrica dedicada al sector de la automoción, y muchas veces me ha tocado que resolver los problemas de conectividad de Robots, Autómatas, Controles de Soldadura, configurar reglas de firewall para sistemas SCADA, etc. Tenía mucho interés por aprender más sobre este tipo de dispositivos y puesto que todos ellos de una manera u otra se “conectan” a la infraestructura de comunicaciones, pues era mi oportunidad.

Dicho esto, a continuación os dejo el enlace del video promocional para que veáis la idea que se persigue y la forma que se imparte:

Enlace

El curso se divide en 7 Unidades, de las cuales haré un breve resumen general ya que no se desea revelar demasiada información sino despertar la curiosidad:

Unidad 0: Bienvenida al curso avanzado de ciberseguridad industrial

Una presentación del curso en general donde se explica el calendario, actividades, normativa, recursos, criterios, manuales, test, etc.

Unidad 1: Introducción a los sistemas de control y automatización

Aquí ya se empieza con la materia en sí. Se abordan temas como historia de la automatización, evolución, problemas de seguridad, particularidades, etc.

Unidad 2: Estudio detallado de los distintos dispositivos de control

Enumeración y descripción de los elementos que intervienen en el proceso de automatización industrial, configuración, parametrización y medidas de seguridad nativas.

Unidad 3: Conceptos fundamentales de las comunicaciones industriales

Propósitos de las comunicaciones, medios físicos, protocolos, tipos de comunicación.

Unidad 4: Sistemas SCADA, historiadores y otros aplicativos

Modelos de implantación, funcionalidades y campo de actuación de los sistemas SCADA, Historización, soluciones BATCH, MES y BII.

Unidad 5: Estudio detallado de amenazas y vulnerabilidades de seguridad 

Amenazas en entornos industriales, vulnerabilidades diseño, desarrollo, operación y mantenimiento; factores de riesgo; incidentes de seguridad. 

Unidad 6: Presentación de iniciativas, buenas prácticas y soluciones

Aproximación a la protección a los sistemas de automatización y control; iniciativas de seguridad a nivel mundial; métodos, modelos, técnicas de seguridad.

Unidad 7: Visita virtual y demostraciones prácticas de seguridad

Introducción a las redes de distribución eléctrica y “Smart Grids”

Evaluación final y encuesta de satisfacción

Examen final de todo el curso y encuesta de satisfacción.

Cada “Unidad” a su vez se subdivide en distintos “Apartados” que abordan de manera específica los temas a tratar. Todas las “Unidades” y “Apartados” cuentan con un documento en formato .pdf, siendo el contenido de estos últimos un resumen del de las respectivas unidades. Adicionalmente cada “Unidad” dispone de un video introductorio. Los “Apartados” también tienen el suyo donde se explica de manera audiovisual su contenido. En algunos casos los documentos y videos tienen contenido muy similar, pero no igual. Es material didáctico complementario y no excluyente. Ojo, a esto!!!

En general cada “Unidad” posee dos ejercicios, uno de investigación y otro práctico. El de investigación se basa en búsqueda, análisis, y desarrollo de información sobre temas propuestos. Los prácticos se basan por ejemplo, en la instalación de software de prueba o libre para realizar distintas actividades como simulación y análisis de cierto tipo de tráfico de comunicaciones industriales.

Aparte la plataforma cuenta con un Blog donde se deberán “subir” los ejercicios prácticos donde los distintos alumnos podrán ver su contenido y votar en consecuencia.

A la hora de evaluar cada, “Unidad” tiene un test final que, para obtener el diploma final, hay que aprobarlo junto con uno  el final. Adicionalmente cada “Apartado” tiene el suyo propio, cuyo objetivo es evaluar los conocimientos. Estos no puntúan, si se suspenden no pasa nada, aunque es muy recomendable hacerlos.

En dos casos, las actividades han de ser plasmadas en documento “Word” o “PDF” para que sean evaluadas por los propios compañeros y calificarlas del 0 al 100 según su propio criterio.

En general, he quedado muy contento con el curso y ha cumplido con mis expectativas. El contenido de los materiales es muy bueno y la inclusión de video ha dinamizado el aprendizaje ya que muchas veces los cursos se basan en documentación escrita que aburre un poco. Con los videos es distintos. Hay que valorar el esfuerzo que supone la edición y maquetación de los mismos.

Otro de los aspectos destacables son los ejercicios, tanto de investigación como prácticos ya que te obliga a trabajar y profundizar en los distintos temas. Esto marca la diferencia con otros cursos que te explican las cosas, te ponen un test y listo. Aquí tienes que “currártelo” más, y eso me parece positivo para el aprendizaje.

Sin embargo no todo ha sido perfecto. Como en todas las cosas que se hacen por primera vez se pueden cometer errores o mejorar ciertas cosas. Por ejemplo, al principio se estimaba que la duración era de 36 horas y luego que no. La organización amplió posteriormente esta cifra a 50. También algunas preguntas de test podían tener a mi juicio (otros alumnos se pronunciaron igual) más de una posible respuesta válida que repercutía en el fallo de la misma. Lo malo es que no se despejaba la duda con lo que te quedas con ella.

Pero bueno, estoy seguro que los responsables tomarán nota de esto último y lo corregirán para futuras ediciones.

En resumen, recomiendo a todo aquel que desee aprender sobre este campo que se apunte y que lo hagan ya que, en mi caso, he aprendido mucho sobre estos sistemas. Ahora queda seguir formándonos, leer, practicar y seguir mejorando.