KICS for Nodes, Parte V

Poniendo un ejemplo práctico, en el equipo donde hemos realizado el inventario tenemos un ejecutable de “Anydesk”, aparte de SIEMENS TIA Portal v13, Schneider Electric. Este software es común emplearlo para posibles asistencias remotas tal y como sucede con otros como Teamviewer.

En este caso, hemos denegado explícitamente su ejecución por lo que una vez aplicada la política en modo “Active”, podremos ver cómo no podremos utilizarla.

Si en ese entonces queremos utilizar «Anydesk» el comportamiento en el equipo final sería el siguiente. No se ejecuta sino que además nos indica un mensaje.

Y se generaría un registro en la consola de KSC.

En cambio, si lo hubiéramos en configurado el modo de operación en “Statistics Only” sí que podríamos pero hubiéramos generado un log al respecto.

Pero en el supuesto que alguien quisiera instalar nuevo software como por ejemplo Mitsubishi GX Works3, KICS for Nodes tampoco permitiría hacerlo, generándose el siguiente mensaje y registro en la consola de KSC, Kaspersky Security Center.

No obstante, sobre aquellos logs generados la herramienta nos da la posibilidad de poderlo incorporar a la “Whitelist”, exportando el contenido del mismo en un fichero de texto, .txt.

Esto es especialmente útil si lo que queremos es crear desde cero una política, es decir, sin crear el inventario del que hablábamos en «KICS for Nodes IV».

En ese caso podremos identificar dónde se almacena la aplicación y denegarlo expresamente. Sin embargo, esto puede no ser efectivo. En este caso «AnyDesk» está ubicado en el escritorio pero si copio en otra carpeta como «Mis Documentos» podría ejecutarlo ya que la ruta es diferente.

Para ello deberemos ir a la configuración de reglas y seleccionar importar un fichero a partir de los logs.

Y seleccionar el fichero que previamente hemos exportados desde KSC, Kaspersky Security Center.

Sin embargo el criterio ahora no es tanto la ruta sino la información contenida en el certificado con el que se ha firmado el software.

Por lo que independientemente  de dónde esté el ejecutable de «Anydesk» éste no se podrá ejecutar.

Así pues, esta es la forma en la que trabaja una solución de protección de PCs industriales basado en estrategia de Whitelisting. El concepto es sencillo, listo lo que tengo en PC y luego permito aquello que considero necesario. Además algunas soluciones permiten complementar esta funcionalidad con otras. como antivirus, Firewall, etc. En el caso de KICS for Nodes podéis encontrar la descripción aqui. Esto dependerá del producto elegido.

Cabe mencionar que cuanto más granularidad o a más bajo nivel queramos llegar, más labor de gestión deberemos llevar a cabo. Hay que buscar un equilibrio…

Espero que os haya sido de utilidad, nos vemos en la siguiente!

Un saludo!

KICS for Nodes, Parte IV

En la entrada “KICS for Nodes Part III” hablábamos de la necesidad de analizar equipos PC antes de empezar a configurar la funcionalidad de “Whitelisting” para ejecutar sólo aquellas aplicaciones que esté estrictamente autorizado o necesarias para su uso. Y por supuesto no incluir aquellas que pudieran ser o estar relacionadas con código malicioso.

En muchos casos estos PCs con distintas funcionalidades (sistemas de visión artificial, workstations, puestos de operador, etc.) pueden no ser incluso de propietario, sino que lo sean de una ingeniería o integrador que haya realizado el desarrollo. Y en la mayoría de las veces, se desconoce mínimamente todo lo que alberga.

El primer paso será realizar un inventario del software que existe actualmente en el equipo a partir del cual podremos autorizar, o no, su uso. Para ello crearemos una tarea, al igual que hicimos para realizar un análisis en busca de código malicioso.

Como podemos comprobar no sólo podremos listar los ficheros .exe, sino además otros como DLLs, MSI y scripts. La herramienta permitirá además definir el ámbito de análisis, es decir, la ruta en la cual se realizará la búsqueda. En nuestro caso hemos seleccionado que la búsqueda se realice sobre la unidad C:\ En caso de tener otras particiones deberíamos indicarlas.

La tarea generará un fichero .xml con el listado de software identificado y lo almacenará en la ruta que le indiquemos, en nuestro caso “C:\SW_Inventory_W7x64.xml” en la unidad C:\ en el equipo final.

Luego, ese fichero habrá que importarlo a la política de Whitelisting de KICS for Nodes para más tarde decidir si el software listado en él lo permitimos ejecutar, o no. Para esto último se podrá establecer qué se va a tener en cuenta para poder ejecutar ese software o utilizar el fichero. En el caso de que los ficheros posean un certificado, podrá emplearse éste así como su información contenida en él. También podrá generarse una Hash a través de un algoritmo como SHA256 o simplemente la ruta donde está ubicado el fichero.

 

Con el inventario en formato .xml; luego deberemos importarlo en la política de KICS for notes y según lo que definamos aplicarse sobre el equipo final.  Para ello deberemos ir a la “Properties – Local activity control – Applications launch Control – Settings”

Una vez allí accederemos a “Rules Managing – Rule list”. Inicialmente podremos tener alguna regla que venga por defecto como pueden ser aquellos del sistema operativo.

Para añadir el fichero .xml pincharemos enb “Add – Import rules from XML file” alguna de las opciones que nos marca. Esto es fusionarse, añadirlas o reemplazar a las ya existentes.

Puesto que inicialmente teníamos 2 reglas, tras la incorporación del fichero tenemos un total de 13493.

Esto es así ya que hemos inventariado todas posibles tipos de ficheros. Si sólo hubiéramos listado los .exe se quedaría en 1725.

Si seleccionamos una de ellas podemos identificar lo comentado anteriormente como los criterios para identificar el fichero y permitir o denegar su ejecución, entre otras opciones.

Cabe mencionar un aspecto importante y es la manera de operar. Para ello tendremos “Statistics only” o “Active”. La primera de ellas no aplicará las restricciones que indiquemos en las reglas.

Es decir, aunque indiquemos explícitamente que una aplicación no puede ejecutarse, podrá hacerlo pero KICS for Nodes generará un log en su lugar. Todas las aplicaciones podrán utilizarse. Este modo es útil en el momento de despliegue o cuando no tengamos la certeza de si debemos permitir algo o no.

En modo “Active” aplicará lo indicado en las reglas. Aquí sí denegará su ejecución e igualmente generará un log.

Poniendo un ejemplo práctico, en el equipo donde hemos realizado el inventario tenemos un ejecutable de “Anydesk”, aparte de SIEMENS TIA Portal v13, Schneider Electric. Este software es común emplearlo para posibles asistencias remotas tal y como sucede con otros como Teamviewer.

En este caso, hemos denegado explícitamente su ejecución por lo que una vez aplicada la política en modo “Active”, podremos ver cómo no podremos utilizarla.

Hasta aquí la entrada de hoy. Próximamente veremos un caso práctico sobre su funcionamiento y de cómo el criterio que permite la ejecución, o no de la aplicación es determinante.

Nos vemos!

Un saludo!

KICS for Nodes, Parte III

Following with “Whitelisting” topic for protecting industrial computers, today we will talk about the step before its configuration, and how to protect our systems with Kaspersky´s KICS for Nodes solution.

Once we have deployed KICS for Nodes modules, the next step is to make an inventory of the software installed on these computers to permit or deny its execution. As mentioned in the post named “KICS for Nodes, Parte II” before that, we have to proceed with an antivirus scan to be sure that the target host is not infected by any piece of malware. If this occurs and it is under a running process, it could be authorized in the whitelist.

For this reason, we will set up a task to scan the system before creating a Whitelist. However, this step must be done keeping in mind that we can impact negatively on the host´s performance when the antimalware software starts to analyze the system. And, of course the tasks related with the process under control.

First of all, we will select the task called “On demand Scan”.

Then you must specify which areas will be analyzed and apply security level. Keep in mind that a deeper inspection will consume more hardware and system resources and take more time.

By default, there are a set of predefined profiles that includes more or less actions during the scan.

Nevertheless, it is possible to make a customized profiles by defining a lot of parameters according your preferences. You will find it in the “General”, “Actions” and “Performance” tabs and in all subset parameters, as you can see in pictures below. It includes what to do if a piece of malware is detected, objects to scan, extensions, and so on.

Here I will point out the “Excluded Files” option. The first analysis that it is recommended, is to scan the hard disc drives as much as possible to find a malware. But once we do it, a re scan of some folders which have a large number of files, could not be needed. For example, SIEMENS TIA Portal software suite that can occupy several gigabytes in the installed modules. If we do it and reduce the time scan, we must assume that if there is a piece of malware in that folder it will not be detected.

Finally we will enable or disable the heuristic module and if it is activated how must, it will works to find code that is not in the antivirus database.

When everything is defined the task will be ready to be applied. According to the enabled features, light or deeper analysis, among other configurations, will determine the time needed to complete the scan will be short or long.

But it is not this aspect on I want to focus on, at the time. I want to show you how an antivirus scan can impact on system behavior, and the amount of resources that could be consumed. In the picture below you can see a idle PC with SIEMENS TIA portal V13, Schneider Electric, installed. The usage of CPU can vary from 1 to 10 percent or even 0 percent when I took the screenshot. The memory has a baseline around 2 GB.

But what happens when the scan starts? The CPU usage increases to 96 percent.

After several seconds we can see that the memory increases and the CPU consumption can vary but is constantly high around 80-90 percent.

This is very important to notice because if we run an antivirus scan, we could impact negatively on system´s resources and in consequence the tasks associated to the industrial process.

This is one reason about why we must be aware how to run some tasks on systems, and why is important to schedule them or configure them with other features.

As we know some facilities and industries work 24x7x365 and do not stop their activities unless is necessary for production, preventive maintenance or other mandatory tasks. For these reasons sometimes will not have a time window to run an Antivirus scan, so we could be forced to run it without impacting on the performance during operation hours.

If this occurs, we are able to check “Perform task in background mode” in the task options. Doing this, we will modify and reduce the task priority in the operating system.

For a better understanding, following the complete description of this feature that you can find in the KICS for Nodes Administrator´s Guide

The check box modifies the priority of the task. 

If the check box is selected, the task priority in the operating system is reduced. The operating system provides resources for performing the task based on the CPU load and protected device file system load from other Kaspersky Industrial CyberSecurity for Nodes tasks and other applications. As a result, task performance will decrease during periods of increased loads and will increase at lower loads. 

If the check box is cleared, the task will start and run with the same priority as the other Kaspersky Industrial CyberSecurity for Nodes tasks and other applications. In this case, the task performance increases. 

The check box is cleared by default.

That’s all for now, stay tuned for the next one.

See you!