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 no sólo realizar un control de los activos de nuestra red y el software en ellos instalados sino también 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.

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óm 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 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.

Hasta ese entonces, ¡un saludo!

Edorta

 

Proveedores Externos, posible punto de entrada… 


Como bien sabemos la seguridad no es algo que se acaba con la implementación de un conjunto de medidas técnicas y la definición de unas políticas que prevengan que algo o alguien cause un daño en nuestra organización. En el caso concreto de los entornos industriales, esto además puede repercutir no sólo en un punto de vista lógico sino además afectar en los elementos físicos de las instalaciones.

A la hora de llevar a cabo un proyecto se ha de realizar un análisis de riesgos que evalúe y cuantifique el nivel en el que una organización está expuesta a sufrir un incidente de seguridad considerando, entre otros, las amenazas, vectores de ataque y vulnerabilidades. Sin embargo, estos aspectos pueden cambiar con el paso del tiempo, en particular las vulnerabilidades ya que, como podemos comprobar, la aparición de nuevas es algo continuo. Por tanto, los niveles que resultan satisfactorios a día de, un año después pueden no serlo, siendo la ciberseguridad  un proceso vivo que debe revisarse y ajustarse.

Una de las circunstancias a las que nos vamos a enfrentar, y que muchas veces nos olvidamos, es la existencia de gran cantidad de proveedores dentro de las organizaciones industriales. Las mismas recurren a productos y servicios especializados de terceros que luego deben ser soportados durante su ciclo de vida y garantizar así un respaldo en caso de incidencias.

Para poder llevar a cabo las respectivas tareas, los técnicos de estos proveedores deberán en algún momento, conectarse a la red de operación. Y esto presenta un problema, ya que:

  1. En muchas ocasiones contarán con un software propietario con licencias asignadas a ese equipo dificultando, o no siendo posible, reasignarlas a otro de la propia organización.
  1. Por supuesto al ser un equipo de un tercero no sabemos el estado de actualización del sistema operativo.
  1. Como no, desconocimiento del uso responsable, o no, que se le ha dado por parte de su propietario o usuario.
  1. Puesto que se tratarán de equipos portátiles para disponer de movilidad para llevarlos a tal o cual cliente, vaya uno a saber a qué otras redes han estado conectados.
  1. Y ya para rematar, como no puede ser de otra manera, usuario con permisos de administración y contraseñas de dominio público para que sea quien sea el que lo utilice, lo pueda hacer con total libertad.

Con todo lo dicho, ¿vamos a dejar conectarse a nuestra red equipos sobre el que no tenemos control o bien desconocemos el estado de actualización, limpieza, software instalado, etc? ¿Cómo encaja esta situación dentro de nuestras políticas? Y por si fuera poco, ¿si encima estos técnicos vienen del extranjero? ¿qué hacemos?

Indudablemente esto es una situación a la que deberemos hacer frente y necesariamente contemplarla dentro de nuestras políticas. Esto es, la gestión de los proveedores.

A este respecto deberemos tener en cuenta dos aspectos. Por un el administrativo y por otro, la solución técnica.

Desde el punto administrativo la organización deberá establecer un proceso donde se regule qué hay que hacer cuando un proveedor deba conectarse a nuestra red OT.

La primera de ellas es realizar un análisis de riesgos de este proveedor con lo que habrá que identificar:

  1. Necesidad justificada de la acción.
  2. Alcance de trabajos.
  3. Activos sobre los cuales se va a actuar.
  4. Información técnica sobre las intervenciones.
  5. Duración estimada.
  6. Recursos empleados.
  7. Manera en la que afecta a la organización.
  8. Análisis del impacto que tiene para la organización en caso de producirse un error y cómo afecta a aspectos tales como financiero, operativo, clientes y trabajadores.
  9. Representación gráfica tanto del riesgo existente como del residual si el primero no puede ser reducido o mitigado.

Otra de la información que tenemos que recoger son las necesidades de comunicación que van a tener. Esto es, direcciones IP, servicios, protocolos, etc. Esto mismo puede ser reflejado en un documento para que los administradores de los firewalls deban configurar los permisos correspondientes. Aquí dependerá de cada cual, pero importante valorar funcionalidades de los mismos en materia de:

  1. Portal Cautivo.
  2. Validación de reglas según validación de usuarios.
  3. Limitación temporal de permisos.
  4. Perfiles de seguridad concretos según labores a realizar.
  5. Otros.

Ya por último es importante considerar los acuerdos de confidencialidad y muy especialmente de responsabilidad. En cada intervención, por mucho que se planifique y se reduzcan las posibilidades de sufrir un incidente, el riesgo está. Por tanto, conviene acordar si fruto de esa intervención se deriva un error que afecte a la actividad de la instalación, y a su vez, un perjuicio económico a la empresa en cuestión.  ¿Quién las asume?

Una de las acciones que también debe  contemplarse, o deben realizarse, es hacer  un escáner de vulnerabilidades para conocer qué o cuáles pueden estar afectando al equipo de nuestro proveedor. Esto nos va a permitir exigir que antes de llevar a cabo cualquier trabajo deba actualizar los equipos o corregir las desviaciones antes de efectuar la conexión a nuestra red.

En el artículo de hoy hemos hecho una aproximación desde el punto de vista de que exista una VLAN dedicada a empresas externas donde toda comunicación contra otra red debe pasar por un Firewall (NGFW, Next Generation Firewall). Sin embargo, puede ocurrir que esta estrategia no sea efectiva dependiendo de la arquitectura y equipos que componen nuestras redes. Puede haber situaciones que sea necesario que los proveedores deban conectarse físicamente a la red control. Veamos la imagen siguiente:

El PLC tiene por un lado una tarjeta de comunicaciones que conecta con la red 192.168.1.0/24, y luego la propia de su CPU con el 192.168.10.0/24. Según el esquema inicial donde nuestro proveedor lo hace desde el entorno de oficinas debiendo pasar por los firewalls  de “Separación” y por el de “Segmentación”, no podría llegar a las interfaces de la red 192.168.10.0/24 ya que el PLC puede no tener la capacidad de llevar cabo el enrutamiento entre ambas. Sí que podríamos llegar a él por la red 192.168.1.0/24 y a través del software de configuración poder ver el resto de interfaces, pero si lo que queremos es llegar directamente a los sensores o actuadores de la periferia 192.168.10.0/24 que controla, por ejemplo por HTTP, S7, ModbusTCP, FTP, o cualquier otro (sea seguro, o no) seguramente no podamos hacerlo por esa falta de capacidad.

Por tanto, he aquí un problema añadido y es que, ¿Dejamos conectar a ese proveedor su PC y que se efectúen las comunicaciones en Capa 2? ¿Cuáles son los riesgos a los que nos enfrentamos si no tenemos ningún cortafuegos que filtre las comunicaciones? ¿Cómo hacemos frente a estas situaciones?

Bueno pues estas y otras cuestiones trataremos de ir resolviéndolas poco a poco en nuevas entradas.

Un saludo, nos vemos en la siguiente.

Edorta

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 03/08/17.


Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. PRP y HSR: Protocolos redundantes.
  2. Robots y drones en la Industria 4.0.
  3. Hardware Hacking en Sistemas de Control Industrial.
  4. CrashOverride: El malware para SCI ataca de nuevo.
  5. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  6. Asegurando la virtualización de tus sistema de control.
  7. Gestión de credenciales en sistemas de control.
  8. Prevención de intrusos y gestión de eventos para sistemas de control.
  9. Insider, las dos caras del empleado.
  10. Amenazas emergentes en entornos industriales.
  11. Honeypots Industriales.
  12. Gestionar el riesgo de los proveedores como propio.
  13. Seguridad en protocolos industriales – Smart Grid
  14. Criptografía para reforzar la ciberseguridad en entornos industriales.
  15. Características y seguridad en PROFINET.
  16. Analizadores de red en Sistemas de Control.
  17. Seguridad Industrial 2016 en cifras.
  18. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  19. Inventario de activos y gestión de la seguridad SCI.
  20. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  21. Protocolos Industriales: Herramientas de Seguridad.
  22. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  23. Atrapando sombras en la industria.
  24. Cyber Kill Chain en Sistemas de Control Industrial.
  25. DDOS de actualidad: IoT y los DNS de Dyn.
  26. Seguridad en BlueTooth: Fortalezas y debilidades.
  27. ZigBee en el laboratorio.
  28. Thinking in Big (Data) y la seguridad industrial.
  29. Seguridad desde abajo: dispositivos finales a escena.
  30. Familia de malware en la industria.
  31. Protegiéndose de BlackEnergy: Detectando anomalías.
  32. Seguridad en Comunicaciones ZigBee.
  33. BlackEnergy y los Sistemas Críticos.
  34. Desmontando Modbus.
  35. Safety y security: juntos pero no revueltos.
  36. BMS: Edificios inteligentes, ¿y seguros?
  37. Seguridad industrial 2015 en cifras.
  38. Un SCADA en la ciudad.
  39. Aplicando seguridad en WirelessHart.
  40. Sistemas de control de software libre.
  41. Arquitecturas de seguridad en la nube para la industria.
  42. Las aplicaciones de control se hacen mayores.
  43. Mi SCADA en las nubes.
  44. Evolucionando la comunicación en la industria.
  45. La Ciberseguridad en la Industria 4.0.
  46. Divide y vencerás: Segmentación al rescate.
  47. Monitorización de amenazas en SCADA.
  48. Evolucionando la infraestructura de red en SCI.
  49. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  50. El consumo eléctrico bajo control.
  51. Buenas prácticas de configuración en la red inteligente.
  52. Disciplina militar en Control Industrial: OPSEC.
  53. Auditorias en sistemas de control.
  54. Amenazas en los Sistemas de Control Industrial.
  55. Certificaciones de seguridad en sistemas de control.
  56. La evolución de los dispositivos en los sistemas de control industrial.
  57. Estándares de ciberseguridad en las redes inteligentes.
  58. BYOD en entornos industriales.
  59. IEC 62443: Evolución de la ISA 99.
  60. La seguridad de los coches inteligentes a examen.
  61. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  62. Herramientas TI que evolucionan para TO.
  63. La evolución del software en los sistemas de control industrial.
  64. Diferencias entre TI y TO.
  65. Normativas de seguridad en sistemas de control.
  66. Identificación de sistemas de control industrial.
  67. Problemática de los antivirus en entornos industriales.
  68. Seguridad en Protocolos de Sistemas de Control Industrial.
  69. Del Air Gap a la Segmentación en ICS.
  70. Guía de seguridad de Sistemas de Control Industrial.
  71. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  72. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  73. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

 

Un breve repaso a definiciones de malware


Como hemos dicho en otras entradas, la proliferación de equipamiento industrial en redes basadas en tecnología Ethernet ha ido en aumento al igual que el grado de exposición frente a actividades maliciosas. Tal es el caso del malware algo que, si bien ya estábamos acostumbrados en entornos IT, su presencia en entornos industriales no sólo está haciéndose mayor sino que su desarrollo está siendo dirigido hacia este tipo de dispositivos. Además, cobra especial importancia cuando los equipos con Sistemas Operativos Windows no sólo no están parcheados sino que además no cuentan con herramientas protección. Aquí podemos entrar en un debate donde encontraremos detractores y defensores sobre la seguridad que ofrecen este tipo de productos, los anitvirus. En cualquier caso convendría realizarse algunas preguntas y que para nada son todas las que podrían ser.

  1. ¿Ofrecen los antivirus del mercado firmas para malware dirigido a Sistemas de Control Industrial?

IRONGATE

  1. Considerando el ciclo de vida mayor de los equipos en comparación con entornos IT, ¿Ofrecen soporte a Sistemas Operativos como Windows 2000 y XP presentes aún en entornos OT?
  1. Todo equipo tiene una parte software y otra hardware. Teniendo en cuenta que estos Sistemas Operativos poseen recursos como CPU, memoria, etc. mucho menor de lo actual. ¿qué impacto tiene la carga computacional cuando se lleva a cabo un análisis de equipo?
  1. Según lo anterior, ¿podrían verse afectadas en un momento dado las aplicaciones que interactúan con los equipos de campo y que cuyo funcionamiento debe garantizarse?
  1. A diferencia de entornos de oficinas donde, como norma general, diariamente existe una ventana de tiempo para poder llevar cabo ciertas acciones, ¿qué ocurre en los casos de 24 X 7 X 365?

Crashoverride portada

Cuestiones aparte, lo que si es cierto es que muchas veces los técnicos, ingenieros de procesos o de mantenimiento, que interactúan en última instancia con el equipamiento potencialmente infectable, no sólo no son conscientes de los riesgos sino además de las diferencias que existen entre los tipos demalware. Por tanto, si una entidad emite una información sobre tal o cual campaña o bien se emite un boletín con las características del “bicho” es más que probable que estas personas entiendan poco, o nada, de todo cuanto ahí se documenta. ¿Porqué? Porque hasta ahora no había esa necesidad. Estos profesionales deben de saber de automatismos, sensores, actuadores, relés, motores, neumática, hidráulica, robots, etc. etc. La ciberseguridad no era una prioridad, hasta ahora. Por tanto, al hablar de Troyanos, Rootkits, Gusanos, o cualquier otro, estamos hablando de algo que pueden no saber interpretar, ni en su particularidad ni en su contexto pero que afecta a los equipos que sí son de su responsabilidad.

Así pues, veía necesario hacer un pequeño resumen de los principales tipos para hacernos una idea de una manera sencilla y sin entrar en muchos detalles, de lo que dicha documentación trata de contarnos. Vamos pues.

Droppers

Es software que permite la instalación de malware sobre un objetivo determinado. Esta acción puede hacerse bien en una sola fase, por ejemplo, el malware viene embebido dentro de un fichero; o bien en dos fases. Esto es, el “dropper” descarga una pieza de software desde un servidor y a continuación se produce la infección.

Rootkits

Estas “herramientas” tratarán de encubrir procesos o servicios que están llevando algún tipo de actividad maliciosa, como puede ser permitir acceso remoto a un atacante. Esto se puede conseguir ofreciendo información falsa sobre las tareas que se están ejecutando y pretender hacer ver que todo está correcto cuando en realidad el equipo está comprometido.

Adware y Spyware

El “Adware” se trata de software publicitario que genelaralmente se presenta en los navegadores web como añadidos con una funcionalidad concreta siendo muy comunes en aplicaciones gratuitas. En algunas ocasiones pueden contener algún tipo de software tipo “Spyware” con el fin de recolectar cierto tipo de información del usuario o del equipo sobre el cual se instala.

Gusanos

La función principal de los gusanos es la de replicarse a sí mismo y conseguir extenderse. Las dos vías más comunes es hacerlo por la red o bien por otro medio como las memorias USB. Pueden operar de forma independiente, aunque a menudo son usados conjuntamente con algún otro módulo. Por ejemplo, el gusano se propaga y dicho módulo infecta al equipo vulnerable. Un ejemplo lo tenemos con el malware Wannacry que tanto oímos hablar no hace mucho tiempo.

Troyanos

Se trata de malware cuyo principal propósito es dar acceso remoto a un sistema para actuar en él en un momento dado. Aparte de abrir una puerta trasera, podrán  incorporar otras funcionalidades como captura de pulsaciones de teclas para posteriormente enviarlos a un host remoto, o incluso un rootkit para pasar desapercibido.

Ransomware

¿Qué se puede decir de este tipo de malware con todo lo que ha acontecido con “Wannacry”?  En cualquiera de los casos debemos de decir que el objetivo de este tipo de malware es impedir el acceso a ficheros y solicitar un rescate para permitir su acceso de nuevo. La principal vía es el cifrado de los mismos, y posterior aviso de que la operación se ha llevado a cabo. Una vez efectuado el pago, el atacante envía la clave para proceder a su descifrado y así recuperar la información.

wannacry_05-1024x774

Hasta qui he querido dar una definición muy muy breve de los principales tipos de malware y que a menudo podremos encontrar en aquellos informes que puedan aparecer relativos a incidentes en entornos industriales. La entrada de hoy puede parecer muy “light” para aquellos que provengan del mundo IT, pero en este caso ha he pretendido dirigirla a personas relacionadas más con las Tecnologías de Operación que, generalmente, no están relacionadas con este tipo de términos.

Dicho lo cual, hasta aquí la entrada de hoy que, aunque descafeinada para algunos, espero sea el punto de partida para otros, que seguro deberán familiarizarse cada vez más con estos u otros tecnicismos.

Un saludo, ¡nos vemos en la siguiente!

Edorta.

 

Evaluando riesgos en entornos industriales.


A menudo oigo en los distintos congresos y personas con las que hablo la manera en la que se abordan las distintas estrategias, aproximaciones y formas con las que securizar instalaciones industriales. Se habla de separar entornos, filtrar tráfico, bastionar, estrategia de Defensa en Profundidad y otros tantos conceptos, pasando por alto el primero de todos ellos. El punto de partida, la base sobre la cual vendrán todas aquellas soluciones técnicas, de infraestructura y operacionales. Esto es: el Análisis de Riesgos o Risk Assesment en la lengua de Shakespeare.

Todos sabemos que la seguridad al 100% no existe y lo que se ha de perseguir es la reducción del riesgo de sufrir un incidente que ponga en peligro la disponibilidad de nuestras instalaciones. Y también, como no, las respectivas consecuencias que puede llegar a tener.

Así pues, podríamos hablar de:

Riesgos inaceptables, aquellos que superan un determinado límite o puedan provocar un efecto significativamente negativo en la empresa.

Riesgos aceptables, son aquellos que pueden ser asumidos o que no requieran de una inversión  de tiempo o medios adicionales para seguir reduciéndolo.

Riesgos latentes, aquellos que no son susceptibles de reducir ya que no existe una forma para alcanzarlo.

Con ellos definidos, podremos plantear alguna de las siguientes estrategias para hacerles frente y avanzar en el desarrollo de la evaluación.

Reconocimiento y aceptación del riesgo, se identifica y se asume el riesgo que por una causa u otra no debamos, o podamos, seguir reduciéndolo.

Reducción de riesgos, se emplean medidas específicas para limitar la probabilidad de que se produzcan incidentes y/o las consecuencias puedan resultar admisibles.

Transferencia del riesgo, el riesgo se “traslada” a otra entidad como puede ser el caso de seguros.

Prevención de riesgos, se trata de mitigar las consecuencias de un suceso antes de que se produzcan tratando de impedir o interrumpir su ejecución. También, por haber encontrado una alternativa.

Evaluación del riesgo v1

Así pues, especialmente en la reducción y mitigación, debemos contar con un conjunto de contramedidas que nos ayuden a materializar todo lo que ahora hemos ido dando forma en el papel. A groso modo, las podemos encuadrar en:

Infraestructura, aquellas en las que se basa especialmente en la arquitectura de red como la separación de los entornos IT y OT y la segmentación de este último.

Técnicas, aquellas abordan el resto de acciones sobre distintos aspectos como pueden ser el Control de Accesos, Antivirus, Cifrado, bastionado, etc.

Operativas, todas las anteriores requieren de personas y métodos de trabajo que  las mantengan y regulen. Resulta necesario establecer Roles y Procesos para asignar responsabilidades y procedimientos sobre los cuales trabajar.

Como norma general los riesgos van cambiando con el paso del tiempo. Lo que hoy presenta unos niveles aceptables, mañana con la aparición de nuevas vulnerabilidades deja de serlo. Por tanto, se requiere que estos procesos deban ser revisados con el fin de actualizarlos y adaptarlos a las nuevas circunstancias.

risk-icon-copy2

Una de las principales dificultades a las que nos encontraremos será cuantificar un riesgo, tanto a nivel individual sino también encuadrado dentro de la actividad de la empresa. Debemos hablar desde un punto de vistico holístico de la seguridad y no como algo de activos concretos o aislados. Esto incluye también a un concepto de seguridad que muchas veces pasa por alto. Hasta ahora nos referimos a seguridad de la información, esto es “Security”. Sin embargo, existe otro clave como es el de la seguridad de personas, esto es, “Safety. Este último también debe ser tenido en cuenta aún más si cabe que el primero.

Este enfoque nos proporcionará no sólo una visión más completa sino dimensionar otro de los conceptos clave, la “probabilidad”. La probabilidad de sufrir en mayor o menor medida un incidente y por tanto dirigir, priorizar y ajustar nuestros recursos con el fin de establecer no sólo el orden sobre el cual actuar sino dónde invertir más dinero.

Teniendo en cuenta toda la información a recolectar y analizar, la evaluación de riesgos puede convertirse en una tarea abrumadora ya que son muchos los factores y variables que pueden participar. A esto hay que sumar las diferencias propias de los dos entornos IT y OT, que de un tiempo a esta parte vienen conviviendo más estrechamente. Para ello es necesario “tratar” de hablar el mismo idioma, cosa que resulta complicado ya que los campos de actuación son muy distintos y las disciplinas, aún más. Por ello vamos a resumir los más relevantes:

Amenazas.

Es el elemento que inicia el evento en cuestión el cual puede producir un daño material o inmaterial sobre los componentes de un sistema o conjunto de ellos. Podemos catalogarlas como Intencionadas o no intencionadas según sea el caso. Os dejo dos enlaces donde hace tiempo hablaba de ello:

Objetivo.

Es el elemento que sobre el que recae la amenaza. Erróneamente podemos pensar en activos o componentes electrónicos, nada más lejos de la realidad. Los administradores, ingenieros de proceso también lo son ya que cuentan con una información privilegiada de la organización, de sus procesos, de su actividad, de todo lo que ello conlleva y que mediante Ingeniería Social pueden revelar mucho conocimiento que de otra manera sería más difícil alcanzar.

Vulnerabilidad. 

Es la debilidad que permite a una amenaza alcanzar al objetivo. Aquí os dejo otro enlace de otro post:

Vulnerabilidades en Sistemas de Control Industrial.

Vector de ataque 

Es el medio a través del cual se lleva a acción. Puede ser de los más variado dependiendo de qué lo origine. Nuevamente me remito a uno de mis artículos.

Vectores de ataque sobre Sistemas de Control Industrial.

Incidente

El evento en sí mismo, la consecución de todos los objetivos anteriores. Dependiendo de los elaborado y estudiado que sea, la capacidad de éxito será mayor.

Probabilidad.

Qué tanto por cien de posibilidades hay de que un ataque consiga su propósito. Cuanto más reduzcamos el riesgo, menor será.

Aquí conviene hacer una diferencia entre dos conceptos que a menudo pueden resultar con fusos como son “Consecuencia” e “Impacto”.

Consecuencia.

Es el resultado directo del ataque.

Impacto.

Es el grado en el que el ataque afecta a la actividad de la empresa, tanto en daños humanos, materiales, económicos o incluso ecológicos. A partir de ahí, la recuperación será más o menos compleja según sea éste mayor o menor.

Así pues y poniendo todo en su conjunto podríamos resumir que:

La probabilidad de que una amenaza pueda llevar a cabo un ataque mediante un vector  determinado debido a una potencial vulnerabilidad sobre un activo, tendrá una consecuencia con un impacto sobre la organización. En resumen, cuanto mejor será nuestra evaluación y medición de los riesgos; más eficiente y mejor dimensionadas serán las estrategias para mitigarlos.

Así pues, podríamos resumir dicho proceso en la siguiente imagen:

Proceso de evaluación de riesgos v2

Si bien los pasos indicados se dividen en otras subtareas, es a grandes rasgos,  estos son los aspcetos clave que nos podemos encontrar antes de poner en marcha cualquier proyecto para securizar nuestras instalaciones e infraestructuras. Como hemos dicho, no es un proceso fácil, y bastante tedioso la verdad, pero totalmente necesario no sólo para buscar las medidas más efectivas, sino también dimensionar la inversión económica tanto inicial como de mantenimiento. Todo tiene un costo, al inicio con el despliegue como en manutención en los años venideros.

Hasta aquí la entrada de hoy, menos técnica pero no por ello menos relevante.

Un saludo.

Edorta

Robots, pero no .txt…


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

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

Este vídeo habla por si mismo:

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

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

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

1.- Brazo robótico

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

2.- Controlador:

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

  • Módulos de Potencia

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

  • Módulo de Control

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

3.- Consola Hombre-Máquina:

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

ABB Flexpendat

4.- Programación:

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

Robostudio_01

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

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

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

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

Un saludo!

Edorta

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


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

En ella proponía el siguiente entorno:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¡Un saludo, nos vemos en la siguiente!

Edorta.