Hay un patrón que se repite constantemente en los entornos de fabricación que aplican programas de ciberseguridad para la tecnología operativa (OT). La auditoría se cierra sin incidencias. Los controles están documentados. Se cumplen todos los requisitos del marco normativo. Y, sin embargo, algo no va bien en la planta: los operadores están buscando soluciones alternativas, los tiempos de respuesta se han ralentizado o las ventanas de mantenimiento se han vuelto más complejas de lo que deberían.
El sistema superó la prueba. Pero el funcionamiento no mejoró.
No se trata de un fallo de ejecución. Se trata de una incompatibilidad estructural, que se encuentra en el núcleo del cumplimiento de la ciberseguridad de las tecnologías operativas (OT) y que la mayoría de los marcos de seguridad nunca fueron diseñados para abordar.
Normas como la IEC 62443 y requisitos normativos como la NIS2 se elaboraron para aportar coherencia donde antes no la había. En ellas se define qué controles deben existir, qué documentación hay que mantener y qué estructuras de gobernanza deben estar en vigor. Para las organizaciones que tratan de demostrar su responsabilidad —ante auditores, organismos reguladores y consejos de administración—, estas normas cumplen una función clara.
Pero los marcos responden a una pregunta concreta: ¿se han definido los elementos adecuados?
No responden a la pregunta: ¿qué pasará cuando esto se implemente en una línea de producción que lleva once años utilizando el mismo firmware de PLC?
Los entornos de tecnología operativa (OT) no son sistemas homogéneos que esperan ser protegidos. Se trata de conjuntos de equipos estructurados en capas, heterogéneos y, a menudo, con documentación insuficiente, cuyas interdependencias no se identificaron en el momento de su instalación y no se han revisado desde entonces. Predominan los sistemas heredados. El tiempo de inactividad se mide en términos de coste real de producción. Y las relaciones entre los sistemas —qué se comunica con qué, en qué condiciones, con qué tolerancia al cambio— a menudo solo las comprenden las personas que los han estado operando durante años.
Los marcos de cumplimiento dan por sentado un grado de estandarización que la mayoría de los entornos de fabricación ya existentes simplemente no reflejan. Esa suposición es precisamente donde surge la brecha.
Un marco de trabajo orientado a la producción para fabricantes que necesitan garantizar la seguridad de sus operaciones sin afectarlas.
En la práctica, se le conoce con un nombre, aunque rara vez aparezca en los informes de seguridad: «conforme, pero inestable».
Se han implantado todos los controles necesarios. Se cumplen los criterios de auditoría. Sobre el papel, el nivel de seguridad parece sólido. Y, sin embargo, la planta es más difícil de gestionar que antes. No de forma drástica —ningún control por sí solo ha provocado un colapso—, pero, desde el punto de vista operativo, algo ha cambiado.
Hay tres situaciones que ilustran este patrón de forma sistemática.
La segmentación de las redes de tecnología operativa (OT) es un control fundamental en cualquier marco de seguridad OT que se precie, y con razón. El objetivo es la contención: limitar el alcance de los efectos si se produce un incidente. Sin embargo, en un entorno de fabricación en el que determinados sistemas se comunican a través de lo que el marco define ahora como zonas separadas, una implementación rígida interrumpe los flujos existentes. Las modificaciones manuales se convierten en algo habitual. Los operadores se adaptan, pero cada solución alternativa añade fricciones y socava la lógica de gobernanza que se suponía que debía garantizar la segmentación.
La aplicación de parches a los sistemas de tecnología operativa (OT) es cada vez más obligatoria en el marco de normas como la IEC 62443-2-1 y los requisitos derivados de la NIS2. Se elabora, documenta y sigue un calendario. Sin embargo, los sistemas de producción del sector manufacturero no cuentan con ventanas de mantenimiento que coincidan con los ciclos de lanzamiento de los proveedores. La implementación de parches en entornos en producción en un momento inadecuado provoca inestabilidad, y esta inestabilidad suele tener repercusiones operativas más duraderas que la propia vulnerabilidad que se pretendía subsanar.
Reducir los privilegios es una práctica de seguridad adecuada. El acceso basado en roles, las sesiones de duración limitada, la arquitectura de privilegios mínimos... Todas estas medidas son justificables y auditables. Pero cuando las políticas de acceso se aplican sin tener en cuenta cómo interactúan realmente los operadores y los proveedores con los sistemas en condiciones reales de producción, el resultado es previsible: surgen cuentas compartidas, se eluden los controles de acceso y el modelo de gobernanza que parecía sólido sobre el papel ya se ha desviado de lo que ocurre en la práctica.
En todos los casos, los controles son correctos en teoría. El problema radica en la ejecución, concretamente en la falta de validación operativa antes de la puesta en marcha.
Lo que hace que esto resulte especialmente difícil es que, cuando se produce un cambio, los entornos de OT no se comportan como los entornos de TI. En TI, una mejora de seguridad suele ser acumulativa: se aplica un control, el sistema se adapta y la postura de seguridad mejora. Aunque pueden producirse consecuencias no deseadas, estas suelen ser controladas y reversibles.
En el ámbito de la ingeniería de operaciones (OT), los pequeños cambios tienen un efecto dominó. Un flujo de comunicación que ha funcionado de forma fiable durante años se basa en supuestos temporales que no figuran por escrito en ningún sitio. Una regla de segmentación que parece clara en un diagrama de red afecta a un protocolo de comunicación SCADA heredado que solo un ingeniero del proveedor entendía. Una actualización de firmware que se validó en un entorno de laboratorio se comporta de forma diferente en una planta que lleva seis días ejecutando el mismo lote de producción sin reiniciar el sistema.
Las interdependencias son reales. A menudo no están documentadas. Y los marcos de cumplimiento no las reflejan, porque no pueden hacerlo. Ninguna norma puede prever la lógica operativa específica de los sistemas de una planta concreta.
Por eso la estabilidad operativa es el principal indicador del éxito en materia de seguridad en entornos de tecnología operativa (OT), y no los resultados de las auditorías. Un programa de seguridad que logre el cumplimiento normativo a costa de mermar la estabilidad no ha mejorado la situación de riesgo de la organización, sino que simplemente ha desplazado el riesgo.
La consecuencia a largo plazo de los programas de seguridad de la tecnología operativa (OT) orientados al cumplimiento normativo que ignoran el impacto operativo es un tipo específico de desviación organizativa.
Los equipos de seguridad se encargan de mantener la estructura de cumplimiento. Los equipos de operaciones se adaptan a las dificultades que esta genera —a nivel local, de manera informal y sin documentación—. Los controles se modifican a nivel de planta. Las soluciones provisionales se integran en el funcionamiento diario. La gobernanza y la realidad operativa van divergiendo poco a poco.
Al cabo de un tiempo, lo que figura en el marco de cumplimiento y lo que realmente ocurre sobre el terreno son dos cosas distintas. La auditoría sigue superándose, porque los controles documentados siguen existiendo. Pero la situación real de seguridad de la organización, la que importa cuando algo sale mal, la gestionan de manera informal personas cuya principal preocupación es mantener la producción en marcha.
Esto no es una falta de disciplina. Es una consecuencia estructural de aplicar la lógica de los marcos de trabajo a entornos para los que no fueron diseñados.
El cambio necesario no consiste en pasar del cumplimiento al incumplimiento. La armonización normativa en el marco de la Directiva NIS 2 y la norma IEC 62443 es una obligación legítima para las empresas manufactureras que operan en sectores críticos, y la responsabilidad que ello genera a nivel directivo es adecuada. La cuestión no es si hay que cumplir, sino qué es lo que el mero cumplimiento no basta para resolver.
Más allá de preguntarse «¿cumplimos con la normativa?», los responsables de fabricación encargados de la seguridad de la tecnología operativa deben plantearse:
Estas preguntas no están reñidas con el cumplimiento normativo. Son precisamente las que garantizan la sostenibilidad de dicho cumplimiento, las que evitan que la brecha entre el modelo de seguridad y el entorno de producción se amplíe con el tiempo.
Los programas de ciberseguridad para sistemas de tecnología operativa (OT) que tienen en cuenta la secuencia operativa, las limitaciones de producción y el comportamiento real del sistema no solo logran el cumplimiento normativo, sino que lo mantienen, ya que los controles que implementan son aquellos que la planta puede realmente mantener.
