Tribuna de opinión. Por Adriel Regueira, Regional Sales Engineer de Nozomi Networks
En los últimos años, el modelo de seguridad Zero Trust o la arquitectura Zero Trust ha ganado popularidad entre audiencia técnicas y no técnicas.
No es difícil de entender las razones detrás de este éxito: el enfoque de confianza por diseño está anticuado y ha demostrado cómo de mal pueden funcionar las cosas cuando un dispositivo o aplicación es fiable a priori, sin ninguna consideración dinámica de contexto. En pocas palabras, suponer que los dispositivos y las aplicaciones son de confianza solo porque están en la misma red es una suposición antigua, insegura e incorrecta.
No hay duros a cuatro pesetas
Este antiguo refrán refleja a la perfección lo que queremos explicar. Aplicar adecuadamente ZT requiere estudiar cómo los sistemas interactúan, lo que necesitan cada uno de otro y cómo minimizar el acceso a la información. Esto podría parecer sencillo, pero no lo es: especialmente si los sistemas de interacción ya existen y necesitan evolucionar o ser adaptados para implementar ZT en un futuro.
Como profesionales de la ciberseguridad, no queremos hacer un trabajo para cubrir el expediente. Queremos implementar lo que la teoría dice de la manera más rigurosa o acabaremos tratando con los mismos problemas que el enfoque confianza por diseño (con alguna complejidad extra). Piensa en la cantidad de veces que ese certificado TLS local auto firmado es aceptado -incluso- de forma insegura y nunca se despliega correctamente con uno emitido por una Autoridad de Certificación. Hay infinidad de ejemplos.
Como sugiere el adagio popular, hay mucho que hacer para lograr realmente este objetivo. En principio, el final deseado de una implementación de ZT requiere que todos los componentes (no algunos, ni los más importantes, ni solo los conocidos, sino todos) interactúen entre sí con todas las verificaciones de acceso establecidas. Pero para conseguirlo, necesitamos que todos los dispositivos, aplicaciones y protocolos de comunicación se diseñen teniendo en cuenta el modelo de seguridad Zero Trust. ¿Es esto posible hoy en día en todos los casos? No. Pero podemos trazar un plan para conseguirlo.
Para conseguir un estado Zero Trust, veo dos hitos principales: el primero donde los viejos hábitos de la confianza por diseño son eliminados, pero los problemas todavía persisten por las limitaciones de la tecnología y el segundo en el que cada pieza del sistema apoya el enfoque ZT.
Mientras que el primer hito debería conseguirse sin ningún esfuerzo, el segundo hito llevará más tiempo y es probable que se produzca de forma gradual. Más importante aún, esto requerirá que los mejores talentos al servicio de la tecnología cooperen en las distintas comunidades de estandarización.
Eliminar los prejuicios: un primero hito hacia el modelo Zero Trust en entornos OT e IoT
El mantra del modelo Zero Trust es no confiar por diseño, pero siempre verificar si un usuario que se ha autentificado en una aplicación/dispositivo/sistema tiene los permisos para acceder a un recurso dado, en un contexto determinado (donde parte de este contexto es el estado del dispositivo).
Esto es suficientemente genérico para trabajar, pero los problemas surgen en los detalles. ¿Cómo de granular es el sistema que solicita el acceso a un recurso? ¿Es un dispositivo completo, una aplicación o una sesión concreta? O incluso más granular o detallado que eso? Y, ¿Cómo de grande es el recurso al que se le está pidiendo acceso? ¿Es un sistema completo, un archivo, un documento o una variable?
Recuerda: No queremos cubrir el expediente
Nuestro objetivo para este primer hito es construir el esqueleto del modelo ZT- sin asumir que es el final del juego. En el documento NIST.SP.800-207, se describen tres principales enfoques para adoptar la arquitectura ZT: ZTA Using Enhanced Identity Governance, ZTA Using Micro-Segmentation and ZTA Using Network Infrastructure and Software Defined Perimeters. Ninguno de ellos es fácil de conseguir ni garantiza la plena compatibilidad con los sistemas existentes
Podemos implementar algunos puntos de las normativas de Policy Decision and Enforcement, como agentes y/o cortafuegos debidamente capacitados y configurados. Definitivamente esto es parte del primer hito: eliminar el prejuicio o la inclinación hacia “misma LAN=más seguro” y empezar a pensar de una forma diferente. Pero si lo miramos con más detenimiento, no resolverá completamente el problema que el modelo ZT quiere solucionar.
Veamos la razón
Pensemos en una instalación OT mínima con un HMI o SCADA que se conecta con un PLC utilizando Modbus, DNP3 o IEC 104. Y supongamos que conseguimos desplegar un agente con ZT en el HMI y microsegmentar la red para que los dos players tengan una red dedicada para comunicarse. Podríamos incluso tener una actualización maliciosa (digamos, por ejemplo, un ataque a la cadena de suministro donde el proveedor de automatización ha sido comprometido) que ha sido instalada en el HMI durante el mantenimiento vía USB.
Debido a las limitaciones de protocolo, será complejo (o prácticamente imposible) permitir un acceso granular al PLC por el nivel semántico de la app; por ejemplo, los sensores/actuadores controlados. Con la terminología ZT en mente, no será tan sencillo limitar el concepto de recurso a un área lo suficientemente pequeña, sino que probablemente será todo el PLC. Todo o nada.
Los protocolos de comunicación vuelven a plantear un reto similar: el ejemplo anterior utilizaba protocolos abiertos y estándar.
Otro reto está relacionado con la autenticación de la sesión sin cambiar de aplicaciones: muchos protocolos OT e IoT, ya sea porque no tienen la autorización o autenticación embebida, o porque son modelos muy básicos para eso. Y todavía, los operadores a menudo entran al sistema con cuentas compartidas, pero esa es otra historia.
¿Qué pasa con el estado de los activos?
Cambiando de tema, debemos hablar del estado de los activos. Un activo debe tener acceso a los recursos también teniendo en cuenta su estado. Esto significa que, si los parches no son aplicados, un antivirus que no está instalado en el endpoint o que tiene las firmas anticuadas, esos activos deberían tener solo acceso a los servicios que les permitan ser actualizados e intentarlo de nuevo. Por ejemplo, en entornos OT, es bastante común que los proveedores de automatización validen las actualizaciones de Windows antes de permitir que se instalen en los HMI. Una implementación pragmática del modelo ZT debería tener esto en cuenta y permitir cierta brecha/distancia en los parches. De nuevo el modelo ZT teóricamente no será totalmente aplicado, dejando espacio a riesgos no gestionados, en última instancia, por una falsa sensación de seguridad completa y absoluta.
Ahora debería estar claro que los retos relacionados con el protocolo hacen que ZT sea implementable, pero con algunas limitaciones y compensaciones dadas en última instancia por las especificaciones y contextos heredados.
Corregir las viejas limitaciones: Un segundo hito hacia la confianza cero para OT e IoT
El primer hito consiste en eliminar la vieja actitud o creencia de que dos dispositivos que conviven en la misma red tienen más confianza que otros. Pero como hemos visto con anterioridad, no es posible hacer una perfecta implementación en este momento. Con este segundo paso, queremos solucionar esas deficiencias.
Y no será solo para nosotros. Esto no puede ser un hito para el cliente X, Y o Z. Esto necesitará más tiempo y cooperación y será sobre todo como una asíntota a la que apuntar, lo que significa que, en ciertas situaciones, este segundo hito nunca estará «hecho» o «completado». Pero, será más completo a medida que cada pieza del rompecabezas vaya en el lugar correcto.
En cuanto a las limitaciones de los protocolos, hay dos enfoques posibles: o bien los protocolos estándar evolucionan para incorporar los principios de la ZT y son adoptados por la industria, o bien los distintos vendedores adaptan y evolucionan los protocolos y proporcionan una solución (¿un agente?) para implementar adecuadamente la ZT.
Para permitir la autenticación y la autorización para embeber los protocolos estándares en los flujos y tener un acceso más granular a los recursos, los esfuerzos deben hacerse en diferentes frentes. Por ejemplo, en el dominio power systems, la familia de estándares IEC 62351 está añadiendo útiles bloques para hacer implementaciones ZT más avanzadas. La organización de desarrollo de estándares ODVA ha mejorado el protocolo de comunicación EtherNet/IP OT, añadiendo una amplia actualización con la extensión CIP Security.
Permitir que los protocolos evolucionen y ofrezcan características de seguridad adecuadas para todos los verticales y contextos llevará tiempo. Una buena idea es unirse a los grupos de trabajo que definen lo que es importante para usted y mantenerse al día o incluso contribuir a las evoluciones necesarias.
Sin duda hay otros aspectos que necesitan revisión, como por ejemplo la rapidez del parcheado frente a la garantía de una calidad adecuada. Llevará tiempo mejorar la infraestructura de software para permitir una validación más rápida y automática y, al mismo tiempo, una buena integración con los servicios de comprobación de estado de los activos, para permitir que el PDP/PEP tome la decisión correcta dado el contexto
Pero… ¿Entonces qué pasa con el modelo Purdue?
El mundo de la tecnología está evolucionando, convergiendo -y hoy en día es interesante echar un vistazo a la red de ordenadores y decir qué es IT, qué es OT, qué es IoT (o IoMT, IIoT…). Las fronteras están difuminándose y a veces es mejor olvidarse de etiquetas y recordar que, al fin y al cabo, es solo tecnología, independientemente del nombre. Un sistema para para ser asegurado de la mejor forma posible.
Con esto, en un mundo OT el modelo Purdue ha existido por décadas y es usada como referencia para diseñar nuevos sistemas y evolucionar los antiguos.
La esencia del modelo Purdue es dividir la red en niveles, donde cada nivel puede comunicarse solo con sus vecinos cercanos y donde la seguridad por el proceso subyacente llega a ser más estricto según el nivel aumenta (y, por tanto, están más alejados del equipo de automatización).
¿Qué tienen en común la confianza cero y el Modelo Purdue? Ambos son soluciones para interconectar activos de forma organizada, tratando de minimizar el acceso no deseado de la red a determinados recursos. Sin embargo, el modelo ZT incorpora conceptos adicionales que potencialmente hacen que el Modelo Purdue quede obsoleto. No queremos profundizar en este tema, pero una posible forma de ver el modelo ZT desde la perspectiva del Modelo Purdue es que es necesario desplegar más controles porque la sola separación en capas no es suficiente; por otro lado, la ZT puede sugerir una arquitectura más flexible y probablemente igualmente segura para las tecnologías de la operación.
Como hemos visto, el modelo Zero Trust para OT e IoT tiene que ver tanto con la verificación como con la (falta de) confianza.
Pero es bueno empezar a adoptarlo, al menos como una mentalidad. La arquitectura Zero Trust evolucionará en los próximos 5/10 años -quizás con el mismo nombre, quizás con otros nombres, pero los conceptos están aquí para quedarse y evolucionar a algo mejor.
