Una planta industrial es una máquina que respira: bombas que arrancan solas, lazos de control que corrigen un caudal cada 200 milisegundos, enclavamientos que paran un molino antes de que se destruya. Nada de eso se diseñó pensando en que alguien, desde otro continente, pudiera escribir en un registro Modbus. Sin embargo, hoy esa misma planta tiene un historian que exporta datos a la nube, un proveedor que entra por VPN a hacer soporte y un ingeniero que descarga una lógica desde su laptop. La ciberseguridad industrial es, en el fondo, el trabajo de reconciliar esas dos realidades sin apagar la planta.
La norma que organiza ese trabajo es la serie ISA/IEC 62443. No es un checklist ni un producto: es un marco que reparte responsabilidades entre quien opera la planta, quien la integra y quien fabrica los equipos, y que traduce el riesgo en decisiones de arquitectura verificables. Este artículo la recorre completa y la aterriza en dos plantas de ejemplo, con los diagramas que uno realmente dibujaría en un proyecto.
La planta no se diseñó para estar conectada
El primer error de quien llega desde el mundo TI es asumir que un sistema de control es una oficina con más polvo. No lo es, y la diferencia no es cultural sino física: en TI el activo a proteger es la información; en tecnología de operación (en adelante, OT) el activo a proteger es un proceso que puede lastimar personas, contaminar un río o fundir un equipo de siete cifras.
Esa diferencia invierte el orden de prioridades clásico de la seguridad de la información.
A eso se suman restricciones que en TI no existen: protocolos como Modbus/TCP, DNP3 o PROFINET nacieron sin autenticación ni cifrado, porque el “perímetro” era una sala cerrada con llave; los equipos tienen ciclos de vida de quince o veinte años, frente a los tres o cuatro de un servidor; y parchear un PLC exige una ventana de parada que puede costar más que el riesgo que se quiere mitigar. Un antivirus con actualización automática, en una estación de ingeniería, es una forma elegante de provocar una parada no programada.
La historia reciente ya dejó claro que la amenaza no es teórica. Stuxnet manipuló en 2010 la lógica de controladores Siemens para dañar centrifugadoras; los apagones de Ucrania de 2015 y 2016 mostraron que se puede abrir un interruptor de potencia desde un teclado remoto; TRITON/TRISIS atacó en 2017 el sistema instrumentado de seguridad de una planta petroquímica, es decir, la última barrera antes de un accidente; y casos como Norsk Hydro (2019) o Colonial Pipeline (2021) probaron que un ransomware que ni siquiera toca el OT puede detener la producción, porque nadie se atreve a operar a ciegas.
Qué es la serie ISA/IEC 62443 y cómo está organizada
La serie nació en el comité ISA99 y se desarrolla junto con el IEC. En 2021 el IEC la reconoció como norma horizontal: deja de ser “la norma de una industria” para convertirse en la referencia que otros comités deben usar cuando escriben requisitos de ciberseguridad para su sector. Está organizada en cuatro grupos, y esa organización es la primera cosa útil que ofrece, porque cada grupo habla a un interlocutor distinto.
La consecuencia práctica de este mapa es que nadie implementa “la 62443” entera. Un operador de planta vive en 2-1 y 3-2; un integrador responde por 2-4 y 3-3; un fabricante de equipos por 4-1 y 4-2. Confundir esos ámbitos es la razón por la que muchos proyectos terminan comprando un firewall y declarando la tarea cumplida.
Tres actores y una cadena de responsabilidad
La serie asume que la seguridad de una planta es un resultado colectivo: si el fabricante no da un equipo con capacidades, el integrador no puede configurarlas; y si el operador no las mantiene, se degradan en un año. Por eso reparte el trabajo así:
El modelo por niveles: de la instrumentación al ERP
Antes de partir nada hay que entender qué se está partiendo. La serie usa un modelo por niveles heredado del modelo Purdue, que ordena los activos según su distancia al proceso físico. Cuanto más abajo, más determinista el tráfico y más grave la consecuencia de una interferencia; cuanto más arriba, más se parece a una red de oficina.
TI
TI
frontera
OT
OT
OT
proceso
El modelo es una guía de lectura, no un dogma. Una planta pequeña puede colapsar los niveles 2 y 3, y una arquitectura moderna con virtualización o con equipos de campo conectados directamente a la nube difumina las fronteras. Lo que la norma exige no es reproducir el dibujo, sino justificar por qué el suyo es distinto.
Zonas y conductos: partir la planta en compartimentos
El corazón conceptual de la serie está en dos definiciones. Una zona es un conjunto de activos agrupados porque comparten requisitos de seguridad: misma criticidad, misma función, misma consecuencia si alguien se mete. Un conducto es el conjunto de canales de comunicación que une dos zonas, tratado como un objeto propio, con sus propios requisitos y su propia justificación de existencia.
La pregunta que ordena todo el ejercicio es incómoda de tan simple: si un atacante toma esta zona, ¿qué alcanza desde ahí? La partición es buena cuando la respuesta es “poco”. Veamos una planta de tratamiento de agua potable, del tipo que opera cualquier EPS municipal.
Vale la pena leer el dibujo despacio, porque cada decisión responde a un criterio de la norma. La zona 1 agrupa proceso y control porque comparten la misma consecuencia: quien escribe en el PLC-02 puede sobredosificar cloro. La zona 1b existe aunque el reservorio esté a ocho kilómetros y tenga un solo equipo, porque su medio de comunicación —radio— tiene un perfil de amenaza distinto al de una fibra enterrada dentro de la planta. La zona 2 concentra lo que un operador toca todos los días. Y la zona 3, la DMZ, es la única que conversa con el mundo exterior.
Los conductos son igual de deliberados. El C2 está dibujado con una regla explícita —solo salida, sin sesiones entrantes— porque la forma más común de comprometer un historian es dejar que TI lo consulte directamente. El C4, el enlace de radio, es un conducto en sí mismo: exige autenticación y verificación de integridad del mensaje, no porque el reservorio sea crítico, sino porque el aire no tiene perímetro.
Los siete requisitos fundamentales
Con las zonas dibujadas hay que decir qué se les exige. La parte 3-3 organiza todos los requisitos técnicos de un sistema en siete requisitos fundamentales (FR), y la 4-2 hace lo propio con los componentes. Son siempre los mismos siete, para cualquier planta y cualquier sector; lo que cambia es cuánto se exige de cada uno.
Cada FR se despliega en requisitos de sistema (SR) —alrededor de medio centenar en la parte 3-3— y cada SR puede tener requisitos de mejora (RE) que se activan conforme sube la exigencia. Traducido a la planta de agua: FR 1 significa que el operador no comparte la cuenta “SCADA/SCADA” con el turno siguiente; FR 5 es la razón por la que el PLC-02 no tiene ruta hacia el ERP; FR 6 obliga a que un intento fallido de escritura en el PLC deje rastro y alguien lo vea; y FR 7 exige que el sistema siga controlando el proceso aunque la red se degrade, algo que ningún estándar de TI le pide a nadie.
Niveles de seguridad: contra quién nos estamos defendiendo
La serie evita la trampa de clasificar la seguridad como “alta” o “baja” y define cuatro niveles según el adversario que se quiere resistir. No mide cuán buena es la protección en abstracto: mide contra quién aguanta.
Lo verdaderamente útil, sin embargo, es que el mismo número se usa en tres sentidos distintos, y confundirlos es el error más caro de un proyecto de OT.
El proyecto de ciberseguridad industrial consiste, literalmente, en cerrar la distancia entre el primer medidor y el tercero. La condición de aceptación se escribe en una línea:
SL-A nivel realmente alcanzado
R riesgo tras las contramedidas
Cuando un equipo no llega al nivel objetivo —y en una planta con controladores de 2009 eso pasa siempre— la norma no obliga a reemplazarlo: obliga a compensar. Un PLC que no soporta autenticación puede vivir detrás de un conducto que sí la exige, con control de acceso físico y monitoreo del tráfico. Lo que no se admite es dejar el hueco sin documentar.
Cómo se evalúa el riesgo: el flujo de la parte 3-2
La partición en zonas no se improvisa en una pizarra. La parte 3-2 define un procedimiento de siete pasos —los requisitos ZCR— que va del inventario a la aprobación formal, con una bifurcación en el medio que decide cuánto esfuerzo merece cada zona.
Dos detalles del flujo suelen pasarse por alto. El primero es que la evaluación inicial trabaja con la peor consecuencia creíble suponiendo que no hay contramedidas: se pregunta qué pasa si el atacante ya está dentro, no qué tan probable es que entre. Es un ejercicio deliberadamente pesimista, y por eso es rápido. El segundo es el paso final: la aprobación del propietario del activo no es un trámite. Fija por escrito qué riesgo la organización aceptó conservar, y ese documento es el que aparecerá el día que algo salga mal.
Caso aplicado: una planta concentradora
La planta de agua es didáctica por lo lineal. Una concentradora minera —chancado, molienda, flotación, espesado— agrega los tres elementos que complican de verdad un diseño en el Perú: una operación remota conectada por microondas, un centro de operaciones integrado en Lima a mil kilómetros de la mina, y proveedores de equipos que exigen acceso remoto permanente como condición de garantía.
Tres decisiones de este diseño merecen comentario. La primera: el anillo de fibra es una sola zona de red aunque atraviese físicamente toda la planta, porque un switch comprometido en chancado alcanza a todos los demás; la segmentación real ocurre en la configuración de las VLAN y en las listas de control, no en la geografía. La segunda: la relavera recibe un nivel objetivo alto —más que el chancado— por su consecuencia ambiental, no por su complejidad técnica. La tercera: el acceso del proveedor no se resuelve con una VPN, sino con un conducto que termina en un servidor de salto dentro de la DMZ, con sesión abierta bajo ticket, grabada, y cerrada al terminar.
Con las zonas definidas, la especificación de requisitos se resume en una matriz que asigna un nivel objetivo por zona y por requisito fundamental. Este es el entregable que un integrador debe recibir en un pliego, y el que casi nunca se escribe.
Una vez fijada la meta, el diagnóstico consiste en superponerle lo que la planta ofrece hoy. El resultado, dibujado sobre los siete ejes, es el mapa de brechas que ordena la inversión: no todas las zonas ni todos los requisitos cuestan lo mismo de cerrar.
El patrón de este gráfico se repite en casi toda planta que he visto diagnosticada: la infraestructura de red suele estar mejor de lo que se cree, y lo que falta es gestión de identidades, control de privilegios y capacidad de detectar que algo pasó. Son, justamente, las partidas que no se pueden comprar como un equipo.
El programa de seguridad: lo que sostiene el diseño
Un diseño impecable se degrada en meses si nadie lo administra. De eso trata la parte 2-1, cuya segunda edición de 2024 reorganizó los requisitos en elementos del programa de seguridad y les añadió un modelo de madurez. La madurez importa porque distingue entre tener un procedimiento y ejecutarlo: ML 1 es hacer las cosas de forma informal y ad hoc; ML 2, tenerlas documentadas y repetibles; ML 3, ejecutarlas de forma controlada y medida; ML 4, mejorarlas con datos de desempeño. Esa misma escala aparece en la parte 4-1 para evaluar el ciclo de desarrollo de un fabricante.
En la práctica, un programa que funciona se construye en este orden, y saltarse el primer paso es la causa más frecuente de fracaso:
62443-2-1
62443-3-2
62443-3-3
FR 6
62443-2-3
madurez
Comprar 62443: qué exigir en un contrato
Para el área legal y de compras, la serie tiene una virtud enorme: convierte la ciberseguridad en cláusulas verificables. Estas son las que marcan diferencia en un pliego peruano.
Dónde aterriza esto en el Perú
El Perú no tiene una norma que obligue a aplicar ISA/IEC 62443 en la industria, y conviene decirlo sin rodeos. Lo que sí existe es un marco de protección de infraestructura crítica que empuja en la misma dirección. El Decreto Supremo N.° 106-2017-PCM aprobó el Reglamento para la Identificación, Evaluación y Gestión de Riesgos de los Activos Críticos Nacionales, elaborado por la Dirección Nacional de Inteligencia: si una planta de generación, una red de agua o una operación minera es calificada como activo crítico nacional, su operador queda sujeto a obligaciones de identificación y gestión de riesgos que difícilmente puede sostener sin un marco técnico como este.
A ese régimen se suma la Ley N.° 30999, Ley de Ciberdefensa, reglamentada por el Decreto Supremo N.° 017-2024-PCM, que ordena la respuesta del Estado ante ataques en el ciberespacio que afecten la seguridad nacional y los activos críticos. Ninguna de estas normas dice “62443”; todas presuponen que el operador sabe qué proteger, con qué prioridad y contra qué adversario, que es exactamente lo que la serie permite responder con evidencia.
Errores que se repiten
Conclusión
ISA/IEC 62443 no es una norma que se compre ni una casilla que se marque: es una manera de razonar. Obliga a decir en voz alta qué proceso no puede detenerse, contra qué adversario se quiere resistir, quién responde por cada pieza y qué riesgo la organización decidió conservar. Todo lo demás —la segmentación, los conductos, los niveles— son consecuencias de esas cuatro respuestas.
Para una planta peruana promedio, con controladores de hace quince años y un proveedor que entra por VPN desde el extranjero, el camino no empieza comprando tecnología. Empieza con un inventario honesto y un dibujo de zonas hecho entre el ingeniero de procesos, el de mantenimiento y quien administra la red. Ese dibujo, imperfecto y todo, ya es más protección que un firewall sin reglas.
¿Necesitas evaluar la ciberseguridad de tu planta o especificarla en un contrato?
Acompaño a empresas industriales y entidades públicas en el diagnóstico de sus sistemas de control bajo ISA/IEC 62443: inventario de activos OT, partición en zonas y conductos, definición de niveles objetivo y redacción de los requisitos técnicos y contractuales para licitaciones. Conversemos sobre tu caso.
Fuentes
- ISA. ISA/IEC 62443 Series of Standards. Disponible en isa.org.
- IEC. IEC 62443-2-1:2024 — Security program requirements for IACS asset owners. Ficha en webstore.iec.ch.
- IEC. IEC 62443-3-2:2020 — Security risk assessment for system design. Ficha en webstore.iec.ch.
- IEC. IEC 62443-3-3:2013 — System security requirements and security levels. Ficha en webstore.iec.ch.
- IEC. IEC 62443-4-2:2019 — Technical security requirements for IACS components. Ficha en webstore.iec.ch.
- CISA. Advisory ICSA-18-107-02 (TRITON/TRISIS) y material de referencia sobre amenazas a sistemas de control industrial. Disponible en cisa.gov.
- Presidencia del Consejo de Ministros. Decreto Supremo N.° 106-2017-PCM, Reglamento para la Identificación, Evaluación y Gestión de Riesgos de los Activos Críticos Nacionales. Disponible en gob.pe.
- Presidencia del Consejo de Ministros. Decreto Supremo N.° 017-2024-PCM, Reglamento de la Ley N.° 30999, Ley de Ciberdefensa, publicado el 14 de febrero de 2024. Disponible en busquedas.elperuano.pe.
Los diagramas de plantas de este artículo son ejemplos didácticos elaborados por el autor y no reproducen la arquitectura de ninguna instalación real. El contenido tiene fines informativos y no sustituye una evaluación de riesgo realizada sobre la planta concreta.
