Securización de redes para DiD

[Publicado el 27 de diciembre de 2011]

Se está hablando mucho sobre el concepto Defence in Depth (DiD) y la consecuente protección de redes de datos. Los artículos técnicos replican una y otra vez la teoría como una plegaria a los dioses, pero la realidad supera con creces las expectativas de una solución simple y barata a un gran problema. 

Fuentes : Experiencia personal

Introducción a DiD

A estas alturas la mayoría de los técnicos, ingenieros o jefes de planta del sector industrial habrán leido en algún momento algo sobre el concepto de Defence in Depth (DiD) como estrategia de implantación de contramedidas dentro de un plan de ciberseguridad industrial.

Como tales debemos estar cada vez más concienciados en mantener todos los aspectos CIA ( Confidentiality, Integrity and Availability ) de los sistemas de control que han abrazado de lleno a los sistemas de información IT. Tradicionalmente en la industria se le da quizás más importancia a la disponibilidad (Availability) que a sus compañeros de viaje "integridad" y "confidencialidad", aunque poco a poco se comprenderá que los métodos de seguridad integral de los sistemas se basa completamemnte en la adopción de la tricotomía.

Si aplicamos el modelo general del Common Criteria (ISO/IEC 15408) para la evaluación de la seguridad de los sistemas de información :
<< Valoraremos una serie de activos de nuestra factoría que inevitablemente sufren de vulnerabilidades. Estas vulnerabilidades explotadas con malicia por una o varias amenazas pueden suponer un grave trastorno a nuestro negocio. Así que, deseamos minimizar los riesgos de sufrir una degradación de nuestra producción adoptando contramedidas. >>

Desde hace miles de años se conoce que una estrategia militar basada en el desgaste del atacante a través de varias líneas de defensa supone grandes beneficios para el atacado, entendiendo beneficios como la minimización de pérdidas.

En los sistemas IT se adopta está táctica militar bajo diferentes técnicas y conceptos de seguridad. Erróneamente muchos técnicos entienden Defence in Depth de forma única como la defensa de las redes de comunicaciones, de modo que automáticamente se entiende que la solución es instalar Firewalls y otros sistemas como el IPS (solo con mencionar el nombre parece ser que "protegen"). En todo caso DiD debe verse como una solución integral de diferentes tipos de medidas, desde el control de accesos lógicos y físicos o el despliegue de antivirus hasta la implantación de zonas DMZ.

Dentro de la estrategia DiD recomendada desde la ISA99 quiero centrarme en este artículo en una de las complejas realidades con la que nos hemos topado muchos expertos en ciberseguridad industrial : la total desprotección de las subredes de comunicaciones dentro de una intranet para los sistemas de control (ICS) y supervisión (SCADA).

¿ Que nos encontramos en las intranets industriales ?

Nos encontramos en casi todos los casos que la adopción de las tecnologías de la información basadas en redes ethernet y TCP/IP por parte de los fabricantes de sistemas ICS no ha sido asociada con la consiguiente consideración de seguridad, sino mas bien con el objetivo de conseguir un funcionamiento "correcto", fiable y mantenible.

Los integradores a su vez tienden a obviar y relajar más aun el tema de la seguridad, sobre todo cuando los clientes presionan para terminar las instalaciones "para ayer" ( a precio de "chinos" ). En definitiva, todavía hoy la seguridad no es una prioridad en los presupuestos de las empresas.

El resultado final pueder estar contemplado en dos escenarios :
- O bien una única subnet agrupando centenares de equipos de todo tipo; desde PLCs y OPs a equipos de sobremesa e impresoras perteneciente a diferentes areas de la compañía ( para mas inri todos con pleno acceso a internet) .
- O bien un conglomerado de subredes VLAN enrutadas entre si con pleno acceso entre ellas; igualmente desde la dedicada a las oficinas de contabilidad y recursos humanos hasta la que integra los PLCs de los paletizadores.

Un atacante que fuese capaz de introducirse en la intranet simplemente con la adecuada ingeniería social (robando un acceso VPN por ejemplo ) u obteniendo facilmente una contraseña WEP Wifi tendría acceso a todos y cada uno de los dispositivos de automatización de nuestro negocio. Este atacante no tendría porque ser una entidad física ya que existe malware como Stuxnet y sus derivados que han demostrado con creces la capacidad de control remoto de los "zombis" (equipos infectados) incluidos en las redes botnets.

Os podeis imaginar si encima nuestro negocio se considera crítico para el gobierno de la nación, la que se puede armar.

¿ Como implantar una estrategia de aislamiento de subredes VLAN ?

Como solución más básica nos vamos a plantear en primer lugar aislar mediante VLANs las correspondientes subnets que consideremos, e imponer en segundo lugar unas reglas de permisividad o restricción ACL.

Tanto para el primer escenario en el que no existe la segregación mediante VLANs y enrutadores de las subnets creadas, como para el segundo escenario en el que si existe el desglose enrutado de la intranet en VLANs, el principal problema para securizar aislando es el conocimiento de las dependencias y requerimientos. Conocer todas las relaciones de dependencias y los requerimientos es obligatorio si queremos tener éxito y compatibilizar la seguridad con la funcionalidad de los sistemas tratados.

El diseño de la infraestructura de comunicaciones es una fase esencial y vital, es imprescindible armarse de conocimientos de networking así como del funcionamiento de las "aplicaciones" (servicios IT y servicios industriales integrados) instaladas en la intranet.

Como referencia nos plantearemos un modelo que estará basado en el esquema de capas recomendado por la ISA 99. Recordemos que a su vez está basado en otros modelos como el antiguo pero aun presente CIM.

Tambien habrá que recurrir a herramientas y tendencias de nuevos conceptos de seguridad para lo cual contamos siempre con la ayuda de internet.

Podríamos distinguir entonces los siguientes pasos :

1) Recopilación de documentación, entrevistas y sus correspondientes análisis.
2) Definición con claridad de la arquitectura física y lógica de la intranet.
3) Definición de los objetivos y planteamiento de un modelo inicial de contramedidas.
4) Captura de información de tráfico
5) Procesamiento de la información capturada para el análisis de dependencias y de estado de tráfico.
6) Diseño del modelo concreto a seguir y la implantación de medidas.
7) Implantación planificada.
8) Seguimiento y mejoras.

Asimilandolo al esquema del maestro Deming, tenemos un completo proyecto con una fase de Plan ( 1) 2) 3) ) , Do ( 4) 5) 6) 7) ) y Check-Act ( 8) ). Cada uno puede hacer un "Project Management" a su gusto.

Una descripción rápida y somera de un primer modelo

Creo que es muy pretencioso llegar a conseguir el modelo de la ISA-99 teniendo que "heredar" los escenarios "legacy" de décadas anteriores que he comentado anteriormente. Es pretencioso por muchos motivos entre los que se encuentran los técnicos y los de gerencia.

Creo que es mas asimilable y menos costoso diseñar una solución progresiva partiendo inicialmente de un modelo muy básico :

 - Control y protección exahustiva de la capa 4 del modelo CIM respecto del exterior, o de la capa 5 en esquemas multicentros.
 - Aislamiento de forma general entre las capas 1,2 y 3 de la capa 4 con las excepciones necesarias supervisadas por reglas de permisividad y/o restricción, y el uso de espacios DMZ.
 - Una agrupación temporal de permisividad general entre los componentes de la capa 1,2 y 3.

Revisar todos los pasos supera la previsión de este artículo asi que centraré la atención en el punto 4) y 5) de captura de tráfico de red y procesamiento de la información.

Captura de tráfico con el objetivo de securización por aislamiento

Para entender la situación me gustaría recurrir a un símil :

<< Todo el tráfico de nuestra intranet es como si tuvieramos un enorme salón de congreso lleno de personas de todas las profesiones posibles entre las que existen o pudiesen existir relaciones comerciales de cliente-proveedor o meramente de contacto profesional. Todos están hablando a la vez moviendose de un lado para otro realizando su labor profesional, generando nuevos contactos, etc.

Nos han encargado crear una estancia mas organizada (y documentada) en la que no se tuviese que dar gritos para entenderse debido al murmullo ambiental que interfiere, y con mayor importancia, que sus relaciones quedacen en la discreción.

Con los listados que podramos disponer de las personas asistentes y sus negocios nos "equiparemos" con una serie de empleados de salón que van a ir anotando "maleducadamente" cada una de las palabras y "ruidos" que entren en su area de "escucha". Analizaremos la información obtenida, clasificaremos, crearemos nuevos espacios y vias de comunicacion, y, reubicaremos las relaciones.

Habrá que estar muy seguros de haber conseguido el listado de conversaciones y "operaciones comerciales" mas verificado posible ya que de lo contrario romperemos relaciones en cuanto implantemos las medidas de aislamiento>>

La imagen propuesta describe el objeto de nuestro problema y las técnicas básicas como el empleo de sondas promiscuas para el registro de paquetes ( port mirroring y sniffing ) y aplicaciones de manipulación/minería de datos ( datamining ) para obtener matrices de relaciones por MAC, dirección IP y servicios a través de flujos.

El registro de paquetes puede llegar a ser inviable si no contamos con potentes y costosas máquinas exclusivas para estas tareas o una meditada estrategia de captura a través de equipos menos potentes y el "divide y vencerás". Su utilidad es indiscutible aunque nos veamos inmersos en centenares de gigas de paquetes registrados. Por un lado apoyarán nuestro estudio de relaciones de dependencias, y por otro, nos darán una visión del estado de salud de las redes. Este último punto puede sugerirnos incluso una parada en "boxes" de nuestros planes para reparar graves deficiencias (suele pasar).

Las matrices de relaciones son el fundamento principal de nuestro empeño de securización por aislamiento, serán tablas convertibles en grafos u otras formas visuales representativas que nos ayudarán a comprender el mapa del tráfico de datos. En estos últimos años diferentes investigadores de universidades y compañías privadas han estado proponiendo metodologías y herramientas para ello.

Registro de paquetes

El registro de paquetes de tráfico es una tarea muy productiva documentalmente hablando pero muy ingrata debido a los volumenes de datos que pueden implicar.

Tengo que recordar que sin la ayuda de los operadores de redes es imposible realizarla adecuadamente. Lo primero es entender que la electrónica de conmutación no permite que un dispositivo conectado pueda acceder a paquetes de tráfico que no van dirigidos a él. Cada fabricante lo denomina de un modo pero el efecto es el mismo, hacer llegar los paquetes de entrada/salida de algunos interfaces o troncales a un determinado puerto categorizado como "span port mirror" o simplemente "port mirror".

El port mirroring "no supone muchos" riesgos pero aun así : hay que revisar la documentación del fabricante por si la arquitectura del aparato de conmutación es afectado por grandes cargas de tráfico "replicado"; y prever la carga de tráfico de los interfaces que se desean capturar respecto a las maquinas recolectoras que conectaremos. capturar todos los interfaces de la intranet a la vez no es buena idea.

A los puertos "espias" conectaremos sondas promiscuas recolectoras que registren cada paquete que le llegue. Capsa de Colasoft en el lado comercial y Wireshark en el de freeware son dos aplicaciones muy representativas. Microsoft tambien provee gratuitamente del Netmonitor ( una "especial" versión del Netmonitor pertenece al paquete del antiguo MS SMS ).

La primera utilidad que encontramos en estos programas, sin entrar en detalles, es el calculo de la carga de trafico para dimensionar nuestras capturas. Capsa lo visualiza en su panel principal, Wireshark a traves de sus graficas de analisis y Netmonitor ( del MS SMS ) como propiedades de la red. En cualquier caso el operador de red nos lo podrá suministrar accediendo a la consola de gestión de la electrónica. Es importante no confundir bits por segundo y bytes por segundo, cada unidad tiene una utilidad y es usada muchas veces incorrectamente.

La segunda utilidad es visualmente hacernos una rápida idea de los protocolos que se están usando respecto a la carga total. Normalmente las aplicaciones tienen un panel de exploración de tipo arbol muy sencillo de consultar.

Pero la principal utilidad es la de guardar el tráfico para estudiar detenidamente los flujos y todos los detalles de los protocolos. Como decia en parrafos anteriores podemos ver si la salud del tráfico es buena revisando por ejemplo los flags TCP para las retransmisiones. El campo es muy amplio y las técnicas de busquedas de problemas y los problemas en sí también. Algo que me suelo encontrar muy a menudo es que el tráfico de las redes es caótico porque normalmente cuando se desplieguan sistemas no se optimizan los equipos ni los usos de los protocolos, por ejemplo, dejando muchas opciones de aplicaciones por defecto activado o las tormentas de multicast y broadcast.

Cuando en otra fase del proyecto estemos analizando la información de las relaciones entre equipos las captura de paquetes de tráfico nos ayudarán a comprender algunas relaciones y servicios.

El equipo a emplear como sonda dotado de un sniffer debe estar optimizado en proceso, memoria y velocidad de transferencia a disco. Realmente la experiencia nos dirá si hemos acertado o deberemos mejorar las prestaciones del equipo sonda.

Como nota comentaré que si queremos ahorrarnos algo de dinero Wireshark cumple muy bien su función hasta determinados límites. Recomiendo usar la versión no gráfica, ampliar el buffer de captura y acudir a la división de las capturas en archivos secuenciales de entre 50 y 150 megas (aunque esto depende del equipo final ). Si no acertamos con el equipo y los tamaños obtendremos solapamiento de recursos y muy probable cuelgue del S.O. .

http://www.wireshark.org
http://www.colasoft.com
http://www.microsoft.com/download/en/details.aspx?id=4865

Captura de conversaciones para las matrices de relaciones

Las conversaciones entre los equipos en una intranet son necesarias para que las dependencias de las aplicaciones instaladas permitan el funcionamiento de los sistemas. Si en nuestra implantación de securización por aislamiento interrumpimos una conversacion evidentemente dejará de funcionar una parte del sistema, mas o menos importante.

Un equipo mantiene un conjunto amplio de conversaciones que no tienen que estar todas presentes al mismo tiempo. Se pueden agrupar por funcionalidad y no todas son de aplicaciones de usuario. Unas conversaciones son : administrativas como en los casos de ARP, Bootp,  LDAP, DNS, NDMP ... ; estandares como RDP, VNC, SMB, FTP, Telnet, Iso-on-TCP; y propietarias.

Si estamos en el escenario en el que solo existe una VLAN la matriz se complicará en proporción directa al numero de equipos y de sistemas y servicios inventariados. Dependiendo de la arquitectura física habrá que ir progresivamente por areas para asimilar toda la intranet y finalmente unificar las capturas.

Si nuestro escenario es de varias VLAN la estrategia puede ser desglosada en varias fases y probablemente mantenga cierta lógica en relación a los servicios implicados. Por ejemplo si existe una VLAN para los departamentos de gestión administrativa y de gerencia y varias para la factoría en definitiva se reduce principalmente a conocer las relaciones entre la factoría y la red de gestión administrativa.

El primer paso que debemos hacer es la solicitud al operador de red que nos suministre el listado de IPs y MACs de la cache de la electrónica para saber el numero de equipos implicados. Tambien nos puede proveer de una contabilidad basica de conversaciones y trafico entre ellas para hacernos una idea de la carga de tráfico.


Netflow y Ntop

Los flujos de tráfico son muy utilizados en los grandes equipos para la monitorización de los volumenes de tráfico. El más conocido es Netflow desarrollado por Cisco pero que está ampliamente usado por otros fabricantes.

Netflow permite enviar a un recolector de información de red datos de trafico, direcciones y servicios necesarios para crear una grafica de volumen de trafico y matrices de relaciones.

El despliegue de esta tecnología no está exenta de meditado diseño entre otras cosas porque en su contra puede estar que requiera de valiosos recursos de la propia electrónica. Además no todos los dispositivos lo soportan.

Hay posibilidades de usar software que emula un flujo netflow y que deberá ser instalado en puntos estratégicos de la infraestructura. Este software, como puede ser el archiconocido Ntop, usará el modo promiscuo y un interface en port mirroring para realizar su labor.

LINK :
http://www.ntop.org
Cisco Freeware netflow http://www.cisco.com/en/US/prod/iosswrel/ps6537/ps6555/ps6601/networking_solutions_products_genericcontent0900aecd805ff72b.html

Nirsoft Smartsniffer

Nir Sofer publica gratuitamente auténticas maravillas para cualquier administrador de sistemas. Entre ellas está una pequeña obra de arte llamada SmartSniff.

Con esta aplicación y habilidad para el datamining se pueden obtener matrices de relaciones de dependencias a coste 0, o casi 0, porque hay que valorar nuestro tiempo.

Todo hay que decirlo, si usais la aplicación deberéis ingeniarosla para ir copiando el grid e ir pegandolo en un txt. Os puedo asegurar que con esta aplicación se pueden capturar mas de un millon de conversaciones y cientos de millones de paquetes revisados. Ojo, esto que os cuento es posible porque una de las principales caracteristicas de esta maravilla es que lo hace en memoria, le podemos decir que no guarde paquetes a disco.

http://www.nirsoft.net/utils/smsniff.html


Tranformaciones para unificar y consultar

Con Smartsniff y algo de habilidad obtendremos unos ficheros txt importables como csv que serán la base de nuestra consultas para filtrar los equipos y los servicios, y por tanto, deducir las relaciones.

Puedo recomendar dos vias, o bien importarlo desde Microsoft SQL o cualquier otro engine SQL (como MySQL, Postgre o Firebird) o bien tratarlo con software ETL como Spoon de Pentaho.

Una vez importado el total de las conversaciones hay que definir que estamos buscando :
- separar las direcciones internas de las externas.
- Filtrar y reducir las conversaciones hasta descubrir el numero de equipos internos y el numero de equipos externos implicados.
- Filtrar y reducir las conversaciones hasta descubrir el numero de conversaciones únicas entre un origen y sus destinos
- Filtrar y reducir las conversaciones hasta descubrir el numero de conversaciones únicas entre un destino y diferentes origenes
- Filtrar y reducir las conversaciones por servicios
- Otras clasificaciones auxiliares.

Recomiendo por ejemplo crear listado en los que se unan en un solo campo las direcciones de la conversacion y los puertos implicados. Ello permitirá psteriormente visualizar un grafo muy clarificador.

http://kettle.pentaho.com
http://www.microsoft.com/download/en/details.aspx?id=21844
http://www.firebirdsql.org
http://www.mysql.com
http://www.postgresql.org

Otras herramientas en tiempo real

Navegando por la red nos podemos encontrar con herramientas que incluso hacen lo mismo que he mencionado con el "coctel" de aplicaciones y en tiempo real. Las mejores valen una auténtica fortuna y son usadas por grandes NCC ( NOC o COR, como las querais llamar ).

Hay algunas que son gratuitas y pueden sorprendernos, revisad el live CD de DAVIX.

Resultados

Los resultados que debemos obtener basicamente son listados de equipos y conversaciones netas de las que se podrá deducir las dependencias entre equipos y sistemas.

Hay que tener presente algunos detalles importantes como el hecho que el uso de DHCP hace que un equipo pueda adoptar varias direcciones en un periodo de varios dias en determinados casos, de forma que unicamente por MAC podremos detectarlo.

Ver la matriz visualmente ayuda a deducir dependencias y es mas grato en cualquier caso para una persona. Hay muchas aplicaciones para la visuzalización gráfica de datos pero personalmente me quedo con una estupenda aplicación gratuita llamada Cytoscape.

Con Cytoscape podemos importar almenos archivos de texto csv con los que debidamente formateados obtendremos unos grafos de relaciones esenciales para comprender la hetereogeneidad de la intranet :

- Equipo contra equipo
- Conversacion contra puertos
- Conversacion contra servicio

http://www.cytoscape.org/

Reglas ACL a nivel de enrutamiento

A estas alturas tenemos una serie de analisis del tráfico de nuestra intranet que nos permite distinguir sistemas, funcionalidades, relaciones y detalles de las relaciones de las mismas si fuera necesario.

En el primer escenario deberíamos ahora tener todo lo necesario para decidir como segmentar la unica VLAN que existe en varias VLANs y enrutarlas con reglas de acceso de acuerdo a las dependencias.

En el segundo escenario deberíamos tener todo lo necesario para diseñar las reglas de permisividad y restricción.

No se me escapa el hecho que probablemente hay que "optimizar" el tráfico. Algunas reuniones con el personal de ingeniería y planta de la factoría asi como de gerencia deberían ser suficientes como para completar el objetivo de una forma coordinada con el único fin de securizar las infraestructuras comunes.

Apuesto que estas reuniones no estarán exentas de roces, sin embargo es parte de la negociación y todos tienen que implicarse para llevar el proyecto a buen puerto.

La implantación técnica de las contramedidas es un tema complejo, pero se puede realizar un primer acercamiento utilizando reglas simples ACL de los equipos CORE y routers. Lo ideal es implantar un despliegue de firewalls e IDS/IPS aunque necesitan bastante especialización y planificación.

Los IPS al final todo el mundo acaba poniendolo en modo transparente, básicamente porque al igual que en otras operaciones complejas, se lleva a cabo con la presión de ejecutarlo en producción o breves periodos de paradas de producción.

Conclusión

La táctica militar de Defence in Depth (DiD) es una estrategia no solo de mitigación de riesgos sino de auténtica defensa. Todo el mundo la menciona pero nadie la especifica principalmente porque muchos la malentienden o simplemente no se sabe que mediar e implantar.

La defensa de las redes de comunicación es una parte de la DiD y está en el ojo de muchos hackactivistas y malware, las industrias no han contado con la oportunidad inicial de securización porque ni se necesitaba antaño ni se conocía el alcance de la expansión de las redes en usos industriales y el riesgo consecuente.

Securizar las redes de comunicaciones puede llegar a ser una tarea muy compleja y cara en tiempo y recursos pero obligatoriamente necesaria para evitar riesgos al negocio.

La tarea de securización recae en varias fases de proyecto y una de ellas es especialemente técnica en cuanto a deducir y/o confirmar las relaciones de dependencias de los sistemas.

El tiempo pasa rápido y con él aumentan las posibilidades de una "moda general" de ataques a la industria, teniendo presente que la securizacion de las redes puede tardar entre 3 y 24 meses, ¿ a que esperas ?.

Javier G. Sáenz

Consultor Senior de sistemas industriales ICS/SCADA
Arquitecto/programador especialista de sistemas ICS/SCADA
Consultor Senior IT
Experto en ciberseguridad industrial, ISA S-99
Analista Programador Senior Siemens Simatic
Ingeniero de Software Senior proyectos de control de procesos

Especialidades:En general :
Ingenieria del Software Senior, metodos formales y ágiles
Ingniero de Sistemas Windows Senior
Programador multidisciplinar y multiplataformas, desktop, servidores e industrial
DBA Junior, specialidad Microsoft MS SQL
Operador de red Junior
Comprometido con ISO9001 , ISO27001, ITIL V2, COBIT, TOGAF, PMBOK