Capítulo 15 — Infraestructura crítica y seguridad sectorial: integración y dependencias | Técnico Seguridad de infraestructuras críticas y sectores

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Capítulo 15 — Infraestructura crítica y seguridad sectorial: integración y dependencias

Mapa de la lección

Lección 15 publicada. Mapa, ejemplo, EX057.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["15.1 Interdependencia"]
  N2["15.2 Las dependencias como grafo"]
  N3["15.5 Actividad práctica"]
  N4["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX057"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["15.1 Interdependencia"]
  N2["15.2 Las dependencias como grafo"]
  N3["15.5 Actividad práctica"]
  N4["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX057"]

[Resultados de aprendizaje y conexión]
    |
    v
[15.1 Interdependencia]
    |
    v
[15.2 Las dependencias como grafo]
    |
    v
[15.5 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX057]

Resultados de aprendizaje y conexión

Al terminar este capítulo debería ser capaz de:

modelar las dependencias técnicas (virtualización, directorio, hora, almacenamiento, telecomunicaciones, energía) como un grafo y calcular a qué afecta un único fallo;
encontrar los componentes compartidos entre servicios y sectores, incluida la compartición indirecta a través de una dependencia de una dependencia;
tratar cada punto de integración (routers de estación, redes de operadores de telecomunicaciones, pasarelas de proveedores, exportaciones de datos) como un límite que hay que modelar, controlar y supervisar;
convertir un análisis de dependencias en comprobaciones y controles concretos.

El capítulo 13 encontró una ruta hacia KW-04 que eludía el cortafuegos a través de la red de un operador de telecomunicaciones. Era una dependencia que nadie había dibujado. Este capítulo las dibuja de forma sistemática.

15.1 Interdependencia

Las infraestructuras críticas dependen unas de otras de forma física (la energía para las bombas), a través de la información (la telemetría sobre la red de un operador), geográfica (conductos e instalaciones compartidos) y lógica (personal, software y administración compartidos). Esta clasificación procede del artículo, ampliamente citado, de Rinaldi, Peerenboom y Kelly (Rinaldi et al., 2001). Para un técnico, las sorpresas más frecuentes son lógicas: un directorio, un clúster de hipervisores, una fuente de hora o un colector de supervisión compartidos por sistemas cuyos responsables creen, cada uno, que es suyo.

Para un técnico, las sorpresas más frecuentes son lógicas: un directorio, un hipervisor o una fuente de hora que comparten varios servicios sin que ningún responsable los reclame. Dibújelos primero, y después los enlaces físicos y de los operadores de telecomunicaciones. El Lab 15 hace visibles los nodos compartidos como recuentos entre servicios.

15.2 Las dependencias como grafo

Escriba cada dependencia como «A necesita B». Para averiguar qué falla cuando falla B, siga las aristas hacia atrás: todo lo que necesita B, todo lo que necesita eso, y así sucesivamente. Es una búsqueda en anchura sobre el grafo invertido. Importan dos resultados: el conjunto de servicios afectados y la ruta por la que se ve afectado cada uno, porque la ruta le dice dónde un control o una redundancia romperían la cadena. La compartición indirecta es el caso importante. En el modelo del KVROC, el servidor del BMS del hospital y el servidor SCADA se autentican ambos contra ad-ops, que se ejecuta en esx-03, mientras que el procesador de comunicaciones de la red eléctrica también se ejecuta en esx-03. Ningún responsable de servicio considera esx-03 como «suyo»; los tres dependen de él.

15.3 Ejemplo resuelto: las dependencias del KVROC (sintético)

Lab 15 (guárdelo como lab15.py y ejecútelo con python3 lab15.py):

# Lab 15 - trace failure impact through technical dependencies (offline, standard library only)
# Synthetic dependency map for the Kestrel Vale operations centre: "A needs B" edges.
from collections import deque
needs = {
 "water-telemetry": ["scada-01", "cell-router-kw", "fw-01"],
 "scada-01": ["ad-ops", "ntp-ops", "hist-02", "esx-02"],
 "hist-02": ["esx-02", "san-01"],
 "hospital-bms": ["bms-server", "fw-02"],
 "bms-server": ["esx-02", "ad-ops"],
 "grid-ss3-telecontrol": ["fep-01", "telco-mpls"],
 "fep-01": ["ntp-ops", "esx-03"],
 "ad-ops": ["esx-03"],
 "ntp-ops": ["gps-clock"],
}
def impacted(failed):
    rev = {}
    for a, bs in needs.items():
        for b in bs: rev.setdefault(b, []).append(a)
    seen, q = set(), deque([failed])
    while q:
        for a in rev.get(q.popleft(), []):
            if a not in seen: seen.add(a); q.append(a)
    return sorted(seen)
services = {"water-telemetry", "hospital-bms", "grid-ss3-telecontrol"}
for comp in ["esx-02", "esx-03", "gps-clock", "san-01", "telco-mpls"]:
    hit = impacted(comp)
    print(f"{comp:<10} -> services {sorted(services & set(hit))} via {len(hit)} dependants")
counts = {c: len(services & set(impacted(c))) for c in {b for bs in needs.values() for b in bs}}
print("shared by all three services:", sorted(c for c, n in counts.items() if n == 3))

Salida esperada (Python 3.13.5):

esx-02     -> services ['hospital-bms', 'water-telemetry'] via 5 dependants
esx-03     -> services ['grid-ss3-telecontrol', 'hospital-bms', 'water-telemetry'] via 7 dependants
gps-clock  -> services ['grid-ss3-telecontrol', 'water-telemetry'] via 5 dependants
san-01     -> services ['water-telemetry'] via 3 dependants
telco-mpls -> services ['grid-ss3-telecontrol'] via 1 dependants
shared by all three services: ['esx-03']

esx-02 aloja el servidor SCADA, el historiador y el servidor del BMS, de modo que su fallo afecta a la supervisión del agua y del hospital. esx-03 es el único componente que afecta a los tres servicios: directamente al procesador de comunicaciones de la red eléctrica e indirectamente, a través del directorio, a los otros dos. gps-clock, la referencia de ntp-ops, afecta al agua y a la red eléctrica: perderlo no detiene nada de inmediato, pero el capítulo 7 mostró lo que hacen los relojes a la deriva con toda investigación posterior. telco-mpls solo afecta a la red eléctrica, y san-01 solo al agua.

De ahí se siguen acciones técnicas: el directorio necesita un segundo controlador de dominio en otro servidor (y hay que probar el comportamiento del servidor SCADA cuando el directorio no está accesible: ¿pueden los operadores seguir iniciando sesión en la HMI?); ntp-ops necesita una segunda referencia independiente y supervisión del desfase; la capacidad de esx-03 y su grupo de administradores pasan a ser una cuestión intersectorial que se revisa con los tres responsables.

15.4 Los puntos de integración son límites

Cada lugar en el que el servicio se conecta con algo que no controla es un límite:

Equipos de comunicación de las estaciones: routers celulares, radios, la red privada del operador de telecomunicaciones. La redirección de puerto del capítulo 13 estaba aquí. La configuración de cada router debe figurar en el inventario de activos, bajo control de cambios y detección de derivas (capítulo 14).
Pasarelas de soporte remoto de los proveedores: capítulo 10.
Exportaciones de datos: el envío diario del historiador al servidor corporativo de informes (conducto C4 del capítulo 6). Las exportaciones deben enviarse hacia fuera desde el lado de control, nunca extraerse desde un equipo corporativo con credenciales dentro de la zona de control.
Servicios compartidos: directorio, hora, supervisión. Sus administradores administran de hecho todo lo que depende de ellos.

El trabajo de CISA sobre las funciones críticas nacionales enmarca estas dependencias a escala nacional (National Critical Functions); el técnico aplica el mismo razonamiento a un centro de operaciones.

15.5 Actividad práctica

Añada un nodo power-ups-a que necesitan tanto esx-02 como esx-03, y un nodo cell-carrier que necesitan tanto cell-router-kw como telco-mpls. Vuelva a ejecutar el Lab 15 y anote qué componentes comparten ahora los tres servicios. Proponga después un cambio técnico para cada uno. Tras el cambio, anote qué componentes comparten los tres servicios y proponga una respuesta técnica para cada uno, como un segundo controlador de dominio o una segunda acometida eléctrica. Mantenga las aristas nuevas en el mismo formato que el laboratorio para que el grafo siga ejecutándose. Revise las propuestas con los tres responsables de servicio antes de cualquier cambio.

15.6 Errores comunes y límites

Tratar el directorio y el servicio de hora como «infraestructura» sin responsable de servicio.
Contar dependientes en lugar de examinar qué servicios se ven afectados y por qué rutas.
El grafo del Lab 15 es binario (necesita / no necesita); las dependencias reales tienen modos degradados y temporizadores (una credencial en caché funciona durante horas; un reloj deriva lentamente).
Enumerar solo las dependencias directas y pasar por alto el hipervisor que hay bajo el directorio.
Dejar gps-clock sin un responsable nombrado, aunque el Lab 15 muestra que de él dependen tanto el telecontrol de la red eléctrica como la telemetría del agua.
Suponer sin comprobarlo que un operador de telecomunicaciones aísla las redes privadas de sus clientes.
Clasificar esx-03 por sus siete dependientes en lugar de señalar que es el único activo que comparten los tres servicios.

Ejercicios — capítulo 15

EX057 — Las rutas importan. Objetivo: trazar una ruta de impacto. Entradas: el Lab 15. Pasos: modifique el programa para que imprima, para esx-03, una ruta de dependencia desde él hasta cada servicio afectado. Evidencia esperada: código y tres rutas. Rúbrica: 3 = por ejemplo, esx-03 → fep-01 → grid-ss3-telecontrol; esx-03 → ad-ops → scada-01 → water-telemetry; esx-03 → ad-ops → bms-server → hospital-bms; explica que un segundo directorio en otro servidor rompe dos de las tres; 2 = rutas sin interpretación; 1 = intentado; 0 = nada.

EX058 — Nuevos componentes compartidos. Objetivo: realizar la actividad. Entradas: la actividad 15.5. Pasos: ejecútela e interprétela. Evidencia esperada: salida y dos cambios técnicos. Rúbrica: 3 = power-ups-a y esx-03 compartidos por los tres (y cell-carrier afectando al agua y a la red eléctrica); cambios como alimentaciones de SAI separadas para los dos servidores y un segundo operador o una ruta de radio para las estaciones más críticas; 2 = solo la salida; 1 = parcial; 0 = nada.

EX059 — Prueba en modo degradado. Objetivo: probar el comportamiento cuando falla una dependencia. Entradas: ad-ops no disponible. Pasos: redacte un plan de prueba delimitado, en una ventana de mantenimiento, para establecer si los operadores pueden seguir iniciando sesión en la HMI y si continúa el sondeo del SCADA. Evidencia esperada: plan de prueba con condiciones de parada. Rúbrica: 3 = probar primero en una réplica de reserva o de laboratorio; en producción, bloquear solo la ruta de la HMI hacia el directorio durante una ventana breve con operaciones presente; comprobar los inicios de sesión en caché, las cuentas locales de emergencia y la continuidad del sondeo; condiciones de parada; evidencia; 2 = sin el paso de la réplica; 1 = «apagar el controlador de dominio»; 0 = nada.

EX060 — Sentido de la exportación. Objetivo: configurar correctamente un límite. Entradas: actualmente, el servidor corporativo de informes inicia sesión cada noche en hist-02 con una contraseña guardada para extraer el CSV. Pasos: rediséñelo y enumere los cambios de configuración en ambos equipos y en fw-01. Evidencia esperada: diseño y cambios. Rúbrica: 3 = hist-02 envía por HTTPS a un único punto de destino; se elimina la credencial corporativa dentro de Z2; se invierte el sentido de la regla de fw-01 (solo Z2 → Z6, equipo y puerto específicos); se comprueba la integridad del envío (resumen en la carga útil o archivo firmado); supervisión de los envíos fallidos; 2 = envío sin eliminar la credencial antigua; 1 = vago; 0 = nada.

Síntesis del capítulo

Los servicios fallan a través de aquello de lo que dependen, y las dependencias más peligrosas son las compartidas que ningún responsable reclama. Modele las dependencias como un grafo, recórralo hacia atrás desde cada componente y examine las rutas, no solo los recuentos. Trate cada punto de integración (routers de estación, operadores de telecomunicaciones, pasarelas de proveedores, exportaciones, directorio y hora) como un límite sujeto a la misma disciplina de control, cambio y supervisión que el cortafuegos.

Siga estudiando — capítulo 15 de 18

← Capítulo 14 · Índice de capítulos del curso · Capítulo 16 →

Continúe con la siguiente lección escrita.