KICS for Nodes, Parte I

La presencia de PCs en entornos industriales a la vez que extensa, sus funciones pueden ser muy diversas. Maletas de programación, puestos para el control de maquinaria, puestos de operador, entre otros muchos pueden ser algunos de los ejemplos. Bien por que la seguridad no ha sido un requisito, una necesidad o por las limitaciones que presentan para llevar a cabo intervenciones de cualquier índole a lo largo de su extenso ciclo de vida, lo cierto es que, como norma general, no cuentan con medidas de protección. Esto incluye sistemas operativos obsoletos, sin actualizaciones, falta de soluciones de seguridad, firewall de host des habilitados, usuarios con permisos de administración, etc.

En este sentido la aproximación para su protección es el “Whitelisting”, tema que abordábamos en la siguiente entrada:

Whitelisting en SCI, Parte I

Hoy comenzaremos a hablar del producto “KICS for Nodes” de Kaspersky, que ya introducíamos en “Protección de PCs Industriales”.

KICS for Nodes proporciona una protección robusta en equipos de estas características localizados en entornos industriales para hacer frente al conjunto de amenazas a los que se están y pueden estar expuestos. La solución se compone de un conjunto de componentes que pueden ser habilitados o deshabilitados de forma selectiva. Esto es especialmente importante en aquellos equipos con mayor antigüedad y con recursos hardware limitados o con menores capacidades computacionales.

Como veremos cada instancia de “KICS for Nodes” podrá ser administrada de forma centralizada a través de “KSC, Kaspersky Security Center” desde donde se podrán definir y aplicar las políticas de protección sobre cada uno de los equipos finales.

Además, se podrán consolidar los distintos logs generados de la actividad detectada, tanto autorizada como no autorizada, entre otras funcionalidades adicionales que veremos en sucesivas entradas.

“KICS for Nodes” se compone de:

  1. Application launch control, Restringe la ejecución de ficheros o scripts acorde a lo definido en las listas blancas definidas en políticas.
  1. Device control, control de dispositivos como memorias USB extraíbles.
  1. Anti-malware protection, Inspección de código malicioso, proporcionando actualización y análisis bajo demanda.
  1. Untrusted host blocker, Restringe el acceso a carpetas compartidas desde equipos que muestran una actividad sospechosa.
  1. Anti-cryptor, Previene el cifrado de ficheros por medio de virus de tipo ransomware, trabajando en conjunto con el módulo “Untrusted host Checker”.
  1. Vulnerability scanner, Obtención de información de vulnerabilidades y falta de actualizaciones en los equipos finales.
  1. File integrity monitor, Supervisa la modificación en los ficheros del sistema con el fin de detectar alguna actividad maliciosa.
  1. Log inspection, supervisión de los logs del sistema operativo Windows para detectar cualquier comportamiento anómalo en el sistema.
  1. Exploit prevention, Protección de los procesos en memoria.
  1. PLC Integrity Checker, verificación periódica de la consistencia de la lógica de control en algunos PLCS compatibles cómo SIMATIC S7 300 y 400, y MODICOM M340 y M580.

Adicionalmente también tiene un módulo de Firewall a nivel de host con el que podremos definir qué conexiones se permiten o deniegan hacia/desde los equipos administrados.

En primer lugar, instalaremos la consola de administración central Kaspersky Security Center la cual requerirá donde una base de datos Microsoft SQL Server. En nuestro caso emplearemos la que viene con el paquete de instalación ya que el número de equipos será mucho más pequeño que un despliegue normal. Luego procedemos a introducir las licencias correspondientes según el número adquirido.

El siguiente paso será identificar y dar de alta los equipos. Para ello, KSC, nos permite llevar a cabo un sondeo sobre los rangos de red en los que se encuentres los equipos a gestionar y a partir de las IP que respondan poder llevar a cabo la instalación del software. Por supuesto, también podremos darlo de alta de forma manual.

Para la administración de los equipos desde KSC, se requiere de la instalación de un agente en los equipos finales. A través de él se recibirán y enviarán todas las operaciones necesarias como la aplicación de políticas, actualización de firmas, habilitar o deshabilitar módulos, logs, etc. Antes que de nada deberemos establecer algunos parámetros necesarios como la IP de KSC, puertos a emplear, método de autenticación, cifrado de comunicación, etc. Luego toda la actividad recolectada por “KICS for Nodes” será enviada a través de este agente al servidor de gestión KSC (IP 10.10.101.100).

Para su instalación tendremos dos opciones. Una, hacerlo por red desde la consola de administración de KSC o dos, generar un fichero ejecutable que más tarde llevaremos al equipo en cuestión e instalaremos de forma manual.

En el primero de los casos, instalación online, KSC deberá tener acceso a los recursos compartidos en cada PC como \\HOST\C$ o \\HOST\ADMIN$ así como acceso con permisos de administrador para poder llevar a cabo la instalación. Durante el proceso tendremos varias opciones de configuración como la definición de credenciales, impedir el reinicio en caso de ser necesario, asignación de grupos de gestión de equipos una vez esté instalado, etc.

Con relación a la segunda opción bastará seleccionar la opción de creación de un paquete de instalación “stand alone”, seguir los pasos y proporcionar la información solicitada. Un proceso sencillo.

 

Ese fichero, por defecto se genera en una de las carpetas de KSC a las que deberemos acceder para poder copiarlo y llevarlo al equipo en cuestión.

Elijamos un método u otro, todos los equipos quedarán listados en el apartado “Managed Devices”, salvo que nosotros hayamos dicho lo contrario Y es que, allí podremos crear subcarpetas para una mejor organización según sea nuestro entorno, tipología de equipos, funcionalidad, subredes, etc. Por ejemplo, en mi caso he creado un directorio llamado “KICS TEST LAB” bajo “Managed devices”. Luego dentro de “KICS TEST LAB” he ordenado 4 equipos; “FIELDPF TIA PORTALL v11, W7 x64, W7 x86 y Wxp x86.

Cada agente tendrá una configuración respecto a diversos ámbitos como tiempo de almacenamiento de logs, tiempo de sincronización con KSC, descarga de actualizaciones de firmas antivirus, parches de Windows, entre otras muchas. En nosotros estará personaliza cada una de ellas en función de la naturaleza del equipo o emplear una genérica.

Deberemos de considerar la forma en la que ésta o éstas aplican al árbol de equipos asignados. La solución podría aplicar una política el directorio “Managed devices” y que luego ésta sea heredada por el resto de subcarpetas como “KICS TEST LAB” y los equipos allí ubicados. O bien, que cada cual tenga la suya propia, es decir, que no se hereden.

Definido esto, lo siguiente será llevar a cabo la instalación de “KICS for Nodes”, pero eso lo dejamos para el siguiente artículo.

Hasta pronto!

 

 

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.

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.

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

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

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

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.

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

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.

Ventana de asignación de contraseñas.

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.

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.

 

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.

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

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.

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

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

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!