Blog del CCI

sábado, 19 de abril de 2014

De cuando una debilidad revoluciona los medios: HeartBleed y los ICS (Claudio Caracciolo, 11Paths, CCI)

Introducción

En la historia de la Ciberseguridad siempre existieron debilidades graves que “revolucionaron” el mercado de alguna u otra manera.  Algunas de ellas por la potencialidad de las fallas encontradas, otras por la masividad en el uso del software afectado, otras simplemente porque afectaban a un producto específico que de por sí, ya era llamativo…

Hace un poco más de 10 días aproximadamente, el mundo entero se hizo eco de una debilidad sobre OpenSSL llamada HeartBleed dado que la falla se encuentra en la funcionalidad llamada HeartBeat y que por medio de la misma, un atacante puede lograr que los servidores que tienen SSL/TLS implementado con la versión de OpenSSL vulnerable, respondan a determinadas peticiones revelando datos contenidos en la memoria del propio servidor. Considerando que el funcionamiento de SSL/TLS se centra en la criptografía asimétrica y para lo cual se poseen 2 claves, una pública utilizada para cifrar una comunicación y otra privada para descifrarla, y que la privada se ejecuta en el servidor, la falla de la funcionalidad de HeartBeat permite obtener la clave privada desde el propio servidor y así descifrar todas las comunicaciones que puedan capturarse a pesar de estar bajo HTTPS.

Esta debilidad ha sido considerada tan grave que incluso ha sido difundida a través de medios de comunicación masivos en todo el mundo con el objetivo de alertar a toda la población usuaria de internet, y es así como nos encontramos con algunos de estos medios que por no terminar de entender cuál era el problema y con el apuro de comunicar rápidamente, han mencionado a esta vulnerabilidad  erróneamente como un virus confundiendo el mensaje y finalmente, desinformando.

Cuando en el Centro (CCI-Es.org) se planteó escribir un post sobre esta vulnerabilidad, me parecía que no tenía sentido volver a comentar la misma explicación que tan bien han realizado otros sitios periodísticos, portales técnicos, o incluso el sitio oficial www.heartbleed.com , y en este sentido preferí dejar pasar unos cuantos días antes de terminar de escribirlo para tratar de ir un poco más allá de la debilidad en sí misma y analizar la problemática en el sector industrial.

Análisis y Respuestas Varias

Es cierto, la debilidad es grave.
Es cierto, la debilidad tiene dos grandes frentes por atacar, y deben ser en el siguiente orden sí o sí:

  1. Los administradores de todos los sitios web con OpenSSL deben verificar si la versión que poseen implementada es vulnerable, y en caso positivo, actualizarla.
  2. Los usuarios de dichos sitios deben cambiar las claves una vez actualizados.  Para lo cual, los administradores de dichos sitios, deberían notificarles que estuvieron expuestos y que han actualizados los servidores para que ellos hagan el cambio.

Pero en verdad, en entornos industriales, ¿es lo más importante que nos ocurre respecto a la Ciberseguridad? ¿Deben los administradores de estos entornos salir corriendo a actualizar las versiones de OpenSSL?  

La respuesta natural es sí, sin embargo, debemos repensar un poco mejor nuestro estado del arte:  

Sobre la fecha en que se hizo pública la debilidad, se realizaron búsquedas en el famoso buscador de dispositivos conectados a Internet, Shodan, con el fin de determinar cuantos ICS eran vulnerables a esta nueva debilidad.  El resultado fue sorprendente, aproximadamente 1500 sistemas eran vulnerables, lo cual es un número realmente bajo pero (siempre hay un pero), con darnos una vuelta por la documentación de los ICS, o realizar otro tipo de búsquedas en el mismo Shodan nos daremos cuenta que la gran mayoría de los sistemas de control industrial implementados no utilizan el protocolo SSL/TLS, por lo cual sus comunicaciones ni siquiera están cifradas.  
A su vez, al día de hoy, los ICS conectados a Internet no están controlados por un área que conozca sobre seguridad de la información, y mayormente no están documentados o ni siquiera son conocidos por ellos.  Además esos ICS conectados a Internet corren sobre versiones de sistemas operativos desactualizados tanto en versión (mayormente Windows XP) como en parches de seguridad, y hasta incluso la versión del software del propio ICS no esta actualizada y/o no esta incluía dentro de un ciclo de actualización de seguridad periódica.   Pero aún, muchos de los ICS se encuentran hoy con usuarios y claves por defecto o triviales. 

Entonces, ¿estamos realmente convencidos que debemos correr por la vulnerabilidad de HeartBleed?

Se me ocurre que ante este estado de situación, el sector industrial debe primero pulir otras cuestiones más importantes que están relacionadas con la identificación de todos los sistemas, la ejecución de un análisis de riesgo, la estandarización de los sistemas, y la evaluación periódica de su seguridad.  Resolviendo esto, también resolverán situaciones como la de HeartBleed sin esfuerzos extras, sino dentro de un proceso natural de revisión y actualización.    ¿Cuál es el sentido de cerrar con llave las puertas de nuestro carro, si dejamos las ventanillas bajas? ¿Cuál es el sentido de mitigar una vulnerabilidad si no lo hago con otras que son mucho más graves y que podrían dar acceso a un atacante a nuestra infraestructura?

Para el caso de un banco, de las redes sociales más conocidas, de las VPN empresariales, etc. HeartBleed es realmente una debilidad  por la cual uno deba correr debido a que existe un trabajo previo de aseguramiento de fondo que se rompe con esta debilidad, sin embargo en las redes industriales, falta mucho más esfuerzo por trabajar para solucionar cuestiones de fondo.    Incluso no solamente en la propia gestión de la redes, sino también en los organismos oficiales, ya que mirando lo que sucedió con los CERT hispano-hablantes en cuanto a lo orientado a infraestructuras críticas, salvo excepciones, podemos darnos cuenta que la Ciberseguridad Industrial aún no es un tema de relevancia real.  Muchos de los CERT se focalizaron en lanzar alertas para que los bancos regularicen la situación, para que los usuarios finales estén atentos, pero muy pocas empresas con infraestructuras críticas recibieron notificaciones específicas para que actualicen sus sistemas. Algunas de ellas, recibieron las alertas normales, las mismas que recibe cualquier usuario suscripto a una lista de correo de un CERT.

Conclusión

Entonces, si administro una red industrial, ¿no debería preocuparme por esta debilidad?

Espero que esta idea no se les haya cruzado por la cabeza en ningún momento mientras leían este articulo, siempre que exista una debilidad debemos hacer algo para mitigarla en nuestros sistemas, es parte fundamental de nuestro trabajo.   Sin embargo, no hay que quedarse en resolver sólo las que salgan en los medios masivos, sino que debemos velar por cerrar todos nuestros agujeros de seguridad.    Nuestro trabajo es cerrar todas las puertas y ventanas para que un atacante no ingrese, además de atender el día a día de nuestro trabajo.  Como siempre decimos, el atacante tiene el tiempo necesario, la paciencia y la determinación para buscar hasta encontrar solo una puerta o ventana abierta, mientras que nosotros debemos cerrar todas, y él, con esa sola, nos deja fuera de juego.

Hoy debemos estar más atentos que nunca.  Si con el correr del tiempo, seguimos encontrando con simples búsquedas en Shodan cientos de sistemas industriales con claves por default, con direccionamiento por DHCP o con software muy desactualizado, es que estamos fallando con algo.   En el Centro trabajamos a diario para minimizar esta brecha.


Claudio B. Caracciolo
CSA en 11Paths
Coordinador del CCI en Argentina
(@holesec)

jueves, 3 de abril de 2014

ICS use cases modeling

The CCI has the honor of taking part in the European Commission Joint Research Centre (JRC) thematic group on Case studies for the Cyber Security of Industrial Automation & Control Systems. The objective of this thematic group is to answer two important questions for the European Critical Infrastructures Cybersecurity:
  1. Is there a need for European Critical Infrastructure operators to have the cyber security properties of IACS components or subsystems tested / evaluated & certified?
  2. If yes, what are the conditions of feasibility for making this happen? (who should do it and pay for it, how and where should be done, based on which standards, what are the benefits,…)
The kick-off meeting was held last march on the JRC facilities in Ispra (Italy), and allow to have a first contact with use cases  modeling through the presentation of two examples of “Airport database” and “SCADA for electric transport”. The modeling of use cases helps to determine which would be the impact of a possible incident, what the attack sources and techniques, and what are the possibilities to fight the incident or mitigate its impact.

Through the analysis of use cases the thematic group seeks to answer the questions raised before. In this task, a number of professionals with wide experience is involved, but we need help. We need more end users to be involved. We need the knowledge of Critical Infrastructures operators in order to model realistic use cases and explore all its implications.

If you work in an organization that uses Industrial Automation and Control Systems and you want to share your knowledge by taking part in the Thematic Group, just let us know through info@cci-es.org. This is a chance to be part of an initiative that will set important aspects of the Industrial Cybersecurity Market in Europe during the following years.

Modelando casos de uso para ICS

El CCI tiene el honor de formar parte del grupo temático, del Joint Research Centre (JRC) de la Comisión Europea, dedicado a casos de estudio para la ciberseguridad de sistemas de control y automatización industrial. El objetivo de este grupo es responder dos preguntas importantes para la ciberseguridad de las infraestructuras críticas europeas:
  1. ¿Existe la necesidad, entre los operadores europeos de infraestructuras críticas, de evaluar y certificar las propiedades de ciberseguridad de los componentes o subsistemas de control y automatización industrial?
  2. En caso de que la respuesta a la primera pregunta sea positiva, se plantearía la siguiente pregunta: ¿De qué manera debería hacerse? Donde se deberán tener en cuenta aspectos de estándares, responsabilidades, financiación, beneficios, etc.
La reunión de lanzamiento de la iniciativa tuvo lugar el pasado mes de marzo en las instalaciones del JRC en Ispra (Italia) y permitió una primera toma de contacto con el modelado de casos de uso, mediante la presentación de los ejemplos de “Base de datos aeroportuaria” y “SCADA en la red de transporte eléctrico”.
Los modelos de casos de uso ayudan a determinar cuáles serían los impactos de un posible incidente, cuáles serían las fuentes y técnicas del ataque, las vulnerabilidades que lo permiten y las posibilidades para contrarrestar el incidente o mitigar su impacto.

Mediante el análisis de distintos casos de uso se pretende determinar la respuesta a las preguntas planteadas en los objetivos del grupo temático. En esta labor estamos implicados un grupo de profesionales con amplia experiencia, procedentes de distintos ámbitos de la ciberseguridad, pero necesitamos ayuda. Necesitamos la participación de más representantes de los usuarios finales. Necesitamos el conocimiento de los operadores de infraestructuras para modelar casos de uso realistas y explorar todas sus implicaciones.

Si trabajas en una organización que utiliza sistemas de control y automatización industrial y deseas compartir tu conocimiento participando en el grupo temático, dínoslo a través del correo info@cci-es.org. Es la oportunidad de formar parte de una iniciativa que determinará importantes aspectos del mercado de la ciberseguridad industrial en Europa durante los próximos años.