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!

2 pensamientos en “Whitelisting en SCI (Parte II)

  1. Pingback: Control de USBs en SCI | Enredando con redes ...

  2. Pingback: LogicLocker, un Ransomware para ICS | Enredando con redes …

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s