17 de diciembre de 2012

TUTORIAL 5522 Sistemas Industriales necesita la protección adicional de los circuitos integrados de seguridad

Resumen: A medida que los sistemas de control industrial (ICS) se han convertido cada vez más conectado y utilizar más off-the-shelf componentes, nuevas vulnerabilidades a los ataques cibernéticos han surgido. Este tutorial se refiere a tres tipos de normas de control interno: controladores lógicos programables (PLCs), control de supervisión y adquisición de datos (SCADA), y los sistemas de control distribuido (DCS), y luego analiza los problemas de seguridad y las soluciones.En este documento también se explican los beneficios y limitaciones de dos soluciones criptográficas (cifrado y firmas digitales) y profundiza en las razones para el uso de circuitos integrados de seguridad en un ICS para apoyar la criptografía.

Una versión similar de este artículo apareció en EE Times , 7 de noviembre de 2012.

Introducción

Hasta ahora, los sistemas de control más industriales (ICS) se han diseñado principalmente para la alta confiabilidad, la seguridad y el máximo tiempo de funcionamiento. Mientras que la industria se ha centrado durante décadas en el cumplimiento de estos requisitos, seguridad digital ha sido históricamente casi no se considera en absoluto. En la década de 1990 algunas agencias gubernamentales empezó a examinar la seguridad cibernética para las infraestructuras críticas, como la distribución de energía eléctrica. Estos esfuerzos fueron siendo confidencial. Ahora, con la aparición de Stuxnet y las numerosas publicaciones que ha desencadenado, los ataques cibernéticos en contra del control industrial y sistemas de automatización son una de las principales preocupaciones de todos los interesados.

Sistemas de control industrial están en riesgo

Admitimos desde el principio que una discusión de todas las estructuras del ICS susceptible a un ataque de seguridad merecería un artículo entero. Es realmente difícil limitar nuestra discusión a unos pocos ICSs importantes, pero eso es lo que debemos hacer. Así que vamos a considerar tres tipos diferentes de una ICS.

  1. Controladores lógicos programables (PLCs), que se utilizan ampliamente para la automatización del proceso de fabricación o el control de los subsistemas. PLC se conectan a menudo como parte de una infraestructura más amplia.
  2. Control de supervisión y adquisición de datos (SCADA), que monitorean y controlan distribuidos geográficamente, infraestructuras críticas, como la distribución de agua o sistemas eléctricos de distribución de energía.
  3. Sistemas de control distribuido (DCS), que controlan procesos industriales como la fabricación de productos químicos y generación de energía. Ellos comprenden generalmente varios subsistemas automatizados.

Las implementaciones de estos sistemas puede, y, difieren en gran medida dependiendo de la aplicación industrial final.Algunos sistemas estarán físicamente concentrada, limitada a una instalación de fabricación bien definido, o extenderse a un área geográfica muy amplia. Sin embargo, todos estos sistemas operan bajo las expectativas de desempeño específicos o, para nuestra discusión, limitaciones. Por ejemplo, un sistema SCADA debe tener un alto nivel de tiempo de actividad, a ser posible "9s cinco" o "9s seis" ("cinco 9s" significa un 99,999% de disponibilidad, lo que equivale a cerca de 5 minutos de inactividad al año). Por otro control industrial y sistemas de automatización, la restricción de rendimiento más importante podría ser tiempos de reacción extremadamente rápidos.

Así ICSs pueden ser similares, pero diferentes enormemente. Sumado a esto, vemos dos tendencias hoy en día. ICS se están volviendo más y más conectados, y que están utilizando más estándar, off-the-shelf componentes como las estaciones de trabajo que se basan en un software estándar, tales como el sistema operativo Windows ® o la comunicación sobre IP. Estas tendencias crean nuevas vulnerabilidades a los ataques cibernéticos.

IT Technologies, en un entorno industrial, no siempre un ajuste perfecto

ICS también están incorporando las tecnologías utilizadas en TI, pero las normas de control interno todavía deben operar dentro de sus objetivos de desempeño específicos o restricciones. Hay una consecuencia importante e inmediata de esta convergencia de tecnologías: algunas amenazas a los componentes de TI estándar ahora también se aplican a los CI. Sin embargo, debido a sus objetivos de rendimiento y ambientes de trabajo, las soluciones de seguridad utilizado en el mundo de las TI no son necesariamente aplicables a los CI.

Antes de entrar en una inmersión profunda en los detalles, vamos a tomar un ejemplo simple. Un sistema SCADA es el control de la presión de agua de refrigeración en una instalación industrial y se espera para emitir una alarma cuando una pérdida de presión es detectada. En esta situación de emergencia potencial, queremos que el operador tome medidas inmediatas.

Consideremos ahora la respuesta de un operador en un clásico de la infraestructura de TI. Después de algunos minutos de inactividad la estación de trabajo es probable que haya cerrado en sí, el operador debe introducir su contraseña para iniciar sesión y, por lo general después de tres intentos fallidos, la estación de trabajo se bloquea de nuevo. Ahora el operador necesita contactar a un administrador para obtener el restablecimiento de contraseña. El tiempo está pasando. Un procedimiento similar, reiterativo sería devastador en un entorno industrial. Con un ICS en esta emergencia, queremos un operador para actuar de inmediato, cualquier vacilación es una pérdida de tiempo crítico. Este es un ejemplo de un estándar muy IT procedimiento que es no aplicable, e incluso es perjudicial, para un ICS.

Las amenazas a los sistemas de control industriales

No se puede confiar en la arquitectura personalizada de los ICS para protegerlos de amenazas electrónicas.Históricamente, los ataques cibernéticos no se consideraron graves amenazas a los sistemas de control y automatización de redes de partida de la ICS porque estaban aislados ya sea o no seguir las normas de TI. Podemos hacer tres observaciones importantes acerca de esto.

  1. Las redes de control y automatización están cada vez más conectados a redes estándar y abiertos porque necesitan interactuar con otros sistemas.
  2. En la industria, un protocolo propietario fácilmente puede hacer ingeniería inversa a un costo razonable. El peligro aquí es que cualquier debilidad en ese protocolo nunca se han estudiado, comprendido, o remediar. Es peligroso pensar que un protocolo propietario ofrece seguridad sólo porque su conocimiento no es del dominio público. Esta suposición ha demostrado ser erróneo y equivocado, es la "seguridad por oscuridad" concepto ¹ Esta vulnerabilidad de protocolos inseguros contrasta marcadamente con los protocolos de conocimiento público y de confianza para que las amenazas y las respuestas son bien comprendidos..
  3. Las redes no son el único camino para los ataques cibernéticos. En consecuencia, una infraestructura aislada en un ICS podría ser vulnerable a los medios de ataque tales como USB claves o consolas de mantenimiento.

Al igual que las redes industriales no seguir los protocolos documentados y conocidos, así también la arquitectura patentada de PLCs normalmente no ofrecen una protección de seguridad. Stuxnet es desafortunadamente un muy buen ejemplo de esto. Es cierto que Stuxnet sólo se daña el software propietario y los autómatas con una configuración específica. Este malware no podría haber sido diseñado sin un profundo conocimiento de los sistemas específicos se focalización. "La seguridad del sistema no debe depender del secreto de la aplicación o de sus componentes". ² En efecto, esta solución hace que el hardware (el PLC en este contexto) demasiado vulnerable. Así que, de nuevo, no se puede afirmar con demasiada frecuencia: no se puede confiar en la arquitectura personalizada de ICS para actuar como una protección contra las amenazas electrónicas.

Mientras que los CI tienen una arquitectura diferente de la típica infraestructura de TI y cumplir con diversos requisitos, sin embargo, la mayoría de las amenazas a los genéricos de las infraestructuras de TI también puede afectar ICS. Por desgracia, la lista de esas amenazas es larga y preocupante: la inyección de malware como gusanos o virus, los cambios de software o hardware de configuración, los mensajes falsos u órdenes de un atacante, el robo de identidad, y la observación no autorizado.

En resumen, nos enfrentamos a una situación extremadamente difícil. ICS amenazas de seguridad son similares a los que acosan infraestructura de TI, pero con demasiada frecuencia los requisitos específicos para el funcionamiento ICS no permiten la reutilización de las contramedidas de seguridad conocidos!

Ponga el más alto nivel de las contramedidas Dentro del ICS

Siendo la seguridad una preocupación generalizada para aplicaciones industriales y automatización, las contramedidas y acciones de mitigación están siendo implementados. Hasta ahora, la mayoría de estas medidas defensivas han incluido los procedimientos de seguridad, el medio ambiente y la protección física y la educación del personal. El propio ICS sigue siendo vulnerable. Antes de dar el salto a criticar a la comunidad industrial para estas mínimas precauciones, debemos recordar que se trata de cómo la seguridad se inició en el dominio de TI tradicional. Este es realmente el primer nivel de protección, una base que debe ser el inicio.

Estas tácticas de defensa tradicionales no, de cualquier manera, proporcionar el máximo nivel de protección necesario para un ICS. Procedimientos, aunque auditado de forma regular, nunca son 100% seguido, la protección física, como puertas de cierre pueden ser anuladas y no se puede aplicar en todas partes. Lo más importante es manual de procedimientos defensivos no cubren los ataques realizados por personas altamente cualificadas con el tiempo y el presupuesto para construir los escenarios más sofisticados. Lo que es peor, hay ejemplos donde el soborno llevado a los operadores de ICS para eludir los procedimientos.

No, la respuesta de seguridad está embebido. Es en el hardware ICS. La jerarquía de nivel superior de las contramedidas de seguridad implica genéricos de TI medidas de seguridad, tales como la criptografía y seguridad de hardware ( Figura 1 ).

Figura 1.  La jerarquía de las medidas de seguridad.
Figura 1. La jerarquía de las medidas de seguridad.

Genéricos de soluciones de seguridad son a veces ya no en el software. Algunas infraestructuras ya están protegidos por firewalls, algunos protocolos de seguridad a través de IP, tales como TLS / SSL también se aplican. Aunque una vez más, todas las etapas de la pirámide son necesarios, ahora vamos a describir la forma en seguridad basada en hardware ofrece el máximo nivel de protección.

Proteja el ICS con Embedded Criptografía

Genéricos políticas de TI no pueden aplicarse sistemáticamente a la amplia gama de normas de control interno en el trabajo en la industria. Sin embargo, existe una tecnología utilizada universalmente en el mundo de TI que puede ser implementado: la criptografía.

Criptografía responde a la mayoría de las amenazas mencionadas anteriormente. Aún así, no es una varita mágica y el enfoque no puede ser tan simple como, "Voy a añadir crypto a mis ICS y de repente va a ser seguro." Algoritmos criptográficos y protocolos son bloques de construcción que se deben implementar en una base de caso por caso, después de un análisis exhaustivo de las amenazas para cada subsistema. Reformulado simplemente, la criptografía es una herramienta común para los ICS y la infraestructura de TI, pero su aplicación en un ICS deben adaptarse al sistema específico. Dentro de la amplia gama de técnicas criptográficas, dos son muy importantes para un ICS: firma electrónica y cifrado. Vamos a examinar los méritos de ambas técnicas para un ICS.

Firma digital . Estas técnicas se utilizan para autenticar mensajes, pedidos, o piezas de software. Consideremos dos ejemplos de un SCI.

  1. En un sistema SCADA, que quiere confiar en la información proveniente de un sensor de campo. Es necesario saber que viene desde el sensor real en su ubicación física, que no está falsificado la información enviada por un atacante para perturbar el sistema. Cuando la información enviada está firmado digitalmente por el módulo de sensor o sensor, la unidad de recepción de terminal remota (RTU) puede verificar que el mensaje procede de un sensor genuino y autorizado ( Figura 2 ). Este procedimiento también funciona en la otra dirección, es decir, en orden descendente de un actuador firmado por su originador. El mismo método puede ser utilizado para la comunicación entre la RTU, PLC, y el sistema maestro SCADA.

    Figura 2.  Una firma digital se aplica a una lectura del sensor.
    Figura 2. Una firma digital se aplica a una lectura del sensor.

  2. Las firmas digitales también permiten a un sistema para verificar que un paquete de software o actualización de software proviene de una confianza fuente . Usemos el ejemplo Stuxnet nuevo. El código malicioso se inyectó en los PLC y los motores de conducción a una velocidad inesperada. Esto hace entonces que los PLC para ejecutar un proceso de fabricación equivocado. ³ Si, sin embargo, todo el software y las actualizaciones de software están firmados digitalmente antes de ser descargado al PLC, el PLC puede verificar que el software es original antes de comenzar su ejecución.

Este mismo principio de firma digital puede proteger un sistema contra cambios de configuración de hardware. Por ejemplo, los atacantes pueden modificar los datos de calibración del sensor. A continuación, los sensores mal configurados que enviaría información errónea a sus sistemas principales, de nuevo molestar a los procesos industriales. Particularmente vulnerables a este tipo de ataque son sistemas de gran escala se distribuyen en una amplia zona geográfica, como la distribución de fluidos, por ejemplo, en el cual no se puede garantizar el acceso físico a cada ubicación del sensor. Un proceso de firma digital resuelve este problema. Cuando se envía información de medición a un maestro, el módulo de sensor o sensor también puede enviar sus datos a lo largo de "firmado" de calibración. Alternativamente, el maestro puede sondear los sensores de forma regular mediante el envío de un desafío y esperando una respuesta firmada, que incluye un resumen de la calibración o de los datos de configuración.

Una firma digital también se puede utilizar para autenticar hardware. Esto es útil, por ejemplo, cuando la RTU se conecta a una red SCADA. Es evidente que uno no querría tener desconocido (es decir, no autenticado) hardware recibir y enviar información crítica, sino más bien sólo hardware genuino usado para construir un ICS crítico. Aquí es donde una firma digital autentica hardware y crea confianza.

Cifrado . Esto también es una técnica útil, ampliamente utilizado para proteger contra la divulgación de información.Recetas de fabricación son a menudo valiosos activos, ya que pueden contener todos los conocimientos necesarios para la fabricación de productos. Mediante el control de datos de los sensores o los parámetros de los actuadores, se puede obtener información valiosa acerca de un proceso de fabricación o de los datos personales, incluso individuales. Hay, por ejemplo, muchas publicaciones sobre los atacantes conociendo el comportamiento del usuario mediante el seguimiento de su consumo de electricidad a través de la red inteligente. El cifrado de datos a través de redes ICS impediría dicha divulgación y que se aplica como en un clásico de la infraestructura de TI.

¿Por qué utilizar circuitos integrados de seguridad para apoyar la criptografía?

Hasta ahora hemos discutido algunas aplicaciones de la criptografía para la seguridad de ICS. La criptografía se suelen implementar en software, por lo que ¿por qué utilizar un CI de seguridad en una ICS? Hay varias razones para ello. Circuitos de Seguridad realmente ofrecen varias ventajas específicas: el almacenamiento seguro de claves, la protección contra la divulgación clave a través de ataques de canal lateral, la simple aplicación de la criptografía libre de errores; cálculo acelerado, la calidad de números aleatorios, y de confianza a través de un software de arranque seguro.

Almacenamiento seguro de claves

Un concepto es tan importante que no podemos exagerar: cualquier implementación de seguridad debe usar algoritmos estándar de cifrado, por ejemplo, AES, Triple DES para el cifrado simétrico, RSA , ECDSA para la criptografía de clave pública. Y así, dentro de estos sistemas de cifrado, los activos más valiosos son las claves. Cuando la criptografía se implementa en el software de un procesador estándar, las claves de cifrado se almacenan en la memoria del sistema de propósito general y, por lo tanto, se puede recuperar fácilmente a través de malware, un puerto de depuración (JTAG), o un ataque físico. Seguridad circuitos integrados reducir drásticamente estas vulnerabilidades.

  • Microcontroladores seguros integrar la protección lógica. Asegure arranque y la unidad de gestión de memoria del microcontrolador (MMU) proteger contra la inyección de malware. El puerto JTAG se puede desactivar.
  • Seguridad circuitos integrados integrar contramedidas tales como el metal escudo, sensores ambientales, y los sensores externos de malla contra la manipulación física. Además, su memoria interna o externa pueden ser codificados. El nivel más alto de protección sería la destrucción automática de claves si se detecta manipulación.
Protección contra la Llave de ataques de canal lateral

El consumo de energía de un microcontrolador depende obviamente de su actividad. Al monitorear el consumo de energía durante la actividad de cálculo criptográfico, se puede recuperar las claves criptográficas. Otros ataques de canal lateral se basan en la emisión electromagnética (EME).

Los circuitos integrados de seguridad más avanzados implementar contramedidas contra ataques de canal lateral, por lo que es imposible de recuperar las claves a través de los canales laterales.

Implementación de confianza, libre de errores Criptografía

Una debilidad común que se encuentra en los sistemas de aplicación de la criptografía es una parcial o "falsa" la ejecución del algoritmo. Un algoritmo defectuoso hace que el ICS vulnerable y puede conducir a ataques con éxito unos meses después del lanzamiento del producto. Mediante el uso de un circuito integrado de seguridad desde el principio del diseño del sistema, sin embargo, un diseñador de ICS puede estar seguro de que la aplicación de los algoritmos es libre de errores. Ese nivel de seguridad puede ser aún más gracias a un aumento de terceros evaluación o certificación de un estándar dado.

Computación Acelerado

En ICS, el tiempo de respuesta es de capital importancia. Por ejemplo, se puede esperar una medición de un sensor que se enviará a la RTU de un SCADA principal controlador dentro de un plazo dado. Con los motores de criptografía de hardware incorporada, circuitos integrados de seguridad ofrecen un mejor rendimiento que las soluciones de software. Además, la medición nuestro sensor puede ser digitalmente "firmado" antes de que sea enviado, incluso si el controlador de sensor en sí tiene el rendimiento computacional limitado. Seguridad ICS también puede descargar un procesador de aplicaciones si éste cuenta con recursos limitados de computación.

En los más pequeños, los sistemas más restringidos, como módulos de sensor, la capacidad informática (típicamente un microcontrolador de 8-bit) para ejecutar una operación matemática sofisticada podría no existir. En estas situaciones, la adición de un IC seguro es a menudo la única opción para tener potencia de cálculo suficiente para la criptografía sin rediseñar el sistema.

Microcontroladores seguros puede incluso agregar una solución de seguridad completa, tales como el manejo de protocolos completos de seguridad, como TLS / SSL.

Calidad de números aleatorios

Un método común de ataque contra los sistemas supuestamente protegidos por criptografía es el llamado ataque de repetición . Este concepto es bastante simple: un atacante registra un mensaje cifrado o firmado (aunque el atacante no puede descifrar o entender) y envía el mensaje grabado un momento después. Nuestro ejemplo de medición de sensor firmado digitalmente ilustra el problema. Supongamos por el momento que la presión del agua en una tubería remoto es normal. El sensor informa de la presión normal en el tubo de agua y envía este mensaje al controlador principal SCADA. El atacante registra este mensaje. Cuando el sensor detecta después de una presión anormal, el atacante ahora interviene.Las repeticiones atacante el mensaje grabado anteriormente y confunde al controlador en la creencia de que el sistema está en modo de funcionamiento estándar con presión normal. Dado lo que sabemos en nuestra situación ejemplo, sin embargo, se esperaría que el sistema SCADA para reportar una alarma. La norma de protección contra tal ataque de repetición es introducir un número al azar en la transacción, y así evitar la reutilización (repetición) de una transacción anterior.

No todos los generadores de números aleatorios son de igual calidad. Ha habido casos en que se ha recuperado una clave secreta en los sistemas que dependen de la mala calidad de los generadores de números aleatorios. Esta es la peor situación que uno puede imaginar. Ahora, la criptografía se vuelve inútil. 4 ¿Cómo sucede esto? En un microcontrolador estándar de la aleatoriedad de la cantidad generada no está garantizada. Compárese esto con seguridad ICs, donde el número aleatorio generador está diseñado satisfacer criterios exigentes en términos de entropía y también se prueba con métodos estandarizados.

Software Trusted Secure Boot través

Desafortunadamente, Stuxnet es una brillante demostración de la importancia de este tema. Operadores de sistemas y diseñadores deben asegurarse de que todos los equipos en los que un SCADA o DCS se construye un sistema funciona bien identificados, pieza genuina de software. Arranque seguro y la gestión de actualizaciones seguras son las maneras de proteger un dispositivo de inyección de malware o software no fiable. Ambos tipos de gestión se llevan a cabo en las más nuevas del estado-of-the-art microcontroladores seguros.

Circuitos integrados de seguridad son los dispositivos de hoy Ultimate Protection

Circuitos de seguridad actual integrar varias funciones diseñadas para garantizar la seguridad de un ICS o cualquier sistema crítico 24/7. DeepCover ™ soluciones de seguridad integradas de ocultar datos sensibles en virtud de múltiples capas de seguridad física avanzada para proporcionar el almacenamiento de claves más seguro posible.

DeepCover autenticación integrados, como el DS28E15 , habilitar criptografía fuerte autenticación, o rechazo, de un subsistema que constan en su sistema principal. Empleando el SHA-2 protocolo de autenticación, se puede autenticar lasE / S de los módulos de expansión de un PLC. Se pueden almacenar con seguridad y firmar digitalmente los datos de configuración y calibración de un módulo sensor, lo que impediría que ser reemplazado por un dispositivo falso o que tengan sus principales parámetros cambiados por un atacante.

Los directores de seguridad almacenar de forma segura las claves secretas. Además, el DS3645 puede desencadenar una destrucción clave cuando se detecta un sabotaje, el MAX36025 gerente de seguridad compatible con la autenticación y el cifrado AES. DeepCover administradores de seguridad se puede añadir a un microcontrolador existente, lo que evita portar software a partir de un diseño anterior.

Asegure los microcontroladores proporcionan un almacenamiento seguro de claves, poner en práctica arranque seguro, habilitar la protección del software lógica, y ofrecen la máxima flexibilidad para la aplicación de la criptografía a nivel de protocolos como el PKCS # 11. También soporta los protocolos de red y descargar el procesador del sistema principal de las operaciones criptográficas. Dispositivos como el MAXQ1050 ya están ofreciendo esta completa gama de servicios de contadores inteligentes. El nuevo MAX32590 ARM926 ™ basado en microcontrolador con su BSP Linux ® es una solución de un solo chip para dispositivos de comunicación seguros como puertas de enlace.

Conclusión

Hemos dicho mucho y tal vez ahora preguntar: "¿Estamos protegidos contra los ataques cibernéticos porque estamos usando ICS de seguridad?" La respuesta no es un simple "sí". La seguridad del sistema completo requiere una identificación exhaustiva de los activos que deben protegerse y un análisis en profundidad de las amenazas antes de cualquier implementación de la solución. La seguridad efectiva depende en gran medida de la aplicación de una serie de medidas criptográficas que software y hardware puente.

Sin embargo, después de un riguroso análisis, vemos que los circuitos integrados de seguridad sin duda elevar la protección de las normas de control interno al más alto nivel.

Referencias
  1. Scarfone, K., Jansen, W., y Tracy, M., NIST Special Publication 800-123 , Guía General de Security Server , julio de 2008, http://csrc.nist.gov/publications/nistpubs/800-123/ SP800-123.pdf .
  2. Ibid.
  3. Para obtener un informe de Symantec sobre Stuxnet, ver Falliere, N., Murchu, LO, y Chien, E., Dossier W32.Stuxnet , Versión 1.4, febrero
  4. Para un análisis de las necesidades de dietas por valor k aleatorio, véase Lawson, N., "Requisitos de DSA para el valor k azar," root laboratorios rdist, 19 de noviembre de 2010, http://rdist.root.org/2010/11/19 / dsa-requisitos-para-random-valor k / .

DeepCover es una marca comercial de Freescale Semiconductor, Inc. Linux es una marca registrada de Linus Torvalds.Windows es una marca registrada y marca de servicio registrada de Microsoft Corporation.



Piezas relacionadas

DS28E15
DeepCover autenticador seguro con 1-Wire SHA-256 y 512-bit del usuario EEPROM
Muestras gratuitas

DS28E22
DeepCover autenticador seguro con 1-Wire EEPROM SHA-256 y 2Kb usuario
Muestras gratuitas

DS28E25
DeepCover autenticador seguro con 1-Wire EEPROM SHA-256 y 4Kb usuario
Muestras gratuitas

DS3645
DeepCover Security Manager con 4KB de memoria Secure y Protección contra intervenciones
Muestras gratuitas

MAX32590
DeepCover Microcontrolador seguro con ARM926EJ-S Procesador Core

MAX36025
DeepCover Security Manager para Tamper-reactiva-Nodo de Control de cifrado con cifrado AES y Memoria Nonimprinting

MAXQ1010
DeepCover Microcontrolador seguro de tokens de seguridad con RTC y USB

MAXQ1050
DeepCover microcontrolador con USB Secure y Criptografía Hardware

No hay comentarios:

Publicar un comentario