Medidas nativas de seguridad en SCI, Siemens S7-1200

Uno de los principales focos dentro de un proyecto para reducir los riesgos en un entorno de control y automatización, son los equipos basados en arquitectura PC. Éstos por sus características y, condiciones, presentan deficiencias en materia de seguridad. Bien porque resulta muy complejo o no se pueden implementar las medidas que las corrigen. Esto se agrava ya que desde ellos se actúa sobre equipos de campo pudiéndose  alterar parámetros, conseguir accesos no autorizados, según marcas y modelos. Sin embargo, los distintos fabricantes de sistemas de control y automatización han ido desarrollando distintas medidas que minimizan, o impiden, que una acción malintencionada o accidental tenga éxito. Hoy hablaremos de algunas que nos podemos encontraren el autómata S7-1200 del fabricante SIEMENS.

Como he comentado en anteriores entradas, la estrategia recomendada para reducir los riesgos en nuestros entornos industriales es la Defensa en Profundidad. La misma, nos proporciona la capacidad de establecer distintos niveles de protección que dificulten el avance de todo aquello que pueda afectar a la disponibilidad del proceso.

Cuando hablamos de proteger el equipo final, mayoritariamente se habla de los equipos basados en arquitectura PC (HMI, Workstations, ertc.) que controlan los equipos de instrumentación y control. Éstos debido a que en muchas ocasiones, poseen sistemas operativos fuera de soporte; aplicaciones con desarrollo específico que dificulta o imposibilita la aplicación de parches; pérdida de soporte en caso de manipulación; elevado coste de migración a plataformas más actuales; entre otras muchas razones, los convierte en objetivo para realizar alguna acción concreta.

Por tanto, es sobre ellos en los que recae la mayoría de las medidas a tomar tales como el bastionado basado en “Whitelisting” de aplicación; control de dispositivos USB; Anitvirus; control de acceso; etc.

Sin embargo, también debemos destacar la labor de los fabricantes de control y automatización cara implementar medidas de seguridad sobre este tipo de dispositivos y que resulta crucial cara a alcanzar una protección lo más completa posible a todos los niveles.

Hoy voy a hablar de algunas que acompañan al PLC del fabricante SIEMENS en su modelo S7-1200.

Por ejemplo, el mismo tiene una interfaz web, la cual viene deshabilitada por defecto, y que podremos habilitar desde según necesidades.

Si deseamos el acceso por este medio podremos hacerlo mediante “HTTPS” en lugar de la tradicional “HTTP” evitando así el envío de credenciales en claro.

Configuración interfaz Web HTTPS PLC Siemens S7-1200

Otra de las capacidades que podremos tener es la definición de usuarios y permisos. De esta manera podremos indicar qué podrá ser visible, o no, a partir de las credenciales de acceso. No todo el personal tiene porqué estar al mismo nivel de información de la red de control. No es lo mismo la responsabilidad de un Operador cara para verificar si un PLC está funcionando; a un Técnico de Mantenimiento que debe además de comprobar otros indicadores, realizar cambios sobre él. Dichos permisos pueden ser seleccionados desde la columna “Nivel de Acceso” de la imagen siguiente.

Definición de usuarios PLC Siemens S7-1200

Y a su vez desde las opciones desde el siguiente menú.

Definición de permisos de usuarios PLC Siemens S7-1200

A partir de aquí, si accedemos a la interfaz sin haber introducido ningún tipo de credencial obtendremos la imagen siguiente.

Interfaz Web PLC Siemens S7-1200

Sin embargo, si en la esquina superior izquierda introducimos el usuario/contraseña de “admin”, la apariencia será bien distinta.

Interfaz Web PLC Siemens S7-1200

Como podemos comprobar de manera inmediata, con “admin” podemos parar la CPU, prueba de encendido de leds, estado de variables entre otras, que podremos encontrar en el menú de la parte izquierda.

No obstante, además del acceso web, también podremos definir el tipo de acceso al PLC tanto para lectura como por escritura, incluso considerando el tipo de equipo como un HMI.

Control de acceso PLC Siemens S7-1200

Otra de las funcionalidades a es la protección del Know-How. SIEMENS dirige esta capa de protección cara a salvaguardar la propiedad intelectual y acceso de los bloques que componen un programa protegiéndolos de modificaciones o copia.

A continuación, se muestra una imagen de la creación de un bloque con nombre “TEST_KNOW-How”.

Creación de bloque en PLC Siemens S7-1200

Luego mediante “botón derecho” podemos acceder a dicha protección. Con la primera de ellas protegeríamos el contenido de dicho bloque mediante la aplicación de un algoritmo que impide su visualización. Con la protección contra escritura, poder visualizarlo, en cambio si deseásemos realizar cualquier cambio, requeriría de una contraseña como en el caso anterior.

Protección de Know How, cambios y copia en PLC Siemens S7-1200

Ventana de asignación de contraseñas.

Definición de contraseñas PLC Siemens S7-1200

Finalmente, la tercera medida, evitaría la copia de este bloque pudiendo asociarlo al número de serie de la “Memory Card” o al de la “CPU” evitando así que pueda ser válido en otro equipo o medio de almacenamiento.

Control contra copia PLC Siemens S7-1200

Cuando se aborda las medidas de seguridad a implementar cara a proteger un entorno de control y automatización, se habla principalmente de medidas tanto a nivel de red como de equipos basados en arquitectura PC. Sin embargo, debemos de considerar que los equipos de control también disponen de algunas, que como es lógico no encontraremos en los modelos más viejos por no haber sido una necesidad.

También es cierto que, como todo, hay que buscar un equilibrio. Con cada medida estamos introduciendo una barrera, tanto para lo malo como para lo bueno. Quiero decir, que si la premisa es garantizar la disponibilidad debemos ser capaces de recuperarnos en el menor tiempo posible, por lo que es necesario definir claramente un proceso tanto de gestión de contraseñas como de procedimientos en los que éstas intervengan. Si no lo hacemos, podemos encontrarnos con no saber qué credenciales introducir llegado el momento.

Espero haya sido de vuestro agrado.

Un saludo!

Edorta

Control de USBs en entornos OT

Una de las medidas que debe estar presente cara al bastionado de nuestros sistemas, como no podía ser de otra manera, es el control de dispositivos USB. Si bien, en general, su uso hay que regularlo, en entornos industriales o Infraestructuras Críticas los riesgos son mayores. Como ya hemos comentado en otras ocasiones, los ciclos de vida, de equipos PC con funciones tipo  HMI, Workstations de Ingeniería, etc. son mayores. Esto les obliga a mantener en la mayoría de los casos Sistemas Operativos fuera de soporte, y exentos de actualizaciones. Además, dependiendo del sector y actividad, el software que interactúa con los distintos elementos de las instalaciones puede haber sido hecho “a medida” del cliente o producto, y cuyo desarrollador garantiza su uso sólo bajo ese entorno, y no en caso de instalar parches o actualizaciones. Que si ya lo del parcheo es difícil de implementar si además tenemos esta condición, pues ya ni os cuento.

En cualquiera de los casos, sin poder instalar parches y sin soporte por parte del fabricante el riesgo al que están expuestos nuestros sistemas es considerablemente alto.

Por tanto, para salvar este escoyo, las alternativas son principalmente son dos. O llevamos a cabo la actualización del sistema a uno superior con la correspondiente inversión de tiempo y dinero; o, utilizamos una solución de tipo “Endpoint” que aparte de limitar su uso nos proporcione otras funcionalidades.

Además, la proliferación de dispositivos que emplean el conector USB ha ido en aumento. Ya no es el clásico “pen drive” que puede contener un malware o un software portable. Ya desde hace tiempo tenemos otros muchos como Smartphones, reproductores de música, “USBHacks”, son desde los cuales podemos lanzar todo tipo de tareas.

Dentro de los entornos de automatización y control el ejemplo más archiconocido lo tenemos con Stuxnet.

 

Stuxnet_01

Luego en el año 2013 saltaba la noticia que, “al parecer”, se quiso espiar a los miembros de la cumbre del G20 por medio de la entrega gratuita de memorias y cables USB para la carga de dispositivos móviles.

Y para terminar el malware que afectó a una Central Nuclear alemana y de cómo había infectado algunos equipos.

Tomando como ejemplo el equipo con Windows 7 Professional de las entradas:

Whitelisting en SCI (Parte I)

Whitelisting en SCI (Parte II)

Puesto que está aplicada una política de “Whitelisting”, si conectásemos una memoria USB con un software y lo quisiéramos ejecutar, podríamos ver el contenido pero no ejecutar nada ya que dicha política nos lo impide. Esto es, la memoria USB es detectada y se puede acceder pero como los ejecutables en él almacenados no están autorizados en la Lista Blanca, no se pueden utilizar. En cambio si hubiéramos querido abrir un fichero con un software que sí está dado de alta en ellas, podríamos verlo.

SCSP_19

Sin embargo sin esta protección, el ejecutable hubiera sido ejecutado. Por ello resulta necesario llevar una estrategia de control y restricción de su uso. Ahora bien, ¿cómo hacerlo? En este caso he vuelto a utilizar Symantec Embedded Security: Critical System Protection

Deberemos dirigirnos a la política de “Prevention” ya que vamos a limitar una operación. Dentro  de “Advanced Policy Settings” seleccionaremos “Global Policy options”.

SCSP_17

Dentro de ella en “General Settings” buscaremos “Block External Storage Devices” y marcaremos la casilla. Al mismo tiempo podremos seleccionar 3 variantes que pudieran ser de utilidad según entornos.

SCSP_18

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

SCSP_20

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

SCSP_21

SCSP_22

Como hemos visto en las capturas anteriores, este “bloqueo” puede ser configurable en lo que a lectura y escritura se refiere. Aquí hemos visto la manera más drástica, a partir de aquí ya podremos ir autorizando excepciones en caso de ser necesario.

Esta funcionalidad es especialmente interesante no sólo en equipos que controlen instalaciones sino en también en departamentos de soporte o mantenimiento. En ellos suelen existir equipos portátiles (ver aquí y aquí) para configurar, parametrizar o diagnosticar PLCs, Robots, etc. por medio del software correspondiente. A menudo es necesario intercambiar algún tipo de información por medio de estos dispositivos ya que puede no disponerse, o no estar autorizado, el acceso a ciertos recursos de red. Para ello podremos habilitar el bloqueo y llegado el momento deshabilitarlo. No obstante es conveniente disponer de algunos “pen drive” para uso específico y así gestionar esta necesidad de forma controlada.

Lo dicho, cuidado con los dichosos USB que aunque necesario también son el origen de muchos disgustos…

Un saludo!

Whitelisting en SCI (Parte II)

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

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

SCSP_10

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

SCSP_11

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

SCSP_12

Tendríamos el siguiente mensaje:

SCSP_13

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

SCSP_14

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

SCSP_15

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

SCSP_16

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

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

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

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

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

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

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

Un saludo nos vemos en la próxima!

Whitelisting en SCI (Parte I)

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

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

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

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

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

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

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

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

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

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

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

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

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

Escenario 01

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

Windows 2012 R2: 192.168.10.254/24

Windows XP: 192.168.10.10/24

Windows 7: 192.168.10.20/24

Windows 2000: 192.168.10.30/24

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

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

SCSP_01

SCSP_01

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

SCSP_02

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

SCSP_23

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

SCSP_05

SCSP_06

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

SCSP_04

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

SCSP_07

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

SCSP_08jpg

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

SCSP_09

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

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

Nos vemos en la siguiente!!

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.