Cliente del sector energético, auditor en la puerta: «¿Hasta dónde han llegado con IEC 62443?». Cliente responde: «Tenemos firewall entre oficinas y producción». Eso no es IEC 62443. Eso es una hipótesis que romperá el primer penetration test. Este artículo trata de qué significa realmente llevar IEC 62443-3-3 a un nivel que pase auditoría y aguante un ataque real.
Por qué ahora — deadline NIS2
La Directiva NIS2 (UE 2022/2555) es vinculante para operadores de servicios esenciales en SR desde el **17 de octubre de 2024** (transposición vía Ley 366/2024 Z. z. de ciberseguridad). Para **operadores NIS2 (energía, agua, transporte, sanidad, manufactura crítica para la cadena de suministro, infraestructura digital)** eso significa la obligación de:
- Risk management framework según un estándar reconocido — IEC 62443 es la referencia de facto para OT.
- Incident reporting en **24 horas** desde la detección de un incidente significativo al Centro Nacional de Ciberseguridad.
- Penalty hasta **10 mill. EUR o el 2 % del volumen**, lo que sea mayor.
Realidad eslovaca: la auditoría NÚKIB del primer año NIS2 (otoño 2025) mostró que ~70 % de los operadores de servicios esenciales no tienen implementado ni el modelo Z/C (zonas y vedľajšie cesty/conduits), mucho menos una segmentación de red que corresponda a SL-1 (Security Level 1).
Modelo Z/C — base que se dibuja primero
IEC 62443-3-2 introduce el concepto de **zonas (Zones)** y **vías secundarias (Conduits)**. Zona = grupo de activos con la misma exigencia de seguridad. Conduit = canal de comunicación controlado entre zonas.
Modelo Z/C típico para nave productiva conectada a ERP
Z0 — Internet / Untrusted (Wild West). Z1 — Enterprise IT (oficinas, ERP, e-mail). Trust level Standard. Z2 — DMZ (servidores web, VPN endpoint, jump servers). Trust level Stricter. Z3 — Operations Management / Historian / MES (Purdue Level 3). Trust level OT-Standard. Z4 — SCADA + HMI (Purdue Level 2). Trust level OT-Strict. Z5 — PLC + control devices (Purdue Level 1). Trust level OT-Critical. Z6 — Field instrumentation (Purdue Level 0). Trust level OT-Critical.
Conduits: C0↔1 — firewall + IDS. ALL deny by default, excepciones para HTTP/HTTPS outbound desde el VPN endpoint. C1↔3 — OT-IT DMZ con proxy inverso. Datos del historian read-only hacia arriba (Z3 → Z1). Ningún comando hacia abajo. C3↔4 — diodo o gateway unidireccional para datos SCADA → MES. Ningún comando de control hacia arriba. C4↔5 — firewall protocol-aware (Tofino Xenon, Hirschmann Eagle One con DPI para Modbus/TCP, EtherNet/IP, S7Comm).
Dónde está físicamente el firewall OT-IT
Disputa habitual en la implantación: **dónde está físicamente el firewall OT-IT**. Tres variantes:
1. **Entre Purdue L2 (SCADA) y L3 (Historian / MES)** — solución más común. Aquí se despliega un firewall hardware con firmas específicas para OT: Fortinet FortiGate 1000F/2000F con OT Threat Intelligence, Cisco Industrial Security Appliance ISA-3000, Hirschmann EAGLE40-7G, o Tofino Xenon (Belden) si se exige «fail-secure». 2. **Entre L3 y L4 (Enterprise IT)** — algunos equipos de seguridad prefieren esta capa porque L3 ya es OT-zone. Funciona, pero los sistemas L3 (Historian) entonces respiran bajo políticas IT y empujan el ataque hacia los datos base. 3. **Ambas (defense in depth)** — la mejor opción para nivel SL-2+. Dos capas de firewalls, distintos vendors (Fortinet + Palo Alto es una mezcla habitual), ningún single point of failure.
Regla: **un conduit entre zonas con distinto Trust level DEBE tener un punto de control explícito**. Un switch con VLAN no es conduit. El switch es topología. Un conduit necesita inspección L3-L7.
SL-1 vs SL-2 vs SL-3 — dónde está la frontera
IEC 62443-3-3 define 7 foundational requirements (FR), cada uno con 4 niveles (SL-0 a SL-4). La frontera en la práctica:
SL-1 — protection against casual or coincidental violation
El mínimo que hoy debe tener cualquier sistema industrial. En concreto:
- Identificación y autenticación de usuarios para HMI/Engineering Workstation (contraseña, ninguna shared account).
- Capa de access control (RBAC en HMI — operario, mantenedor, ingeniero, admin).
- Logging de cambios (quién se logó, qué cambió, cuándo).
- Prohibición de USB en engineering workstations (BIOS-level disable + GPO).
- Antivirus / EDR en todas las estaciones Windows en zonas OT.
Coste de SL-1 para una producción mediana (50–100 estaciones OT): **30–60 k€** de infraestructura + **150–300 horas** de ingeniería.
SL-2 — protection against intentional violation using simple means with low resources
Aquí el precio cambia drásticamente. SL-2 sobre SL-1 incluye:
- **MFA (multi-factor authentication)** para accesos privilegiados. Lo más habitual YubiKey 5 NFC (~55 €/ud × 30 personas = 1 650 €) o Duo Security (8 €/user/mes).
- **Anti-malware con firmas OT** — Nozomi Networks Guardian, Claroty xDome, Dragos Platform, Forescout SilentDefense. Precios: **25–80 k€ licencia/año** según número de nodos monitorizados.
- **Segmentación de red con VLAN+ACL+firewall**, no solo VLAN. La microsegmentación en OT es relevante pero computacionalmente cara — típicamente con Cisco TrustSec o Forescout eyeSegment.
- **Cifrado del tráfico de management** (HTTPS en vez de HTTP para HMI web access, SSH en vez de Telnet, nada de SNMPv2c — solo SNMPv3 con authPriv).
- **Logging con integración SIEM** — todos los logs de firewall, IDS alerts, eventos de autenticación van al SIEM. Splunk Enterprise (2–4 €/GB/día), QRadar, Elastic Security, o el open-source Wazuh + ELK si el presupuesto va apretado.
- **Procedimientos de backup / restore con copias offline.** Imm copy, air gap, pruebas mensuales de restauración.
Coste de SL-2: **120–280 k€** de infraestructura + **500–1 000 horas** de ingeniería, más **15–25 % anual** en mantenimiento + threat intelligence subscription.
SL-3 — protection against intentional violation using sophisticated means with moderate resources
Aquí se añade:
- **NIDS con deep packet inspection** para protocolos OT (Modbus TCP, EtherNet/IP, S7Comm, OPC UA, DNP3) — Nozomi o Claroty en modo avanzado.
- **Active hardening** — port disable en interfaces no usadas, certificate-based device authentication, application whitelisting (Microsoft AppLocker, Carbon Black Protection).
- **Air-gapped engineering networks** — el engineering laptop nunca está conectado a OT e IT a la vez.
- **Ejercicios trimestrales de red team.**
- **Proceso detalladamente validado de change management** — ningún cambio de firmware de PLC sin approval en 3 etapas (engineering, operations, security).
Los costes de SL-3 ya son diametralmente otros — **500 k€–1,5 M€** de infraestructura + **2 000+ horas** de ingeniería + dedicated OT-security team (3–5 FTE). Este es el nivel que hoy cumplen sobre todo energéticas (centrales nucleares, transporte eléctrico), aguas críticas, algunos grandes complejos químicos.
NERC CIP — comparativa para clientes energéticos
Para operadores en energía (y sobre todo redes de transporte, redes de gas) también es relevante el americano NERC CIP (Critical Infrastructure Protection). Diferencias frente a IEC 62443:
- **NERC CIP-007** (System Security Management): comparable con IEC 62443-3-3 FR3 + FR4.
- **NERC CIP-005** (Electronic Security Perimeter): define el «Electronic Security Perimeter» (ESP), más estricto que la zone de IEC 62443 — exige **inventory explícito de cada access point cruzando el ESP** y annual review.
- **NERC CIP-010** (Configuration Change Management and Vulnerability Assessments): exige baseline configuration de cada control device, monthly vulnerability assessment. IEC 62443 lo cubre en FR2.
- **NERC CIP-008** (Incident Reporting): ventana de 1 hora de reporting para NERC frente a las 24 horas de NIS2.
Los clientes con exposición a NERC CIP y NIS2 (típicamente grandes utilities paneuropeas) suelen mapear ambos estándares a **un único framework interno** que cumple lo más exigente de los dos.
Deep packet inspection Modbus TCP — qué hace realmente
Modbus TCP es un protocolo SCADA de 1979 (Modbus RTU) con wrapper TCP de 1999. **Ninguna autenticación, ningún cifrado.** Cualquier dispositivo en la red que vea el puerto 502 puede enviar Write Single Coil (function code 5) y voltear la salida.
Un firewall con deep packet inspection (DPI), por ejemplo Tofino Xenon o Fortinet OT-aware, hace:
- **Distinción Read-only vs Read-Write**: permite function code 1–4 (read coils, read registers), prohíbe function code 5–6, 15–16 (write single/multiple coil/register) desde fuentes no autorizadas.
- **Function code filtering**: algunos function codes (8 — diagnostic, 17 — report slave ID) se prohíben fuera de la ventana de mantenimiento.
- **Address whitelisting**: SCADA → PLC direcciones 1–247 permitidas, fuera de rango = drop + alert.
- **Rate limiting**: > 10 write operations por segundo desde una IP = anomalía, alert.
Detección real de ataque en Modbus TCP por DPI: en promedio **80–95 %** de los ataques básicos (replay, command injection, address scanning). Los ataques sofisticados (Stuxnet-like) necesitan **integridad de la configuración del PLC** (HMI sees same value as PLC sends), lo cual es tarea para NIDS (Nozomi o Claroty), no para el propio firewall.
«Patches» en entorno OT — no espere Patch Tuesday mensual
En IT lo normal es ciclo de parches mensual. En OT lo normal es **2–4 patch windows al año**, típicamente:
- **Mantenimiento de primavera** (marzo–abril): outage planificado de 5–10 días, parcheo completo de OS, update de firmware PLC, upgrade del servidor SCADA.
- **Mantenimiento de otoño** (septiembre–octubre): mismo scope.
- **Ventana extraordinaria ante un CVE crítico** (CVSS 9+) en servicios accesibles, con respuesta en 24–72 horas.
El patch management en OT requiere:
- **Test bed / digital twin** — los parches se prueban antes en hardware duplicado o en simulador (Mimic Simulation Software, Codesys SoftPLC), nunca en producción.
- **Compensating controls** entre parches — si no es posible parchear (vendor end-of-life, sistema validado), la compensación se hace con reglas de firewall, monitorización adicional con IDS o network isolation.
- **Approved baseline** — el parche se distribuye solo si ha pasado approved por el change management board.
Pasos prácticos para los primeros 90 días para un operador NIS2
Si está en posición de que la auditoría puede llegar en 6–12 meses y IEC 62443 es solo una palabra en un PowerPoint:
1. **Inventory assets** (mes 1). Pasivo scan de red OT — Nozomi Guardian Trial, Claroty xDome PoC, o el open-source GRASSMARLIN/Wireshark + scripts custom. Objetivo: lista de cada PLC, HMI, switch, transmisor, drive, robot — IP, MAC, versión de firmware, vendor. 2. **Borrador del modelo Z/C** (mes 1–2). Workshop con ingenieros OT + IT security + management. Output: un diagrama A1 que se pega en la pared del sala de servidores. 3. **Risk assessment según IEC 62443-3-2** (mes 2). Tabla: zona × amenaza × probabilidad × consecuencia × SL target. 4. **Conduits prioritarios para implementar** (mes 3). Suelen llevarse la mejor puntuación C3↔4 (SCADA-MES) y C1↔3 (IT-OT DMZ). Lo menos C5↔6 (PLC-field). 5. **Vendor selection + PoC** (mes 3). Tres vendors, dos semanas cada uno en entorno de laboratorio, elección en base a protocol coverage + alerting accuracy + price.
Tras 90 días tiene un paquete documental defendible en auditoría + roadmap de implementación que lleva otros 12–18 meses para SL-2 / 24–36 meses para SL-3.
Errores más frecuentes en implantaciones eslovacas
- **«Tenemos firewall».** Pregunte: ¿lleva firma OT-aware? ¿Inspección Modbus/S7Comm? ¿Los logs van al SIEM? Si no, tiene un filtro de paquetes L3, no una security boundary.
- **«Lo hemos separado todo con VLAN».** Una VLAN sin ACL o sin firewall L3 entre ellas es solo broadcast separation. Un atacante en el mismo switch con VLAN hopping (DTP/802.1Q double tagging) salta en 30 segundos.
- **«Los PLC no están en internet».** Tras 6 meses, en cada auditoría hemos encontrado al menos un PLC accesible vía Shodan a través de un módem 4G no documentado (enchufado en el panel para «actualizar desde casa rápido»).
- **«El vendor hace updates remotos por TeamViewer».** TeamViewer / AnyDesk / VNC en zonas OT sin jump host y MFA es punto de entrada de supply chain attack. Sustituirlo por bastion host con recording (Wallix, BeyondTrust, o el open-source Apache Guacamole + audit log).
- **«No tenemos nada que proteger, somos pymes».** NIS2 también se aplica a **medium entities** en la cadena de suministro de servicios esenciales. Si usted es proveedor de una gran utility, su auditoría arrastra auditoría hasta usted.
---
*Lo escribimos como socio técnico que en los últimos 8 años ha implantado segmentación OT en energía, agua y manufactura. Si le espera auditoría NIS2 o implementación IEC 62443, la primera consulta (90 minutos) recorre su modelo Z/C, los conduits actuales y la roadmap, y le da una estimación realista de CAPEX y horas de ingeniería para SL-1 o SL-2 según su perfil de riesgo.*