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!

Deja un comentario