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!

 

 

Protección PCs Industriales

En entornos industriales, como es lógico,  también nos encontramos con equipamiento basado en tecnología PC (x86, x64) con una gran cantidad de usos, como controlar una célula de automatización, estación de programación, interactuar con elementos de periferia, visualización de estados de procesos, entre otros muchos.

Sin embargo, las características son muy distintas si las comparamos con sus similares en entornos de oficinas aún cuando estemos hablando funcionalmente del mismo tipo de equipos.

Una de esas diferencias son el superior ciclo de vida lo que nos expone a tratar con equipos con antigüedad elevada pero plenamente funcionales. Sin embargo, hay que decir que presentan algunas limitaciones. Por ejemplo, el sistema operativo, el cual puede estar sin soporte o sin aplicar muchas (sino todas) las actualizaciones que corrijan errores o vulnerabilidades.

Aparte existen otras importantes. En el caso que un integrador haya desarrollado una instalación, maquinaria, DCS, etc. donde exista un equipo de estas características, el contrato de soporte permitirá cualquier intervención únicamente a la empresa desarrolladora, o fabricante. Con ello se busca impedir que ninguna manipulación pueda afectar al normal funcionamiento de componentes, equipamiento o maquinaria e incumplir acuerdos de rendimiento, disponibilidad u operación. Y como no, entre ellas, la aplicación de las actualizaciones de seguridad que tanto se recomiendan.

Eso en materia de sistema operativo, pero si nos referimos a las aplicaciones o software, podremos encontrarnos con escenarios en los no sólo se empleen los del mismo fabricante que sistemas de control, sino también otros empresas y que han sido desarrolladas “a medida” acorde a las necesidades del cliente. A ello hay que sumar que cada parametrización de ese software bien de control, telemetría o visualización será acorde a cada escenario concreto. Esto es, aunque existan dos compañías llevando a cabo la misma actividad, las representaciones, umbrales, alertas, sistemas de seguridad funcional serán distintas.

Por otra parte, el hardware, por su antigüedad, también presenta limitaciones que nos obliga a trabajar con menores recursos hardware, lo cuales deben estar dedicados a las aplicaciones que controlen el proceso o las funcionalidades asignadas. Es decir, no podemos, aún cuando sea posible, implementar software adicional que pueda impactar negativamente en recursos de CPU, memoria o acceso a disco.

Además de lo anterior, tales despliegues, como norma general no se han hecho teniendo en cuenta la ciberseguridad, con lo que es más que habitual que firewalls a nivel de host estén deshabilitados o con un “Permit, Any, Any”; todos los servicios por defecto, habilitados; ausencia de software de seguridad, etc. etc. etc.

Aunque los sistemas de control no estén expuestos directamente en la red, es posible que estos equipos dispongan de dos tarjetas de red. Una “aguas abajo” para comunicar con los elementos de control; y otra “aguas arriba” para ser accesible con otros sistemas de planta, servidores, mantenimiento, etc.

Según todo lo anterior, a la vista está que las circunstancias que rodean a equipos PC o servidores hacen que los riesgos que permitan a algo o alguien, poder llevar a cabo una acción que repercuta en la operación son elevados. Por ello, debemos presentarles especial atención ya que como hemos visto pueden tener la capacidad de interactuar con otros sistemas o tecnología de control y automatización. Obviamente esto no puede afirmarse con rotundidad ya que dada la heterogeneidad puede haber escenarios que no aplique en su totalidad. En cualquier de los casos es necesario desplegar medidas para su protección.

Cuando hablamos de equipos industriales no sólo podremos referenciarnos a HMI (Human Machine Interfaces), servidores SCADA o Estaciones de ingeniería. Podemos encontrarnos como sistemas de visión artificial; DNCs; CNCs; Thin Clients, Visualización, equipos de operador para la visualización de órdenes de fabricación o recetas,

En este sentido la aproximación es distinta a los entornos IT. Aquí, OT, por ser equipos donde los cambios son menos frecuentes; recursos hardware limitados y reservados a aplicaciones concretas; cualquier funcionalidad no puede penalizar funcionalidades, el recurso más frecuente es el Whitelisting.

Esta estrategia se centra en la definición de una “Lista Blanca” donde incluir aquellas aplicaciones que deben ser empleadas para la funcionalidad del equipo. Todo aquello que no esté incluida en ella, no podrá ser ejecutado; sea código, aplicaciones, etc.

Aquí os dejo un enlace donde podéis encontrar más información en un documento elaborado por el ICS-CERT.

Guidelines for Application Whitelisting in Industrial Environments

Conceptualmente hablando, esto mismo puede ser realizado a nivel de red. Esto es, por medio de los firewall de próxima generación con capacidades de realizar DPI (Deep Packet Inspection) y poder permitir o denegar aplicaciones, software o consignas que se envían por protocolos tales como S7, Modbus, Bacnet, Ethernet/IP, IEC 104, entre otros muchos.

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

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

Hace tiempo atrás hablé de la solución de Symantec Critical System Protection, cuyos artículos puede encontrarlos aquí:

Whitelisting en SCI (Parte I)

Whitelisting en SCI (Parte II)

Sin embargo esta ocasión abordaré este aspecto con la solución del fabricante Kaspersky KICS for Nodes ya que, como toda evolución de producto introduce mejoras. Más aún cuando Kaspersky se ha posicionado como líder en el ámbito de la Ciberseguridad Industrial.

Aquí os dejo un video donde se describen algunas funcionalidades, aunque no son las únicas.

Como podemos comprobar esta solución, tanto para equipos clientes como servidores, se basa en distintas capas de protección. Desde el Whitelisting de aplicaciones, control de dispositivos USB, Firewall a nivel de host, antivirus, entre otros.

Desde el punto de gestión, todos los equipos podrán ser gestionados y administrados desde una consola centralizada, como es Kaspersky Security Center, KSC.

Estas y otras funcionalidades son las que iremos descubriendo y ejemplarizando en futuros artículos sobre distintos casos de uso en entornos industriales.

Nos vemos en la siguiente!

 

CPU Protection, Part II

In addition to my last post where I talked about CPU protection (click here to access), today I will write about how we can detect if protection is enabled on a S7-300. If not, we could connect to the PLC (CPU or communications module), upload the program, and modify it. After this, download it again.

Other actions that could be accomplished are establishing new passwords on FCs, FBs, etc. When a legitimate user would want to access to read or write them, he/she could not do it because would not know the configured password.

S7Scan tool can help us to get this information, CPU Protection. We have to take a look at “Module Protection” section. There, we can see if this is set up. In the figure below, it is not.

Well, what can we do? As I said we could be online and inspect the program, its configuration and upload it.

On the other hand, if “Module Protection” is configured as on the picture below, we will not be able to do it.

A password will be requested in two ways. Firstly, if we want to access to a Block or Function after we are online.

And secondly, if we want to upload the program. See the area where indicates “<introducir contraseña> that means <introduce your password>

This is an example on how these features can help us introducing new controls. Are they all effective as we expect? Well this is another question… During this work I found there is a limitation of eight characters long.

Apart from this, we know that passwords can be cracked by specific software or stored in plain text. Configure a password it is not a silver bullet to protect access. We have to implement other security measures and try to stop an intrusion, deliberate action or similar, before it reaches the objective.

We can not trust the security device by its own features because they could not be as robust as they should be. Industrial components, devices or systems have been designed to be robust, simple, reliable, safe, etc. not secure. Security is relatively new, since attacks have been carried out or vulnerabilities have been discovered and published.

Thanks again, I will see you in the next!

Having said this, I hope you have enjoined this post!

To be continued…

Stay tuned!