CPU Protection, Part I

Anuncios

To alter the normal operation of a system it is necessary to get access. For this reason we have to configure all available features to prevent that unauthorized people or software could carry out any action over them. However, we must not forget that security measures can obstruct the recovery of an equipment if do not define clear processes to get it back if something goes wrong or simply beaks down.

Two years ago, I wrote about some controls over Siemens S7-1200 PLCs. You can access it by clicking here. But today I will talk about other.

One of these features is to configure online control access to PLC CPUs. Not to protect the program and the content stored in it. Why is this important? Because when we connect any device to ethernet networks we are increasing the attack and exposure surface. Accordingly, to that, there are more possibilities to suffer any intentional or unintentional action that could affect to our OT devices.

With this feature we can set up passwords to restrict the access to functions and memory areas. In general, in level 1 hardware configuration can be read and modified by anybody; Level 2, read access do not need any password but if you want to change some parameter you will need to type a password; and finally, Level 3, without a password you cannot modify some several parameters. Obviously in both cases there are conditions and exceptions that you can do. For further information please visit “Virtual Library” and locate the following document named “Security with SIMATIC controllers” in SIEMENS area.

After several years in the Industrial Cybersecurity field, in most cases I have not seen this feature implemented that can be used to hamper unsolicited actions on process controllers. If we do not restrict access to anybody, they could upload the program, modify functions and other parametrizations and download it to the PLC again. After that, who knows what will happen if this occur. Other scenario could be the theft of intellectual property by the third parties that can participate in a project during a commissioning phase.

It does not matter which controller we are using, Siemens, OMRON, B&R, Schneider, or any other. The message is to request, identify or consider if this kind of feature is available and apply it to bring more security, to end devices. Of course, without introducing potential factors that could compromise the normal operation.

We know, there are scenarios where it could be difficult to start up some controls and invest more time to find compensatory measures instead of applying them natively. Obviously, if the device count with it.

In addition to that, keep in mind that a password or any other similar measure, could by cracked, but at least, we have applied one more step to reinforce the Defense in Depth concept that we must implement to protect our industrial environments.

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

To be continued…

Stay tuned!

 

 

Recolectando tráfico con Nozomi Guardian

Anuncios

Aunque en entornos industriales hay, y seguirá, habiendo por mucho tiempo comunicaciones basadas en protocolos serie, existe una clara tendencia hacia el uso de aquéllos basados en Ethernet. Este hecho que, aunque no resulta fácil por el impacto y consumos de recursos de tiempo, dinero y humanos aporta, entre otras, una escalabilidad e interoperabilidad mucho mayor.

Sin embargo, esto tiene su parte negativa ya que la superficie de exposición aumenta exponencialmente. Es por ello que resulta necesario implementar medidas capaces de reducir los riesgos de sufrir un incidente y por ende alterar el normal funcionamiento de la instalación.

Al igual que sucede en las redes de datos tradicionales, también en este tipo de entornos es necesario llevar a cabo una captura de tráfico para realizar un análisis a bajo nivel. Para conseguirlo recurrir a un puerto espejo alguno de los switches o un dispositivo TAP tal y como hablábamos en las dos siguientes entradas.

Puerto espejo, un aliado a veces olvidado

TAP Devices, SIEMENS TAP 104

Luego le llegará la hora de la parte software. Si bien la herramienta estrella es Wireshark la cual cuenta con la capacidad de analizar el contenido de protocolos industriales, también podremos recurrir a otras como Grassmarlin ya en su última versión 3.2.

Sin embargo, existen otras soluciones propietarias que también tiene la capacidad de recolección y análisis. Hace unos meses hablaba en concreto de la del fabricante Nozomi y su producto Guardian.

Monitorización redes industriales, SCADAGuardian

Este producto gracias al desarrollo de nuevas capacidades, mejoras, acuerdos con compañías líderes del sector ha hecho que tenga una gran presencia en el mercado situándose como la de referencia en el mercado.

Una vez desplegada la sonda en el segmento en cuestión, ésta comenzará a analizar y procesar el tráfico recibido para luego opcionalmente recolectarlo para una descarga estudio posterior. Para ello deberemos aplicar un filtro concreto, como puede ser una dirección de origen, destino, protocolo, puerto o cualquier otro paraámetro que pueda ser proporcionado o soportado.

Dicho lo cual, para hacerlo, dentro del menú principal, deberemos de acudir al menú “admin – Other actions”.

Allí deberemos de seleccionar “Continous trace” y acceder al menú correspondiente.

El siguiente punto, tal y como indicábamos anteriormente, habrá  indicar el filtro que queremos aplicar. En nuestro caso será lo relativo con la dirección 192.168.1.XX. Tras seleccionar “Start” comenzará la captura y que veremos en la parte inferior en la imagen siguiente.

A medida que se vaya cumpliendo la condición especificada, Nozomi Guardian irá almacenando el tráfico que más tarde podremos descargar. Para ello deberemos seleccionar el cuarto de los iconos de la parte inferior. Allí aparecerán todos los ficheros generados hasta ese entonces. A partir de aquí,  como decíamos, bien con Wiresahrk o cualquier otra herramienta podremos analizarlo con detalle.

No obstante, también podremos hacerlo son la misma herramienta. Para ello deberemos ir a “Administration – System – Upload PCAPs” tal y como viene indicado en la imagen siguiente:

Allí bastaría con subir la captura y reproducirla presionando en el icono que se indica.

Como podemos comprobar este tipo de herramientas además de informarnos de los activos, comunicaciones, integración con SIEM, informarnos de anomalías, potenciales vulnerabilidades, entre otras muchas más opciones, también nos permite recolectar el tráfico que pueda capturar. Esto resulta de gran importancia y vitalidad ya nos permitirá analizar a bajo nivel los flujos de comunicaciones y detectar anomalías de distinta índole.

 

Un saludo, nos vemos en la siguiente!

Identificando tráfico con cortafuegos, Parte II

Anuncios

Hablábamos en la entrada “Más que IPs y puertos para proteger entornos industriales” la necesidad de identificar los protocolos e instrucciones para limitar aquellas acciones que pueden realizar sobre Sistemas de Control Industrial. Para llevar a cabo esta acción, podemos emplear soluciones como Nozomi SCADAGuardian la cual, entre otras funciones, permite realizar Deep Packet Inspection (DPI) y extraer la información que necesitamos.

Sin embargo, los  mismos cortafuegos que nos ayudan a “Separar y Segmentar” podrán ayudarnos en esta tarea. En “Identificando tráfico con cortafuegos, Parte I” veíamos como podríamos hacerlo con equipamiento del fabricante Fortinet. En el día de hoy abordaremos la misma tarea, pero con aquellos del fabricante Palo Alto.

El mismo, dispone del equipo PA-220R para proteger este tipo de entornos teniendo la capacidad para realizar DPI sobre protocolos de esta índole. Además, es apto para instalaciones de entornos tales como subestaciones o plantas generadoras de energía ya que dispone de compatibilidad con estándares como IEC 61850-3 e IEEE 1613. Sus características físicas le permiten operar en rangos de temperatura y humedad de -40-70º C y 10-90%; respectivamente, pudiendo evitar daños físicos en entornos hostiles y polvo en suspensión ya que carece de piezas móviles para su refrigeración. Igualmente dispone de doble alimentación proporcionando así redundancia en lo que suministro eléctrico se refiere.

Dicho lo cual, veremos que las interfaces pueden ser configuradas de distintos modos, entre ellas el “TAP” con el que podremos monitorizar y analizar el tráfico que le llega.

Más tarde, definiremos una “Zona” en la cual incluir la interfaz que recibirá el tráfico que replicaremos desde el puerto espejo del switch o un dispositivo TAP. La denominaremos “Analisis_Trafico_ICS” y le asignaremos la interfaz “ethernet1/8”.

Luego, habrá que crear una política en la que deberemos indicar como origen y destino la Zona configurada en los puntos anteriores e indicar qué aplicaciones queremos detectar.  En nuestro caso seleccionaremos “Any” para poder hacerlo sobre todas aquellas que recojan las firmas que hayan sido desarrolladas hasta el momento.

Adicionalmente podremos habilitar otros controles para la detección de amenazas tales como antivirus, vulnerabilidades, filtrado URL, etc. Esto nos permitirá identificar la presencia de actividades o tráfico malicioso ya presente en nuestra red. Como se puede apreciar hemos creado un “Security Profile Group” con alguno de ellos.

Hecho esto, el siguiente paso será comenzar a procesar tráfico. De igual modo que hicimos en la entrada “Identificando tráfico con cortafuegos, Parte I”, reproduciremos tráfico con la herramienta TCPReplay previamente capturado a partir de distintas fuentes. En este nos hemos decantado por IEC 60870-5-104 y BACnet.

A partir de aquí, en la pestaña “Monitor” podremos ver los logs generados según distintos resultados de ese análisis. Por ejemplo, continuación se muestra el contenido relativo al tráfico en sí mismo, esto es, IPs de origen destino, puertos, Aplicación, etc.

Pero como hemos dicho, también nos interesa analizar en busca de amenazas como intentos de intrusión, malware, etc. Esta información la localizamos en el subapartado “Threat”. En este caso vemos cómo de entre las capturas reproducidas identificamos la presencia del archiconocido “Wannacry”, algunas anomalías relativas a Siemens S7 o DNP3.

Con la interoperabilidad entre entornos IT y OT, es imprescindible conocer las comunicaciones que se realizan hacia/desde los equipos. Un activo no sólo se compone de los datos de fabricante, modelo, instalación, etc. también han de incluirse sus comunicaciones dentro del modelo de gestión de activos. Un firewall y sus funcionalidades extras serán tan eficientes como estrictos seamos con su configuración y mantenimiento.

Pero, para conseguirlo, hemos hacer la tarea previa de identificarlas y estructurarlas y para ello los mismos cortafuegos también pueden ayudarnos.

Un saludo, ¡nos vemos en la siguiente!