Implementar controles efectivos en un ICS (Norma ISO IEC 62443)

Día a día pensamos la seguridad desde varios puntos de vista, ponemos a evaluar una necesidad y en función a esa necesidad implementamos como arquitectos lo que más creemos conveniente dado el caso.

Pensamos a veces en que sería más efectivo, acorde a la tecnología en la cual nos desenvolvemos, también decimos según el caso que los viejos pensamientos basados en el perímetro ya no nos sirven encontrándonos con que la lista de estrategias se achica cada vez más.

Algunas escuelas pueden indicar que la seguridad basada en normas es también el principal motivo de una falsa sensación de seguridad, ya que lleva a los analistas a una zona de confort de la cual en muchos casos es imposible salir. Si bien esto último puede ser cierto, la realidad es que las normas nos ayudan mucho a crear procesos, una norma bien usada es una gran herramienta para combatir los riesgos en todos los ámbitos en los cuales nos desempeñamos.

Puede ser a nivel red, a nivel aplicación y en distintos sistemas también, pero más aún en uno de los ámbitos que últimamente llama la atención o en realidad están comenzando a enfocarse en la seguridad con mayor frecuencia, estamos hablando de los ámbitos industriales, más particularmente los ámbitos industriales que tienen la necesidad de implementar controles efectivos en sus sistemas ICS.

En general, hace un tiempo no muy lejano carecían de normas que regulen los diseños y las arquitecturas correspondientes enfocadas en mejorar estas áreas, en esta oportunidad analizaremos cómo influye esta carencia de normas en ámbitos que no están enfocados en la seguridad porque su naturaleza está asociada a las tecnologías de la operación.

Mejorar la seguridad de los sistemas de control industrial (ICS, por sus siglas en inglés) generalmente implica una exhaustiva evaluación de riesgos seguida de una evaluación de seguridad, ambas complementadas por informes que detallan vulnerabilidades, debilidades y recomendaciones. Luego viene una avalancha de actividad en forma de planes de mitigación de riesgos enfocados en determinar qué hallazgos realmente merecen la inversión necesaria para su mitigación, planes de mitigación completamente extensos y casi imposibles de seguir. Por lo que esta cuestión suele terminar en un acuerdo con el auditor correspondiente o en un compromiso de cumplimiento de la brecha. Este nivel homologación tiene sus beneficios, pero tiende a reducir el problema de seguridad a una lista enfocada de hallazgos que representan apenas una parte del panorama completo de seguridad de los ICS. Luego de revisar los hallazgos, las medidas de mitigación pueden llevar de uno a tres años en completarse, según factores como la madurez actual de la seguridad de los ICS, su agilidad y el presupuesto disponible, sumado a todo el costo operativo de tener que frenar las actividades completamente debido a que es improbable tener una plataforma de testing igual a la productiva por la complejidad de algunos ambientes. Para entonces, es hora de una nueva evaluación completa.

Las mejoras necesarias pueden implementarse, pero lo que falta en este enfoque es cohesión. Mejorar la seguridad de los ICS no se trata solo de abordar debilidades mediante la adición de controles de seguridad. Esos controles deben seleccionarse cuidadosamente, ser complementarios y respaldar de manera conjunta una comprensión clara de cómo prevenir, monitorear, detectar y responder a incidentes de ciberseguridad dentro de esos entornos. Mejorar la ciberseguridad en un ICS no se puede incluir en un simple mapa secuencial de fases. Idealmente, dependiendo de los requisitos de seguridad y los niveles de protección identificados durante el proceso de evaluación de riesgos, el ICS debería segmentarse en zonas de seguridad que pueden operar en diferentes fases de madurez, como toda solución que se desee mejorar una brecha que no tiene trato particularmente hace bastante tiempo.

La norma IEC 62443 separa una organización con ICS en zonas de seguridad basadas en evaluación de riesgos. La norma proporciona orientación sobre cómo seleccionar las zonas y asignar los respectivos niveles de seguridad (SL, Security Level), para poder aplicar esas fases de madurez de las que hablamos más arriba.

Para cada nivel se requieren ciertos controles, ya que una organización debe evaluar los niveles asignados para poder aplicar la seguridad a conciencia en cada etapa del análisis de la arquitectura a evaluar. Como toda norma se deben evaluar las brechas correspondientes para ver cuan lejos se está de ese estándar que se quiere imponer en el ámbito en el que nos desplegamos. Estas zonas o niveles, están asociadas a un rango de Security Level que va desde 0 a 4.

Características de los niveles de seguridad

Para lograr un nivel óptimo de seguridad y cumplir con los requisitos de seguridad, los SR (Requerimientos del sistema) se despliegan en función de la protección requerida contra las amenazas específicas. Los niveles de protección IEC 62443 se mencionan a continuación.

Implementando estos niveles segmentados, según el requerimiento de la zona puede aportar a las soluciones de seguridad mucha más simpleza a la hora de implementar las mismas. Ya que no es lo mismo aplicar un nivel a toda la arquitectura (mucho más costoso), que tratar cada parte de nuestro ICS de forma independiente para economizar los esfuerzos en función al riesgo.

Foto ilustrativa a modo de ejemplo

Cuando una organización separa sus entornos de ICS en múltiples zonas, nunca existe un aislamiento del riesgo absoluto entre todas las zonas, por lo que una zona debilitada puede afectar a las zonas circundantes de dos maneras.

• Primero, una interrupción de servicios u operaciones dentro de la zona debilitada puede propagarse a otras zonas, dependiendo de los servicios que la zona maneje.
• Segundo, comprometer una zona y acercar una amenaza a otras zonas, brindándoles la debida visibilidad. Para superar estos desafíos, el Estándar sugiere varias mejoras en los requisitos (REs), que abordaremos en breve.

Para ayudar a los usuarios a determinar los requerimientos de los SL asociados a cada zona de seguridad, el estándar que estamos explorando categoriza siete requerimientos fundamentales (FR), que a su vez se desarman en una serie de requerimientos de los sistemas para mejorar la seguridad.

Para asistir a la definición de cada SL el estándar provee una definición de amenazas para cada nivel en donde se pueden visualizar a través de una tabla que haga dialogar las cuestiones más específicas. El paisaje de las amenazas difiere dependiendo de cada sector, industria y tipo de organización. Esta norma nos provee definiciones sólidas y un buen lugar para comenzar a considerar las mismas como un buen punto de partida para definir la postura de la defensa a desarrollar. A continuación veremos un ejemplo de mapeo de SRs que se desprenden de los requerimientos fundamentales y sus respectivas mejoras (RE), para los niveles de seguridad.

Potencialmente, los SL podrían plantear diferencias únicas para cada zona de seguridad, como amenazas, cambios operativos y tecnología como el Internet Industrial de las Cosas (IIoT), que pueden cambiar la superficie de ataque de un ICS. Los SL ayudan a establecer objetivos, pero estos deben ser flexibles y alineados de manera activa para mantenerse al día con los cambios globales en las amenazas. Ninguna norma nos brinda un panorama certero alineado a las condiciones locales de cada una de las soluciones asociadas a un ICS, siempre tenemos que tener esa capacidad de adaptación, que nos brinda versatilidad a la hora de ir alternando entre dichas superficies.

También es importante entender el rol de las contramedidas que podemos llegar a generar, por ejemplo cuando buscamos una lista de recomendaciones, identificamos las oportunidades y las capacidades para expandir las contramedidas en un futuro cercano en donde beneficie al resto de las zonas, es un poco el arte de reciclar el esfuerzo para evitar tener una sobrecarga de trabajo a la hora de remediar un ICS, todo lo que podamos hacer tiene que ser lo suficientemente adaptable y maleable acorde al entorno y al resto de los mecanismos. Esta idea de cómo enfrentar la cuestión desde el punto de vista del reciclaje transforma la ilusión de ahorro de tiempo, en un ahorro de tiempo neto, que se ve reflejado en el día a día. Logrando así maximizar nuestro retorno de inversión.

Importancia de las Zonas y Subzonas

A cada zona de seguridad y la vía de comunicación entre ellas (conducto) se le asigna un nivel de seguridad objetivo (SL-T). Para alcanzar lo que el Estándar considera un nivel de seguridad satisfactorio ("nivel de seguridad alcanzado" o SL-A), deben estar presentes varios factores contribuyentes. Estos factores deben tenerse en cuenta al establecer zonas de seguridad, conductos, y sus respectivos niveles de seguridad.

Modelo Purdue de un sistema de control industrial dividido en Zonas

Como veremos, un ICS puede ser segmentado en zonas de seguridad, pero las vías de comunicación pueden dejar vectores de ataque residuales entre esos segmentos. Este concepto de darle un nombre a cada parte de nuestro sistema, es un concepto poderoso que nos provee los fundamentos necesarios para realizar una segmentación.

Debido a que un ICS es un sistema de sistemas, dependiendo de la industria en la que se desempeñe, pueden ser separados en grupos más pequeños, los sistemas físicos, como por ejemplo las máquinas, los sistemas de aplicación, que llevan a cabo las funciones de operación compartiendo el riesgo operacional, y los activos de información. Una zona de seguridad puede estar situada dentro de estos grupos, llegando a compartir requerimientos en común creando así esos límites imaginarios que los separan. Un ICS puede estar estructurado de tal manera que una pequeña parte, como una caldera, requiera un nivel de seguridad ligeramente más alto, pero por lo demás pueda beneficiarse del nivel de seguridad de los activos circundantes. Para estos casos, se puede utilizar una sub zona. Al realizar la segmentación, una zona de seguridad y una sub zona son simplemente construcciones lógicas de las operaciones de un ICS y deben ser consideradas fuera del contexto de la red física real y los componentes.

Después de revisar y comprender las rutas de comunicación requeridas entre las zonas de seguridad, se puede superponer esta estructura de segmentación con el hardware y la red del sistema de control físico, para que los controles sean aplicados en esa instancia y se pueda realizar la traducción de las necesidades de segmentación, para que luego se lleve a cabo una solución acorde a la problemática resuelta.

Hay situaciones en las que la información debe fluir dentro, hacia dentro y fuera de una zona de seguridad mediante comunicación. Esto incluye también las comunicaciones intermitentes realizadas a través de terminales de programación, dispositivos móviles y dispositivos de almacenamiento extraíble, entre otros. El Estándar se refiere a estos canales de comunicación como conductos, que pueden ser identificados como confiables o no confiables.

Las comunicaciones dentro de una zona se reconocen en su mayoría como conductos confiables. Los conductos no confiables son las comunicaciones provenientes de otras zonas de seguridad que no se encuentran en el mismo nivel de seguridad o que se realizan a través de un canal de comunicación que no está en el mismo nivel de seguridad.

Al modelar zonas y conductos, existen una serie de reglas importantes que los profesionales deben tener en cuenta. A continuación, les compartimos algunas:

• Una zona puede tener sub zonas
• Un conducto no puede tener sub subconductos
• Una zona puede tener más de un conducto. Los activos cibernéticos (HOSTs) dentro de una zona usan uno o más conductos para comunicarse.
• Un conducto no puede atravesar más de una zona
• Un conducto puede ser utilizado por dos o más zonas para comunicarse con otras.

En la siguiente imagen, podemos visualizar ejemplos de una configuración correcta y una incorrecta para que puedan entender la diferencia de ambas arquitecturas.

Imagen extraída de https://gca.isa.org

Para muchas organizaciones, la segmentación puede ser un proceso difícil. Es por eso que las zonas deben ser abstraídas sin centrarse demasiado en el hardware y software actual. Solo después de aplicar los SLs se debe superponer a los equipos del ICS (como equipos de red, PLC, unidades, computadoras, firewalls, servicios, protocolos). Este proceso mostrará claramente todas las deficiencias del hardware compartido, las rutas de red y el software presente en el entorno.

Esa información puede identificar oportunidades que ayuden a minimizar la asignación de SLs más altos en muchas zonas, reduciendo así los costos. Cada entorno es diferente, pero los procesos utilizados pueden incluir los siguientes principios:

• Los niveles de seguridad más bajos requieren menos controles de seguridad.
• La segmentación jerárquica de zonas y sub zonas proporciona una defensa en profundidad.
• Los límites de zona proporcionan puntos de estrangulamiento para la monitorización.
• La segmentación de servidores y aplicaciones informáticas puede introducir otras oportunidades.
• El uso del control de acceso a la red a nivel de switch puede ayudar a extender los controles.

Algunos entornos de ICS pueden ser problemáticos porque los sistemas de control pueden tener una relación significativa de datos con los sistemas de información empresarial, creando una dependencia operativa que debe adaptarse a zonas de seguridad amplias, una zona de seguridad amplia implica un mayor seguimiento. Además de esto, los sistemas de información tienden a residir en la empresa, lo que dificulta la creación de zonas jerárquicas independientes para una defensa en profundidad. Pero sin embargo en estas arquitecturas, puede ser útil utilizar switches con control de acceso a la red para generar múltiples sub zonas en entornos existentes y nuevos ambientes que necesiten dicha interacción.

Conclusión

Entre otras cosas debemos aprender a afinar nuestras herramientas de diseño, y mejorar nuestra capacidad de abstracción al evaluar entornos complejos o aparentemente complejos como lo son los ICS. Una menor complejidad en las soluciones nos lleva a comprender el problema con una escalabilidad mucho mayor, respecto de los sistemas complejos.
Quizás llegó la hora de que las tecnologías de la operación inserten en sus procesos de arquitectura, a profesionales en seguridad que abran los caminos a través del poder de abstracción para poder simplificar las soluciones a su máxima expresión posible apuntando a la eficiencia de las comunicaciones en estos ámbitos. A modo de respuesta de esa frase inicial ¿la seguridad basada en normas es efectiva?, muchas veces ayuda a orientar los procesos, pero si sólo aplicamos la norma puede que muy pronto pierda esa efectividad que aparenta. Por lo que debe ser nuestra herramienta, pero no debería ser la única herramienta de referencia para resolver problemas.