Vulnerabilidades en los Sistemas de Medición de Tanques Automáticos: Un Riesgo Silencioso

Los medidores automáticos de tanque, o automatic tank gauges (ATG), llevan años funcionando en segundo plano en gasolineras, terminales y otras instalaciones de almacenamiento de combustible. Precisamente por eso son un buen ejemplo de riesgo infraatendido: si nadie los mira, nadie los parchea, nadie revisa quién accede y nadie comprueba si están integrados en la arquitectura de seguridad de la empresa o abandonados en una red industrial aparte, confiando en la suerte. Y la suerte, en entornos OT, suele ser una estrategia regulatoria bastante mediocre.

La cuestión no es si un ATG se parece más a un activo de TI clásico o a un equipo industrial especializado. La cuestión es que, cuando forma parte de procesos operativos que afectan al suministro, al control de existencias o a la seguridad física de una instalación, entra de lleno en el perímetro que hoy vigilan normas como NIS2, el GDPR cuando haya datos personales de por medio, y marcos de control como ISO 27001 o NIST CSF 2.0. No porque el regulador haya escrito “ATG” en una línea concreta, sino porque la lógica de estas normas va precisamente de eso: identificar activos críticos, evaluar riesgos reales y aplicar controles proporcionales.

Ahí está el problema práctico. Muchas organizaciones siguen tratando estos sistemas como un apéndice técnico del proveedor, no como un activo gobernado por seguridad, compliance y continuidad operativa. Ese enfoque ya era flojo hace diez años. Hoy empieza a ser difícil de defender ante un auditor, ante el consejo y, si algo sale mal, ante el regulador.

El error de fondo: pensar que “industrial” significa “fuera del radar”

Los ATG no suelen entrar en la conversación pública sobre ciberseguridad con la misma facilidad que los entornos cloud, los endpoints o los modelos de IA. Sin embargo, su función operativa es clara: monitorizan niveles de combustible, facilitan datos para inventario y ayudan a mantener control sobre procesos físicos que no admiten demasiadas improvisaciones. Cuando un sistema así se conecta, se integra o intercambia información con otros entornos corporativos, deja de ser una caja negra puramente mecánica. Pasa a ser un activo digital con dependencias, accesos, configuraciones y riesgo operacional.

Eso encaja de forma bastante directa con NIS2. La Directiva (UE) 2022/2555 no habla el lenguaje antiguo de “operadores de servicios esenciales”, propio de NIS1. Habla de entidades esenciales y entidades importantes, y esa diferencia no es cosmética. Define quién cae dentro del alcance y qué nivel de supervisión y sanción puede esperar. Si una organización del sector energético o de combustibles entra en ese perímetro, no necesita que el texto mencione “ATG” para tener que evaluar si esos sistemas forman parte de los activos y procesos que sostienen sus servicios.

El anclaje jurídico clave está en el artículo 21 de NIS2, que obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que amenazan la seguridad de las redes y sistemas de información utilizados para sus operaciones o para la prestación de sus servicios. El artículo no prescribe un catálogo cerrado de controles por dispositivo concreto; exige gestión de riesgos. Y ahí se acabó la coartada de “esto lo lleva mantenimiento”.

Lo que sí dice NIS2, y lo que algunos textos le hacen decir de más

Conviene limpiar una confusión frecuente. NIS2 no impone, línea por línea, que todos los operadores implementen exactamente segmentación de red, cifrado en tránsito y en reposo o autenticación multifactor en cualquier entorno ATG. Lo que sí hace el artículo 21.2 es enumerar ámbitos mínimos que deben cubrir esas medidas de gestión de riesgos. Entre ellos están la gestión de incidentes, la continuidad de negocio —incluida la gestión de copias de seguridad y la recuperación en caso de desastre—, la seguridad de la cadena de suministro, la seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información, las políticas y procedimientos para evaluar la eficacia de las medidas de ciberseguridad, y las prácticas básicas de ciberhigiene y formación.

Traducido al terreno ATG, el regulador no te dicta el diagrama de red. Te obliga a justificar que has evaluado el riesgo del activo y que has implantado controles razonables para ese riesgo. Puede que eso te lleve a segmentar. Puede que te lleve a endurecer accesos remotos del proveedor. Puede que te obligue a revisar cómo se registran los eventos o cómo se restauran configuraciones tras un incidente. Lo que no puedes hacer es esconderte detrás de un checklist genérico y fingir que la parte OT no existe.

Otro punto que suele citarse mal es el artículo 23 de NIS2, que regula las obligaciones de notificación de incidentes significativos. Si un incidente que afecte a sistemas industriales o de monitorización de combustible alcanza el umbral aplicable para la entidad, el debate deja de ser técnico y pasa a ser ejecutivo. Ya no se trata solo de qué se ha caído, sino de si la organización ha notificado a tiempo, si puede describir el impacto y si dispone de trazabilidad suficiente para explicar qué ha ocurrido. Ese detalle importa más que cualquier eslogan sobre “resiliencia”.

GDPR: no todo ATG implica datos personales, pero no conviene presumir que nunca los hay

El cruce con privacidad exige bastante más precisión de la que suelen ofrecer algunos artículos superficiales. Un sistema ATG, por sí mismo, no tiene por qué tratar datos personales. Si solo mide niveles de combustible, alarmas técnicas o parámetros de funcionamiento, hablar de “datos sensibles” en términos del GDPR es, como mínimo, aventurado. Y jurídicamente, aventurado suele ser una forma elegante de decir incorrecto.

Dicho eso, tampoco conviene irse al extremo contrario. El artículo 4.1 del GDPR define dato personal de forma amplia: cualquier información sobre una persona física identificada o identificable. Si un entorno ATG se integra con sistemas de acceso, registros de operador, credenciales nominales, trazas vinculadas a empleados o proveedores, o plataformas donde la actividad de usuarios concretos queda asociada a eventos operativos, entonces sí puede haber tratamiento de datos personales en los sistemas de soporte, en los logs o en las herramientas de administración conectadas al ATG.

En ese caso, las obligaciones relevantes no nacen de una mención específica a los ATG, sino de los principios generales del Reglamento. El artículo 5.1.f exige integridad y confidencialidad; el artículo 24 obliga al responsable a aplicar medidas apropiadas para garantizar y poder demostrar que el tratamiento es conforme; y el artículo 32 exige medidas técnicas y organizativas adecuadas al riesgo para garantizar un nivel de seguridad apropiado. Si un incidente en un sistema conectado al entorno ATG afecta a datos personales, entonces entra también el artículo 33, con la notificación de violaciones de seguridad a la autoridad de control, y eventualmente el artículo 34 si hay alto riesgo para los derechos y libertades de las personas.

La implicación práctica es sencilla: antes de invocar el GDPR como comodín, hay que mapear si en ese entorno existen datos personales, dónde están y para qué se usan. Si no haces ese ejercicio, puedes sobrerregular un equipo que no toca datos personales o, peor, dejar sin evaluar registros y sistemas auxiliares que sí los contienen.

El impacto operativo es real aunque no haga falta adornarlo

No hace falta inflar escenarios para entender por qué estos sistemas importan. Un ATG forma parte de la visibilidad operativa sobre existencias y estado de depósitos. Si ese sistema falla, se degrada o deja de ser fiable, la organización pierde capacidad de monitorización y verificación en un proceso que afecta a operaciones físicas. Eso ya es suficiente para activar preocupaciones de continuidad, seguridad y control interno.

También hay un ángulo de gobierno corporativo que suele subestimarse. Cuando una empresa depende de datos automatizados para conciliar inventarios, gestionar reposiciones o detectar anomalías operativas, la fiabilidad de esos datos deja de ser una cuestión técnica menor. Pasa a tocar controles internos, gestión del riesgo operacional y, en algunos casos, la capacidad de la dirección para demostrar supervisión efectiva sobre procesos críticos. No hace falta adjudicar automáticamente a un ATG consecuencias ambientales o macroeconómicas concretas para sostener ese argumento. Basta con reconocer que un fallo en sistemas de monitorización industrial puede alterar la toma de decisiones y complicar la continuidad del servicio.

La cadena de suministro entra por la puerta de atrás, que suele ser la favorita del riesgo

En muchos despliegues, los ATG no se gestionan de forma aislada por el equipo interno. Intervienen fabricantes, integradores, distribuidores de software, empresas de mantenimiento y proveedores de acceso remoto. Y ahí aparece uno de los apartados más incómodos —y más relevantes— de NIS2: la seguridad de la cadena de suministro, expresamente recogida en el artículo 21.2.d.

La obligación no consiste en desconfiar teatralmente de todos los proveedores mientras se firma el contrato sin leer el anexo técnico. Consiste en evaluar las vulnerabilidades específicas de cada relación de suministro y la calidad general de las prácticas de ciberseguridad de los proveedores, incluidos sus procedimientos de desarrollo seguro cuando proceda. Si un tercero mantiene, actualiza o administra un sistema ATG, la organización no puede tratar ese acceso como una cortesía operativa. Tiene que gobernarlo como una dependencia crítica.

Aquí la pregunta útil no es “tenemos proveedor?”. Claro que lo tienes. La pregunta útil es otra: ¿sabes exactamente qué acceso conserva, cómo se autentica, quién aprueba las intervenciones, qué se registra y cómo se revoca? Si la respuesta está dispersa entre operaciones, compras, mantenimiento y TI, ya tienes un problema de control. Todavía no un incidente. Pero sí el tipo de desorden que convierte un incidente en algo mucho más caro.

Cybersecurity Act: menos obligación directa de la que a veces se vende, pero no irrelevante

Otro terreno donde conviene bajar el volumen de la retórica es el Cybersecurity Act, es decir, el Reglamento (UE) 2019/881. No establece, en términos generales, una obligación universal para que las organizaciones certifiquen sus productos y servicios bajo esquemas europeos, ni puede afirmarse sin más que un artículo concreto imponga certificar sistemas ATG. Lo que sí hace el Reglamento es crear un marco europeo de certificación de ciberseguridad para productos TIC, servicios TIC y procesos TIC.

La utilidad práctica de ese marco, para quien opera entornos industriales o de monitorización, no está en fingir que toda certificación es obligatoria desde mañana. Está en otra parte: ofrece una referencia para evaluar confianza, requisitos de seguridad y nivel de aseguramiento cuando existan esquemas aplicables. Si compras tecnología conectada o software de soporte para un entorno ATG, el debate sobre certificación puede volverse relevante como criterio de adquisición o diligencia debida, aunque no exista una obligación automática y directa de certificar ese sistema concreto.

Eso, por cierto, encaja con NIS2 otra vez. El artículo 21.2 incluye la seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información. No convierte cualquier compra en una tesis doctoral, pero sí obliga a dejar de comprar tecnología operativa como si la seguridad fuera una nota al pie.

ISO 27001 y NIST CSF 2.0: útiles si se usan para gobernar, no para decorar presentaciones

Cuando una organización intenta ordenar el riesgo de activos híbridos entre TI y OT, dos marcos siguen siendo especialmente útiles: ISO/IEC 27001 y NIST CSF 2.0. No porque resuelvan solos el problema, sino porque fuerzan disciplina donde normalmente hay intuición, costumbre y bastante fe.

Con ISO 27001, lo prudente es no jugar a la ruleta de numeraciones mal citadas. La versión ISO/IEC 27001:2022 cambió la estructura del Anexo A respecto de ediciones anteriores, así que las referencias heredadas a controles concretos a menudo acaban mal. Lo que sí puede afirmarse con seguridad es que el estándar exige un proceso de evaluación y tratamiento de riesgos y controles organizativos, físicos y tecnológicos que la entidad debe seleccionar en función de ese análisis. Para un entorno ATG, eso se traduce en preguntas de base: inventario del activo, responsabilidades asignadas, control de acceso, gestión de cambios, registro de eventos, dependencia de terceros, recuperación y revisión periódica de riesgos. Nada glamuroso. Todo esencial.

NIST CSF 2.0, publicado en 2024, tampoco menciona ATG de forma específica. No hace falta. Su valor está en que amplía el componente de gobierno y conecta gestión del riesgo con objetivos de negocio. La función Govern y categorías como GV.RM se centran en cómo la organización establece, comunica y supervisa su estrategia de gestión de riesgos de ciberseguridad. Eso no equivale a una instrucción textual de crear métricas específicas para ATG, pero sí respalda algo bastante menos vistoso y más útil: que la empresa defina cómo evalúa la eficacia de sus controles y cómo integra esos activos en su modelo de riesgo. Si no puedes medir si un control funciona, en realidad no tienes un control; tienes una esperanza con presupuesto.

Qué debería estar haciendo ahora una organización con ATG en su entorno

Si tu empresa opera sistemas ATG y quiere dejar de tratarlos como un artefacto heredado, el primer paso no es comprar tecnología nueva. Es saber qué tiene, dónde está y de qué depende. Parece básico porque lo es. Y aun así, falla con una frecuencia deprimente.

• Identifica el activo y su función operativa. No basta con saber que “hay un ATG”. Hay que documentar qué procesos soporta, qué datos genera, con qué sistemas se integra y qué impacto tendría su indisponibilidad o degradación.
• Determina si entra en el alcance regulatorio de la entidad. Si la organización es una entidad esencial o importante bajo NIS2, el análisis del artículo 21 debe incluir estos sistemas cuando sean relevantes para las operaciones o los servicios. Si existen datos personales en registros, accesos o plataformas conectadas, entra también el análisis bajo GDPR, especialmente artículos 5, 24, 32 y, en caso de incidente, 33.
• Revisa accesos de terceros y soporte remoto. Contratos, cuentas compartidas, credenciales persistentes, ausencia de trazabilidad y mantenimiento sin supervisión son una combinación conocida y bastante poco entrañable.
• Integra el activo en continuidad e incident response. Si mañana falla el sistema, ¿quién decide, quién comunica, qué procedimiento alternativo existe y qué evidencias se conservan? Si esa respuesta depende de llamar “al técnico de siempre”, todavía no hay gobierno del riesgo; hay costumbre.
• Valida controles con evidencia, no con declaraciones. En línea con NIS2 art. 21.2 y con los marcos de gestión de riesgos, importa poder demostrar que los controles funcionan: revisiones de acceso, pruebas de restauración, registros de intervención, evaluación de proveedores y seguimiento de incidencias.

La conclusión incómoda: el regulador no necesita escribir “ATG” para que te afecte

Ese es el punto que algunas empresas siguen intentando esquivar. No existe, al menos en las normas citadas aquí, una obligación redactada como “los sistemas ATG deberán…”. Pero esa ausencia no libera a la organización. Al contrario: le traslada la carga de hacer el trabajo serio de clasificación, análisis de riesgo, selección de controles y supervisión de terceros.

NIS2, en sus artículos 21 y 23, ya da un marco bastante claro para activos que sostienen operaciones críticas y para la respuesta cuando algo falla. El GDPR, a través de sus artículos 5, 24, 32 y 33, entra en juego cuando esos entornos tratan o comprometen datos personales. ISO 27001 y NIST CSF 2.0 aportan estructura para convertir intuiciones dispersas en un programa de control defendible.

La lectura adulta de todo esto es sencilla: si un ATG forma parte de tu operación, ya no puedes permitirte gestionarlo como una reliquia técnica fuera del radar del compliance. Porque el radar regulatorio, a estas alturas, no funciona por nombre del dispositivo. Funciona por riesgo, dependencia y capacidad de demostrar control. Y ahí es donde muchas organizaciones descubren, un poco tarde, que el problema nunca fue el tanque. Era la gobernanza.