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

Hace poco más de dos meses hablaba de la necesidad de utilizar NGFW (Next Generation Firewall) para securizar nuestros entornos industriales. En ese ejemplo empleaba Modbus como protocolo y el uso de la funcionalidad IPS (Intrusion Protection System) para frenar posibles ataques. El artículo lo podéis encontrar a continuación:

¿Por qué es necesario NGFW en entornos ICS/SCADA?

Si bien los fabricantes están incorporando características de seguridad en sus productos, la presencia de equipos que no disponen de ellas es, y seguirá siendo, muy amplia. Esto es debido a que el ciclo de vida de los mismos es mayor si lo comparamos contra entornos IT tradicionales. Esto da pie a que exista equipamiento “antiguo”, totalmente funcional, pero con vulnerabilidades susceptibles de ser explotadas. Esto es comprensible ya que en el momento de su diseño, la seguridad no era una necesidad. Sí, la funcionalidad y robustez, algo que se mantiene en la actualidad. A veces es posible corregirlas mediante actualizaciones, pero no siempre es así ya que el hardware puede ser parcial o totalmente incompatible según el modelo en cuestión. Entonces, bien sea porque no es necesario su reemplazo o técnicamente posible su actualización, la securización pasa por elementos o medidas externas. Y como no, los NGFW son una de ellas.

Otras de las funcionalidades que poseen los NGFW es el denominado “Control de Aplicación”. Esta permite identificar el software que circula por la red, interpretar la información contenida en los paquetes mediante “Deep Packet Inspection” y a partir de aquí, permitir, bloquear, monitorizar o poner en cuarentena el mismo. Esto facilita reconocer herramientas en entornos donde, en principio, no debiera darse esas comunicaciones y por tanto alertarnos de que algo anormal está sucediendo o, aún peor, una actividad hostil.

Si bien resulta necesario frenar cualquier actividad no autorizada o perjudicial para nuestras infraestructuras, mejor aún es poder identificarlas o frenarlas antes de que se produzcan. Situándonos en el papel de un atacante, antes de llevar a cabo cualquier acción han de darse fases como reconocimiento, identificación de equipos, redes, servicios, vulnerabilidades, etc. debiendo emplear herramientas con las que, de forma activa o pasiva, poder obtener dicha información. Por tanto, si somos capaces de detectarlas, no sólo estaremos previniendo una actividad inusual sino además, que algo o alguien pueda estar dando los primeros pasos antes de llevar a cabo una acción mayor. Y como no, si esto se produce, identificar qué es lo que ha fallado o es necesario corregir.

Por poner un ejemplo, propongo el siguiente escenario:

Escribir una leyenda

En la red 192.168.0.0/24 tendremos un PLC (en este caso un Siemens S7-300 emulado con la aplicación Snap7) con IP 192.168.0.65 el cual es accesible desde una Workstation 192.168.0.100/24 destinada a labores propias del entorno. Por otro lado, tenemos una red 10.10.10.0/24 donde ubicamos una DMZ, y en ella, un servidor SCADA con IP 10.10.10.101/24. Por último, la Red de Oficinas bajo un direccionamiento 192.168.1.0/24, donde a priori no debiera haber ningún tipo de software de Control.

Como NGFWs he empleado un Fortinet FortiWifi 60D, el cual tiene instalada una versión FortiOS 5.4.2. Cabe recordar que en esta versión hay que habilitar las firmas “Industrial” ya que por defecto no vienen activadas.

En la siguiente imagen vemos una captura del Software Step7 de Siemens desde la Workstation que citaba anteriormente.

Para el “Firewall Separación IT-OT” de los entornos de Oficinas y de Control, hemos creado el siguiente perfil de “Application Control”. Aquí bloqueamos todo tipo de aplicaciones, no debe darse ninguna comunicación desde un lado a otro.

Sin embargo, ya dentro del entorno OT, en “Firewall Segmentación OT-OT”, sí que permiten las aplicaciones “Industrial” y “Network Services”. Esto es:

Si queremos ser más estrictos podríamos bloquear una categoría completa y permitir a su vez que aplicaciones incluidas dentro de ésta, se ejecuten. Esto es, monitorizar la actividad de estos dos últimos y sin embargo denegar una acción concreta. Esto se consigue mediante la opción “Application Overrides”, cuya configuración prevalecerá sobre la definida de un modo más global.  En la imagen siguiente podemos ver que aunque monitoricemos el tráfico, vamos a impedir especificamente la acción de Bloquear la CPU del PLC mediante el protocolo S7 de Siemens.

También podríamos hacer lo propio definiendo un filtro, “Filter Overrides”. Por ejemplo todas las comunicaciones “Cliente-Servidor bloquearlas independientemente de qué categoría estén.

A partir de aquí será configurar las reglas en el Firewall según sean nuestros direccionamientos, interfaces y servicios de igual manera que lo sería en un Firewall tradicional. Es decir, podemos definir que desde un origen a un destino y bajo un mismo puerto sólo se puedan llevar a cabo tareas específicas de ese protocolo.

Hasta aquí una presentación de los que es y para qué se utiliza el “Control de Aplicaciones” dentro de un NGFW del fabricante Fortinet. En la próxima veremos algunos ejemplos y la funcionalidad de esta característica.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Un saludo.

Edorta.