Aplique conceptos de IEC 62443 a subestaciones: riesgo OT, zonas, conductos, inventario, acceso remoto, hardening, monitoreo, pruebas y aceptación de ciberseguridad.
¡Descúbrelo!
La digitalización de las subestaciones amplió la capacidad de protección, control, supervisión, teleasistencia y diagnóstico, pero también aumentó la cantidad de activos programables, interfaces de comunicación y accesos que deben gobernarse. Relés digitales, IED, UTR, SSCL, switches, gateways, servidores, estaciones de ingeniería, sistemas SCADA y conexiones con centros de operación forman una infraestructura de tecnología operacional — OT — directamente vinculada al proceso eléctrico.
En este entorno, una falla cibernética no se limita a la pérdida de información. Puede provocar pérdida de supervisión, indisponibilidad de telemandos, alteración de ajustes, bloqueo de estaciones de ingeniería, degradación de canales de comunicación o presentación de estados incorrectos al operador. La ingeniería de ciberseguridad debe, por tanto, preservar simultáneamente la seguridad de las personas, la integridad de las funciones, la disponibilidad de la operación y la capacidad de recuperación.
La IEC 62443 ofrece conceptos y estructuras para tratar la seguridad de sistemas industriales de automatización y control a lo largo del ciclo de vida. En subestaciones, puede combinarse con referencias específicas de sistemas de potencia, como IEC 62351, con orientaciones de ingeniería de redes de ABNT NBR 16932 y con prácticas de seguridad OT consolidadas por NIST SP 800-82.
Este artículo presenta un método de aplicación de estos conceptos a subestaciones de distribución, transmisión y generación. El objetivo no es transformar la norma en una lista genérica de equipos, sino mostrar cómo riesgos, zonas, conductos, accesos, hardening, monitoreo y pruebas se convierten en entregables de proyecto y criterios de contratación.
Por qué las subestaciones exigen un enfoque propio de ciberseguridad
Las subestaciones combinan requisitos que normalmente no coexisten con la misma intensidad en redes corporativas. Determinadas comunicaciones tienen restricciones de latencia y previsibilidad; los activos pueden permanecer en operación durante décadas; las ventanas de mantenimiento son limitadas; los cambios deben coordinarse con protección, automatización y operación; y las fallas pueden afectar la continuidad del suministro eléctrico.
En TI corporativa, la confidencialidad puede ocupar una posición central. En OT, integridad y disponibilidad suelen recibir mayor peso, con la seguridad operacional como restricción superior. Esto no vuelve irrelevante la confidencialidad: diagramas, ajustes, topologías, credenciales y archivos de configuración también son sensibles. Significa que cualquier control debe analizarse por su efecto sobre el proceso.
Una solución de inspección profunda, autenticación o cifrado puede ser técnicamente deseable, pero inadecuada en un camino crítico de comunicación si introduce retraso, indisponibilidad o comportamiento no determinista. IEC 62443 reconoce este conflicto al tratar desempeño y continuidad como parte del propio problema de seguridad.
El enfoque correcto comienza con cuatro preguntas:
1. qué funciones eléctricas y operativas deben preservarse; 2. qué activos y comunicaciones sustentan esas funciones; 3. qué consecuencias pueden resultar de alteración, indisponibilidad o acceso indebido; 4. qué controles reducen el riesgo sin comprometer protección, control y seguridad operacional.
Qué es IEC 62443
IEC 62443 es una familia de documentos orientada a la ciberseguridad de sistemas industriales de automatización y control. El trabajo original de ISA99 fue utilizado en el desarrollo de la serie internacional, razón por la cual también son comunes las expresiones ISA/IEC 62443 e ISA IEC 62443.
La familia distribuye responsabilidades entre propietarios de activos, prestadores de servicios, integradores y fabricantes. En términos generales, sus documentos tratan de:
- conceptos, modelos y terminología;
- programas, políticas y procedimientos de seguridad;
- evaluación de riesgos y requisitos de sistemas;
- ciclo de desarrollo seguro y requisitos de componentes.
ABNT IEC/TS 62443-1-1:2023, disponible en la base técnica de A3A, establece conceptos fundamentales como defensa en profundidad, activos, amenazas, vulnerabilidades, zonas, conductos y niveles de seguridad. No debe utilizarse de forma aislada como si contuviera todos los requisitos detallados de las demás partes de la serie.
También es importante no presentar IEC 62443 como obligación universal. Los documentos técnicos ABNT son, por regla general, voluntarios. Pueden volverse exigibles cuando se incorporan a contratos, estándares corporativos, licitaciones, reglamentos u otros instrumentos aplicables al proyecto.
Requisitos fundamentales de seguridad industrial
ABNT IEC/TS 62443-1-1 identifica siete grupos fundamentales de requisitos. Ayudan a verificar si el proyecto cubre las dimensiones esenciales de seguridad.
| Requisito fundamental | Aplicación en una subestación |
| Control de acceso | Restringir quién o qué sistema puede alcanzar IED, servidores, switches, gateways y herramientas de ingeniería |
| Control de uso | Limitar lo que una identidad autenticada puede visualizar, alterar, comandar o administrar |
| Integridad de datos | Detectar o impedir alteraciones no autorizadas de comandos, ajustes, archivos, eventos y comunicaciones |
| Confidencialidad de datos | Proteger información sensible cuando el riesgo o el camino de comunicación lo justifique |
| Restricción del flujo de datos | Permitir únicamente comunicaciones necesarias entre zonas y activos |
| Respuesta oportuna a eventos | Detectar, registrar, comunicar y tratar violaciones o anomalías en un plazo compatible con el riesgo |
| Disponibilidad de recursos | Mantener funciones críticas y evitar que fallas o ataques agoten recursos necesarios para la operación |
Estos requisitos no son una lista de productos. El control de acceso, por ejemplo, puede involucrar identidad, reglas de firewall, protección física, política de proveedores y aprobación operacional. La disponibilidad puede depender de redundancia, alimentación CC, rutas independientes, backup y procedimientos de recuperación.
IEC 62443, IEC 62351, NIST 800-82 e ISO 27001
Las referencias se complementan, pero no tienen la misma finalidad.
IEC 62443
Proporciona una estructura para la seguridad de sistemas industriales de automatización y control, incluyendo ciclo de vida, responsabilidades, riesgo, zonas, conductos, requisitos de sistema y seguridad de componentes.
IEC 62351
La serie IEC 62351 trata la seguridad de datos y comunicaciones utilizados en la gestión y el intercambio de información en sistemas de potencia. La propia ABNT NBR 16932 indica esta serie como referencia para ciberseguridad de las comunicaciones y cita la parte dedicada a IEC 61850.
Mientras IEC 62443 ayuda a estructurar el programa y la arquitectura de seguridad del entorno OT, IEC 62351 se aproxima a los mecanismos aplicables a protocolos e intercambios del sector eléctrico. La selección de las partes aplicables debe considerar los protocolos efectivamente utilizados y el soporte de los equipos.
NIST SP 800-82
NIST SP 800-82 Rev. 3 es una guía de seguridad OT que aborda gobernanza, riesgos, arquitecturas, segmentación, acceso remoto, monitoreo, proveedores, vulnerabilidades, incidentes y recuperación. Es una referencia de buenas prácticas, no un reglamento brasileño.
El documento enfatiza que los controles de TI deben adaptarse a las restricciones de desempeño, disponibilidad y seguridad operacional de OT. También recomienda un equipo multidisciplinario que reúna automatización, operación, redes, TI, ciberseguridad, seguridad física, gestión y proveedores cuando sea necesario.
ISO/IEC 27001
ISO/IEC 27001 proporciona la estructura de un sistema de gestión de seguridad de la información. Es útil para gobernanza, evaluación de riesgos, responsabilidades, auditorías y mejora continua. IEC 62443 añade especificidad para entornos industriales y sus restricciones operacionales.
Ninguna de estas referencias sustituye los requisitos del propietario del activo, los procedimientos de la concesionaria, la filosofía de operación o las condiciones contractuales del proyecto.
La seguridad no es un proyecto con fecha de término
IEC 62443 trata la seguridad como un ciclo de vida. Una arquitectura puede cumplir los requisitos en el momento de la puesta en servicio y perder eficacia posteriormente por nuevas vulnerabilidades, cambios de configuración, obsolescencia, accesos no revocados o cambios en las amenazas.
El ciclo debe incluir:
- evaluación y definición de requisitos;
- proyecto y especificación;
- implantación y validación;
- operación y monitoreo;
- mantenimiento y gestión de cambios;
- reevaluación de riesgos;
- modernización, desactivación y descarte seguro.
Esta perspectiva es especialmente importante en subestaciones, donde la vida útil del activo primario y de los sistemas de protección puede superar el ciclo de soporte de sistemas operativos, switches, servidores y componentes de software.
Activos y funciones críticas de una subestación
El inventario no debe comenzar únicamente por las direcciones IP. Es necesario relacionar activos físicos, lógicos y humanos con las funciones que sustentan.
Activos físicos y tecnológicos
- relés de protección e IED;
- merging units y equipos de interfaz con el proceso;
- UTR, RTU, SSCL y gateways;
- switches, routers, firewalls y equipos de telecomunicaciones;
- servidores SCADA, históricos y servicios de sincronismo;
- estaciones de operación y de ingeniería;
- sistemas de teleprotección;
- VMS, cámaras y equipos de video operativo;
- paneles de control, distribuidores ópticos y enlaces;
- fuentes, rectificadores, bancos de baterías y UPS.
Activos lógicos
- firmware y versiones de software;
- ajustes de relés;
- lógicas de protección y control;
- archivos SCL y bases de datos;
- configuraciones de switches y firewalls;
- certificados y claves;
- listas de puntos y matrices de telemandos;
- diagramas, procedimientos y backups;
- registros de eventos e históricos.
Activos humanos y organizativos
- operadores;
- ingenieros de protección, automatización y telecomunicaciones;
- equipos de mantenimiento;
- administradores de redes y servidores;
- integradores y fabricantes;
- gestores responsables de la aceptación de riesgo.
El compromiso de una estación de ingeniería puede ser más relevante que la pérdida temporal de una estación de consulta, porque la primera puede alterar configuraciones de varios activos. La criticidad debe reflejar función, autoridad y consecuencia.
Inventario y clasificación de activos OT
Un inventario útil para ingeniería y seguridad debe incluir, como mínimo:
| Campo | Finalidad |
| Identificación y ubicación | Relacionar el activo con el bay, panel, sala, subestación o centro de operación |
| Función | Indicar protección, control, supervisión, telecomunicaciones, video o gestión |
| Fabricante y modelo | Apoyar soporte, vulnerabilidades, reposición y compatibilidad |
| Hardware, firmware y software | Determinar estado de actualización y dependencias |
| Interfaces y direcciones | Mapear puertos físicos, direcciones IP, MAC, seriales e interfaces ópticas |
| Protocolos y servicios | Identificar MMS, GOOSE, SV, SNMP, NTP, PTP, DNP3, IEC 60870-5-104 y otros |
| Zona y conducto | Relacionar el activo con la arquitectura de seguridad |
| Responsable | Definir propietario técnico y autoridad de cambio |
| Criticidad | Registrar el impacto de la pérdida de integridad, disponibilidad o control |
| Soporte y fin de vida | Planificar actualización, stock, sustitución y controles compensatorios |
| Backup y restauración | Informar dónde está la configuración y cómo recuperarla |
El descubrimiento automático puede ayudar, pero las herramientas activas deben utilizarse con cautela. NIST registra que escaneos y pruebas inadecuados ya han causado interrupciones en redes de control. En entornos en operación, el levantamiento pasivo, la documentación existente, las consultas a los equipos y las ventanas controladas tienden a ser más seguros.
Análisis de riesgos cibernéticos
El análisis de riesgos debe relacionar activos, amenazas, vulnerabilidades, consecuencias y controles. No basta con importar una matriz de TI y cambiar el nombre de los servidores.
En subestaciones, las consecuencias pueden incluir:
- pérdida de visión del proceso;
- pérdida o retraso de telemandos;
- indicación incorrecta de estados;
- alteración de ajustes de protección;
- indisponibilidad de teleprotección;
- bloqueo de estaciones de ingeniería;
- pérdida de registros necesarios para el análisis de eventos;
- propagación a otras subestaciones o centros de operación;
- operación degradada durante un período superior al aceptable;
- necesidad de desplazamiento de emergencia del equipo;
- riesgo para la seguridad de personas y equipos.
Una evaluación práctica puede seguir el ciclo:
1. definir alcance, fronteras y funciones críticas; 2. inventariar activos y comunicaciones; 3. identificar amenazas y vulnerabilidades; 4. evaluar consecuencias físicas, operacionales y digitales; 5. estimar riesgo inicial; 6. seleccionar controles técnicos, administrativos y físicos; 7. evaluar el impacto de los controles sobre la operación; 8. registrar riesgo residual y autoridad de aceptación; 9. monitorear cambios y reevaluar periódicamente.
La respuesta puede involucrar evitar, reducir, compartir, transferir o aceptar el riesgo. La aceptación debe ser explícita y trazable, principalmente cuando la corrección depende de una futura ventana de desconexión o sustitución del activo.
Amenazas relevantes para subestaciones
La seguridad no debe considerar únicamente invasores externos. IEC 62443 y NIST tratan amenazas intencionales, accidentales, estructurales y ambientales.
| Origen | Ejemplos |
| Adversarial | acceso indebido, malware, manipulación de comandos, falsificación de datos, denegación de servicio y abuso de credenciales |
| Interna | alteración no autorizada, uso excesivo de privilegios, eliminación de logs o conexión de un dispositivo no aprobado |
| Accidental | error de configuración, aplicación de patch incompatible, comando en la instalación equivocada o uso de herramienta inadecuada |
| Estructural | falla de hardware, fuente, switch, software, almacenamiento, sincronismo o comunicación |
| Ambiental | sobretensiones, interferencia electromagnética, pérdida de climatización, incendio, inundación o falla prolongada de energía |
| Cadena de suministro | componente comprometido, software sin soporte, actualización insegura o acceso excesivo del proveedor |
La arquitectura también debe responder a errores y fallas no maliciosas. Un control que protege contra intrusión, pero crea un punto único de falla, puede reducir la seguridad global de la operación.
Zonas y conductos
Las zonas y los conductos son conceptos centrales de IEC 62443.
Una zona de seguridad agrupa activos físicos, lógicos o de aplicación que comparten requisitos de seguridad. Posee una frontera, política, responsables y criterios de acceso. Puede ser física, como una sala de telecomunicaciones, o lógica, como un conjunto de servidores e IED separados por función.
Un conducto agrupa comunicaciones y mecanismos que permiten el flujo de información dentro de una zona o entre zonas. Un conducto puede incluir enlaces, switches, routers, firewalls, gateways, VPN y reglas que protegen los canales transportados.
La definición debe partir de la función y del riesgo, no únicamente de la topología existente.
| Elemento | Preguntas de proyecto |
| Activos de la zona | ¿Qué dispositivos, aplicaciones y personas pertenecen al grupo? |
| Función | ¿Qué proceso o servicio sustenta la zona? |
| Frontera | ¿Dónde comienzan y terminan la responsabilidad y el control? |
| Riesgo | ¿Cuál es la consecuencia de un compromiso o indisponibilidad? |
| Flujos | ¿Con qué zonas es realmente necesaria la comunicación? |
| Controles | ¿Cómo se implementarán identidad, integridad, disponibilidad y restricción de flujo? |
| Gestión | ¿Quién aprueba cambios y quién responde por los activos? |
| Monitoreo | ¿Qué eventos e indicadores demuestran la condición de la zona? |
Una VLAN no constituye, de forma aislada, una zona de seguridad completa. Puede colaborar con la separación lógica, pero debe combinarse con controles de flujo, protección de puertos, gestión de configuración, monitoreo, reglas de acceso y documentación.
Una arquitectura segura comienza por el inventario, las zonas y el control de los flujos.
El proyecto debe convertir el análisis de riesgos en topología, fronteras, comunicaciones permitidas, accesos, monitoreo y criterios de aceptación compatibles con la operación de la subestación.
Arquitectura de referencia para subestaciones
Cada concesionaria o agente puede adoptar una arquitectura corporativa de referencia y detallarla por familia de subestación. El modelo debe reflejar la realidad operacional y no solo un diseño genérico basado en niveles.
A continuación se presenta una posible descomposición.
| Zona | Activos y funciones típicas | Consideraciones principales |
| Proceso | sensores, actuadores, merging units e interfaces primarias | integridad, disponibilidad, latencia y acceso físico |
| Protección y control | relés, IED, unidades de bay y enclavamientos | desempeño determinista, independencia y cambio controlado |
| Supervisión local | UTR, SSCL, gateways, HMI y servidores locales | disponibilidad, lista de puntos, comandos y logs |
| Estación de ingeniería | herramientas, notebooks y archivos de configuración | acceso privilegiado, integridad y trazabilidad |
| Telecomunicaciones operacionales | switches, routers, multiplexores y WAN | redundancia, rutas, gestión y supervisión |
| Teleprotección | relés, equipos y canales dedicados o lógicos | baja latencia, independencia y pruebas end-to-end |
| Video operativo | cámaras, VMS, grabación e integraciones con eventos | separación de tráfico, disponibilidad y acceso controlado |
| Seguridad patrimonial | CCTV, acceso, perímetro e intrusión | impedir que los sistemas de seguridad creen un camino hacia OT |
| DMZ OT | jump server, proxy, repositorio y transferencia controlada | impedir comunicación directa entre la red corporativa y OT crítica |
| Centro de operación | SCADA, históricos, estaciones y servicios de gestión | identidad, disponibilidad, segregación y continuidad |
| Red corporativa | aplicaciones administrativas y usuarios generales | no debe alcanzar directamente activos de niveles operacionales inferiores |
| Acceso remoto | VPN, bastion, autenticación y registro de sesiones | aprobación, duración limitada, menor privilegio y revocación |
La lista no es universal. Una instalación pequeña puede combinar funciones; una operación de mayor criticidad puede subdividir protección principal y alternativa, separar estaciones de ingeniería por dominio o crear zonas distintas para sincronismo y gestión.
La arquitectura de zonas y conductos depende de una base de red bien definida. Topología, switches, VLAN, enrutamiento, protocolos, redundancia y monitoreo deben especificarse en conjunto, conforme se detalla en la guía de redes industriales, seguridad e integración con SCADA.
Segmentación entre protección, control, SCADA, video y gestión
La segmentación debe impedir que una falla o compromiso en un sistema menos crítico se propague libremente hacia funciones de protección y control.
Algunas separaciones que merecen análisis son:
- bus de proceso y bus de estación;
- sistemas principal y alternativo de protección;
- protección y supervisión;
- red local de la subestación y WAN operacional;
- gestión de equipos y tráfico funcional;
- estación de ingeniería y estaciones de operación;
- video operativo y automatización;
- seguridad patrimonial y red OT;
- subestación y centro de operación;
- OT y red corporativa.
ABNT NBR 16932 proporciona orientaciones de ingeniería para redes IEC 61850, incluyendo topologías, redundancia, VLAN, multicast, desempeño, sincronismo, gestión y pruebas. La propia norma informa que no detalla ciberseguridad. Por ello, su uso debe combinarse con una arquitectura de seguridad basada en riesgo.
La separación lógica puede ser adecuada en determinadas aplicaciones, siempre que se analicen el riesgo, el desempeño y las fallas comunes. Protección principal y alternativa en VLAN diferentes, pero en los mismos switches, fuentes y enlaces, continúan sujetas a dependencias compartidas.
Matriz de flujos autorizados
Antes de configurar firewalls y ACL, debe elaborarse una matriz de comunicación. Esta transforma la arquitectura en requisitos verificables.
| Origen | Destino | Servicio o protocolo | Dirección | Finalidad | Criticidad | Responsable |
| IED de bay | SSCL | MMS | según arquitectura | supervisión y control | alta | automatización |
| IED | IED | GOOSE | multicast local | enclavamiento o protección | crítica | protección |
| Reloj | IED y switches | PTP/NTP/IRIG-B | distribución | sincronismo | alta | automatización/telecom |
| SSCL | Centro de operación | protocolo de telecontrol | bidireccional controlado | datos y telemandos | alta | operación |
| Estación de ingeniería | IED | protocolo de gestión | sesión autorizada | parametrización | crítica | protección/automatización |
| Dispositivo OT | servidor de logs | syslog o mecanismo soportado | salida | auditoría | media/alta | ciberseguridad |
La política recomendada es negar por defecto y permitir únicamente lo necesario. Las reglas de salida también deben controlarse. Un activo comprometido puede utilizar comunicaciones de salida para movimiento lateral, comando y control o exfiltración.
DMZ OT y comunicación con la red corporativa
Cuando existe necesidad de integración entre OT y TI, debe evitarse la comunicación directa entre la red corporativa y los niveles críticos. Una DMZ OT puede alojar servicios intermedios, como:
- jump server o bastion host;
- servidores de transferencia controlada;
- réplicas de históricos;
- proxy de actualización;
- servicios de autenticación específicos;
- colectores de logs;
- herramientas de monitoreo;
- gateways de aplicación.
La DMZ no debe ser solo una VLAN con otro nombre. Debe poseer fronteras controladas, políticas distintas, reglas mínimas, monitoreo y procedimientos de administración.
En casos donde el flujo deba ocurrir únicamente desde OT hacia entornos superiores, pueden considerarse gateways unidireccionales. La decisión depende de los servicios requeridos, de la necesidad de comandos o mantenimiento y del análisis de riesgo.
Identidades, perfiles y menor privilegio
El acceso a activos OT debe concederse con base en función, necesidad y período. Operadores, ingenieros, administradores, auditores y proveedores no necesitan los mismos permisos.
El proyecto debe definir:
- identidades individuales siempre que sea técnicamente viable;
- perfiles de acceso por función;
- cuentas administrativas separadas de las cuentas de uso común;
- cuentas técnicas con responsable y finalidad;
- procesos de concesión, revisión y revocación;
- tratamiento de cuentas de emergencia;
- protección y rotación de secretos;
- registro de acciones privilegiadas.
Las cuentas compartidas reducen la trazabilidad. Cuando un equipo legado no permite identidades individuales, los controles compensatorios pueden incluir bóveda de contraseñas, registro de retiro, supervisión de sesión, aprobación previa y correlación con orden de servicio.
La autenticación corporativa no debe aplicarse automáticamente a todos los niveles. Una dependencia directa de la red OT respecto de servicios corporativos puede comprometer la disponibilidad. La arquitectura debe decidir qué servicios serán locales, replicados o aislados.
Estaciones de ingeniería
La estación de ingeniería posee autoridad elevada porque puede alterar ajustes, lógicas, archivos SCL, configuraciones de red y parámetros de dispositivos. Debe tratarse como un activo crítico, no como un notebook convencional de mantenimiento.
Los controles posibles incluyen:
- uso dedicado a la función;
- inventario de software y versiones;
- bloqueo de aplicaciones no autorizadas;
- control de medios removibles;
- protección contra malware compatible con el entorno;
- autenticación fuerte;
- backups de las configuraciones antes y después de los cambios;
- registro de quién cambió qué y mediante qué orden de servicio;
- acceso únicamente a las zonas necesarias;
- almacenamiento controlado de archivos y credenciales;
- verificación antes de conectarse a diferentes subestaciones.
Cuando se permiten notebooks de proveedores, el contrato debe definir requisitos mínimos, validación, herramientas autorizadas, acceso a internet, protección contra malware y procedimiento de cuarentena.
Acceso remoto de operadores y proveedores
El acceso remoto atraviesa la frontera física de la subestación. Una VPN, de forma aislada, no resuelve identidad, autorización, duración, destino, registro y revocación.
Una arquitectura robusta puede incluir:
1. solicitud vinculada a ticket u orden de servicio; 2. aprobación operacional y técnica; 3. autenticación multifactor en la entrada remota; 4. acceso a jump server en la DMZ OT; 5. autorización únicamente para activos y protocolos necesarios; 6. ventana de tiempo definida; 7. monitoreo y registro de la sesión; 8. finalización automática al concluir la actividad; 9. validación de la configuración alterada; 10. revocación inmediata tras la conclusión o terminación contractual.
Las conexiones permanentes de fabricantes, módems olvidados, software de soporte no inventariado y reglas amplias de VPN constituyen riesgos recurrentes. El inventario debe incluir todos los caminos remotos, incluidas soluciones de nube, enlaces celulares y herramientas incorporadas en equipos.
El mantenimiento remoto también necesita modo degradado. La subestación no puede depender de la disponibilidad del acceso del proveedor para ejecutar funciones esenciales o restaurar una configuración básica.
Hardening de IED, relés, switches y gateways
Hardening es la definición y aplicación de una configuración de referencia que reduce la superficie de ataque sin impedir la función operacional.
IED y relés
- cambiar credenciales predeterminadas;
- crear perfiles según las capacidades del equipo;
- deshabilitar servicios y puertos no utilizados;
- controlar interfaces locales, frontales y de mantenimiento;
- proteger archivos de ajuste y firmware;
- configurar registros y alarmas disponibles;
- documentar modos de operación y llaves físicas;
- validar el impacto sobre protección y comunicación.
Switches y routers
- desactivar puertos no utilizados;
- limitar VLAN permitidas en cada puerto;
- controlar trunks e interfaces de gestión;
- utilizar protocolos de gestión seguros cuando sean compatibles;
- restringir el origen de la administración;
- configurar logs, hora y monitoreo;
- proteger configuraciones y backups;
- documentar multicast, QoS, redundancia y rutas.
Servidores y estaciones
- instalación mínima;
- solo servicios necesarios;
- firewall local compatible;
- cuentas de servicio con menor privilegio;
- control de aplicaciones;
- actualizaciones probadas;
- protección de bases de datos e históricos;
- backup y restauración verificados.
Una baseline debe identificar qué requisitos son obligatorios, recomendados o no aplicables. Las excepciones deben poseer justificación, riesgo, control compensatorio y aprobación.
Gestión de firmware, patches y vulnerabilidades
Actualizar inmediatamente cualquier activo puede ser tan arriesgado como no actualizar nunca. El proceso debe combinar inteligencia de vulnerabilidades, análisis de aplicabilidad y validación operacional.
Etapas recomendadas:
1. recibir avisos de fabricantes, CISA, bases de vulnerabilidades y fuentes sectoriales; 2. identificar modelos, versiones y activos afectados; 3. evaluar exposición, función, consecuencia y existencia de explotación; 4. consultar compatibilidad y dependencias; 5. probar en un entorno representativo; 6. planificar ventana, backup y rollback; 7. aplicar y validar funciones; 8. registrar evidencias y actualizar el inventario; 9. implementar control compensatorio cuando la corrección no pueda aplicarse.
Los controles compensatorios pueden involucrar segmentación adicional, restricción de acceso, bloqueo de un servicio vulnerable, monitoreo específico o sustitución planificada. No deben convertirse en una excusa permanente para mantener activos sin soporte.
El programa también debe tratar el fin de vida. Fabricantes e integradores deben informar períodos de soporte, política de vulnerabilidades, disponibilidad de firmware y requisitos de actualización.
Certificados, claves y sincronismo
Los certificados y las claves pueden autenticar dispositivos, usuarios y comunicaciones, pero introducen una infraestructura que debe operarse.
El proyecto debe definir:
- autoridad emisora y cadena de confianza;
- inventario de certificados;
- responsables de emisión y renovación;
- almacenamiento de claves privadas;
- tratamiento de expiración y revocación;
- sustitución de equipo;
- recuperación tras pérdida de configuración;
- impacto de un reloj incorrecto sobre la validación.
El sincronismo también sustenta eventos, registros e investigación. Las fuentes de tiempo, caminos principal y alternativo, holdover, alarmas y seguridad de la distribución deben documentarse. La alteración indebida del tiempo puede perjudicar la correlación de eventos y la trazabilidad.
Logs, monitoreo y detección
El monitoreo debe combinar contexto operacional y cibernético. En redes OT, el tráfico tiende a ser más previsible que en redes corporativas, lo que favorece la creación de baselines.
Las fuentes posibles incluyen:
- firewalls y routers;
- switches;
- servidores y estaciones;
- IED y gateways que soporten registro;
- sistemas SCADA y SDSC;
- control de acceso físico;
- sistemas de acceso remoto;
- antivirus, allowlisting y herramientas de integridad;
- plataformas de gestión e inventario.
Eventos relevantes:
- autenticación exitosa o denegada;
- creación y modificación de cuentas;
- cambio de configuración;
- actualización de firmware;
- alteración de regla de firewall;
- conexión de dispositivo;
- pérdida o retorno de comunicación;
- cambio de ruta o redundancia;
- falla de sincronismo;
- tráfico nuevo entre activos;
- uso de protocolo no previsto;
- reinicio y pérdida de recursos.
La recopilación pasiva mediante TAP o SPAN suele ser preferible como punto de partida. Las respuestas automáticas de IPS deben evaluarse cuidadosamente porque un bloqueo incorrecto puede afectar comunicaciones críticas.
La integración con SIEM o SOC es posible, pero los casos de uso deben considerar la semántica de OT. Una ráfaga GOOSE legítima, una conmutación PRP o una secuencia de eventos operacionales no debe interpretarse sin contexto.
Backup, restauración y continuidad
El backup debe abarcar más que archivos de servidor. La recuperación puede depender de:
- ajustes y firmware de IED;
- proyectos de automatización y archivos SCL;
- configuraciones de switches, routers y firewalls;
- bases de datos y listas de puntos;
- certificados y documentación de claves;
- imágenes de sistemas e instaladores;
- licencias;
- versiones compatibles de herramientas de ingeniería;
- diagramas, inventarios y procedimientos.
Las copias deben protegerse contra alteración e indisponibilidad. Al menos una parte debe permanecer separada del entorno operacional para resistir incidentes destructivos.
La restauración debe probarse. La prueba debe responder:
- si el archivo está íntegro;
- si existe una herramienta compatible para abrirlo;
- si la versión puede cargarse en el equipo;
- si las licencias y certificados están disponibles;
- si la secuencia de recuperación está documentada;
- si el tiempo de restauración atiende la necesidad operacional.
La continuidad también implica operación degradada. Los procedimientos deben indicar cómo se operará la subestación durante pérdida de SCADA, WAN, servidor, sincronismo, estación de ingeniería o parte del monitoreo de ciberseguridad.
Respuesta a incidentes en entornos OT
El plan de respuesta debe elaborarse antes del incidente. La contención de TI basada en apagar o aislar inmediatamente un equipo puede ser inadecuada cuando el activo sustenta protección, control o seguridad.
El procedimiento debe definir:
- clasificación del incidente;
- funciones y autoridades;
- contactos de operación, protección, automatización, telecomunicaciones, TI y proveedores;
- criterios para aislamiento;
- preservación de evidencias;
- comunicación interna y externa;
- operación segura durante la respuesta;
- restauración y validación;
- retorno a la condición normal;
- análisis de causa y mejora.
Entre los escenarios útiles para ejercicios están:
- credencial de proveedor comprometida;
- malware en estación de ingeniería;
- cambio no autorizado en un relé;
- pérdida de visibilidad en el centro de operación;
- tráfico anormal en la red de estación;
- indisponibilidad de servidor SCADA;
- compromiso de VPN;
- ransomware en entorno corporativo con riesgo de propagación a OT;
- pérdida de configuración de switch o firewall.
Los ejercicios de mesa permiten verificar decisiones y responsabilidades sin afectar la instalación. Las pruebas técnicas deben planificarse para no interrumpir funciones activas.
Seguridad física y ciberseguridad
La frontera cibernética puede superarse físicamente. Puertos de switch, interfaces seriales, USB, paneles, racks, cajas de empalme y equipos en ubicaciones remotas necesitan protección proporcional a la criticidad.
La integración con control de acceso, intrusión y CCTV puede ayudar a correlacionar:
- entrada de una persona en una sala técnica;
- apertura de un panel;
- conexión de equipo;
- inicio de sesión administrativa;
- cambio de configuración;
- salida del lugar.
Los propios sistemas de seguridad física son activos conectados. Cámaras, controladoras y paneles no deben crear un puente no controlado hacia redes de automatización. El video operativo y la seguridad patrimonial deben tener flujos y zonas definidos.
Seguridad de proveedores y cadena de suministro
Las subestaciones dependen de fabricantes, integradores, desarrolladores y prestadores de mantenimiento. El riesgo no termina con la entrega del equipo.
Los requisitos contractuales pueden incluir:
- prácticas de desarrollo seguro;
- proceso de divulgación de vulnerabilidades;
- plazo de comunicación al contratante;
- política de patches y firmware;
- período de soporte y fin de vida;
- composición de software o SBOM cuando corresponda;
- cuentas y accesos necesarios;
- protección de los entornos de desarrollo y soporte;
- control de subcontratistas;
- devolución o eliminación de datos;
- transferencia de configuraciones, contraseñas y certificados;
- apoyo durante incidentes;
- evidencias de pruebas de seguridad.
Un producto certificado o con recursos de seguridad no garantiza, por sí solo, que la instalación alcanzará el nivel previsto. La seguridad resulta de la combinación entre capacidades del componente, arquitectura, configuración, procesos y operación.
Proyecto y documentación de ciberseguridad OT
La contratación debe producir documentos utilizables por implantación, operación y fiscalización.
Entre los posibles entregables están:
- definición de alcance y fronteras;
- inventario de activos OT;
- clasificación de criticidad;
- matriz de riesgos y tratamiento;
- arquitectura de referencia;
- mapa de zonas y conductos;
- matriz de flujos autorizados;
- tabla de puertos y protocolos;
- matriz de accesos y perfiles;
- política de acceso remoto;
- baseline de hardening por familia de activos;
- requisitos de logs y monitoreo;
- estrategia de certificados y claves;
- plan de vulnerabilidades y actualizaciones;
- estrategia de backup y recuperación;
- plan de respuesta a incidentes;
- requisitos de proveedores;
- especificaciones para adquisición;
- plan de modernización;
- procedimientos de FAT y SAT;
- matriz de pruebas y criterios de aceptación;
- documentación as-built.
El proyecto debe identificar claramente qué corresponde a la concesionaria, al integrador de automatización, al proveedor de telecomunicaciones, al fabricante de relés y al equipo de ciberseguridad. Las interfaces indefinidas tienden a generar lagunas.
Modernización de subestaciones existentes
En instalaciones existentes, la implantación debe comenzar por diagnóstico y plan de transición. Los equipos legados pueden no soportar autenticación individual, cifrado, logs o firmware actual.
La modernización debe considerar:
- indisponibilidades permitidas;
- secuencia de migración;
- coexistencia entre equipos nuevos y antiguos;
- ventanas de desconexión;
- controles compensatorios;
- retorno a la condición anterior;
- actualización de los centros de operación;
- compatibilidad de herramientas;
- capacitación de los equipos;
- revisión de procedimientos.
La segmentación puede implantarse progresivamente, comenzando por fronteras críticas, accesos remotos y caminos entre TI y OT. El objetivo es reducir riesgo sin crear una transformación inviable o una arquitectura paralela imposible de mantener.
FAT, SAT y puesta en servicio de ciberseguridad
Los controles de seguridad deben probarse como parte del sistema. El FAT puede verificar configuraciones, perfiles, flujos, hardening, logs, backups y comportamiento de componentes antes de la instalación. El SAT valida la arquitectura real, incluyendo enlaces, direcciones, reglas, integraciones y condiciones de campo.
Una matriz de pruebas puede incluir:
| Dominio | Verificación |
| Inventario | modelo, versión, dirección, función y responsable coinciden con el proyecto |
| Zonas | los activos están conectados a las zonas previstas y no existen caminos alternativos |
| Flujos | solo se permiten puertos, protocolos, orígenes y destinos aprobados |
| Identidades | perfiles, cuentas administrativas, cuentas técnicas y revocaciones funcionan |
| Acceso remoto | MFA, aprobación, jump server, limitación temporal y logs son comprobados |
| Hardening | servicios innecesarios, credenciales predeterminadas y puertos no utilizados fueron tratados |
| Redundancia | fallas de enlaces, equipos y fuentes no eliminan funciones críticas |
| Desempeño | los controles no degradan GOOSE, SV, teleprotección, SCADA o sincronismo más allá de lo permitido |
| Monitoreo | los eventos son generados, transportados, sincronizados e interpretados correctamente |
| Backup | las configuraciones son exportadas, protegidas y restauradas en un entorno controlado |
| Incidentes | los procedimientos, contactos y operación degradada son ejercitados |
| Documentación | diagramas, matrices, configuraciones e informes reflejan la instalación final |
Las pruebas activas, escaneos y simulaciones deben estar autorizados y evaluados en cuanto al riesgo. En producción, herramientas inadecuadas pueden bloquear controladores o degradar comunicaciones.
Los controles declarados en proyecto deben comprobarse durante FAT, SAT y operación asistida.
Las pruebas deben validar segmentación, perfiles, acceso remoto, hardening, logs, redundancia, recuperación y el impacto de los controles sobre GOOSE, SV, teleprotección, SCADA y sincronismo.
Conozca el servicio de Puesta en Servicio y Aceptación Técnica
Criterios de aceptación y dossier técnico
Cada requisito debe asociarse con método, resultado esperado, tolerancia y evidencia. Declaraciones como “red segmentada” o “acceso seguro” son insuficientes sin demostración.
El dossier puede reunir:
- matriz de requisitos y trazabilidad;
- diagramas aprobados y as-built;
- inventario final;
- configuraciones exportadas;
- informe de reglas y flujos;
- lista de cuentas y perfiles;
- evidencias de hardening;
- resultados de FAT y SAT;
- mediciones de desempeño;
- pruebas de redundancia y recuperación;
- registros de acceso remoto;
- backups e informe de restauración;
- pendientes, riesgos aceptados y planes de acción;
- términos de aceptación.
Los pendientes de ciberseguridad necesitan responsable, plazo, impacto y control temporal. La energización o entrada en operación no debería borrar la trazabilidad de esos pendientes.
Owner’s Engineering en programas de subestaciones
En programas con varias subestaciones y proveedores, Owner’s Engineering puede actuar en la gobernanza de las interfaces y en la verificación independiente de los requisitos.
Las actividades posibles incluyen:
- revisar arquitectura y especificaciones;
- verificar adherencia a estándares corporativos;
- analizar propuestas técnicas;
- coordinar protección, automatización, telecomunicaciones y ciberseguridad;
- controlar documentos y revisiones;
- acompañar FAT y SAT;
- verificar la matriz de pruebas;
- registrar pendientes y desvíos;
- evaluar solicitudes de cambio;
- consolidar evidencias de aceptación;
- acompañar riesgos residuales.
Esta función es particularmente útil cuando cada proveedor demuestra únicamente su equipo, pero nadie demuestra el comportamiento integrado de la subestación y del centro de operación.
Indicadores para operación continua
Después de la puesta en servicio, los indicadores ayudan a demostrar si se mantiene el nivel de seguridad.
- porcentaje de activos inventariados;
- activos sin soporte o próximos al fin de vida;
- vulnerabilidades por criticidad y plazo;
- accesos remotos realizados y excepciones;
- cuentas sin revisión periódica;
- cambios no conciliados con la baseline;
- fallas de backup o restauración;
- fuentes de logs indisponibles;
- comunicaciones nuevas o no autorizadas;
- tiempo de detección y tratamiento de incidentes;
- controles y procedimientos probados;
- pendientes de FAT y SAT aún abiertos.
El indicador no debe incentivar acciones inseguras. Una meta de aplicación rápida de patches, por ejemplo, debe considerar pruebas, ventana e impacto operacional.
Errores comunes
Tratar IEC 62443 como checklist de equipos
La norma estructura riesgo, responsabilidades, arquitectura y ciclo de vida. Comprar firewall o NAC no sustituye inventario, flujos, políticas y pruebas.
Crear VLAN sin controlar las comunicaciones
Las VLAN ayudan en la organización y segmentación lógica, pero por sí solas no garantizan restricción de flujo, identidad o monitoreo.
Aplicar prácticas de TI sin evaluar la operación
Escaneos, patches, IPS y autenticación pueden introducir indisponibilidad o latencia. Cada control debe probarse en el contexto de la función.
Conectar sistemas de apoyo directamente a la red crítica
Video, acceso, mantenimiento, impresión, antivirus, historización y servicios corporativos pueden crear caminos no planificados.
Mantener acceso permanente de proveedores
El acceso sin aprobación, duración, registro y revocación amplía la superficie de ataque y reduce la responsabilización.
No conocer los activos existentes
Sin modelo, versión, firmware, función y responsable, no es posible evaluar vulnerabilidad, soporte o impacto.
Confundir redundancia con independencia
Dos sistemas que comparten switch, fuente, cable, servidor o credencial pueden fallar simultáneamente.
Probar únicamente la configuración nominal
La aceptación debe incluir pérdida de enlace, falla de autenticación, indisponibilidad del servicio, restauración, conmutación y operación degradada.
Finalizar el programa después de la implantación
El nivel alcanzado disminuye con el tiempo. Auditoría, vulnerabilidades, cambios, capacitación y revalidación deben continuar.
Rutas de profundización en ciberseguridad OT
IEC 62443 proporciona la arquitectura de riesgo, zonas, conductos y ciclo de vida. Los controles específicos pueden profundizarse en las rutas siguientes.
Identidad y acceso
Monitoreo y protección
- SIEM en entornos OT
- EDR y XDR en servidores SCADA y estaciones de ingeniería
- SNMPv3 y monitoreo de la infraestructura
Protocolos y arquitectura
- IEC 62351 para IEC 61850, IEC 104 y DNP3
- DMZ entre redes TI y OT
- Hardening de servidores, endpoints y activos OT
- Subestación digital e IEC 61850
- Telecomunicaciones operacionales en subestaciones
Cómo contratar un proyecto de ciberseguridad para subestaciones
El término de referencia debe informar:
- tipos y cantidad de instalaciones;
- etapa de los proyectos o condición del legado;
- arquitectura corporativa existente;
- estándares de protección, automatización y telecomunicaciones;
- sistemas y protocolos involucrados;
- centros de operación e integraciones;
- requisitos de acceso remoto;
- proveedores existentes;
- restricciones de ventana e indisponibilidad;
- entregables y formatos;
- responsabilidades por implantación;
- pruebas y criterios de aceptación;
- necesidad de apoyo a la adquisición, fiscalización u Owner’s Engineering.
Las propuestas deben compararse por el método y los productos de ingeniería, no únicamente por la cantidad de equipos de seguridad. El contratante debe saber quién realizará el levantamiento, cómo se evaluarán los riesgos, qué documentos se producirán y cómo se probarán los controles.
Conclusión
Aplicar IEC 62443 en subestaciones significa transformar riesgos operacionales en decisiones de arquitectura, responsabilidades, controles y evidencias. El resultado no es una red aislada de forma indiscriminada, sino una infraestructura en la que cada activo es conocido, cada comunicación posee una finalidad, cada acceso posee autoridad y cada cambio puede rastrearse.
La seguridad debe preservar protección, control, telecomunicaciones y operación. Por ello, el proyecto debe integrar ingeniería eléctrica, automatización, redes, ciberseguridad, seguridad física y operación desde la definición de requisitos hasta la puesta en servicio.
Las zonas y los conductos ofrecen un lenguaje para organizar esta arquitectura. Inventario, matriz de flujos, acceso remoto controlado, hardening, monitoreo, recuperación y pruebas completan el ciclo. El mantenimiento continuo garantiza que el nivel alcanzado no se pierda con vulnerabilidades, cambios y obsolescencia.
Referencias técnicas
[1] ASOCIACIÓN BRASILEÑA DE NORMAS TÉCNICAS. ABNT IEC/TS 62443-1-1:2023 — Seguridad para sistemas de automatización y control industriales — Parte 1-1: Terminología, conceptos y modelos.
[2] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security. 2023.
[3] ASOCIACIÓN BRASILEÑA DE NORMAS TÉCNICAS. ABNT NBR 16932:2020 — Redes y sistemas de comunicación para automatización de sistemas de potencia — Orientaciones sobre ingeniería de red.
[4] ASOCIACIÓN BRASILEÑA DE NORMAS TÉCNICAS. ABNT NBR IEC 61850-10:2018 — Redes y sistemas de comunicación para automatización de sistemas de potencia — Parte 10: Ensayos de conformidad.
[5] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST CSWP 28 — Security Segmentation in a Small Manufacturing Environment.
Preguntas frecuentes
Es una familia de documentos para ciberseguridad de sistemas industriales de automatización y control. Trata conceptos, programas de seguridad, evaluación de riesgos, requisitos de sistemas, prestadores de servicios y componentes.
No de forma universal. Los documentos técnicos normalmente son voluntarios, pero pueden convertirse en requisitos cuando se incorporan a contratos, estándares corporativos, licitaciones, reglamentos u otros instrumentos aplicables.
Una zona agrupa activos que comparten requisitos de seguridad. Un conducto agrupa y protege las comunicaciones dentro de una zona o entre zonas, incluyendo canales, equipos, reglas y mecanismos de control.
No. La VLAN puede colaborar con la separación lógica, pero la zona también necesita frontera, política, control de flujos, gestión de acceso, monitoreo, responsables y criterios de prueba.
IEC 62443 estructura la seguridad de sistemas industriales, su ciclo de vida, riesgos, zonas y requisitos. IEC 62351 se concentra en la seguridad de datos y comunicaciones utilizados en sistemas de potencia. Son complementarias.
El acceso debe ser aprobado, autenticado con mecanismos fuertes, limitado a los activos necesarios, preferentemente intermediado por jump server o bastion, registrado, temporal y revocado al concluir la actividad.
No siempre. Los patches deben evaluarse y probarse respecto de compatibilidad, desempeño y seguridad operacional. Cuando no puedan aplicarse, deben adoptarse controles compensatorios y un plan de corrección o sustitución.
El monitoreo pasivo mediante TAP o SPAN suele ser el punto inicial más seguro. Las herramientas activas y respuestas automáticas deben evaluarse y probarse para no degradar comunicaciones críticas.
El uso compartido no debe presumirse. Video, seguridad física y automatización tienen requisitos diferentes y deben separarse mediante zonas y flujos controlados según el análisis de riesgo.
Deben verificarse inventario, zonas, flujos, perfiles, acceso remoto, hardening, logs, redundancia, desempeño, backup, recuperación, fallas y adherencia de la documentación a la instalación real.
Owner’s Engineering puede revisar requisitos, coordinar interfaces, analizar propuestas, fiscalizar proveedores, acompañar pruebas, controlar pendientes y consolidar evidencias para la aceptación técnica.
Entre los principales están inventario, matriz de riesgos, arquitectura, mapa de zonas y conductos, matriz de flujos, perfiles de acceso, baseline de hardening, política de acceso remoto, plan de vulnerabilidades, monitoreo, backup, incidentes y pruebas.
Materiales técnicos complementarios
Soluciones
- Redes Industriales
- Network Access Control (NAC)
- Centro de Operaciones de Seguridad (SOC)
- Zabbix — Monitoreo de Infraestructura
Servicios de ingeniería
- Proyecto de Telecomunicaciones
- Integración de Sistemas
- Puesta en Servicio y Aceptación Técnica de Instalaciones Eléctricas
- Compatibilización e Integración de Proyectos
Materiales técnicos complementarios
