OpenCyber AcademyMapa de la lección
Lección 18 publicada. Mapa, ejemplo, EX035.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["18.1 Arquitecturas de TO por niveles"]
N2["18.2 La DMZ y la intermediación de datos"]
N3["18.3 Confianza cero en la TO"]
N4["18.4 Acceso remoto"]
N5["18.5 Arquitectura de monitoreo"]
N6["18.7 Actividad práctica"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX035"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["18.1 Arquitecturas de TO por niveles"]
N2["18.2 La DMZ y la intermediación de datos"]
N3["18.3 Confianza cero en la TO"]
N4["18.4 Acceso remoto"]
N5["18.5 Arquitectura de monitoreo"]
N6["18.7 Actividad práctica"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX035"]
[Resultados de aprendizaje y conexión]
|
v
[18.1 Arquitecturas de TO por niveles]
|
v
[18.2 La DMZ y la intermediación de datos]
|
v
[18.3 Confianza cero en la TO]
|
v
[18.4 Acceso remoto]
|
v
[18.5 Arquitectura de monitoreo]
|
v
[18.7 Actividad práctica]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX035]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted podrá (1) describir arquitecturas de referencia para la tecnología operativa, incluidos los modelos por niveles y las DMZ; (2) aplicar los principios de confianza cero donde encajan en la TO y explicar dónde no encajan; (3) diseñar arquitecturas de acceso remoto, registro y monitoreo; y (4) evaluar una arquitectura según las consecuencias, no solo según el número de controles. Se apoya en los capítulos 11, 12 y 15 y prepara los capítulos 26 y 27.
18.1 Arquitecturas de TO por niveles
Las arquitecturas de TO suelen describirse por niveles: proceso físico (nivel 0), sensores y actuadores con control básico (1), control de supervisión (2), operaciones del sitio (3), una zona desmilitarizada y la empresa (4–5). El modelo, que desciende de la arquitectura de referencia de Purdue y aparece en la guía de TO del NIST, es una herramienta para ubicar activos y conductos, no una ley. Los sistemas modernos difuminan los niveles: sensores conectados a la nube, servicios remotos de los proveedores y dispositivos de campo con enlaces celulares directos.
En LRWA, los servidores SCADA están en la zona de control, las RTU en la zona de campo y la réplica del historiador en la DMZ.
18.2 La DMZ y la intermediación de datos
La DMZ de TO se sitúa entre las redes de control y las corporativas. Ningún tráfico directo la atraviesa: los sistemas corporativos hablan con los servicios de la DMZ (réplica del historiador, servidor de parches, pasarela de acceso remoto), que hablan con los sistemas de control. Una prueba útil: si se compromete cualquier equipo corporativo, ¿puede enviar un paquete que llegue a un controlador? Si la respuesta es sí, la DMZ es decorativa. En LRWA, la revisión de flujos aplicó esta prueba y no la superó: un script corporativo de informes llegaba directamente a una RTU de campo. Trasladar esos datos a la réplica del historiador en la DMZ es la forma en que LRWA hace que su DMZ sea real y no decorativa, y la prueba se repite cada vez que se añade un conducto nuevo.
18.3 Confianza cero en la TO
La confianza cero, tal como la describe NIST SP 800-207, elimina la confianza implícita basada en la ubicación en la red; cada acceso se autentica, se autoriza y se evalúa por sesión. En la TO, el principio es valioso para el acceso humano y de ingeniería (identidades nominativas, autenticación fuerte, privilegio justo a tiempo, grabación de sesiones) y para los dispositivos nuevos que lo admiten. Encaja mal donde los controladores heredados no pueden autenticarse en absoluto y donde los lazos de control no toleran un punto de decisión de políticas en su camino. La respuesta de ingeniería es aplicar la confianza cero en las fronteras donde se puede (acceso de ingeniería, intermediación de datos, pasarelas) y usar la segmentación y el monitoreo alrededor de lo que no puede autenticarse.
18.4 Acceso remoto
El acceso remoto de proveedores y personal es una de las principales vías de entrada a la TO. Diséñelo así: una pasarela de acceso en la DMZ; autenticación multifactor; cuentas nominativas; acceso aprobado por sesión; conexiones a un servidor de salto, nunca directamente a los controladores; grabación de sesiones; y caducidad automática. El incidente de la planta de tratamiento de agua de Oldsmar se atribuyó inicialmente a un acceso remoto no autorizado mediante software de escritorio compartido; declaraciones posteriores, recogidas por WUSF Public Media (2023), indicaron que probablemente se trató de un error de un empleado. En cualquier caso, el caso ilustra por qué el escritorio compartido sin control en las estaciones de los operadores es una debilidad de arquitectura, y por qué los primeros relatos de un incidente deben tomarse como provisionales.
18.5 Arquitectura de monitoreo
El monitoreo de la seguridad de la red en la TO suele ser pasivo: copias del tráfico procedentes de puertos espejo de los conmutadores o de derivadores (taps) alimentan sensores que entienden los protocolos industriales y establecen una línea base del comportamiento normal. Los registros de servidores, cortafuegos y pasarelas van a un recolector en la DMZ o en una zona de seguridad dedicada. El monitoreo no debe crear caminos nuevos hacia el control: los sensores reciben solo copias, y las interfaces de gestión están en una red separada.
En LRWA, los derivadores pasivos están en el conmutador de la zona de control y en la cabecera LTE, y sus interfaces de gestión se mantienen fuera de la red monitoreada.
18.6 Ejemplo resuelto: la arquitectura objetivo del TMRP (sintético)
El objetivo de LRWA: empresa — cortafuegos — DMZ (réplica del historiador, pasarela de acceso remoto con MFA, preparación de parches, recolector de registros) — cortafuegos — zona de control (par SCADA, servidor de salto de ingeniería) — conducto de campo sobre LTE privada con autenticación en la capa de aplicación (pasarelas para las RTU heredadas) — RTU y paneles de control locales con modo manual. Los derivadores pasivos de monitoreo están en el conmutador de la zona de control y en la cabecera LTE. La arquitectura se evalúa según las consecuencias: las órdenes falsificadas exigen comprometer la clave de una pasarela de campo o los servidores SCADA; el compromiso corporativo da acceso a los datos de la réplica del historiador, pero a ningún camino de paquetes hacia los dispositivos de campo; la pérdida de LTE deja los sitios en modo automático local o manual, con baterías de telemetría de 24 h.
18.7 Actividad práctica
Dibuje la arquitectura objetivo en texto o en un diagrama sencillo y anote cada conducto con las entradas de la lista de permitidos del Lab 5. Después aplique la prueba de la DMZ de §18.2. Marque cada conducto con su dirección y su protocolo, y muestre dónde están los derivadores pasivos. Para cada entrada de la lista de permitidos, pregúntese qué zona inicia la conexión y si la prueba de la DMZ sigue superándose si esa zona se compromete. Después añada el camino de ingeniería a través del servidor de salto y compruebe que ninguna regla permite que una estación de ingeniería llegue directamente a una RTU de campo, que fue una de las tres infracciones de flujo de LRWA. Un diagrama que oculta la dirección no puede mostrar si la DMZ funciona realmente.
18.8 Errores comunes y límites
- DMZ con reglas directas «temporales».
- Confianza cero declarada para sistemas que no pueden autenticarse.
- Acceso remoto que elude la pasarela (módems de proveedores, herramientas de escritorio compartido).
- Sensores de monitoreo con interfaces de gestión en la red monitoreada.
- Arquitecturas juzgadas por el número de controles y no por las consecuencias que evitan.
En LRWA, el tercer y el primer error son los más probables: un proveedor que quiere acceso rápido a RTU-B para hacer diagnósticos, y una regla directa temporal añadida durante una interrupción. La arquitectura objetivo responde a ambos con la pasarela de acceso de la DMZ y con control de cambios en cada conducto.
Ejercicios — capítulo 18
EX035 — Prueba de la DMZ. Objetivo: probar un diseño de DMZ. Entradas: una regla propuesta que permite al servidor ERP corporativo escribir el estado de las órdenes de trabajo directamente en la base de datos del SCADA por TCP/1433. Pasos: aplique la prueba de la DMZ; proponga un diseño alternativo que satisfaga la necesidad del negocio. Evidencia esperada: análisis y diseño. Rúbrica: 3 = regla rechazada con su motivo, la alternativa intermedia los datos a través de la DMZ, con el lado de control recogiéndolos o con una exportación unidireccional; 2 = la alternativa sigue siendo entrante; 1 = acepta la regla; 0 = nada.
EX036 — Arquitectura de acceso remoto. Objetivo: diseñar el acceso del proveedor. Entradas: el proveedor de RTU-B necesita acceso trimestral para diagnósticos. Pasos: especifique el camino de acceso, la autenticación, la aprobación, el monitoreo y la caducidad; enumere la evidencia que mostraría que el diseño funciona. Evidencia esperada: especificación y lista de evidencias. Rúbrica: 3 = pasarela, MFA, aprobación por sesión, servidor de salto, grabación, caducidad y evidencia (registros, prueba de que el camino directo está denegado); 2 = sin evidencia; 1 = VPN directa hacia el control; 0 = nada.
Síntesis del capítulo
Use los modelos por niveles para ubicar activos y conductos, haga real la DMZ sin permitir ningún cruce directo, aplique la confianza cero donde los sistemas puedan autenticarse y la segmentación donde no puedan, haga pasar todo el acceso remoto por una pasarela controlada, monitoree de forma pasiva sin crear caminos y juzgue la arquitectura por las consecuencias que hace difíciles de provocar.