Ciberseguridad y seguridad física: dónde las direcciones deben coincidir

La separación entre ciberseguridad y seguridad física es, en la mayoría de las organizaciones industriales, un artefacto organizativo que ya no describe la realidad técnica de los activos que protege. Quien mantiene esa frontera intacta no está gestionando dos disciplinas, está creando una tercera vulnerabilidad: la del espacio entre ellas.

La convergencia no es una moda de consultoría ni un eslogan de feria. Es el reconocimiento de que una cámara IP, un torno de acceso conectado, un autómata programable de planta y un sistema de control de incendios viven todos sobre la misma capa lógica y comparten, en la práctica, las mismas superficies de ataque. Cuando el responsable de seguridad física reporta a operaciones y el responsable de ciberseguridad reporta a tecnología, y ambos se ven en comité una vez al trimestre, lo que se ha diseñado no es una organización, es una junta sin sellar entre dos placas que se mueven a velocidades distintas.

El supuesto que ya no se sostiene

Durante décadas, la seguridad física y la ciberseguridad pudieron operar en paralelo sin conflicto porque sus dominios eran físicamente distintos. La primera vigilaba puertas, vallas, cámaras analógicas y centrales de alarma cableadas. La segunda vigilaba servidores, redes corporativas y aplicaciones. Los activos no se tocaban. Los proveedores eran distintos. Los presupuestos eran distintos. Las certificaciones eran distintas. La separación funcionaba porque reflejaba una realidad técnica.

Esa realidad ya no existe. La cámara que cubre el perímetro de una planta logística es un dispositivo IP con sistema operativo, firmware actualizable y, en muchos casos, una contraseña por defecto que nadie cambió. El control de accesos del centro de datos se sincroniza con el directorio activo de la organización. El sistema de detección de intrusión perimetral envía sus eventos a un servidor que, a su vez, está conectado a la red corporativa para que el panel se pueda consultar desde la oficina del director de operaciones. Cada uno de esos puentes, construidos en su momento por una razón legítima, ha trasladado los activos físicos al dominio de los activos digitales sin que la organización haya rehecho su mapa de responsabilidades.

El resultado es que el director de seguridad física firma contratos con instaladores que entregan sistemas conectados a redes que él no controla, y el director de ciberseguridad descubre, durante una auditoría, que hay decenas de dispositivos en su red de los que no tenía inventario y cuyas credenciales no gestiona. Ninguno de los dos está haciendo mal su trabajo según la definición clásica del puesto. Lo que está mal es la definición.

INCIBE y CCN-CERT llevan años publicando guías sobre la convergencia IT/OT y sobre la protección de sistemas ciberfísicos, y la directiva NIS2, transpuesta al ordenamiento español, formaliza la obligación de tratar de manera unificada los riesgos sobre los activos físicos y digitales en sectores esenciales. La regulación ha llegado antes que la reorganización interna. Esto no es excepcional, es el patrón habitual.

La capa donde IT y OT se encuentran sin haberlo pactado

En una instalación industrial moderna, la red de tecnología operativa, OT, y la red corporativa de tecnología de la información, IT, están separadas en el diagrama y conectadas en la realidad. Hay un cortafuegos entre ambas, sí. Hay reglas, sí. Y hay, casi siempre, una serie de excepciones que se fueron añadiendo a lo largo de los años para permitir que el sistema de mantenimiento predictivo accediera a los datos del autómata, que el proveedor pudiera conectarse remotamente para diagnosticar, que el panel de supervisión se pudiera ver desde la sala de control corporativa.

Cada excepción tiene un nombre, un propietario y una justificación. Lo que falta, en la mayoría de los casos, es una revisión periódica que pregunte si la justificación sigue siendo válida y si el propietario sigue trabajando en la organización. El resultado es un cortafuegos cuya configuración real es desconocida para quienes lo administran, porque la suma de excepciones acumuladas en cinco años supera la capacidad de cualquier persona para mantenerla en la cabeza.

La capa donde IT y OT se encuentran es también la capa donde la seguridad física conectada vive. Las cámaras, los controles de acceso, los sistemas de gestión de edificios, los SCADA de protección contra incendios, los lectores biométricos. Todos ellos están técnicamente en OT o en una red dedicada, pero todos ellos tienen algún punto de contacto con IT, ya sea para recibir actualizaciones, para enviar logs a un SIEM, para sincronizar usuarios o para que el equipo de seguridad corporativa pueda monitorizar desde un panel unificado.

Quien gestiona esa capa intermedia es, en la práctica, el verdadero responsable de la postura de seguridad del activo. Pero en el organigrama, esa función rara vez está nombrada. Suele estar repartida entre el responsable de OT, que se ocupa de la disponibilidad, el responsable de IT, que se ocupa de la red, y el responsable de seguridad física, que se ocupa del propósito original del dispositivo. Tres responsables y ningún propietario.

El fabricante que entrega un sistema de seguridad física moderno debe saber dónde se va a alojar lógicamente, qué tráfico va a generar, qué actualizaciones va a requerir y qué cadena de responsabilidades va a activarse cuando algo falle. Si entrega el equipo sin esa información, la responsabilidad se diluye desde el primer día. La conversación que el fabricante debe forzar con el cliente no es sobre el producto, es sobre la integración.

Los paneles compartidos y la ilusión del control unificado

En los últimos años se han popularizado las plataformas que prometen un panel único donde el responsable de seguridad ve, al mismo tiempo, las alarmas de intrusión, los eventos de las cámaras, las alertas del SIEM, los incidentes de control de accesos y las anomalías de los sistemas OT. La promesa es atractiva: una sola pantalla, una sola cola de eventos, una sola lógica de escalada. La realidad de esos paneles, en operación, es más matizada.

Un panel unificado consolida la visualización, no la responsabilidad. Si los eventos llegan desde sistemas que pertenecen a departamentos distintos, con criterios de criticidad distintos, con tiempos de respuesta distintos y con cadenas de escalada distintas, la consolidación visual no resuelve el problema de fondo. Lo enmascara. El operador de turno ve una pantalla con cien eventos y no sabe cuáles son competencia suya, cuáles tiene que reenviar, a quién, y en qué plazo. La consecuencia previsible es que los eventos importantes se pierden en el ruido de los irrelevantes, o que el operador desarrolla, por instinto, una clasificación informal que nadie ha validado.

El panel compartido funciona cuando, debajo de él, hay una organización compartida. Si el panel es de la planta pero las decisiones sobre lo que se ve, lo que se filtra y lo que se escala se toman en tres comités distintos, el panel es un teatro. Si el panel es de la corporación pero los datos vienen de sistemas locales sobre los que el equipo central no tiene autoridad, el panel es un riesgo, porque crea la sensación de control sin la sustancia.

La ENISA ha insistido en que la integración de sistemas de seguridad debe ir acompañada de una integración de procesos y de gobernanza, y no al revés. La tecnología es la parte fácil. Lo difícil, lo que cuesta dos años de trabajo interno, es decidir quién es el dueño del evento, quién es el dueño de la respuesta y quién es el dueño de la mejora del proceso después del incidente. Sin esas tres preguntas resueltas, la inversión en plataformas de consolidación es una capa más, no una respuesta.

En las auditorías que conducimos para clientes industriales, la primera pregunta operativa no es nunca sobre el sistema. Es sobre la matriz RACI. Si la matriz no existe, o existe pero no está firmada por las tres direcciones implicadas, el resto del trabajo se hace sobre arena.

La cadena de escalada cuando un incidente cruza dominios

Un caso típico. A las tres de la mañana, el sistema de detección perimetral de una planta logística detecta movimiento en una zona donde no debería haber actividad. La cámara correspondiente, que es IP, había sido desconectada de la red veinte minutos antes mediante un comando enviado desde una IP interna que nadie reconoce. El SIEM corporativo había generado una alerta de tráfico anómalo hacia el segmento OT cuarenta minutos antes de la detección física, pero esa alerta estaba en una cola que se revisa por la mañana porque históricamente el ratio de falsos positivos era alto.

Este incidente no es una hipótesis. Es la forma genérica de una clase entera de eventos que están ocurriendo en infraestructuras europeas con regularidad creciente. Y la pregunta operativa, cuando ocurre, no es técnica. Es organizativa. ¿Quién lo gestiona? ¿El responsable de seguridad física, porque hay intrusión perimetral? ¿El responsable de ciberseguridad, porque hubo un movimiento lateral previo? ¿El responsable de OT, porque el dispositivo afectado vive en su red? ¿El director de operaciones, porque la planta está implicada? ¿El director general, porque puede haber implicaciones reputacionales y regulatorias?

La respuesta correcta es que la cadena de escalada debe estar definida antes del incidente, no construida durante él. Y debe estar definida con un nivel de granularidad que contemple, al menos, los tres tipos de cruces: incidente físico con causa cibernética, incidente cibernético con consecuencia física, e incidente que afecta simultáneamente a la disponibilidad de un proceso OT y a la integridad de un sistema IT. Cada uno de esos tres tipos requiere un decisor distinto en primera instancia, un equipo de respuesta distinto y una secuencia de comunicación distinta hacia la autoridad competente.

Para operadores de servicios esenciales, la notificación a la autoridad nacional, en España al CCN-CERT o al INCIBE-CERT según el sector, tiene plazos que se cuentan en horas. Si el equipo está discutiendo internamente quién es el dueño del incidente cuando esos plazos corren, la organización está ya en infracción regulatoria antes de haber empezado a contener el daño. La AEPD entra en escena si hay datos personales implicados, y esa rama de la cadena suele estar mal modelada en empresas industriales que no se ven a sí mismas como tratadoras de datos sensibles.

La cadena de escalada se prueba con simulacros conjuntos, no con tabletops separados. Si el equipo de ciberseguridad hace su ejercicio anual por su lado y el equipo de seguridad física hace el suyo por el otro, lo que se está ensayando es el funcionamiento de cada silo, no la coordinación entre ellos. El simulacro que sirve es el que reúne, en la misma sala y durante el mismo escenario, a los responsables de IT, OT, seguridad física, comunicación, asuntos legales y dirección general.

La separación organizativa como riesgo principal

La tesis dura de este artículo es que, en el estado actual de la tecnología y de la amenaza, la separación organizativa entre ciberseguridad y seguridad física es el mayor riesgo no técnico que una organización industrial puede acumular. No es el riesgo más visible, porque no aparece en ningún escáner de vulnerabilidades ni en ninguna auditoría de cumplimiento. Pero es el riesgo que determina, cuando el incidente ocurre, si la organización responde como un cuerpo o como dos cuerpos que tropiezan.

Resolver esta separación no significa fusionar los dos departamentos en uno bajo un único director. Esa solución, que algunas grandes corporaciones han intentado, suele fracasar porque las competencias técnicas requeridas son lo suficientemente distintas como para que una sola persona no pueda dirigir ambas con autoridad real. Lo que funciona, en la experiencia que hemos acumulado en proyectos industriales, es una estructura matricial donde los dos responsables mantienen su línea jerárquica pero comparten una capa de gobernanza común con autoridad ejecutiva. Esa capa, normalmente un comité de seguridad operativa con reuniones semanales y no trimestrales, es la que decide sobre los activos de la zona gris, la que aprueba las excepciones de cortafuegos, la que firma la matriz RACI de cada incidente potencial y la que gestiona la relación con los reguladores.

Para que ese comité funcione, necesita tres cosas: un mandato escrito firmado por la dirección general, un presupuesto propio que no dependa de la negociación entre departamentos, y un cuadro de mando con indicadores que midan la coordinación, no solo el desempeño de cada disciplina. Sin esos tres elementos, el comité es una reunión más y la separación organizativa permanece.

Las organizaciones que han hecho este recorrido han descubierto, casi sin excepción, que el coste de la integración es menor que el coste del primer incidente que cruza dominios. La aseguradora lo sabe, y en el mercado español, Unespa lleva tiempo señalando que la suscripción de pólizas de daños patrimoniales en sectores industriales se está endureciendo precisamente en función de la madurez de la convergencia. Quien presenta una organización integrada negocia primas distintas que quien presenta dos organigramas paralelos.

Lo que el fabricante puede y no puede hacer

Un fabricante de tecnología de seguridad no puede resolver el problema organizativo de su cliente. Sería pretensioso afirmar lo contrario. Lo que el fabricante sí puede hacer, y debe hacer si toma en serio su papel, es entregar sistemas cuyas asunciones organizativas sean explícitas. Si un sistema de cámaras requiere, para funcionar correctamente, que exista un proceso definido de gestión de incidentes que cruce IT y seguridad física, el fabricante debe decirlo antes de la instalación, no después del primer fallo.

En BOSWAU + KNAUER hemos integrado esta exigencia en el proceso de auditoría que precede a cualquier despliegue. Antes de instalar una sola cámara, un solo robot de vigilancia, una sola torre móvil, preguntamos por la matriz de responsabilidades, por la cadena de escalada y por la relación con el SIEM corporativo si lo hay. Si las respuestas no existen, el primer entregable del proyecto no es hardware, es una propuesta de gobernanza. Esto alarga el ciclo de venta y, en algunos casos, lo cierra antes de empezar. Lo aceptamos como coste de hacer las cosas bien.

El libro "BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad" desarrolla este principio en los capítulos sobre integración y sobre software, donde se argumenta que un panel sin proceso es un teatro, y que la disciplina organizativa es la condición sin la cual la tecnología más avanzada se degrada a decoración.

Lo que permanece

La convergencia entre ciberseguridad y seguridad física no es un proyecto que se termine. Es un estado que se mantiene mediante reuniones que sí ocurren, simulacros que sí se ejecutan, matrices que sí se firman y excepciones que sí se revisan. Cuando una organización deja de hacer alguna de esas cosas durante seis meses, la separación organizativa vuelve por sí sola, porque es el estado natural de los departamentos que reportan a líneas distintas.

La forma de saber si una organización está realmente integrada es mirar qué pasa cuando un evento ambiguo aparece a las tres de la mañana. Si el primer responsable que se entera sabe a quién llamar sin pensar, la integración existe. Si tiene que abrir el organigrama, no existe. Esa es la prueba, y se hace cada noche sin avisar.

Para los operadores que reconozcan en este artículo su propia situación, BOSWAU + KNAUER ofrece tres caminos. El primero es una conversación confidencial de sesenta minutos con la dirección, sin coste y sin compromiso, para situar la postura actual frente a las exigencias que ya están en vigor. El segundo es una auditoría de tres a cinco días en planta, con entregable escrito y aprovechable internamente o con terceros, que documenta el estado de la convergencia y propone un plan de integración con hitos. El tercero es un piloto de noventa días sobre un emplazamiento definido, con indicadores acordados antes del inicio, para medir el efecto real de una arquitectura unificada sobre la cola de incidentes y sobre el tiempo de respuesta. Los tres caminos están descritos al final del libro, y los tres existen porque la convergencia no se compra, se construye.

Preguntas frecuentes

¿Qué es la convergencia?

Convergencia, en este contexto, es la integración operativa de la gestión de la seguridad física y la ciberseguridad de manera que los incidentes que cruzan ambos dominios se traten como un único proceso, con un único propietario en cada momento y una única cadena de decisión. No implica fusionar departamentos ni crear un superdirector. Implica establecer una capa de gobernanza compartida con autoridad ejecutiva sobre la zona gris, donde viven los activos que son simultáneamente físicos y digitales, como cámaras IP, controles de acceso conectados y sistemas SCADA.

¿Quién la lidera?

En la práctica funciona un comité de seguridad operativa que reúne, con cadencia semanal, a los responsables de ciberseguridad, seguridad física, OT y operaciones, con presidencia rotatoria o asignada según el sector. Ese comité necesita un mandato escrito de la dirección general, presupuesto propio y autoridad para resolver conflictos entre departamentos sin escalada continua. El liderazgo individual no resuelve el problema, lo desplaza. Lo que sostiene la convergencia es una estructura colegiada con autoridad real, no una persona con doble sombrero que termina dependiendo de la línea jerárquica más fuerte.

¿Qué herramientas la conectan?

Las plataformas de consolidación de eventos, los SIEM con integración OT, los sistemas PSIM, los inventarios unificados de activos físicos y lógicos, y las soluciones de detección de anomalías que cruzan datos de red con datos de cámaras y sensores. Pero la herramienta es secundaria. Lo primero es el inventario común, la matriz RACI firmada y los procesos de escalada documentados. Una plataforma sin esos tres elementos amplifica el desorden previo. Con ellos, multiplica la capacidad de respuesta. El orden de las decisiones importa, y siempre va de la gobernanza al software, nunca al revés.

¿Qué reglas de escalada?

Una cadena de escalada útil distingue al menos tres tipos de incidentes: físico con causa cibernética, cibernético con consecuencia física, y simultáneo en disponibilidad OT e integridad IT. Cada tipo tiene un decisor en primera instancia, un equipo de respuesta y una secuencia de notificación interna y externa. Los plazos regulatorios hacia CCN-CERT, INCIBE-CERT o AEPD se cuentan en horas, por lo que las decisiones deben estar predefinidas. La cadena se prueba en simulacros conjuntos, no en ejercicios separados por departamento, porque lo que se está ensayando es la coordinación, no la competencia técnica.