Electrónica: Stuxnet y otras cosas que asustan en la noche. ¿Qué es Stuxnet?

TUTORIAL 5445

Stuxnet y otras cosas que asustan en la noche

Por:
Kris Ardis, Director de Negocios

27 de noviembre 2012

Resumen: Stuxnet, un virus sofisticado que dañó la capacidad nuclear de Irán, debería ser un abridor de ojos para el mundo. Podemos optar por aprender algo muy estrecha (la manera de combatir el virus Stuxnet) o podemos optar por centrarse en el objetivo más amplio de frustrar el siguiente tipo de ataque cibernético creativo. Desafortunadamente, la infraestructura industrial crítica no está diseñado con la seguridad como un objetivo clave, dejando abiertas múltiples posibilidades para un atacante educado y financiado para crear enormes problemas. Este tutorial describe algunos conceptos básicos que los ingenieros y los definidores de productos debe tener en cuenta para asegurarse de que sus nuevos proyectos mantenerse por delante de las amenazas futuras.

Una versión similar de este artículo apareció en EDN , 11 de octubre de 2012.

¿Qué es Stuxnet?

Stuxnet es en su raíz un virus informático. Pero es muy sofisticado. La mayoría de los virus se transmiten por correo electrónico, archivos adjuntos, o USB sticks, y provocar el caos mediante la explotación de las debilidades y fallas en los modernos sistemas operativos de PC. Se pueden propagar rápidamente, pero muchos enfoques de sentido común para el manejo de correo electrónico, descargas de Internet, y el software antivirus puede ayudar a mitigar la amenaza. Los virus informáticos son normales indiscriminada: atacan cada PC que tocan. Stuxnet es diferente-mientras que se extendió en una manera similar a otros virus, en la mayoría de los sistemas que no tuvo efecto. Stuxnet fue diseñado para:

Infiltrarse en un PC a través de las vías de virus típicos. Memorias USB son muy eficaces.
Confirme si la ubicación del PC anfitrión fue Irán.
Establecer si existe un cierto tipo de controlador lógico programable (PLC) conectado al PC.
Comprobar si había un número específico de los PLCs conectados.
Confirmar si los PLCs estaban conectados en una disposición muy específica y el control de una pieza particular del equipo.
Vuelva a programar los PLCs de alterar su comportamiento, pero el diagnóstico del informe de que todo estaba bien.

Esto suena bastante complejo. Pero es sólo una parte de la historia, el número de PLC y la configuración que Stuxnet objetivo demostrar que el virus se ha definido claramente para atacar una instalación nuclear específico en Irán, y para dañar lentamente y de forma permanente las centrifugadoras allí para hacer retroceder el uranio iraní programa de enriquecimiento. El daño que se pretendía hacer con el tiempo a confundir los operadores-que no creo que de un virus o cualquier tipo incluso de IT problema hasta que estuvieron profundamente en el diagnóstico del problema.

La evidencia sugiere que Stuxnet fue un éxito en dañar permanentemente 1.000 centrifugadoras en la planta nuclear iraní.Se especula que el virus fue diseñado por los Estados Unidos, Israel, o ambos. Tenga en cuenta que Stuxnet no en realidad la mayoría de sistemas daño que infecta-que fue un ataque muy concretas. Esto permitió que se propague a la meta antes de que se ha detectado y las compañías antivirus han alertado de su presencia.

¿Por qué deberíamos preocuparnos?

Debemos preocuparnos por muchas razones. Este es un modelo para la guerra cibernética eficaces. Es probable que haya inspirado a los esfuerzos de TI de los estados nacionales en todo el mundo. Si bien Estados Unidos / Israel puede haber alcanzado sus objetivos en esta huelga de apertura, tiene una caja de Pandora se abrió donde ahora veremos ataques de represalia que se dirigen a EE.UU. u otros intereses aliados? Se ataques en el Stuxnet modelo occidental, sino ampliar el enfoque para causar el máximo daño a la infraestructura crítica?

Stuxnet y otras cosas que asustan en la noche Hay otra razón para preocuparse: Stuxnet muestra que la infraestructura crítica no está protegida. La seguridad no es a menudo una consideración de diseño en muchas aplicaciones, incluyendo control industrial. Hay una regla básica sobre el diseño de la seguridad en una aplicación: nunca sucede debido a que es una buena idea. Esto sólo ocurre porque (1) está dictada por la situación (por ejemplo, una certificación que requiere un nivel de seguridad), o (2) en reacción a la exposición pública o perjudicial de un fallo de seguridad. Tenga en cuenta que la primera razón es preventiva, y el segundo es reactivo. ¿En qué situación nos encontramos ahora?

En la era posterior a Stuxnet, nos estamos haciendo las preguntas correctas para tratar de resolver este problema?Algunos se preguntan: "¿Cómo podemos luchar contra Stuxnet?" y "¿Cómo podemos asegurar una memoria USB?" Soluciones que resultan de estas preguntas son similares a las vendas, las medidas de seguridad del aeropuerto que nos exigen tomar nuestros zapatos para comprobar bombas. Sí, la inspección de los zapatos detectará el ataque que fue casi efectivo, pero no comprueba el siguiente tipo de ataque creativo. Incluso si creemos memorias USB son una debilidad y una ruta para la diseminación de virus, un seguro dispositivo USB no ayudará-, es bastante fácil de crear un USB que se parece a la segura, y cargarlo con el virus.

La raíz del problema

En nuestro ejemplo terrorista del zapato, la raíz del problema es fácil de identificar: ¿Cómo nos aseguramos de que todos los que tiene acceso al plano (es decir, los pasajeros, mantenimiento, tripulación) tiene buenas intenciones viajar, de reparación, u operar los aviones? La pregunta es fácil de identificar, pero no responder.

Es similar a Stuxnet. La pregunta debe ser "¿Cómo podemos proteger la infraestructura crítica para que opere en la manera que se esperaba?" La respuesta es en consecuencia complejo, pero en su raíz es una necesidad para los sistemas integrados de considerar la seguridad en todos los aspectos de diseño. Ingenieros típicamente diseñar un sistema de primera para la funcionalidad nominal, y si se considera que la seguridad en todo lo que es generalmente el último momento, aplicado sobre un sistema existente y diseñado. Todos los involucrados en la industria de seguridad está familiarizado con el concepto de que "la seguridad se diseñarán más tarde" ... que en realidad significa que la solución no estará asegurado. Seguridad añadida a un paso tan tarde sólo puede ser superficial, sólo la protección contra las amenazas obvias.

Vamos a utilizar otro equipo como un ejemplo: un contador inteligente es la primera diseñada para satisfacer los requisitos de metrología de precisión e implementar una pila de comunicación correctamente. En esa pila de comunicación, el Advanced Encryption Standard (AES) se suele añadir para proteger los datos que el medidor genera y envía de nuevo a la utilidad, y para proteger a los comandos enviados desde la utilidad para el medidor. La respuesta de muchos servicios públicos, proveedores de comunicaciones y fabricantes de metro es entonces cuando el medidor está asegurada, ya que utiliza AES para cifrar los datos que entran y salen del medidor. Pero este es un vendaje-la amenaza se identifica como sólo la "manipulación de los datos procedentes de la metro y los comandos que van a la metro." Esto es el equivalente a sacar de nuestros zapatos en la línea de seguridad en el aeropuerto, tenemos una sola amenaza identificada, y un vendaje solo para hacer frente a esa amenaza única. No hay ninguna consideración para la nueva amenaza que viene. En el caso del metro, la amenaza hábil siguiente podría estar en contra de que el medidor físico en sí-un atacante puede tener acceso al medidor físico y cargar un nuevo programa de aplicación en el firmware, lo que permite al atacante tomar el control del medidor? Ahora tenemos una amenaza, un nuevo firmware programador malicioso. Pero podemos desarrollar otro vendaje o en lugar pensar en un enfoque más amplio de la seguridad?

Un planteamiento más amplio

Los vendajes no va a funcionar. Sólo prevenir los ataques anteriores. Nuestros adversarios son lo suficientemente inteligentes como para pasar a un nuevo truco, pero nuestros métodos de seguridad no lo son. Es hoy un terrorista va a abordar un avión con una bomba en su zapato? Probablemente no. Ellos desarrollarán un ataque, tal vez más creativos van a penetrar la seguridad en un aeropuerto mucho más pequeño, y luego volar un avión privado a un aeropuerto más grande, donde tendrán acceso a mayores objetivos.

Un enfoque más amplio de la seguridad requiere algunos cambios fundamentales en cómo los sistemas integrados están diseñados. Algunas industrias pueden tener especificaciones o requisitos de seguridad que deben cumplirse. Sin embargo, en las aplicaciones de redes inteligentes y más industrial, nos encontramos con una falta de directrices de seguridad, dejando ingenieros dirección. En estos casos, los ingenieros y los definidores del producto deberían adoptar un enfoque más fundamental a la seguridad:

La seguridad debe ser una meta clave antes de que el producto está definido. Las amenazas deben ser evaluados como parte de la fase conceptual de un producto, y los componentes deben ser seleccionados con la seguridad en mente.
Un producto seguro debe considerar la cuna a la tumba de seguridad. Esto significa controlar y validar el proceso de fabricación de tal manera que un atacante no infiltrante puede proporcionar su propio firmware o fabricar su propio diseño de la placa en lugar del producto deseado.
Firmware / software y comunicaciones deben ser de confianza. Con el fin de confiar en algo, es necesario validarla.Así que antes de los sistemas operativos y las aplicaciones se cargan a funcionar, deben ser criptográficamente verificado como confiable. Antes de que se ejecute un comando (como "desconectar este usuario de la red eléctrica"), el comando debe ser criptográficamente validado. Esto conduce a otra serie de preguntas sobre la autoridad que tiene la autoridad para cargar el dispositivo con el nuevo código de aplicación o enviar un comando?
El proceso de diseño de equipos de seguridad no debe ser un proceso cerrado. Esto puede parecer contradictorio, pero trabajando con la industria o los consultores académicos de seguridad puede ayudar a identificar las amenazas en su sistema y los problemas con su implementación. Incluso en las zonas donde se carece de normas, un consultor de seguridad o de terceros evaluación de seguridad puede ayudar con la evaluación de las amenazas globales. Seguridad diseñado en el vacío tiene un problema: es lo suficientemente seguro para dejar sólo las personas que hicieron el diseño!
Evitar la seguridad por oscuridad. Técnicas seguras y algoritmos no deben basarse en el hecho de que la documentación de un algoritmo o programa no está disponible públicamente. Las mejores técnicas de seguridad, de hecho, no se basan en el secreto del algoritmo o esquema de protección. Por ejemplo, muchos ingenieros creen que los sistemas de comunicación que emplean salto de frecuencia son seguras porque el "salto" hace que sea difícil para un atacante para aferrarse a la frecuencia de la corriente activa y descifrar la comunicación (es decir, la frecuencia de los datos se lleva escondido en teoría ). La verdad es que el salto de frecuencia debe ser determinista de alguna manera (o el otro lado no podía predecir el lúpulo), y por lo tanto podría ser determinada por un atacante.

Un error común es que la tecnología para lograr un verdadero sistema integrado no existe. Esto es absolutamente falso: la industria terminal financiero y muchas aplicaciones gubernamentales han construido equipos contra las normas de seguridad durante años. Los procesadores pueden incrustar la tecnología de seguridad que van desde la simple (sólo un motor AES) a lo complejo (generación de entropía real, aceleración matemática modular para la criptografía asimétrica, detección de manipulación, monitoreo ambiental, código de cifrado o encriptación, y más). El Instituto Nacional de Estándares y Tecnología (NIST) de los Estados NISTIR 7816 que tecnologías como la generación real de la entropía y la criptografía asimétrica son difíciles embebido en systems.1 Abra cualquier terminal financiero y se puede ver que la tecnología existe hoy.

Conseguir la seguridad perfecta

Si seguimos los planteamientos anteriores (de comprometerse con la seguridad como un objetivo, asegurar el ciclo de vida, la validación de entradas, consultar con expertos externos, y evitando la seguridad por oscuridad), podemos lograr la seguridad perfecta? No. De hecho, nunca se puede lograr una seguridad perfecta. Cuanto más se acerque a la seguridad perfecta, el más caro se vuelve exponencial para cerrar la brecha. Diseño de seguridad es en gran medida un juego de equilibrios entre las amenazas, los riesgos y el costo de asegurar contra esas amenazas. Adopción vigoroso de las indicaciones anteriores sin duda ayudará a cerrar la brecha de seguridad por lo que están más cerca del ideal de la "seguridad perfecta". Si los dispositivos PLC atacados por Stuxnet había validado criptográficamente su nuevo código de aplicación, la ruta de ataque no hubiera sido posible. El autor Stuxnet habría tenido que considerar otro camino, tal vez tratando de obtener las llaves de la raíz a través de algún camino de ingeniería social (más amenazas que se identificarán en las primeras fases de diseño!).

Embedded Security es sólo una parte de la ecuación. Una mentalidad de seguridad debe ser aplicado a todo el sistema.Sin embargo, la seguridad integrada es a menudo más carentes de sistemas de control industrial de hoy. La aplicación de los métodos anteriores para mejorar la seguridad de los sistemas integrados sólo ayudará a mejorar el estado de seguridad de punto final-la diferencia más importante en la infraestructura crítica de hoy.

Referencias

Instituto Nacional de Estándares y Tecnología, "Computer División de Seguridad 2011 Informe Anual."http://csrc.nist.gov/publications/nistir/ir7816/nistir_7816.pdf .

Piezas relacionadas

71M6541D
Energy Meter IC
Muestras gratuitas

71M6541F
Energy Meter IC
Muestras gratuitas

71M6541G
Energy Meter IC
Muestras gratuitas

71M6542F
Energy Meter IC
Muestras gratuitas

71M6542G
Energy Meter IC
Muestras gratuitas

71M6543F
Energy Meter IC
Muestras gratuitas

71M6543G
Energy Meter IC
Muestras gratuitas

71M6543GH
Energy Meter IC

71M6543H
Energy Meter IC

DS3231
Extremadamente Preciso I ² C-integrado RTC / TCXO / Crystal
Muestras gratuitas

DS3231M
± 5 ppm, I ² C Real-Time Clock
Muestras gratuitas