Controlando nuestros Proveedores, Parte II.

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

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

Control de Proveedores en entornos industriales OT

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

Control de Proveedores en entornos industriales OT

Viendo los logs:

Control de Proveedores en entornos industriales OT

en total fueron 55 detecciones:

Control de Proveedores en entornos industriales OT

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

Control de Proveedores en entornos industriales OT

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

Control de Proveedores en entornos industriales OT

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

Snap7

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

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

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

Control de Proveedores en entornos industriales OT

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

Integración de Fortigate y FortiClientEMS.

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

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

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

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

Edorta

 

Controlando nuestros Proveedores, Parte I.

Hace unos días hablaba acerca de la necesidad de gestionar los proveedores externos e incluirlos en nuestras políticas de seguridad, claro está, orientadas a su actividad. Muy particularmente en grandes corporaciones, éstas se ven obligadas adquirir a terceros equipos, productos y servicios especializados para la actividad de la misma. Luego, cara a garantizar una respuesta o asesoramiento, firman contratos de soporte con el fin de obtener ayuda en caso de ser necesario. Como veíamos en la entrada “Proveedores Externos, posible punto de entrada…” ha de establecerse un procedimiento tanto administrativo como técnico que regule cómo han de conectarse y qué requisitos deben reunir sus equipos antes, durante y después de conectarse a nuestra red de control.

A diferencia del post que citaba anteriormente, hoy hablaré sobre cómo podemos controlar técnicamente dichos equipos. Es un ejemplo, obviamente no dará respuesta a todas las necesidades ni a todas las casuísticas que sin duda serán muy particulares dependiendo de tecnologías, industrias, equipos, actividad, o cualquier otro factor.

El objetivo será llevar a cabo un control sobre el PC de un proveedor que necesariamente ha de conectarse, sí o sí, a nuestra red OT para llevar a cabo tareas de soporte o mantenimiento. Estos PC contendrán el software necesario sin embargo, no tendremos ni su control, ni conocimiento alguno del estado de actualización de sistema operativo, aplicaciones; firmas antivirus (si las hubiera); vulnerabilidades; etc. etc. Habrá quien piense que una alternativa pueda ser instalar las herramientas en PCs de la propia organización sobre los que sí tendríamos aquello que ahora nos falta. No le quito razón, sin embargo, la realidad nos muestra una serie de inconvenientes:

  1. Coste de licenciamiento de Software. ¿Nueva instalación, nueva licencia? ¿reasignación de licencias?
  2. Necesidad de probar aplicaciones en PCs de la organización para garantizar pleno funcionamiento.
  3. Dada el ciclo de vida mayor, probabilidad de uso en Sistemas Operativos con distintas versiones.
  4. Desarrollo de herramientas a medida y bajo condiciones concretas, diferentes a los empleados en la organización.

Por tanto, con todo en contra, lo que sí podríamos hacer es obligar a nuestros proveedores a cumplir nuestras normativas y marcarles las vías de cómo hacerlo. De hecho, es algo que las políticas de seguridad deben contemplar. Me refiero a que una vez implementadas todas las herramientas y medidas, todo nueva sistema, instalación o equipo debe cumplir con aquello especificado para el nuevo “ciberseguro” escenario. Para algo lo hemos hecho, ¿no?

Para ello emplearemos la aplicación endpoint FortiClient de Fortinet con el que podremos identificar y remediar equipos vulnerables, o comprometidos, reduciendo así la superficie de ataque. Luego podremos integrarlo en otras soluciones del mismo fabricante, aspecto que no abordaremos en este post.

Para la Prueba de Concepto he creado el siguiente ejemplo:

Como vemos en la figura, un proveedor ha de conectarse a la red Control para llevar a cabo determinadas tareas. Tiene dedicada una VLAN con un direccionamiento 192.168.254.0/24 a la que deberán conectarse todos los equipos de proveedores. Así pues, todas las comunicaciones deberán pasar por el Firewall (NGFW) que bien podría ser el de Separación o de Segmentación dependiendo de cómo tenga definida la arquitectura la organización. Luego, en función de cómo configuremos el mismo, dejaremos pasar el tráfico necesario hacia la red 192.168.0.0/24, esto es, la de Control.

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

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

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

Allí deberemos especificar algunos parámetros como: la red sobre la que se aplicará, en nuestro caso la 192.168.254.0/24, “LAB_RED PROVEEDORES”; acción en caso de no cumplimiento, “Block – Warning – Auto-update”; el tipo de dispositivo, “ALL”; Versión mínima del software FortiClient, “5.4.1”; comportamiento del motor Antivirus, “Realtime Protection, Up-to-date signatures”; y por último el perfil de Firewall de Aplicación, el que hemos definido anteriormente, “LAB_APP-CONTROL_S7”.

Aquí quizás puede llevarnos a confusión el concepto de Control de Aplicación, pero que en este caso se aplica de dos maneras distintas. Una cosa es el Control de Aplicación que se  ejecuta sobre las aplicaciones del PC y que lo regula en el endpoint FortiClient; y otro distinto el que podemos aplicar sobre el tráfico de red en cada una de las reglas configuradas y definidas dentro de la columna “Security Profiles”.

Si en estos instantes alguien quisiera acceder a algún recursos de la red no podría ya que no cumple con los requisitos. Si por ejemplo abriésemos un navegador y pretenderíamos navegar aparecería el siguiente mensaje:

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

Control de Proveedores en entornos industriales OT

Hasta aquí hemos visto la manera en la que configuramos, de forma resumida, todo lo necesario para comenzar a ejercer el control del que hablábamos. Con todo listo, será en la próxima entrada, cuando comprobemos los resultados y por tanto su eficiencia.

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

Edorta

 

Whitelisting en SCI (Parte II)

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

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

SCSP_10

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

SCSP_11

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

SCSP_12

Tendríamos el siguiente mensaje:

SCSP_13

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

SCSP_14

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

SCSP_15

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

SCSP_16

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

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

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

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

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

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

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

Un saludo nos vemos en la próxima!

Whitelisting en SCI (Parte I)

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

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

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

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

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

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

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

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

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

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

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

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

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

Symantec Critical System Protection

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

Windows 2012 R2: 192.168.10.254/24

Windows XP: 192.168.10.10/24

Windows 7: 192.168.10.20/24

Windows 2000: 192.168.10.30/24

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

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

SCSP_01

SCSP_01

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

SCSP_02

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

SCSP_23

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

SCSP_05

SCSP_06

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

SCSP_04

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

SCSP_07

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

SCSP_08jpg

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

SCSP_09

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

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

Nos vemos en la siguiente!!

Defensa en Profundidad OT

En la entrada anterior escribía sobre el concepto de Defensa en Profundidad en entornos IT (pincha aquí) y lo finalizaba haciendo un par de preguntas sobre si el mismo concepto sería aplicable a entornos OT y si se presentan las mismas necesidades. Así que hoy con esta entrada espero dar respuesta a estas y otras preguntas.

En esencia podemos decir que el concepto de “Defensa en Profundidad” es equiparable a ambos entornos, entendiéndolo como un modelo consistente en implementar una serie de medidas de seguridad con el fin de frenar la actividad de un usuario o software mal intencionado.

Estas medidas irán dirigidas en función de los activos que queramos proteger y que en el caso de IT y OT, son bien distintos. En el caso de entornos IT, lo principal es la información. Debemos evitar el robo, el acceso no autorizado, la pérdida, la confidencialidad, la integridad, etc. Sin embargo en entornos OT, nuestra premisa es garantizar la disponibilidad de nuestras instalaciones. Tendremos que impedir paradas en sistemas de producción, desastres medioambientales, accesos no autorizados a sistemas de control, etc. Desde un punto de vista gráfico sería:

Visio 01

El problema ha ido en aumento a medida que estas instalaciones han quedado expuestas a otras redes y entornos por el uso de buses de campo basados en Ethernet (Profinet, Ethernet/IP, Sercos, ModBus TCP, etc. ) o bien por el uso de tarjetas, o pasarelas, de otros basados por ejemplo en RS-485 (Profibus, DeviceNet, Canbus, etc.).

Otras de las razones, ha sido la necesidad de accesibilidad desde localizaciones remotas por medio de redes inseguras como Internet. Pensemos en RTUs (Remote Terminal Units) que recojan datos y que sean enviados un sistema SCADA para su tratamiento. O bien, que por cuestiones de mantenimiento sea necesario el acceso a un PLC para realizar algún tipo de cambio.

A esto hay que sumar la idea, de que estos dispositivos, autómatas programables, robots, maquinaria, estaciones de control, etc. han sido concebidos para ser útiles, no para ser seguros. Esta necesidad es relativamente reciente. Hasta la aparición de malware específico de este tipo de entornos e intrusiones en sistemas, no ha habido la necesidad ni de invertir ni de implementar medidas a este respecto. Sin embargo de un tiempo a esta parte, debido principalmente a medidas reactivas, no ha quedado más opción. Si bien distintos países han creado legislación para proteger sus Infraestructuras Críticas sobre distintos sectores aún queda un sector industrial que no entra dentro de esta definición pero que sin embargo no está exento de sufrir algún tipo de ataque. Sea como fuera, las redes industriales han ido quedando más visibles, tanto para lo bueno como para lo malo.

Así pues la estrategia para proteger instalaciones industriales implantando un modelo de distintas capas de protección quedaría representado gráficamente de la siguiente manera:

Visio 02

Dentro de este esquema, la organización deberá de seguir un proceso a través del cual se irán abordando distintas cuestiones, las cuales quedan resumidas en los siguientes puntos.

1.- Análisis de riesgos

Sin duda, es el primer paso a tomar. Un análisis de riesgos es el paso más importante cara a la administración de la seguridad tanto si hablamos de las instalaciones como de las máquinas en ella instaladas. Ayuda a la identificación y evaluación de los riesgos y peligros individuales. El contenido principal que todo análisis debe tener es:

  • Identificar los objetos amenazados.
  • Análisis del valor y daño potencial.
  • Análisis de amenazas y puntos débiles.
  • Identificación de medidas de seguridad ya implementadas.
  • Evaluación de riesgos.

2.-Definición de Roles y Procesos

Dentro de cada organización se han de finir una serie de figuras con unos roles en lo referente a la Gestión de la Seguridad. Se han de establecer responsabilidades y sobre todo los criterios bajo los cuales se basen decisiones como la aceptación de riesgos, importancia de eventos, coordinación de actores, evaluación de procesos, etc.

Estas personas han de pertenecer a distintos ámbitos, tanto de IT como de OT, componiendo un equipo donde cada cual aporte su experiencia y conocimiento. Trabajando coordinadamente y conjuntamente se reducirán las posibilidades de tener una brecha de seguridad.

3.-Seguridad de Planta

La seguridad de las instalaciones consiste principalmente en bloquear el acceso a dispositivos e instalaciones a personas no autorizadas. Alguna de estas pueden basarse en llaves físicas, tarjetas inteligentes, dispositivos biométricos, cámaras de seguridad, etc. Igualmente, se deben regular quién, de qué manera y si tiene que acceder, o no a tal o cuál espacio. Y tener los medios para trazar todo ello.

4.- Seguridad de red

Aquí dos conceptos básicos son los de la segmentación y separación de los entornos de Oficinas y Producción. Ambos deberán comunicarse, inicialmente, por medio de un firewall apoyado si es posible por un IDS/IPS. Para un nivel de seguridad efectivo deberíamos hablar de cortafuegos de próxima generación, NGFW.

Luego, en lo que respecta a las redes de “producción” se deberán segmentar en lo que en algunos casos se denomina “celdas”, “áreas de seguridad” y otros similares términos. Podemos entenderlas como unidades operativas e independientemente funcionales. Estas unidades podrán estar compuestas de un mayor o menor número de dispositivos y cada una de ellas tendrán sus propias políticas y equipos de seguridad que las proteja dentro del conjunto de redes de producción.

5.- Seguridad sobre sistemas y dispositivos

Este apartado se centra en la securización de los distintos elementos que se ubican en el área de producción, como pueden ser PLCs, PCs, HMIs, etc.

Entre las medidas a tomar estarían:

  • Control de acceso

El control de acceso debe aplicarse en tres direcciones. Una de ellas es el acceso a las configuraciones de los equipos, ya sean PLCs, estaciones de control, switches industriales gestionados, firewalls, etc. Otro, el “logon” al equipo; aunque sólo se necesite acceso a interfaces de sólo visualización o se desarrollen actividades aparentemente sin importancia. Finalmente, tendríamos el control a nivel de red como seguridad en puerto, control de MACs, sistemas NAC, etc. tanto a redes cableadas como inalámbricas.

  • Bastionado de los equipos.

En cuanto al bastionado de equipos lo podemos dirigir también en tres puntos clave. Por un lado reducir los servicios de red y aplicaciones a los estrictamente necesarios; dos, proteger las interfaces físicas como son los las tarjetas de red, puertos USB o interfaces Bluetooth; y tres las cuentas de usuario limitándose tanto en número como en permisos asociados a ellas. En cuanto a las aplicaciones una medida eficiente es la definición de una “Lista Blanca” donde se definan cuáles se pueden ejecutar y cuáles no. En resumen, lo que se denomina “WhiteListing”.

  • Gestión de Parches

En lo referente a este apartado deberíamos actualizar nuestros equipos, por un lado con las últimas versiones de Firmware, parches emitidos para los sistemas operativos (como norma general Microsoft Windows) y nuevas versiones de aplicaciones que puedan tener algún tipo de “bug” identificado. Cualquier cambio o actualización debe testearse en una primera instancia en un laboratorio o entorno de test antes de llevarse a producción.

  • Protección contra virus.

Este capítulo está dirigido a PCs. El uso de software antivirus supone una medida importante en lo que malware se refiere. Si por algún medio, código malicioso llegase a nuestros sistemas, podría ser eliminado siempre y cuando se encontrase en su base de firmas. Repito, si se encuentra en su base de firmas. Sin embargo puede no llegar a ser una solución eficiente, he aquí un artículo muy interesante.

Visio 03

  • Cifrado en las comunicaciones

Otras de las medidas que deberemos considerar es el cifrado en las comunicaciones. Dependiendo de las características de nuestra organización, podremos o deberemos implementarla. Todo depende qué nivel de confidencialidad o criticidad tendrá la información que viaje y si ésta lo hace a través de redes inseguras. El riesgo de no hacerlo, deberá ser evaluado y en función del resultado del análisis, se asumirá si el riesgo es aceptable, o no.

  • Monitorización

Este es otro de los puntos que ha de abordarse claramente. Deberemos diferenciar entre monitorizar la Disponibilidad y la Seguridad. En entornos industriales hemos de conocer el estado operativo de los equipos y en caso de fallo o anomalía tener el conocimiento de ello para poder remediarlo. Por ejemplo la ejecución de un “ping” puede ser suficiente para que en caso de no respuesta generar una alerta, y notificación. Sin embrago cuando hablamos de monitorización de la seguridad la cosa cambia. En este caso deberemos emplear soluciones de tipo SIEM. Este sistema se encarga de correlar los eventos generados por equipos de red y sistemas con el fin de detectar posibles anomalías referentes al estado de la seguridad. Estas soluciones conllevan una inversión importante con lo que estamos en las mismas circunstancias que en el caso del Cifrado de las Comunicaciones. Deberemos analizar el riesgo que supone su no implementación y si es asumible.

  • Revisión y mejoras

Una vez implementadas y puesto en marcha nuestro plan de seguridad, se han de realizar periódicamente revisiones de todas las medidas adoptadas.

La realización de auditorías internas es una obligación que los responsables han de llevar a cabo para reducir los riesgos ante nuevas amenazas y adoptar las medidas necesarias para mitigarlas. Aparte, se ha de tener en cuenta que las compañías pueden realizar cambios en cuanto a maquinaria, dispositivos y cualquier otro elemento, que deba ser incorporado dentro del plan y sometido a éste.

La seguridad, es un concepto “vivo”. El hecho de minimizar los riesgos a día de hoy no nos exime de ser objeto de un ataque mañana. Continuamente vemos cómo se descubren nuevas vulnerabilidades, se generan nuevos vectores de ataque o de como de se desarrollan nuevo malware para dispositivos de automatización y control industrial.

Como podemos comprobar existen muchas similitudes entre el concepto de “Defensa en Profundidad” entre los entornos IT y OT. En su esencia es el mismo para ambos, pero las medidas a adoptar no son las iguales. Por ejemplo, a un PLC no podremos instalarle ningún agente que nos supervise su comportamiento, algo que sí podremos hacer sobre PCs. Sobre estos últimos también hay que tener en cuenta la retrocompatibilidad de cierto tipo de software con sistemas operativos más antiguos.

Más adelante iremos adentrando más en alguno de estos puntos. Por ahora, tanto si te ha gustado la entrada, como si no, por favor deja un comentario. Te animas?

Un saludo, nos vemos en la siguiente.