CSET, Herramienta para evaluación de riesgos. Parte II.

Anuncios

Siguiendo con la primera parte donde os presentaba CSET vamos a recorrer ahora los distintos pasos en su utilización.

Tras la instalación, al iniciar la herramienta accederemos a la pestaña “Home”. Allí nos encontraremos con una pantalla donde tendremos las opciones de crear un proyecto, dónde guardarlo, etc.

Para lleva a cabo nuestro análisis deberemos crear un fichero donde se recogerá toda la información referente a nuestro análisis, añadiendo información complementaria en la pestaña “Information”. Para ello deberemos completar algunos campos como nombre, contacto, nombre de las instalaciones, entre otros.

Listo el punto anterior, el siguiente será definir los “Standards” que utilizaremos como referencia.

Tendremos tres opciones “Questions”, para el usuario medio con un conjunto de preguntas generales; “Requirements”, dirigido a técnicos con conocimiento de los estándares disponibles para cada uno de los ámbitos; y finalmente “CyberSecurity Framework”, orientado a la protección de infraestructuras Críticas.

En mi caso he seleccionado “Requirements”, apareciendo las distintas opciones que siguen. Tomaré como ejemplo “Process Control and SCADA – NIST Special Publication 800-82″.

Aquí llegamos a un punto clave, el “Security Assurance Level”, es decir el grado de seguridad al que queremos llegar con nuestro análisis.

A modo general podremos elegir entre 4 tipos de niveles, “Very high”, “High”, “Moderate” o “Low”; pudiendo hacerlo a su vez en los tres pilares de la ciberseguridad, “Confidentiality”, “Integrity” y “Availavility”. Luego, en la parte izquierda, existen otros parámetros más específicos acerca del potencial impacto para la economía de la organización o la población civil.

En el siguiente paso podremos realizar una ilustración sobre cómo están interconectados nuestros sistemas. Esto nos proporciona tener una visión gráfica de los elementos involucrados en el análisis ayudando a interpretar otros apartados. Bien editado por nosotros mismos o importándolo desde un fichero Microsoft Visio este será su sitio. Como podemos observar, disponemos de una variedad de equipos como PLC, RTU, HMI, entre las distintas temáticas como IT, Medical, Radio, General, Zone, etc.

De nuestra selección en el paso “Standard”, a continuación llega el momento de empezar a responder las preguntas en el apartado “Requirements”. Puede ser algo aburrido, pero crucial para poder identificar las deficiencias y diseñar soluciones. Puesto que hemos elegido el SP 800-82 del NIST, las preguntas irán dirigidas en esa dirección. Como muestra la imagen, comenzaremos con “Policy Vulnerabilities” y finalizaremos con “Technical Controls” no sin antes pasar por un conjunto de ellos. En la parte derecha tendremos información complementaria, además de la inclusión de ficheros adjuntos que pudieran ser necesarios o interesantes.

Respondidas las preguntas, el siguiente paso será analizar los resultados. Tras todo cumplimentado, tendremos los mismos en la pestaña “Analysis”. Estarán organizados bajo distintas categorías, teniendo varias opciones para su visualización tal y como aparece en la  parte izquierda de la pantalla, bajo “Dashboard”, “Assessment”, “Ranked Questions”, etc.

Finalmente, con todo lo anterior es la hora de generar el reporte definitivo. Dependiendo a quién vaya dirigido tendremos varias opciones en lo que a contenido se refiere. Para ello en “Report selection” elegiremos entre las opciones disponibles. La herramienta también nos ofrece la posibilidad de presentarlo en dos formatos, PDF o DOCX.

Así pues tendremos en nuestro caso un resultado como el que sigue.

Esta tarea que hemos visto, además de cómo realizarla, debe considerarse de vital importancia. No podemos llevar a cabo un plan y una estrategia de seguridad si no sabemos cómo, ni de qué manera, evaluar nuestras debilidades. Una vez detectadas entonces, y sólo entonces, podremos plantearnos la manera de cómo corregirlas. Sin embargo para poder solucionar un problema no solo debemos realizarnos las preguntas correctas sino adaptadas a cada entorno. Esto es, no es lo mismo una fábrica de coches, que una farmacéutica, que una de distribución de agua potable o una central nuclear. Las consecuencias de que se produzca una brecha en la seguridad podrán llegar a ser más o menos graves y con un posible impacto sobre población civil. Así pues, debemos contar con algo que nos oriente en esta labor, especialmente cuando la solución pasa por involucrar a profesionales de entornos tan distintos como son IT y OT. CSET es una excelente herramienta que nos facilitará y cubrirá nuestras necesidades en este ámbito por lo que resulta obligado contar con ella para securizar nuestras instalaciones.

Un saludo, nos vemos en la próxima!

Irongate, al descubierto un nuevo malware para ICS.

Anuncios

El pasado 2 de junio, desde FireEye nos anunciaban los resultados del informe elaborado por  su «FireEye Labs Advanced Reverse Engineering (FLARE)».

Según nos cuentan, este grupo de trabajo a finales de 2015 identificó varias versiones de un malware dirigido a Sistemas de Control Industrial, ICS; con la capacidad de manipular procesos específicos dentro de un entorno simulado con dispositivos del fabricante Siemens. Decidieron llamarlos, IRONGATE.

La gente de FLARE encontró las muestras en Virustotal mientras investigaban ejemplares compilados con PyInstaller, algo empleado en otras ocasiones. Éstas destacaban por sus referencias a los sistemas SCADA y funcionalidades asociadas. Dos de ellas, contenían un payload subido desde distintos orígenes en 2014 pero ninguno de los antivirus lo detectó como malicioso.

Por otro lado, el CERT de productos de Siemens (Siemens Product Computer Emergency Readiness Team, ProductCERT), confirmó que IRONGATE no es viable contra sistemas, de control de Siemens, ni tampoco explotar ninguna vulnerabilidad en productos de este fabricante. No se puede hablar entonces de que exista una campaña de infección ni que suponga una amenaza, por lo que la conclusión más probable es que se trate de una prueba de concepto o una investigación sobre técnicas de ataque contra ICS.

El análisis concluye que IRONGATE aplica conceptos ya vistos en Stuxnet pero en un entorno simulado. Así pues, dado que la información sobre malware dirigido a sistemas ICS y SCADA es menor en comparación con otros ámbitos, es que han decidido compartir los detalles con la comunidad.

Vayamos con los aspectos técnicos.

Una de las características de IRONGATE es la de llevar a cabo un MiTM contra los procesos de entrada y salida I/O del PLC y el software del equipo que interactúa con el ICS dentro del proceso simulado. El malware reemplaza una DLL (Dynamic Link Library) con otra maliciosa convirtiéndose en intermediario entre la estación de monitorización y el PLC. Esta DLL registra cinco segundos de tráfico “normal” desde el PLC a la interfaz de usuario para reproducirla mientras manda de vuelta tráfico distinto al PLC. Esto podría permitir a un atacante alterar un proceso sin que el operador lo sepa.

La segunda característica a destacar es la capacidad para la evasión de Sandboxes. Algunas muestras del malware no se ejecutaban si se corrían sobre entornos VMWare o Cuckoo Sandbox. El malware usas estas técnicas para evitar la detección y resistir al análisis. La implementación de estas técnicas denota que el autor quería evitar su detección y por tanto estamos ante una aplicación maliciosa en contra de una aplicación legítima.

Finalmente, se averiguó que las distintas muestras estaban compiladas con PyInstaller, algo similar a lo empleado en otras ocasiones. Además se localizaron strings que contenían el término “payload”, también bastante común y asociado a otras piezas de malware.

IRONGATE no es comparable con Stuxnet en términos de complejidad, capacidad de propagación o implicaciones geopolíticas, sin embargo sí que comparten ciertas características y técnicas empleadas por éste como pueden ser:

  1. Ambos buscan un propósito específico.
  2. Ambos reemplazan DLLs para alcanzar manipulación de los procesos.
  3. IRONGATE detecta la observación/detección de malware mediante Sandoboxes o entornos virtuales, mientras que Stuxnet buscó la presencia de software Antivirus.
  4. IRONGATE graba y devuelve datos de proceso con el fin de ocultar las manipulaciones que introduce, mientras que Stuxnet si bien no intentaba esconderse de igual forma, si afectaba al funcionamiento de los autómatas S7-315 si ciertos valores representados en el HMI eran de carácter estático.

Por otro lado, no se ha identificado la forma de propagación, y probablemente no exista ya que se considera dicho malware aparenta ser parte de un proyecto de investigación, herramienta de pentesting o un desarrollo para testear un producto de Sistemas de Control Industrial. Esto puede interpretarse que estamos ante un suceso aislado, lo cual no significa que en un futuro pueda sofisticarse y representar una amenaza.

La parte principal de código ha sido escrito en Python e identificado en VirusTotal. Al parecer se hizo llegar a la citada plataforma de forma manual por medio de la interfaz Web. Esto, junto con la idea de que está dirigido a un entorno simulado, subido a un recurso público y que el malware no haya sido liberado, afirma la idea que se trate efectivamente de una prueba de concepto o una demo para algún producto concreto. Es difícil creer que alguien quiera llevar a cabo una APT contra ICS suba de forma manual a la citada Web algo tan sofisticado y más con los antecedentes de Stuxnet.

Aunque no suponga una amenaza, no podemos quitar importancia al hallazgo. Este hecho pone de relevancia que atacantes o personas con conocimientos específicos, están cada vez más preparados y con mayores capacidades para desarrollar código más elaborado, inteligente y posiblemente más destructivo de lo que fueron Stuxnet, HAVEX o BlackEnergy2. Lo cierto es que según afirman varias fuentes, las muestras de IRONGATE no fueron detectadas por ninguno de los motores antivirus, con lo que pone en evidencia la capacidad de éstos para detectar malware dirigido contra Sistemas de Control Industrial. En parte, claro está, porque se trata de una novedad frente a los ya conocidos.

Muchos responsables se estarán preguntando cómo protegerse de algo que muchas herramientas no han sido capaces de hacerlo por nosotros. Esto pone de relevancia que no podemos delegar en nuestras herramientas toda la responsabilidad de la protección. Obviamente debemos contar con ellas para securizar nuestras instalaciones, aparte de tener implementar unas políticas y estrategias debidamente establecidas, asentadas y sobre todo que se cumplan a rajatabla, pero no depositar confianza ciega. Las organizaciones deben contar con profesionales especializados en la materia, que entiendan las características de la Industria y la protección de Infraestructuras Críticas, muy distinto al tradicional mundo IT. Expertos que entiendan las nuevas necesidades, tiempos, tendencias, vectores y amenazas que están por llegar y que según indican las estadísticas van al alza.

En cualquiera de los casos todos debemos estar atentos con lo que está por venir, que como ya sabemos, va a seguir dando de qué hablar.

Un saludo!

Mas Información:

Enlace 1

Enlace 2

Enlace 3

Enlace 4

Enlace 5

Why IRONGATE is a big ICS security Security Story?

Artículos y noticias de interés semana 23

Anuncios
  1. Más sobre Irongate, esta vez en The Hacker News. Enlace.
  2. 7 pasos para ser ciber resiliente. Enlace.
  3. Ejercicios de cibera ataques para formación de profesionales. Enlace.
  4. Vulnerabilidad en múltiples productos Siemens. Enlace.
  5. Corregida vulnerabilidad que afecta a CPU de PLC Siemens S7-300. Enlace.
  6. Presentación de Ciberseguridad Industrial en el evento «Security Day» de Telefónica. Vídeo. PDF.