Los sistemas de control industrial nunca se diseñaron pensando en el riesgo cibernético. Se crearon para el tiempo de actividad, la seguridad y la precisión, y a menudo se esperaba que funcionaran sin modificaciones durante quince o veinte años. Esa filosofía de diseño es exactamente la razón por la que existe la norma IEC 62443. Es lo más cercano que tiene el mundo industrial a un lenguaje compartido para la seguridad de OT, ya que brinda a los propietarios de activos, integradores de sistemas y fabricantes de equipos un conjunto común de requisitos sobre los cuales trabajar, en lugar de que cada planta reinvente su propio enfoque para proteger los sistemas que mantienen en funcionamiento la producción, la energía y el agua.

Antes de comenzar, no olvide consultar nuestra publicación anterior sobre "A technical analysis of the fairlife cyber incident" aquí.

Para los líderes de seguridad de OT, gerentes de planta y CISOs responsables de la infraestructura crítica, el cumplimiento de la norma IEC 62443 ya no es un ejercicio teórico reservado para los sectores más regulados. Las aseguradoras preguntan al respecto durante la renovación. Los clientes preguntan al respecto durante las evaluaciones de proveedores. Los reguladores lo toman como referencia al diseñar reglas específicas del sector. Y, cada vez más, las juntas directivas preguntan al respecto porque han visto a organizaciones similares perder semanas de producción debido a incidentes que un entorno segmentado y bien gobernado podría haber contenido. Esta guía detalla lo que la norma realmente exige, por qué existen esos requisitos y cómo convertirlos en un programa viable en lugar de una pila de papeleo.

¿Qué es IEC 62443 y por qué existe?

IEC 62443 es una serie de normas internacionales enfocadas específicamente en proteger los sistemas de control y automatización industrial (IACS): los controladores lógicos programables, los sistemas de control distribuido, las plataformas SCADA, las interfaces hombre-máquina y los sistemas de seguridad que operan plantas de fabricación, redes eléctricas, servicios de agua y otras infraestructuras críticas. A diferencia de los marcos de seguridad de TI generales que tratan a cada activo como algo prácticamente intercambiable, la norma IEC 62443 se redactó teniendo en cuenta las realidades específicas de la tecnología operativa: ciclos de vida prolongados de los equipos, prioridades de diseño enfocadas en la seguridad

ante todo, requisitos de disponibilidad en tiempo real y una combinación de dispositivos modernos y con décadas de antigüedad que coexisten en la misma red.

La norma es inusual porque no se dirige a un solo público. Establece requisitos para los propietarios de activos que operan la planta, para los integradores de sistemas que diseñan e implementan el sistema de control y para los proveedores de productos que fabrican los componentes subyacentes. Esa estructura tripartita es deliberada: las fallas de seguridad industrial rara vez se deben a un solo eslabón débil. Por lo general, se remontan a una brecha en la forma en que se dividió la responsabilidad entre las personas que construyeron el sistema, las personas que lo integraron y las personas que ahora lo operan todos los días.

También ayuda a comprender lo que IEC 62443 no es. No es un producto que se compra, un certificado único que se cuelga en la pared o un proyecto de una sola vez con una fecha de finalización definida. Es una norma de ciclo de vida, lo que significa que espera que la seguridad se diseñe desde la fase de ingeniería más temprana, se mantenga durante años de operación y se revise cada vez que cambie el entorno: una nueva conexión de proveedor, una nueva ruta de acceso remoto, una actualización del sistema de control. Las organizaciones que lo tratan como un proyecto finito tienden a aprobar su primera auditoría y luego perder silenciosamente el cumplimiento dentro de los dieciocho a veinticuatro meses, simplemente porque no se construyó nada para sostener el programa.

Esta orientación al ciclo de vida es también la razón por la que la norma IEC 62443 se ha convertido en el punto de referencia que señalan cada vez más las aseguradoras, los reguladores y los grandes clientes industriales, incluso en sectores donde ninguna ley lo exige explícitamente. Cuando un marco se construye en torno a la gestión continua del riesgo en lugar de una lista de verificación estática, resiste mejor bajo un escrutinio de auditoría real, y produce una postura de seguridad que realmente refleja cómo opera la planta en el día a día.

Entendiendo la estructura de IEC 62443

Las cuatro partes de la norma

La norma IEC 62443 está organizada en cuatro grupos de documentos, cada uno de los cuales aborda un nivel diferente de responsabilidad. En lugar de leerse como una sola especificación densa, funciona más como un conjunto de bloques de construcción: conceptos generales en la parte superior y requisitos técnicos cada vez más específicos a medida que se desciende.

Figura 1: Las cuatro partes de la norma IEC 62443, desde la terminología compartida hasta los requisitos a nivel de producto.

Requisitos básicos de cumplimiento de la norma IEC 62443 que las organizaciones deben cumplir

Una vez que se supera la terminología, el cumplimiento de la norma IEC 62443 se reduce a un puñado de requisitos entrelazados. Si se hacen correctamente, el resto del programa (políticas, documentación, evidencia de auditoría) tiende a seguir de manera natural. Si se hacen mal, ninguna cantidad de papeleo resistirá el escrutinio.

Niveles de seguridad (SL 0–4): Adaptando la protección a la amenaza

La norma IEC 62443 no asume que todos los activos necesitan el mismo nivel de protección. En su lugar, define cinco niveles de seguridad, que van desde el SL 0 (no se requiere protección específica) hasta el SL 4 (protección contra un adversario con grandes recursos, altamente motivado y que utiliza medios sofisticados). A cada zona de una instalación se le asigna un nivel de seguridad objetivo (SL-T) basado en las consecuencias de un compromiso, y el nivel real alcanzado (SL-A) se mide frente a ese objetivo.

Zonas y conductos: La columna vertebral del cumplimiento técnico

Una zona es una agrupación de activos que comparten requisitos de seguridad comunes; por ejemplo, todos los controladores en una sola línea de producción, o todas las estaciones de trabajo de ingeniería en una sala de control. Un conducto es la vía a través de la cual se mueven los datos entre las zonas, y es donde se aplican los controles de seguridad, como firewalls, filtrado de protocolos y diodos de datos. Este modelo es importante porque reemplaza una red plana donde todo confía en todo por una deliberadamente segmentada, de modo que un compromiso en una zona de menor confianza (por ejemplo, la red corporativa) no pueda pasar sin obstáculos a una zona que controla procesos físicos.

Figura 2: Un modelo típico de zonas y conductos que separa los activos a nivel de empresa, DMZ, control, seguridad y campo.

Definir las zonas correctamente es una de las decisiones más trascendentales en un programa IEC 62443. Si dibuja los límites de las zonas de manera demasiado amplia, un solo dispositivo comprometido pone en riesgo a toda la planta. Si los dibuja sin comprender los flujos de datos reales, los conductos que construya interrumpirán las operaciones legítimas o dejarán rutas no documentadas completamente abiertas. Aquí es precisamente donde una evaluación de riesgos estructurada, en lugar de un ejercicio de diagrama de red, debe guiar el trabajo.

Los siete requisitos fundamentales (FR)

Por debajo de los niveles de seguridad se encuentran los siete requisitos fundamentales, las categorías técnicas contra las cuales se miden los controles de cada zona. Cada requisito específico en la parte del sistema de la norma se remonta a uno de estos siete.

Evaluación de riesgos de la norma IEC 62443: La base del cumplimiento

Casi todas las brechas de auditoría que encuentran los consultores de Shieldworkz se remontan a la misma causa raíz: la evaluación de riesgos se trató como un ejercicio de documentación en lugar de la base técnica que debe ser. La norma IEC 62443 es explícita en que los niveles de seguridad objetivo, los límites de las zonas y las contramedidas deben derivarse del riesgo, no seleccionarse primero y justificarse después.

Figura 3: El ciclo de vida de la evaluación de riesgos de la norma IEC 62443 es continuo, no un hito de cumplimiento de una sola vez.

Una evaluación de riesgos defendible bajo la norma IEC 62443 generalmente pasa por seis etapas, y cada una produce evidencia que un auditor esperará ver:

• Identificar y realizar el inventario de activos: crear y mantener un inventario completo y preciso de controladores, estaciones de trabajo, dispositivos de red y sistemas de seguridad, incluidos los datos de firmware y configuración.

• Evaluar vulnerabilidades y amenazas: evaluar las debilidades conocidas en el entorno frente a escenarios de amenazas realistas relevantes para el sector y la geografía.

• Determinar la consecuencia y la probabilidad: estimar el impacto operativo, de seguridad, financiero y reputacional de un compromiso exitoso para cada grupo de activos.

• Establecer niveles de seguridad objetivo (SL-T): asignar el SL-T adecuado a cada zona en función del análisis de consecuencias, no de valores predeterminados genéricos de la industria.

• Diseñar y aplicar contramedidas: seleccionar controles técnicos y de procedimiento mapeados con los siete requisitos fundamentales para cerrar la brecha entre el SL-A y el SL-T.

• Monitorear, reevaluar y mantener: revisar la evaluación cuando cambien los activos, la conectividad o las condiciones de amenaza, en lugar de esperar a la próxima auditoría programada.

Aquí también es donde las organizaciones suelen subestimar el esfuerzo. Una evaluación de riesgos de alto nivel a nivel de toda la instalación establece las prioridades, pero la norma IEC 62443 espera una evaluación más detallada, zona por zona, antes de finalizar las contramedidas. Pasar directamente a los controles técnicos (comprar un firewall o una plataforma de monitoreo antes de completar este análisis) suele llevar a gastar en las prioridades equivocadas mientras las brechas de mayor consecuencia permanecen abiertas.

Incidentes del mundo real que demuestran por qué importan estos requisitos

Los requisitos de la norma IEC 62443 no se escribieron de forma abstracta. Cada uno se mapea con una categoría de falla que ya ha causado daños operativos reales en el sector industrial. Algunos incidentes bien documentados ilustran claramente el patrón.

Red eléctrica de Ucrania, 2015 y 2016

Los atacantes obtuvieron acceso a las empresas de distribución de electricidad de Ucrania y, durante un período de reconocimiento sostenido, aprendieron lo suficiente sobre el entorno de control como para abrir interruptores de forma remota y cortar la energía a cientos de miles de clientes. Un ataque posterior al año siguiente utilizó malware diseñado específicamente capaz de comunicarse directamente con los protocolos de la red eléctrica. Ambos incidentes apuntan a la misma brecha subyacente que el FR 5 y el modelo de zonas y conductos están diseñados a cerrar: una segmentación insuficiente entre las redes corporativas y los sistemas capaces de manipular directamente la infraestructura física.

TRITON/TRISIS, 2017

In un incidente dirigido a una instalación petroquímica, los atacantes implementaron malware diseñado específicamente para reprogramar sistemas instrumentados de seguridad: la última línea de defensa diseñada para llevar un proceso a un estado seguro durante una condición peligrosa. En última instancia, el ataque no tuvo éxito debido a un error de configuración en el propio malware. Sigue siendo una de las ilustraciones más claras de por qué la norma IEC 62443 asigna a las zonas de seguridad los niveles de seguridad objetivo más altos: comprometer un sistema de seguridad no solo pone en riesgo los datos o el tiempo de actividad, sino que pone en riesgo la integridad física.

Norsk Hydro, 2019

Un importante productor de aluminio fue afectado por un ransomware que se propagó desde los sistemas de TI a los entornos operativos, lo que obligó a varias plantas a operar de forma manual durante un período prolongado. La respuesta pública transparente de la empresa lo convirtió en uno de los casos de ransomware industrial más estudiados, en gran parte porque demostró con qué rapidez un compromiso originado en TI puede propagarse en cascada a la OT cuando los controles de los conductos y la segmentación de la red están incompletos.

Planta de tratamiento de agua de Oldsmar, 2021

Un operador notó que un cursor se movía por sí solo y que se utilizaba el acceso remoto para aumentar brevemente el nivel de hidróxido de sodio en el suministro de agua en una planta de tratamiento de agua de Florida. El cambio fue detectado y revertido antes de que llegara al público, pero el incidente se convirtió en un ejemplo ampliamente referenciado de lo que sucede cuando el acceso remoto no se gobierna estrictamente, una brecha que cae directamente bajo el FR 1 y el FR 2, control de identificación, autenticación y uso.

Colonial Pipeline, 2021

Un ataque de ransomware contra los sistemas de TI de la empresa provocó el cierre preventivo y voluntario de un importante oleoducto, lo que interrumpió el suministro de combustible en una gran región de los Estados Unidos durante varios días. Cabe destacar que la tecnología operativa en sí no se vio comprometida directamente: el cierre fue una decisión comercial tomada porque los sistemas de facturación y de TI no eran confiables. Sigue siendo uno de los ejemplos más citados de por qué la seguridad de OT y TI no se puede tratar como problemas completamente separados, y por qué los requisitos de gobernanza bajo la norma 62443-2 importan tanto como los controles técnicos.

En los cinco incidentes, el hilo conductor no es la falta de una sola herramienta. Es un requisito ausente: segmentación, control de acceso, robustecimiento del sistema de seguridad o una gobernanza que conecte la toma de decisiones de TI y OT. Esa es exactamente la brecha que se diseñó a cerrar con la norma IEC 62443.

Desafíos comunes que enfrentan las organizaciones al buscar el cumplimiento de la norma IEC 62443

Cada organización con la que trabaja Shieldworkz subestima al menos uno de los siguientes desafíos durante su primer intento serio de cumplimiento:

• Activos heredados que no se pueden parchar o escanear: muchos controladores en uso activo tienen entre diez y veinticinco años de antigüedad y nunca se diseñaron para admitir agentes de endpoint o autenticación modernos.

• Una brecha cultural entre los equipos de TI y OT: las prioridades de seguridad, la tolerancia al control de cambios e incluso la terminología básica difieren drásticamente entre los dos grupos, lo que ralentiza cada decisión conjunta.

• Inventarios de activos incompletos o desactualizados: no se pueden asignar niveles de seguridad precisos a activos que no se han identificado por completo.

• Límites de zonas trazados por conveniencia en lugar de por riesgo: las redes a menudo se segmentan por ubicación física o proveedor, no por la consecuencia real de un compromiso.

• Experiencia interna limitada en seguridad de OT: la mayoría de los equipos de ingeniería de planta no cuentan con el personal ni la capacitación para realizar una evaluación de riesgos formal según una norma internacional.

• Sensibilidad al tiempo de inactividad que limita las pruebas: la validación de los controles a menudo requiere ventanas de mantenimiento que compiten directamente con los programas de producción.

• Brechas de proveedores e integradores: los requisitos a nivel de componente bajo la norma 62443-4 dependen de proveedores que tal vez aún no construyan conforme a la norma, lo que obliga a los propietarios de activos a compensar con controles adicionales.

Mejores prácticas para lograr y mantener el cumplimiento de la norma IEC 62443

Las organizaciones que tienen éxito con la norma IEC 62443 tienden a seguir una secuencia que refleja la propia lógica de la norma, en lugar de saltar directamente a las herramientas o la documentación.

• Comenzar con un inventario de activos completo y activo. Los métodos de descubrimiento pasivo que no interrumpen a los controladores sensibles son esenciales en entornos donde el escaneo activo conlleva un riesgo operativo.

• Ejecutar la evaluación de riesgos antes de seleccionar la tecnología. Los niveles de seguridad objetivo y las prioridades de control deben surgir del análisis de consecuencias, no del catálogo de productos de un proveedor.

• Diseñar zonas y conductos en torno a los flujos de datos reales. Mapear cómo se mueve realmente la información entre los sistemas antes de trazar los límites de segmentación en papel.

• Tratar el SL-T como una decisión comercial, no solo técnica. Involucrar al liderazgo de la planta y a los equipos de seguridad al establecer los niveles objetivo para las zonas vinculadas a procesos físicos.

• Construir una gobernanza que abarque TI y OT. Las políticas compartidas, los planes conjuntos de respuesta a incidentes y una ruta de escalación común evitan las fallas de coordinación observadas en varios de los incidentes anteriores.

• Adaptar la gestión de parches a las limitaciones de OT. Cuando no sea factible aplicar parches, los controles de compensación, como la segmentación de red y el monitoreo, deben cubrir la brecha y documentarse como tales.

• Crear un plan de respuesta a incidentes específico para OT. Los manuales de TI genéricos rara vez tienen en cuenta las implicaciones de seguridad, el impacto en el proceso físico o la necesidad de mantener la producción en funcionamiento durante la contención.

• Reevaluar continuamente. Los nuevos activos, los nuevos proveedores y la nueva conectividad deberían desencadenar una revisión; esperar a la próxima auditoría programada deja las brechas abiertas mucho más tiempo de lo necesario.

Cómo apoya Shieldworkz a las organizaciones

Shieldworkz trabaja junto a los líderes de seguridad de OT, gerentes de planta y CISOs para convertir los requisitos de la norma IEC 62443 en un programa práctico y secuenciado, creado en torno al perfil de riesgo real de cada instalación, no a una lista de verificación genérica.

• Descubrimiento e inventario de activos integral y principalmente pasivo, adaptado a entornos de OT sensibles

• Evaluaciones de riesgos estructuradas bajo la norma IEC 62443, incluido el análisis de consecuencias y la determinación del nivel de seguridad objetivo

• Diseño de zonas y conductos basado en el tráfico de red real y los flujos de datos de procesos

• Evaluaciones de brechas que comparan los niveles de seguridad del estado actual (SL-A) con los niveles objetivo (SL-T)

• Desarrollo de marcos de gobernanza que conectan la toma de decisiones de seguridad de TI y OT

• Monitoreo continuo y detección de amenazas diseñados para protocolos industriales y dispositivos heredados

• Planificación de respuesta a incidentes específica para OT y simulacros de mesa

• Capacitación de la fuerza laboral que desarrolla la capacidad interna de seguridad de OT, no solo la dependencia externa

El objetivo siempre es el mismo: un programa de cumplimiento que resista el escrutinio de las auditorías y, lo que es más importante, que realmente reduzca el riesgo operativo al que está expuesta su organización todos los días.

Conclusión

El cumplimiento de la norma IEC 62443 no es un certificado que se deba obtener una vez y luego olvidar. Es una forma estructurada de pensar sobre el riesgo industrial, una que pide a las organizaciones comprender lo que tienen, lo que podría salir mal, qué tan graves serían las consecuencias y qué nivel de protección necesita realmente cada parte del entorno. Los incidentes que continúan apareciendo en los titulares de los sectores de manufactura, energía y agua no son evidencia de que la norma sea demasiado exigente. Son evidencia de lo que sucede cuando sus requisitos principales (segmentación, control de acceso, gobernanza y evaluación continua de riesgos) se implementan de forma parcial.

Para los líderes de seguridad de OT y los tomadores de decisiones bajo presión para mostrar un progreso medible, el camino a seguir más eficaz comienza con una evaluación honesta y dirigida por expertos sobre la situación actual de la organización. Ese único paso suele aclarar las prioridades más rápido que meses de debate interno.

Recursos adicionales  

Un informe descargable sobre el incidente cibernético de Stryker aquí  
Lista de verificación para la evaluación y selección de proveedores de soluciones de escaneo de medios extraíbles aquí  
Lista de verificación para la evaluación de riesgos de OT/ICS basada en la norma IEC 62443 para el sector de fabricación de alimentos y bebidas aquí