Los sensores industriales de IoT hacen que un mismo número se utilice para varios fines. En el lugar de trabajo, se observan la concentración de gases y el estado de los equipos para detener una tarea o comprobar la ventilación. En la gestión empresarial y del carbono, los mismos registros se emplean como evidencia de tendencias a largo plazo, eficiencia energética y actividades de reducción. Un mismo dispositivo y una misma red se convierten así en una entrada común para Safety y Carbon.

Esta estructura es eficiente, pero mezclar responsabilidades resulta peligroso. La detección para seguridad y la monitorización ambiental o de carbono pueden exigir tiempos de respuesta, intervalos de medición, criterios de instalación, calibraciones, certificaciones y comportamientos ante fallos diferentes. No debe suponerse que disponer de un sensor para análisis de carbono satisface los requisitos legales o de seguridad del lugar. A la inversa, tampoco pueden calcularse resultados de carbono a largo plazo únicamente con valores instantáneos de alarma de seguridad. La ciberseguridad debe conectar ambos fines sin perder sus límites funcionales.

Primer equívoco: la seguridad es un problema de fuga de datos del equipo de IT

Las consecuencias de un incidente de seguridad en sensores industriales no se limitan a una filtración de datos personales. Si un atacante eleva el umbral de alarma, una concentración peligrosa puede parecer normal; si interfiere con la señal de control de la ventilación, puede cambiar el entorno físico. Por el contrario, las falsas alarmas repetidas provocan evacuaciones y paradas innecesarias y pueden insensibilizar a los trabajadores frente a una alarma real. Por eso NIST SP 800-82 considera conjuntamente el rendimiento, la fiabilidad y la seguridad en la protección de OT.

En el ámbito de Carbon, quedan comprometidos los valores medidos, el tiempo, el estado del dispositivo y los coeficientes de corrección. La reducción puede sobreestimarse o subestimarse, pueden quedar vacíos de datos sin explicación y quizá sea necesario revisar informes ya emitidos. Es decir, una misma vulnerabilidad se manifiesta en un lado como riesgo físico inmediato y, en el otro, como riesgo para afirmaciones acumulado durante un periodo largo.

También importan las diferencias entre ambos ámbitos. Safety puede ser muy sensible a retrasos de segundos y falsos negativos, mientras que Carbon es sensible a la integridad, el linaje y la reproducibilidad de todo el periodo. Evaluar ambos fines con un único KPI de seguridad hace que se pierdan riesgos esenciales. Los controles comunes deben operarse conjuntamente, pero con indicadores de rendimiento y criterios de aceptación separados para cada finalidad.

Cómo el robo de una cuenta produce dos consecuencias distintas

Supongamos que una empresa de mantenimiento remoto utiliza la misma cuenta para las pasarelas de varias granjas. Si la cuenta se ve comprometida, el atacante puede modificar la configuración de los sensores y borrar registros. En la ruta de Safety, cambiar el umbral de alarma o la interconexión con relés puede retrasar la respuesta del trabajador. En la ruta de Carbon, las modificaciones del intervalo de muestreo y del valor de corrección cambian la tendencia anterior y posterior a la intervención.

La recuperación también es diferente. Para la seguridad del lugar, primero hay que aislar el dispositivo, comprobar la atmósfera con un equipo independiente y asegurar un estado operativo seguro. En cuanto a los datos de carbono, deben identificarse el periodo, los dispositivos, los resultados de cálculo y los informes externos afectados. Restablecer la seguridad no recupera automáticamente la confianza en los datos históricos. A la inversa, restaurar los registros históricos tampoco demuestra que el estado actual de los gases en el lugar sea seguro.

Por tanto, la tabla de respuesta a incidentes debe plantear simultáneamente dos preguntas: «¿Están seguras ahora las personas y las instalaciones?» y «¿Qué periodo de evidencia de carbono se ha visto afectado?». Deben designarse previamente los equipos responsables, los criterios de aislamiento, las mediciones alternativas, la retención de datos, las comunicaciones externas y quien aprobará la reanudación.

Ocho controles comunes que deben protegerse

El primero es la identificación de activos. Se hace un inventario de sensores, pasarelas, firmware, módulos de comunicación, servicios en la nube y portátiles de mantenimiento, indicando para cada uno su uso en Safety, Carbon o ambos. Los objetivos básicos de rendimiento de CISA también recomiendan actualizar periódicamente el inventario de activos de IT y OT. Un dispositivo ausente del inventario no puede gestionarse en cuanto a parches, calibración, certificados o fin de soporte.

El segundo son las cuentas únicas y el privilegio mínimo. Se cambian las contraseñas predeterminadas del fabricante y se evitan cuentas compartidas entre granjas, empresas y dispositivos. Se separan los permisos para modificar umbrales de seguridad, cambiar coeficientes de corrección de carbono, consultar datos y desplegar firmware. A los cambios de alto riesgo se les aplican varias aprobaciones y autenticación reforzada, y el uso de una cuenta de emergencia genera de inmediato una alerta registrada.

El tercero es la segmentación de la red. Los ordenadores de oficina, la red Wi-Fi de visitantes, la red de sensores, una red de control con funciones de seguridad cuando exista, y la conexión a la nube no deben situarse en la misma red plana. Solo se permiten las rutas y puertos de comunicación necesarios, y el acceso remoto se controla mediante un punto intermedio, una franja horaria aprobada y el registro de la sesión. La segmentación reduce hasta dónde puede desplazarse una intrusión hacia otras granjas y controladores.

El cuarto son las actualizaciones seguras. Se verifican el origen y la integridad de los archivos de actualización, que solo pueden instalar entidades autorizadas. Antes del despliegue se prueban la compatibilidad y el uso de recursos, y debe ser posible volver a una versión segura si falla. En los dispositivos que afectan a Safety, en lugar de imponer parches sin interrupción durante el funcionamiento, el cambio se realiza con una parada planificada y monitorización alternativa. En la fase de compra también se comprueban la fecha de fin de soporte y el canal de avisos de vulnerabilidad.

El quinto es la protección de datos y registros. Se protegen los datos en tránsito y almacenados, y se transmiten a un repositorio central o separado los historiales de configuración, calibración, permisos, actualizaciones y reinicios. Si un dispositivo de campo se ve comprometido, sus registros locales también pueden borrarse. Las horas de los registros se sincronizan con una referencia común, y el propio error temporal se registra como estado.

El sexto es el conocimiento del estado de seguridad. El sistema debe mostrar no solo si el dispositivo está «en línea», sino también si utiliza firmware aprobado, si su configuración coincide con la referencia, si el certificado está vigente y si el envío de registros funciona. NIST IR 8259A incluye entre sus criterios esenciales la capacidad de un dispositivo IoT para informar de su propio estado de ciberseguridad y permitir acceso únicamente a entidades autorizadas.

El séptimo son las copias de seguridad y las pruebas de recuperación. Se hacen copias periódicas de la configuración de las pasarelas, el inventario de dispositivos, la información operativa de los certificados, las reglas y modelos y los esquemas de datos, y se prueba su recuperación. NIST SP 1339 destaca que las copias de OT deben vincularse a la gestión de cambios y revisarse en ejercicios de recuperación. Si una copia permanece siempre conectada a la red de producción con las mismas credenciales, aumenta el riesgo de que también resulte dañada, por lo que deben considerarse el aislamiento y el control de acceso.

El octavo es la responsabilidad de la cadena de suministro. El contrato debe especificar quién, entre el fabricante del sensor, el instalador, el operador de telecomunicaciones, la plataforma y el organismo de verificación, se encarga de avisar de vulnerabilidades, aplicar parches, retirar cuentas, facilitar registros y responder a incidentes. IEC 62443-2-4 trata los procesos de seguridad de integración y mantenimiento de los proveedores de servicios para sistemas de automatización y control industrial. En lugar de exigir únicamente el nombre de una norma, deben comprobarse el alcance real del servicio y sus evidencias.

La separación por finalidad también debe reflejarse en la arquitectura técnica

La alarma de seguridad debe mantener localmente, en la medida de lo posible, las funciones necesarias en el lugar y diseñarse para que un fallo de la nube no detenga la propia alarma. Los cambios en la capa de seguridad se limitan mediante procedimientos y permisos validados. El análisis de carbono lee una copia de los datos brutos para agregarlos a largo plazo, pero no tiene permiso para modificar la configuración de seguridad. Aunque ambos resultados se muestren en una pantalla, no es necesario unificar también los permisos del backend y las rutas de fallo.

La finalidad también se indica en el modelo de datos. Separar measurement_purpose, safety_status, carbon_quality_status y calibration_context permite explicar para qué decisión resulta adecuado un mismo valor. Así se reducen errores como promediar sin más, en el análisis de carbono, un valor fuera del intervalo de un dispositivo de seguridad, o reutilizar la lectura de un sensor de baja concentración para carbono como alarma de seguridad.

También hacen falta vías alternativas físicas. Cuando se dude de la red o la plataforma, deben estar disponibles detectores portátiles independientes, procedimientos manuales en el lugar, alarmas locales y una cadena de comunicaciones. Para los datos de carbono, las medidas equivalentes son una cola aislada, originales de solo lectura y la capacidad de suspender la publicación de informes. La resiliencia existe cuando las personas pueden intervenir de forma segura si falla la automatización.

Los KPI no terminan en una tasa de parcheo

Entre los KPI comunes de seguridad pueden observarse la proporción de dispositivos gestionados identificados, la tasa de eliminación de cuentas predeterminadas, la proporción de firmware con soporte, la cobertura de recopilación de registros, el tiempo de corrección de vulnerabilidades de alto riesgo y la tasa de éxito de la restauración de copias. Para Safety se añaden la disponibilidad de la ruta de alarma, el número de cambios de umbral no autorizados y el tiempo de transición a la monitorización alternativa. Para Carbon se incorporan el tiempo de identificación del periodo afectado, los fallos de verificación de integridad, las retenciones y correcciones de datos y la integridad del linaje.

Una cifra alta no garantiza automáticamente la seguridad ni el desempeño de carbono. Por ejemplo, incluso con una tasa de parcheo del 100%, desplegar por lotes un firmware incorrecto resulta peligroso. Un KPI es una señal que pregunta si un control funciona, no un sustituto de la evaluación de riesgos ni de las pruebas de campo. En particular, «0 incidentes» no demuestra que no haya incidentes sin detectar, por lo que también deben examinarse la cobertura de los registros y los ejercicios de respuesta.

Lista de verificación para la ejecución

  • ¿Se ha indicado si cada sensor y dato se utiliza para Safety, Carbon o ambos?

  • ¿Se ha evitado confundir una medición para carbono con el cumplimiento de los requisitos de certificación y alarma de seguridad?

  • ¿Se separan los permisos de configuración de seguridad y análisis de carbono, y se someten los cambios de alto riesgo a doble aprobación?

  • ¿Se han definido los límites entre la red de sensores, la red de control de seguridad, la red de oficina y la red de soporte remoto?

  • ¿Se han eliminado las cuentas predeterminadas del fabricante y las cuentas compartidas de proveedores?

  • ¿Existen verificación del origen del firmware, pruebas previas, reversión y respuesta al fin de soporte?

  • ¿Se monitorizan por separado el estado en línea y el estado de seguridad del dispositivo?

  • ¿La recuperación de Safety y la evaluación del impacto en los datos de Carbon se realizan mediante procedimientos separados?

  • ¿Existen vías alternativas como detección independiente, procedimientos manuales y suspensión de la publicación de datos?

  • ¿Los contratos con proveedores especifican las responsabilidades sobre aviso de vulnerabilidades, parches, registros e incidentes?

  • ¿Las copias se han restaurado realmente y se ha probado el reinicio seguro?

  • ¿Los KPI específicos de cada finalidad miden de verdad el riesgo del lugar y la calidad de la evidencia?

Conclusión: proteger conjuntamente la base común y separar la responsabilidad de las decisiones

La ciberseguridad de los sensores industriales de IoT no es una función adicional entre Safety y Carbon. Si quedan comprometidos las cuentas, el firmware, el tiempo, la configuración, la red y los registros, en un lado se debilita el juicio sobre las personas y las instalaciones y, en el otro, la confianza en el resultado de reducción. Por eso, la gestión de activos, el privilegio mínimo, la segmentación, las actualizaciones seguras, los registros y las copias deben operarse como una base común.

Sin embargo, ambos fines no deben fusionarse. El procedimiento para confirmar un estado actual seguro y el que evalúa el impacto sobre los datos históricos de carbono son distintos. Los requisitos de certificación, intervalo y respuesta de los dispositivos también pueden diferir. Cuando la infraestructura común se protege conjuntamente, pero se separan las decisiones y los límites de fallo de cada finalidad, la ciberseguridad se convierte en una capacidad operativa que protege a la vez la seguridad y el carbono.

Fuentes