Si ha pasado algún tiempo investigando los marcos de ciberseguridad industrial, es probable que se haya topado con la norma IEC 62443 más de una vez, y también es probable que se haya sentido un poco abrumado por ella. No se trata de un único documento. Es una familia de normas e informes técnicos, cada uno de los cuales aborda un nivel diferente de responsabilidad a lo largo del ciclo de vida de la tecnología operativa (OT). Esa estructura es muy potente una vez que se comprende, pero resulta confusa si se aborda por primera vez o si se intenta determinar qué parte se aplica realmente a su función. 

Este blog desglosa la serie IEC 62443 en términos sencillos. Aprenderá cómo están organizadas las partes, qué pretende lograr cada una, quién es responsable de su implementación y cómo se conectan las piezas para formar un enfoque completo y basado en riesgos para proteger los sistemas de control industrial. Ya sea que usted sea el propietario de un activo que intenta crear un programa de seguridad, un integrador que diseña una nueva red de control o un proveedor que desarrolla componentes para infraestructura crítica, este artículo le ayudará a identificar exactamente dónde encaja usted. 

La serie IEC 62443 está organizada en cuatro categorías que reflejan las responsabilidades de las diferentes partes interesadas a lo largo del ciclo de vida de OT. 

Qué es la norma IEC 62443 y por qué es importante para la seguridad de OT 

La norma IEC 62443 es una serie de estándares reconocidos internacionalmente y desarrollados para proteger los sistemas de automatización y control industrial, comúnmente denominados IACS. A diferencia de los marcos de seguridad de TI tradicionales, se diseñó específicamente para entornos donde la seguridad física, el tiempo de actividad y los procesos físicos tienen prioridad sobre las preocupaciones convencionales de confidencialidad de los datos. El fallo de un sistema de control no significa simplemente una brecha de datos. Puede significar una línea de producción detenida, un activo dañado, un incidente ambiental o, en el peor de los casos, una amenaza para la seguridad humana. 

Esta es precisamente la razón por la que las listas de verificación genéricas de seguridad de TI resultan insuficientes en los entornos de OT. Aplicar parches a un controlador lógico programable con la misma frecuencia que a una computadora portátil, o aplicar una regla de prevención de intrusiones sin comprender su efecto en la comunicación en tiempo real, puede generar más riesgos de los que elimina. La norma IEC 62443 se diseñó teniendo en cuenta esta realidad. Ofrece a las organizaciones una metodología estructurada y basada en el riesgo que respeta las limitaciones operativas de los sistemas industriales, al tiempo que eleva el nivel de seguridad de manera medible. 

Los reguladores, las aseguradoras y los organismos del sector hacen referencia cada vez más a la norma IEC 62443 al evaluar la madurez de la postura de seguridad de OT de una organización. Ser capaz de demostrar la alineación con partes específicas de la norma se está convirtiendo en un verdadero diferenciador durante las evaluaciones de proveedores, las renovaciones de seguros y las auditorías regulatorias en los sectores de manufactura, energía, agua y otras infraestructuras críticas. 

Comprensión de la estructura de la familia IEC 62443 

La forma más sencilla de entender la norma IEC 62443 es dejar de pensar en ella como un solo documento y empezar a verla como cuatro categorías, cada una dirigida a un público diferente y a una etapa distinta del ciclo de vida de OT. 

Una perspectiva simplificada de cómo se agrupan las partes de la norma IEC 62443 por categoría, alcance y público previsto. 

Generalidades (Serie de la Parte 1) 

Estos documentos sientan las bases. Definen la terminología, los conceptos y los modelos que se citan en el resto de la serie, incluida la idea fundamental de los niveles de seguridad, a la que volveremos en breve. Si es nuevo en la norma, este es el punto de partida adecuado, aunque rara vez es donde las organizaciones dedican la mayor parte de su esfuerzo de implementación. 

Políticas y procedimientos (Serie de la Parte 2) 

Esta categoría está dirigida directamente a los propietarios y operadores de activos. Define cómo debe ser un sistema de gestión de ciberseguridad eficaz para OT, cómo debe gestionarse la aplicación de parches de forma que se respete la continuidad operativa y qué se espera de los proveedores de servicios que realizan el mantenimiento o dan soporte a los sistemas industriales. Si su organización está intentando crear un marco de gobernanza en torno a la seguridad de OT en lugar de limitarse a comprar tecnología, aquí es donde pasará la mayor parte del tiempo. 

Sistema (Serie de la Parte 3) 

Aquí es donde la evaluación de riesgos se vuelve concreta. Introduce la práctica de segmentar una red en zonas y conductos, asignar niveles de seguridad objetivo basados en el riesgo real y definir los requisitos técnicos que debe cumplir un sistema para alcanzar cada nivel. Los propietarios de activos e integradores de sistemas confían en gran medida en esta categoría al diseñar o rediseñar la arquitectura de red. 

Componente (Serie de la Parte 4) 

Esta categoría traslada la responsabilidad a los proveedores de productos. Define un ciclo de vida de desarrollo seguro para los productos de sistemas de control, junto con los requisitos técnicos específicos que deben cumplir los componentes individuales, como controladores, sensores y dispositivos embebidos. Si su organización fabrica o integra hardware y software industrial, estos requisitos definen cómo deben diseñarse los productos desde su origen, en lugar de protegerlos una vez fabricados. 

Desglose de cada parte: Qué abarca y a quién se dirige 

Ahora vayamos un nivel más profundo. Comprender la categoría es útil, pero saber lo que cada parte individual le exige realmente es lo que transforma la teoría en una hoja de ruta práctica. 

Conceptos fundamentales: Terminología, modelos y ciclo de vida 

Los primeros documentos generales establecen el vocabulario compartido y los modelos conceptuales utilizados en toda la serie, incluyendo cómo se agrupan los activos, cómo se definen los límites de confianza y cómo se espera que funcione el ciclo de vida general de la seguridad, desde el diseño hasta el desmantelamiento. Omitir esta etapa a menudo lleva a los equipos a aplicar de forma incorrecta los requisitos posteriores simplemente porque trabajan con una comprensión inconsistente de términos básicos como zona, conducto o nivel de seguridad. 

Creación de un sistema de gestión de ciberseguridad 

Los requisitos del programa de seguridad describen cómo establecer, operar y mejorar continuamente un sistema de gestión de ciberseguridad específico para OT. Esto no es un proyecto de una sola vez. Abarca las estructuras de gobernanza, los procesos de gestión de riesgos, las responsabilidades del personal, la planificación de la respuesta a incidentes y la disciplina organizativa continua necesaria para mantener la relevancia de un programa de seguridad a medida que evolucionan las amenazas y los activos. 

Gestión de parches sin interrumpir la producción 

Una de las partes más prácticas de toda la serie aborda cómo se deben evaluar, probar e implementar los parches en entornos industriales. Reconoce una realidad que los marcos centrados en TI suelen pasar por alto: no se puede simplemente enviar una actualización a un controlador que ejecuta un proceso químico continuo o a una turbina en una central eléctrica sin una validación cuidadosa. Esta parte proporciona estructura a los controles compensatorios y a los despliegues escalonados cuando la aplicación inmediata de parches no es viable desde el punto de vista operativo. 

Requisitos para proveedores de servicios 

Muchos entornos de OT dependen de integradores y proveedores de mantenimiento externos que tienen acceso directo a los sistemas de control. Esta parte establece las expectativas sobre cómo deben operar de manera segura dichos proveedores, abarcando desde las prácticas de acceso remoto hasta la forma en que manejan las credenciales y los equipos mientras trabajan de forma presencial o remota. Dado el gran número de ocasiones en que el acceso de terceros ha estado presente en incidentes de OT en el mundo real, esto dista mucho de ser una formalidad. 

Evaluación de riesgos, zonas y conductos 

Este suele ser el punto de partida de cualquier proyecto de arquitectura serio. Describe cómo realizar una evaluación de riesgos estructurada y cómo traducirla en zonas (agrupaciones lógicas o físicas de activos que comparten requisitos de seguridad similares) conectadas por conductos que controlan cómo se mueven los datos y el tráfico entre ellas. Si se realiza correctamente, esta segmentación es una de las formas individuales más eficaces de contener un incidente antes de que se propague por toda una planta o instalación. 

Requisitos de seguridad del sistema y niveles de seguridad 

Una vez definidas las zonas y los conductos, esta parte especifica los requisitos técnicos que debe cumplir un sistema dentro de una zona determinada, organizados en torno a siete áreas de requisitos fundamentales, como el control de acceso, el control de uso, la integridad del sistema y la confidencialidad de los datos. A cada zona se le asigna un nivel de seguridad objetivo en función de la capacidad de amenaza que debe resistir, lo que proporciona a las organizaciones una forma defendible y proporcional al riesgo de decidir qué nivel de protección es suficiente, en lugar de aplicar los mismos controles en todas partes. 

Los niveles de seguridad describen la sofisticación de la amenaza que una zona está diseñada para resistir, desde una exposición casual hasta la capacidad de un Estado-nación. 

Ciclo de vida de desarrollo de productos seguros 

Por el lado del proveedor, esta parte define las prácticas que debe seguir un fabricante al diseñar, desarrollar y mantener productos de sistemas de control, incluidas las prácticas de codificación segura, la gestión de vulnerabilidades, el modelado de amenazas y las pruebas de seguridad a lo largo de la vida del producto. Las organizaciones utilizan cada vez más esta parte como referencia durante las adquisiciones, solicitando a los proveedores que demuestren cómo se alinea su proceso de desarrollo con ella. 

Requisitos técnicos para componentes 

Esta parte entra en detalles minuciosos y define requisitos técnicos específicos para componentes individuales, como dispositivos embebidos, dispositivos de red, aplicaciones de host y aplicaciones de software. Es el equivalente a nivel de componente de los requisitos a nivel de sistema descritos anteriormente, lo que garantiza que los bloques de construcción individuales de un sistema de control sean capaces de soportar el nivel de seguridad para el que se diseñó el sistema en su conjunto. 

Riesgos, desafíos y perspectivas de la industria 

Comprender la estructura de la norma IEC 62443 es importante porque los riesgos que aborda no son hipotéticos. Entornos industriales de todo el mundo han experimentado consecuencias reales debido a brechas que la norma se diseñó específicamente para cerrar. 

Considere un caso bien documentado de hace unos años que afectó a un productor mundial de aluminio. Una infección por ransomware se propagó desde la TI corporativa a los entornos de producción, lo que obligó a varias plantas a cambiar a operaciones manuales durante semanas. El impacto financiero ascendió a decenas de millones de dólares, y la causa raíz se atribuyó a una segmentación insuficiente entre las redes empresariales y los sistemas operativos, precisamente la brecha que los requisitos de zonas y conductos están diseñados para prevenir. 

Otro incidente muy citado ocurrió en una planta de tratamiento de agua en los Estados Unidos, donde un operador detectó un acceso remoto no autorizado que intentaba alterar los niveles de dosificación de productos químicos en el proceso de tratamiento. La intrusión se detectó a tiempo, pero puso de manifiesto cómo las vías de acceso remoto utilizadas por los proveedores de mantenimiento externos (exactamente la preocupación que abordan los requisitos para proveedores de servicios) siguen siendo uno de los puntos de entrada más comunes en entornos de OT sensibles. 

Estas no son historias aisladas. Representan un patrón que se repite en los sectores de manufactura, energía y servicios públicos: redes planas sin una segmentación significativa, acceso remoto que resulta cómodo pero que está mal regulado, procesos de aplicación de parches que se mueven con demasiada lentitud o de forma descuidada, y componentes que nunca se diseñaron teniendo en cuenta la seguridad porque nadie le pidió al proveedor que la incorporara. 

Los siguientes riesgos y desafíos surgen constantemente en entornos de OT que aún no han evaluado su exposición frente a las partes pertinentes de la norma IEC 62443: 

• Redes planas o mal segmentadas que permiten a un atacante moverse lateralmente desde una única estación de trabajo comprometida hacia zonas de procesos críticos

• Controladores y dispositivos heredados que nunca fueron diseñados para autenticar usuarios, cifrar comunicaciones o resistir manipulaciones 

• Procesos de gestión de parches tomados directamente de TI, aplicados sin tener en cuenta las limitaciones de tiempo de actividad y seguridad física 

• Acceso remoto otorgado a proveedores e integradores con una supervisión, registro o permisos con límite de tiempo mínimos 

• Decisiones de adquisición tomadas sin ningún requisito de seguridad estipulado en el contrato o en los criterios de evaluación 

• Falta de una responsabilidad clara sobre la ciberseguridad de OT, con funciones dispersas entre ingeniería, TI y operaciones 

• Programas de seguridad que existen sobre el papel pero que no se prueban, ejercitan ni actualizan a medida que cambia el entorno 

Lo que hace que estos desafíos sean especialmente costosos es que rara vez se solucionan con una sola medida. Un firewall por sí solo no resuelve un diseño de segmentación deficiente. Un único documento de política no soluciona las prácticas de parcheo inconsistentes. Por esta razón, la norma IEC 62443 distribuye la responsabilidad entre la gobernanza, la arquitectura y el diseño de productos, en lugar de tratar la seguridad como un problema de un solo departamento. 

Recomendaciones prácticas y mejores prácticas 

Llevar a la práctica la norma IEC 62443 no requiere adoptar todas las partes de la norma a la vez. Un enfoque gradual y basado en el riesgo suele producir mejores resultados y una resistencia interna mucho menor que intentar un despliegue a gran escala en un solo paso. 

Comience con una evaluación de riesgos realista 

Antes de decidir qué nivel de seguridad establecer como objetivo, comprenda qué está protegiendo realmente y cómo es la capacidad de amenaza real contra ello. Una evaluación de riesgos basada en sus procesos específicos, las implicaciones de seguridad física y la exposición a amenazas le ahorrará un tiempo y un presupuesto significativos en comparación con la aplicación de una norma uniforme en todos los activos, independientemente de su criticidad. 

Defina zonas y conductos antes de comprar tecnología 

Es tentador pasar directamente a la compra de un firewall de última generación o de una plataforma de monitoreo específica para OT. Resista ese instinto hasta que la segmentación de la red se haya diseñado adecuadamente. La tecnología adquirida antes de definir la arquitectura suele estar mal configurada, infrautilizada o colocada en una parte de la red totalmente equivocada. 

Diseñe la gestión de parches en torno a la realidad operativa 

En lugar de seguir una frecuencia fija de parches, diseñe un proceso que evalúe el riesgo real de cada vulnerabilidad en su entorno, pruebe las actualizaciones en un entorno representativo que no sea de producción cuando sea posible y utilice controles compensatorios, como el aislamiento de la red o un monitoreo mejorado, cuando la aplicación inmediata de parches no sea viable desde el punto de vista operativo. 

Incorpore requisitos de seguridad en los contratos de adquisición 

Si va a adquirir nuevos controladores, software o dispositivos de IoT industrial, pregunte directamente a los proveedores cómo se alinea su proceso de desarrollo con las expectativas del ciclo de vida de desarrollo seguro. Los proveedores que no puedan responder a esto con claridad le están indicando algo importante sobre cómo se construyeron sus productos. 

Formalice la gobernanza del acceso remoto y de terceros 

Cada conexión remota a su entorno de OT debe tener un límite de tiempo, registrarse y estar vinculada a un propósito específico y aprobado. El acceso permanente para integradores y proveedores de mantenimiento es una de las fuentes de exposición más comunes y fáciles de prevenir. 

Trate el programa de seguridad como un sistema vivo 

Un sistema de gestión de ciberseguridad que se escribe una vez y nunca se vuelve a revisar se desconecta rápidamente de la realidad. Establezca ciclos de revisión periódicos, ejercicios teóricos y una asignación de responsabilidades clara para que el programa evolucione junto con sus activos, su panorama de amenazas y su estructura organizativa. 

Cómo apoya Shieldworkz a las organizaciones 

Shieldworkz colabora con propietarios de activos, operadores y organizaciones industriales para traducir el marco de la norma IEC 62443 en un plan práctico y priorizado, en lugar de una lista de verificación abrumadora. Nuestro enfoque se basa en las realidades de los entornos de producción reales, donde la seguridad física y el tiempo de actividad no pueden verse comprometidos en aras de la seguridad. 

• Realización de evaluaciones de riesgos específicas de OT que relacionan sus activos, procesos y exposición reales con los requisitos más relevantes para su entorno 

• Diseño de arquitecturas de zonas y conductos que contienen incidentes antes de que puedan propagarse por áreas de procesos críticos 

• Ayuda a definir y poner en marcha un sistema de gestión de ciberseguridad que se adapte a su estructura organizativa, en lugar de utilizar una plantilla genérica 

• Soporte en estrategias de gestión de parches que equilibran la urgencia de la seguridad con la continuidad operativa 

• Revisión y fortalecimiento de las prácticas de acceso remoto y gobernanza de terceros en todos los integradores y proveedores de servicios 

• Asesoramiento a los equipos de adquisiciones sobre cómo evaluar las prácticas de seguridad de los proveedores frente a las expectativas reconocidas de desarrollo seguro 

• Provisión de visibilidad continua y monitoreo adaptado a los protocolos industriales y al comportamiento del sistema de control 

• Orientación a las organizaciones a través de una hoja de ruta por etapas que desarrolla la madurez a lo largo del tiempo en lugar de forzar una transformación radical de golpe 

Trabajamos junto con sus equipos de ingeniería, operaciones y seguridad, y no al margen de ellos, porque los programas de seguridad de OT duraderos se construyen mediante la colaboración con las personas que mejor entienden el proceso. 

Conclusión 

La norma IEC 62443 no es una simple lista de verificación para completar y olvidar. Es un marco de trabajo por capas diseñado bajo la premisa de que las diferentes partes interesadas tienen distintas responsabilidades a lo largo del ciclo de vida de OT, y que la seguridad real surge cuando esas responsabilidades funcionan de manera conjunta. Los propietarios de activos definen la gobernanza y la arquitectura. Los integradores diseñan e implementan sistemas seguros. Los proveedores desarrollan productos seguros desde su origen. Cuando estas piezas se alinean, las organizaciones logran una defensa proporcional al riesgo real, en lugar de un conjunto de controles inconexos. 

Las organizaciones que obtienen el mayor valor de la norma IEC 62443 son aquellas que comienzan por identificar qué partes se aplican genuinamente a su función, y luego construyen un plan realista y por etapas en torno a esos requisitos. Esa claridad suele ser la parte más difícil de alcanzar en solitario, y es precisamente ahí donde la orientación experimentada marca la diferencia entre una norma que se queda guardada en un estante y otra que reduce el riesgo de manera medible. 

Reserve una consulta gratuita con nuestros expertos 

Si está intentando determinar qué partes de la norma IEC 62443 se aplican a su organización, o cómo convertir este marco en una hoja de ruta realista para su entorno específico, nuestro equipo está listo para ayudarle. Reserve una consulta gratuita con los expertos en seguridad de OT de Shieldworkz y obtenga orientación clara y práctica adaptada a sus sistemas, su perfil de riesgo y sus prioridades, sin listas de verificación genéricas asociadas.

Recursos adicionales  

Un informe descargable sobre el ciberincidente 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 de evaluación de riesgos de OT/ICS basada en la norma IEC 62443 para el sector de fabricación de alimentos y bebidas aquí