[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
.