Durante una parada programada, el equipo de mantenimiento conecta una estación de ingeniería para actualizar un controlador. Entonces descubre que el sistema operativo ya no recibe soporte, la regla del cortafuegos permite más tráfico del necesario y nadie conserva un inventario confiable de las versiones instaladas. En una red corporativa, estas deficiencias son graves; en una planta pueden afectar la continuidad, la calidad del proceso y la seguridad física.
La ciberseguridad de la tecnología operacional (OT) debe proteger sistemas que observan o modifican procesos reales sin interrumpir operaciones críticas. La serie IEC 62443 aporta una estructura para repartir responsabilidades, evaluar riesgos, segmentar arquitecturas y definir requisitos técnicos. Este artículo explica cómo utilizar ese enfoque sin convertir la norma en una lista mecánica ni trasladar controles de TI a la planta sin adaptación.
Respalda formación en seguridad OT
El Instituto Internacional de Ingeniería (3i) permite a organizaciones e instructores que ya capacitan emitir credenciales verificables y revisar si la plataforma se adapta a la gestión de sus programas.
Por qué OT exige otro enfoque
La tecnología operacional incluye sistemas y dispositivos programables que interactúan con el entorno físico: PLC, DCS, SCADA, sistemas instrumentados, automatización de edificios y otras plataformas de supervisión o control. La guía NIST SP 800-82 Rev. 3 sobre seguridad OT señala que su protección debe considerar requisitos propios de desempeño, confiabilidad y seguridad. Esto cambia la forma de aplicar parches, ejecutar escaneos, desplegar agentes o reiniciar equipos.
Un control técnicamente válido puede resultar inaceptable si introduce latencia, bloquea una comunicación determinista o obliga a detener un proceso continuo. Por eso la evaluación comienza con las consecuencias operativas: qué ocurre si se pierde visibilidad, se modifica una consigna, falla una protección o queda indisponible una estación. La respuesta debe coordinar ciberseguridad, automatización, mantenimiento, seguridad de procesos y responsables de producción.
Una serie para cada responsable
IEC 62443 no es un único documento. La descripción oficial de la serie ISA/IEC 62443 la presenta como un enfoque de responsabilidad compartida entre propietarios de activos, integradores, proveedores de servicios y fabricantes de productos. Cada participante controla una parte distinta del riesgo y necesita evidencias propias.
IEC 62443-2-1:2024 establece requisitos del programa de seguridad para propietarios u operadores de sistemas industriales de automatización y control. IEC 62443-2-4:2023 aborda los procesos que los proveedores de servicios aplican durante la integración y el mantenimiento. Para fabricantes, IEC 62443-4-1:2018 define prácticas de desarrollo seguro, desde los requisitos y el diseño hasta la gestión de defectos, los parches y el fin de vida. Adoptar una parte no demuestra automáticamente conformidad con toda la serie.
Zonas y conduits con propósito
La segmentación industrial no debería empezar dibujando VLAN. IEC 62443-3-2:2020 pide primero definir el sistema bajo consideración, dividirlo en zonas y conduits, evaluar el riesgo de cada uno y documentar los requisitos. Una zona agrupa activos con necesidades de seguridad semejantes; un conduit reúne y controla las comunicaciones entre zonas.
En una línea de envasado, por ejemplo, los controladores y la interfaz de operación pueden pertenecer a una zona de proceso. La estación de ingeniería merece una zona separada por su capacidad para modificar la lógica, mientras el intercambio con servicios corporativos puede atravesar una zona desmilitarizada industrial.
El diagrama solo resulta útil cuando cada flujo queda vinculado con una necesidad real: protocolo, origen, destino, dirección, frecuencia, propietario y respuesta esperada si la comunicación se interrumpe. Esa información permite limitar reglas de acceso y revisar cambios sin depender de conexiones heredadas cuyo propósito ya nadie recuerda.
Niveles y requisitos de seguridad
IEC 62443-3-3:2013 organiza los requisitos del sistema alrededor de siete fundamentos: identificación y autenticación, control de uso, integridad del sistema, confidencialidad de datos, flujo de datos restringido, respuesta oportuna a eventos y disponibilidad de recursos. La selección depende de la evaluación de riesgo y del nivel objetivo definido para cada zona o conduit.
En la terminología habitual de la serie, SL-T identifica el nivel de seguridad objetivo, SL-C expresa la capacidad de seguridad que puede aportar un componente o sistema y SL-A describe el nivel de seguridad alcanzado y sustentado por la implementación y su evidencia. Estas denominaciones no sustituyen el análisis de riesgos ni representan una calificación general de la planta. Tampoco conviene asignar el nivel más alto a todos los activos: hacerlo puede crear requisitos inviables para equipos heredados y desviar recursos de los escenarios con mayores consecuencias.
Del diagnóstico al programa OT
Una implementación útil produce decisiones operables, no solo matrices. El punto de partida puede ser una unidad, celda o proceso crítico con límites claros. A partir de allí, el equipo contrasta la arquitectura real con los procedimientos de acceso, respaldo, mantenimiento, respuesta a incidentes y gestión de cambios.
La edición 2024 de IEC 62443-2-1 reconoce que muchos sistemas industriales permanecen en servicio durante décadas y pueden incluir componentes sin soporte. En esos casos, una política realista documenta la limitación y define medidas compensatorias, como segmentación adicional, restricción del acceso remoto, monitoreo de comunicaciones, repuestos verificados o procedimientos de recuperación. La excepción debe tener propietario, justificación y fecha de revisión.
Proveedores y ciclo de vida
La seguridad de una arquitectura OT también depende de decisiones tomadas fuera de la planta. Antes de adquirir una solución conviene precisar cómo se notifican las vulnerabilidades, cuánto dura el soporte, qué mecanismos existen para autenticar usuarios, cómo se protegen las actualizaciones y qué evidencia entrega el proveedor. IEC 62443-4-1 sitúa estas prácticas dentro del ciclo de desarrollo, mientras IEC 62443-2-4 las conecta con la integración y el mantenimiento. La conformidad declarada de un producto no sustituye la evaluación del sistema donde será instalado: una configuración débil, una cuenta compartida o un conduit demasiado abierto pueden neutralizar capacidades disponibles. La aceptación técnica debería comprobar requisitos, configuración, interfaces, recuperación, registros y responsabilidades antes de pasar a operación.
Conclusión
Aplicar IEC 62443 con criterio significa relacionar el riesgo del proceso con personas, arquitectura, productos y evidencia de operación. El resultado más valioso no es una carpeta de controles, sino una planta donde cada conexión tiene propósito, cada excepción tiene responsable y cada cambio puede revisarse sin perder de vista la continuidad y la seguridad.
Emite credenciales verificables para tus alumnos
Si tu organización imparte formación en ciberseguridad industrial, puede conservar sus programas y emitir certificados con QR, enlace o código de validación.
Fuentes consultadas
National Institute of Standards and Technology. Guide to Operational Technology (OT) Security, NIST SP 800-82 Rev. 3. 2023.
International Society of Automation. ISA/IEC 62443 Series of Standards. Consulta realizada en 2026.
International Electrotechnical Commission. IEC 62443-2-1:2024, Security program requirements for IACS asset owners. 2024.
International Electrotechnical Commission. IEC 62443-2-4:2023, Security program requirements for IACS service providers. 2023.
International Electrotechnical Commission. IEC 62443-3-2:2020, Security risk assessment for system design. 2020.
International Electrotechnical Commission. IEC 62443-3-3:2013, System security requirements and security levels. 2013.
International Electrotechnical Commission. IEC 62443-4-1:2018, Secure product development lifecycle requirements. 2018.
