Arquitecturas de seguridad en la nube para la industria

Publicado el 09/12/2015, por INCIBE
Arquitecturas de seguridad en la nube para la industria

Pocos son los que dudan de los beneficios que las aplicaciones basadas en la nube pueden traer a la industria en los próximos años. Los sistemas de producción inteligentes y distribuidos serán una pieza clave de la innovación en este sector. La flexibilidad, ubicuidad de acceso y la gran capacidad de computación de los sistemas basados en la nube posibilitarán una gestión integrada, no sólo de las fábricas entre sí sino de toda la cadena de valor desde los proveedores hasta el consumidor.

Sin embargo, para que este prometedor paradigma se convierta en una realidad son varios los retos a los que se han de enfrentar los sistemas de control:

  • Disponibilidad y latencia: Algunas de las aplicaciones industriales, como la lectura de medidas en tiempo real a través de arquitecturas como la definida en IEC_61499 o los sistemas de gestión de procesos en tiempo real, para utilizar servicios distribuidos de la nube deben minimizar el tiempo de latencia y por ello debe haber algún nodo en las proximidades del punto de control. Hay que tener en cuenta que determinadas medidas de seguridad como el cifrado de datos perjudican la latencia.
  • Integridad y seguridad de datos en tránsito y en reposo: en los sistemas SCADA en la nube, que a veces controlan infraestructuras críticas, la integridad de los datos recogidos por la red de control es crucial. Así mismo, la seguridad de los datos también debe estar bajo control, para lo cual es recomendable implementar desde el principio una política de “necesidad de saber” (need-to-know) limitando el acceso a la información al personal necesaria para la realización del proceso.
  • Confianza y cumplimiento de normativa de protección de datos: A la hora de elegir el proveedor de cloud hay que evaluar la fiabilidad y confianza que nos da. Existen numerosos trabajos de investigación en la línea de sistematizar la solicitud de garantías de seguridad y privacidad a los proveedores de cloud, no sólo en los contratos o SLA (Service Level Agreements) (p.ej. algunos proyectos de investigación financiados por Europa, la CCM (Cloud Control Matrix) y el PLA (Privacy Level Agreement) de la Cloud Security Alliance), sino también en los protocolos de transparencia de los métodos de seguridad que emplean (p.ej. el CTP (Cloud Trust Protocol) de la Cloud Security Alliance).

Opciones de arquitecturas para aplicar al despliegue de la nube en un entorno seguro

Básicamente, los sistemas SCADA pueden aprovecharse de los servicios de la nube de dos formas diferentes:

Las peculiaridades de seguridad para esta arquitectura son las siguientes:

Nube privada/híbrida

- PLC y sistemas de control conectados directamente a través de comunicaciones WAN a nube híbrida/privada -

  1. La aplicación SCADA se ejecuta en servidor/es local/es y se conecta directamente con la red de control centralizada por un lado y con la nube por otro, para almacenamiento y distribución (visualización) de los datos de control.

    Nube pública

    - Control del SCADA on-site con entrega de información a través de una nube pública -

    • El control y actuación del sistema SCADA queda dentro de la organización. La información que se envía fuera es tratada través de la nube mediantes aplicaciones SaaS de SCADA para la visualización de los datos, pero no de control ni actuación.
    • En este tipo de arquitectura la nube suele ser pública. La industria debe solicitar transparencia a los proveedores de cloud, p.ej. a través del protocolo CTP, para ello se debe considerar que el proveedor pueda ofrecer la siguiente información:
      • Iniciación: identificación e inicio de sesión del servicio de petición de evidencias, de forma transparente y entre pares.
      • Petición de evidencias: configuración, análisis de vulnerabilidades (hipervisor, SO del destinatario, switches virtuales y cortafuegos virtuales), estado (situación geográfica e identificación de las unidades separadas de la plataforma), auditoría, gestión de servicios (indicador de cambios de registros de los propios servicios) y provisión de estadísticas de servicios
      • Aserciones del proveedor: listado de las capacidades ofrecidas por el proveedor de cloud, tanto de funcionalidad (por ejemplo flexibilidad, configuraciones, etc.) como de seguridad (prácticas y controles de seguridad y de privacidad, informes de auditorías, certificados, etc.)
      • Notificación de proveedores: alertas sobre eventos de confidencialidad, integridad y disponibilidad.
      • Introducción a las políticas de seguridad: provisión de políticas para los mecanismos de identificación, autenticación y autorización (AAA), configuración, localización y alertas.
      • Extensiones: cualquier elemento, incluso de seguridad, que quiera extender el cliente al proveedor de cloud.
    • El acceso de los usuarios a la aplicación sólo debe ser de lectura. La aplicación (SaaS) no debiera realizar ningún tipo de actuación para restringir al máximo el riesgo (no existe comando o actuación de fuera hacia dentro, de forma análoga a la idea de un diodo de datos).
  2. La aplicación SCADA se ejecuta en la nube y se conecta de forma remota a la red de control distribuida. Un ejemplo de esta segunda opción son los llamados SCADA as a Service, mencionados en el artículo Mi SCADA en las nubes.

Las peculiaridades de seguridad para esta arquitectura son las siguientes:

  • En este caso se permite el telecontrol desde la nube. La seguridad debe ser completa en todo el recorrido (end-to-end security). La seguridad no tiene que tener fisuras, desde el uso de protocolos industriales que soporten autenticación y cifrado como Secure DNP3, hasta el procesado y almacenamiento seguro en la nube.
  • La latencia generada por la incorporación de los mecanismos de seguridad debe ser considerada, ya que en las comunicaciones se transmiten tramas de datos tanto críticos como no críticos.
  • Para que pueda existir un control desde la nube hasta los dispositivos de la organización, es necesario abrir los puertos del cortafuegos que dan acceso a la red interna. La apertura debe estar justificada, monitoriza y restringida a aquellos usuarios autorizados y casos estrictamente necesarios.
  • El hecho de que haya tráfico de datos y comandos de control hace que sean comunicaciones más atractivas para ser atacadas y puedan sufrir ataques de “hombre en el medio” (Man In The Middle), o incluso modificaciones de los paquetes durante el camino. Esto puede hacer que los valores que introduzca un operario en la nube cuando lleguen al dispositivo tengan otro valor totalmente diferente pudiendo poner en peligro la operación. Para prevenir este tipo de ataques es necesario el cifrado de la información.

En ambos casos, el modelo de provisión de los servicios de la nube puede ser público, privado o híbrido. Y es el segundo escenario el que se prevé se adopte masivamente en un futuro próximo.

Tanto si la aplicación SCADA se ejecuta en local (opción 1) como en la nube (opción 2), a la hora de proteger la seguridad en la capa de infraestructura se debe controlar el acceso a los recursos virtuales. Hay varias opciones para realizar esto:

  • Acceder a través de VPN (Virtual Private Network) o proteger la red interna con una instancia que haga de frontal y añadirle balanceadores de carga y un servidor NAT (Network Address Translation).
  • Configurar las reglas y grupos de seguridad para que sólo se otorgue acceso explícito a los mínimos puertos necesarios en los servidores virtuales.
  • Proteger el acceso SSH mediante el uso de pares de claves y modificar el puerto de acceso SSH por defecto en la configuración SSH de la máquina.

El hecho de tener todos los datos y el control en un único punto centralizado hace muy atractiva la utilización de la nube, sobre todo la segunda arquitectura mostrada. Sin embargo, hay que valorar la latencia de aquellos datos que necesitan leerse en tiempo real y la seguridad de los mismos. Antes de contratar con un proveedor de cloud se debe verificar que contempla las medidas de seguridad planteadas en el artículo: autenticación, cifrado, protocolos seguros, etc. Además la infraestructura debe contar con las características adecuadas para que pueda hacer uso de la nube como en el caso de Secure DNP3.

Por todo lo comentado, es necesario hacer una valoración de la infraestructura y los servicios que ofrece el proveedor antes de migrar a la nube.

Arquitecturas en la nube

En definitiva, si se está buscando tener un mejor tiempo de latencia y tener mayor control propio sobre la seguridad se debe optar por una arquitectura on-site. Si por el contrario, no se tienen muchas restricciones de latencia y se desea tener un control de los procesos industriales desde un único punto, por ejemplo, para organizaciones muy distribuidas, esta es la solución a elegir.