Catorce días escuchando una celda operativa: una PoC de visibilidad OT por dentro

La ventana es a las cinco de la mañana, antes del cambio de turno. Llegas con el gabinete, el supervisor de la linea te acompaña, y lo primero que descubres es que el switch está en un tablero al que nadie ha abierto en año y medio. Adentro hay cables sin etiqueta, dos puertos ocupados que no deberían estarlo y una etiqueta escrita a mano que dice algo que ya no es cierto.

Todavía no has conectado nada y ya aprendiste algo de esa planta.

Así arranca de verdad una prueba de concepto de visibilidad. No con un tablero de control lleno de gráficas, sino con alguien de tu lado y alguien del nuestro parados frente a un gabinete a una hora incómoda. Lo que sigue son catorce días en los que el colector escucha y nadie vuelve a interrumpir a nadie — y al final, una junta que suele ser más incómoda que la instalación.

Esto es lo que pasa en medio, contado sin nombres ni datos de nadie.

El primer día no revela nada, y eso es normal

Hay una expectativa que conviene desarmar temprano: que al conectar el sensor la pantalla se llene de alertas rojas y en dos horas tengas el diagnóstico. No pasa, y si pasara sería mala señal.

Un colector pasivo aprende por acumulación. El primer día ve el tráfico del primer día: el turno que estaba corriendo, los equipos que hablaron en esas horas, las rutinas que tocaron ejecutarse. Lo que no habló, no existe todavía.

Por eso la ventana es de catorce días y no de dos. En dos semanas alcanza a pasar lo que no pasa a diario: el arranque después de un paro, el mantenimiento programado, el fin de semana con la planta a media carga, la conexión del proveedor que entra una vez cada tanto. Ese último suele ser el más interesante, y casi nunca aparece en las primeras cuarenta y ocho horas.

Si alguien te ofrece un diagnóstico de visibilidad en una tarde, lo que te está ofreciendo es un escaneo activo. Es otra cosa, tiene otros riesgos, y en una red de control no es un detalle menor.

Lo primero que aparece no es un ataque

Es una lista mal contada.

En prácticamente todas las pruebas que hemos corrido, el número de dispositivos que responde no coincide con el número que estaba en el inventario. A veces sobran, a veces faltan, y casi siempre las dos cosas al mismo tiempo: hay equipos activos que nadie registró y hay registros de equipos que ya no están.

No es descuido de nadie en particular. Es lo que le pasa a cualquier planta que lleva quince años operando: se cambió un variador en una parada de emergencia, se agregó una estación de trabajo para un proyecto que se volvió permanente, se conectó un equipo de un proveedor externo "temporalmente". Cada uno de esos movimientos fue razonable el día que ocurrió. El inventario simplemente no se enteró.

Y ahí está el punto que hace que valga la pena mirar esto antes que cualquier otra cosa: no puedes proteger, segmentar ni monitorear lo que no sabes que existe. Lo desarrollamos aparte en por qué el inventario de activos OT casi siempre está mal, pero verlo con datos propios pega distinto que leerlo.

El hallazgo que más incomoda es la segmentación

Cuando la prueba cubre más de una celda —y por diseño se pone un colector por celda, precisamente para esto— aparece el hallazgo que cambia conversaciones.

El colector de una celda ve tráfico que no debería ver.

Puede ser tráfico de otra celda. Puede ser tráfico de la red corporativa. Puede ser un equipo de planta contestándole a algo que vive del otro lado de una frontera que, según el diagrama, no se cruza. Y el diagrama no está mintiendo: estaba bien el día que se dibujó, normalmente sobre las mismas capas del modelo Purdue que casi todas las plantas usan como referencia. Lo que pasó después fue una regla temporal que se quedó, un puerto que se abrió para una prueba, un enlace que se reconfiguró en una emergencia a las tres de la mañana.

Este hallazgo incomoda porque tiene dueño. El del inventario se puede atribuir al tiempo; el de la segmentación apunta a una decisión que alguien tomó y no se documentó. Por eso conviene presentarlo con cuidado, con la evidencia enfrente y sin buscar culpables — el objetivo es cerrar la brecha, no ganar la discusión. Cómo se cierra sin parar la línea está contado en segmentar IT/OT sin frenar la producción.

Lo que no vas a ver, dicho antes y no después

Una prueba honesta declara sus límites al principio. Estos son los que importan, y los decimos en la sesión previa por una razón muy práctica: ya nos tocó explicarlos en la junta de entrega, y ahí es tarde.

1. Solo aparece lo que habla TCP/IP. El colector escucha tráfico de red. Un instrumento colgado de un bus serial no aparece como activo propio: aparece el equipo que sale a la red por él. Si buena parte de tu instrumentación es serial, la prueba te va a dar menos de lo que esperas — y eso hay que saberlo antes de firmar, no después.
2. Lo apagado no existe. Un equipo que estuvo fuera durante los catorce días no está en el inventario. No porque el sensor falle, sino porque nunca habló.
3. Solo se ve donde se puso el sensor. El alcance son las celdas acordadas. Una celda correctamente segmentada no ve a la de enseguida, que es justo lo que queremos que pase — pero implica que instrumentar una no te dice nada de la otra.
4. No es un pentest. El sensor no interroga a nadie. No manda un paquete a un PLC para ver cómo reacciona. En una red de control esa distinción no es filosófica.

Ninguno de estos límites es un defecto del método. Son el precio de no tocar el proceso, y es un precio que en un entorno industrial casi siempre vale la pena pagar. Si quieres el fondo de por qué monitorear OT no se parece a monitorear TI, está en este otro artículo.

El entregable no es el reporte, es la junta

El documento se entrega en sesión, con operación y con TI en la misma mesa. No es una formalidad: es donde ocurre lo que de verdad justifica la prueba.

Lo que pasa una y otra vez es que las dos áreas descubren que no tenían la misma versión de la planta. TI creía que cierto segmento estaba aislado; operación sabía que no, pero nunca le pareció un tema de seguridad sino de disponibilidad. Nadie ocultó nada. Simplemente miraban la misma red desde dos lugares distintos y ninguno tenía el dato completo.

El inventario, en esa mesa, deja de ser un documento técnico y se vuelve un lenguaje común. Y a partir de ahí la conversación cambia de tono: ya no es "necesitamos invertir en seguridad industrial" en abstracto, sino "estos catorce equipos están donde no deberían y esta regla lleva dos años abierta".

Es también donde se decide si hay proyecto o no. A veces el resultado es que la planta está mejor de lo que se temía y no hay nada urgente que hacer. Ese también es un resultado, y decirlo es parte del trabajo.

Por qué esto va antes de comprar nada

La secuencia importa. Diseñar una arquitectura de seguridad industrial sin saber qué hay en la red es cotizar sobre una suposición — y en OT las suposiciones se pagan en paros, no en incomodidad.

Medir primero cuesta poco y acota mucho. El resto —la frontera, las políticas, el firewall en medio— se diseña después, con los hallazgos enfrente. No al revés.

Y si estás pensando que esto no te aplica porque no tienes una planta, vale la pena que leas esto otro antes de descartarlo: las cámaras, los accesos y el sistema del edificio también son computadoras que tocan el mundo físico.

La pregunta con la que cerramos siempre la sesión previa es la misma, y sirve igual para decidir si necesitas una prueba: si mañana te preguntan cuántos dispositivos hay en tu red industrial y qué está hablando con qué, ¿contestarías con datos o con memoria? Si la respuesta es memoria, ya sabes qué es lo primero. Así funciona la prueba de concepto, y así encaja en el resto de la ciberseguridad industrial que hacemos.