Capítulo 5 — Infraestructura crítica y seguridad sectorial: alternativas de diseño | Posgrado 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.

Mapa de la lección

Lección 05 publicada. Mapa, ejemplo, EX021.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["5.1 Partir de la consecuencia"]
  N2["5.2 Principios que generan alternativas"]
  N3["5.3 Los diseños como grafos"]
  N4["5.4 Los diseños como sistemas operables"]
  N5["5.6 Actividad práctica: rutas y puntos de estrangula"]
  N6["5.7 Elegir y registrar"]
  N7["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX021"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["5.1 Partir de la consecuencia"]
  N2["5.2 Principios que generan alternativas"]
  N3["5.3 Los diseños como grafos"]
  N4["5.4 Los diseños como sistemas operables"]
  N5["5.6 Actividad práctica: rutas y puntos de estrangula"]
  N6["5.7 Elegir y registrar"]
  N7["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]

[Resultados de aprendizaje y conexión]
    |
    v
[5.1 Partir de la consecuencia]
    |
    v
[5.2 Principios que generan alternativas]
    |
    v
[5.3 Los diseños como grafos]
    |
    v
[5.4 Los diseños como sistemas operables]
    |
    v
[5.6 Actividad práctica: rutas y puntos de estrangula]
    |
    v
[5.7 Elegir y registrar]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX021]

Resultados de aprendizaje y conexión

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

Generar alternativas de arquitectura realmente distintas para un problema de seguridad en un servicio esencial, partiendo de las consecuencias y no de los productos.
Representar las alternativas como grafos de rutas permitidas y compararlas por sus rutas, sus puntos de estrangulamiento y las barreras de cada ruta.
Evaluar cada alternativa como un sistema operable: los modos de fallo de los propios controles de seguridad, el acceso de emergencia, la mantenibilidad y el personal que debe operarlo.
Combinar la evidencia de seguridad, operabilidad y coste en una recomendación, usando los métodos de decisión de los capítulos 1 y 4.
Dejar constancia de la elección en un registro de decisión de arquitectura.

El capítulo 4 cuantificó el riesgo; este capítulo muestra dónde lo cambian las decisiones de diseño. Después, el capítulo 6 comprueba si un diseño elegido funciona como se afirma.

5.1 Partir de la consecuencia

Las revisiones de arquitectura suelen partir de un producto («¿deberíamos comprar un diodo de datos?») o de un patrón («necesitamos confianza cero»). Un especialista parte de la consecuencia que debe evitarse y trabaja hacia atrás hasta las rutas digitales que podrían causarla. La ingeniería impulsada por las consecuencias e informada por la ciberseguridad, desarrollada en el Idaho National Laboratory, formaliza este enfoque: identificar las funciones cuyo fallo sería intolerable, mapear los sistemas y las dependencias que podrían causarlo y elegir mitigaciones de ingeniería (incluidas las no digitales, como los límites mecánicos) que eliminen o acoten la consecuencia (INL, CCE; Bochman and Freeman, 2021). En la planta de Hollin de Merrow Water, la consecuencia intolerable es que una dosis de cloro no segura llegue a los clientes; la pregunta de diseño es cómo debería funcionar el acceso remoto al controlador de dosificación, si es que debe existir.

La mitigación no digital merece el primer lugar en el conjunto de opciones. Una bomba dosificadora dimensionada de modo que físicamente no pueda superar una dosis segura, o un analizador independiente que dispare la dosificación en un límite estricto, acota la consecuencia pase lo que pase en la red. Después se eligen los controles digitales para reducir la frecuencia de los intentos sobre lo que queda.

5.2 Principios que generan alternativas

Los principios de diseño clásicos siguen generando buenas alternativas: economía del mecanismo, valores por defecto a prueba de fallos, mediación completa y mínimo privilegio (Saltzer and Schroeder, 1975). La IEC 62443 los aplica a los sistemas de control mediante zonas (grupos de activos con requisitos de seguridad comunes) y conductos (la comunicación controlada entre zonas) (ISA overview). La arquitectura de confianza cero traslada la aplicación de las políticas de la ubicación en la red a decisiones por sesión basadas en la identidad, el dispositivo y el contexto (NIST SP 800-207). La ingeniería de ciberresiliencia añade técnicas (segmentación, no persistencia, diversidad, redundancia, integridad fundamentada) orientadas a seguir operando a pesar del compromiso, y no solo a evitarlo (NIST SP 800-160 Vol. 2 Rev. 1). Cada principio apunta a un diseño distinto; usar varios de forma deliberada produce alternativas que difieren en su naturaleza.

5.3 Los diseños como grafos

Una representación sencilla y potente: los nodos son sistemas, las aristas dirigidas son conexiones permitidas y cada arista lleva la barrera que un intruso debe superar para usarla. Tres medidas permiten entonces comparar diseños:

Número de rutas desde puntos de entrada plausibles hasta el activo que soporta la consecuencia. Menos es mejor, pero solo junto con la siguiente medida.
Conjunto mínimo de puntos de estrangulamiento: el menor número de nodos cuya eliminación (o defensa perfecta) corta todas las rutas. Un único punto de estrangulamiento fuerte es más fácil de defender, monitorizar y evidenciar que varios débiles; también es un punto único de fallo para las operaciones legítimas (§5.4).
Fuerza de las barreras a lo largo de cada ruta: una ruta cuyas aristas posteriores a la entrada inicial no llevan ninguna barrera ("none") permite que un punto de apoyo se convierta en control.

El grafo debe incluir las rutas inesperadas que contienen los entornos reales: conexiones del historiador, enlaces de copia de seguridad, módems de proveedores, agentes de monitorización en la nube. Muchas debilidades de arquitectura no están en el diseño previsto, sino en la ruta que alguien añadió después por comodidad. El análisis de grafos no demuestra la seguridad; hace explícitos y contables los supuestos.

5.4 Los diseños como sistemas operables

Un diseño seguro sobre el papel puede hacer fracasar las operaciones. Para cada alternativa, pregunte:

¿Qué ocurre cuando falla el control de seguridad? Si el intermediario de acceso está caído durante una emergencia nocturna, ¿cómo llega un ingeniero al controlador? Debe existir y probarse una ruta de acceso de emergencia (credenciales selladas, presencia física, una vía de emergencia grabada y con alarma); si no, los operadores construirán la suya.
¿Quién lo opera? Un diseño que necesita competencias que la organización no tiene, o un proveedor al que no puede exigir responsabilidades, se degradará.
¿Cómo se modifica? Cada excepción a una regla es una arista nueva en el grafo; los diseños que facilitan el trabajo legítimo reducen la presión para crear excepciones.
¿Cuánto cuesta a lo largo de su vida? Licencias, personal, pruebas, renovaciones.
¿Qué efecto tiene sobre la monitorización? Los flujos de datos unidireccionales pueden proteger una red de control y, aun así, permitir que el negocio vea los datos del proceso; también limitan el diagnóstico remoto.

5.5 Ejemplo resuelto: tres diseños de acceso remoto en Hollin (sintético)

Merrow Water tiene tres diseños candidatos para el acceso remoto a la red de control de Hollin:

D1 VPN plana: la configuración actual; la VPN de proveedores y personal llega directamente a la red de control; el historiador es accesible desde la red corporativa.
D2 VPN más servidor de salto: MFA en la VPN; todo el acceso interactivo a través de un servidor de salto bastionado; el historiador se traslada a una DMZ.
D3 acceso intermediado con historiador unidireccional: acceso remoto solo a través de un intermediario de acceso que exige MFA y aprobación por sesión, con sesiones grabadas y limitadas en el tiempo, que llegan a una única estación de trabajo de ingeniería; el historiador se replica hacia la DMZ a través de un enlace unidireccional; el interruptor de llave del controlador de dosificación se deja en RUN, lo que (en este controlador sintético) bloquea las descargas de programas.

Se modelan dos puntos de entrada: internet y un correo de phishing que llega a un PC corporativo.

5.6 Actividad práctica: rutas y puntos de estrangulamiento

# Lab 5 - comparing three remote-access architectures as graphs (offline, standard library only)
# Synthetic: paths from the internet to the dosing PLC at Merrow Water's Hollin works under three designs.
# An edge is a permitted connection; its label is what an intruder must defeat to use it.
from itertools import combinations
DESIGNS = {
 "D1 flat VPN": {
   "internet": [("vpn", "password")],
   "vpn": [("hmi", "none"), ("eng-ws", "none"), ("historian", "none")],
   "corp-pc": [("vpn", "none"), ("historian", "password")],
   "eng-ws": [("plc", "none")], "hmi": [("plc", "none")], "historian": [("hmi", "none")],
   "email": [("corp-pc", "user click")], "plc": []},
 "D2 VPN + jump host": {
   "internet": [("vpn", "MFA")],
   "vpn": [("jump", "password")], "corp-pc": [("jump", "password"), ("historian-dmz", "password")],
   "jump": [("hmi", "password"), ("eng-ws", "password")],
   "historian-dmz": [("historian", "none")], "historian": [("hmi", "none")],
   "eng-ws": [("plc", "none")], "hmi": [("plc", "none")], "email": [("corp-pc", "user click")], "plc": []},
 "D3 brokered access + one-way historian": {
   "internet": [("broker", "MFA + per-session approval")],
   "broker": [("eng-ws", "recorded session, time-boxed")],
   "corp-pc": [("broker", "MFA + per-session approval")],
   "historian": [("historian-dmz", "one-way")],  # data leaves OT only; nothing flows back
   "eng-ws": [("plc", "PLC key switch in RUN blocks writes")], "hmi": [("plc", "none")],
   "email": [("corp-pc", "user click")], "historian-dmz": [], "plc": []},
}
ENTRY, TARGET = ["internet", "email"], "plc"
def paths(g, node, seen):
    if node == TARGET: yield [node]; return
    for nxt, _ in g.get(node, []):
        if nxt not in seen:
            for rest in paths(g, nxt, seen | {nxt}): yield [node] + rest
def reachable(g, removed):
    stack = [e for e in ENTRY if e not in removed]; seen = set(stack)
    while stack:
        n = stack.pop()
        for nxt, _ in g.get(n, []):
            if nxt not in seen and nxt not in removed: seen.add(nxt); stack.append(nxt)
    return TARGET in seen
for name, g in DESIGNS.items():
    ps = [p for e in ENTRY for p in paths(g, e, {e})]
    inner = sorted({n for n in g if n not in ENTRY + [TARGET]})
    cut = next(c for k in range(1, len(inner) + 1) for c in combinations(inner, k) if not reachable(g, set(c)))
    free = [p for p in ps if all(lbl == "none" for a, b in zip(p, p[1:]) for nxt, lbl in g[a] if nxt == b and a not in ENTRY)]
    print(f"{name}: {len(ps)} paths; smallest chokepoint set {list(cut)}; "
          f"paths with no barrier after the first hop: {len(free)}")
    for p in ps:
        bars = [lbl for a, b in zip(p, p[1:]) for nxt, lbl in g[a] if nxt == b]
        print("   ", " -> ".join(p), "|", ", ".join(bars))

Salida esperada:

D1 flat VPN: 7 paths; smallest chokepoint set ['corp-pc', 'vpn']; paths with no barrier after the first hop: 6
    internet -> vpn -> hmi -> plc | password, none, none
    internet -> vpn -> eng-ws -> plc | password, none, none
    internet -> vpn -> historian -> hmi -> plc | password, none, none, none
    email -> corp-pc -> vpn -> hmi -> plc | user click, none, none, none
    email -> corp-pc -> vpn -> eng-ws -> plc | user click, none, none, none
    email -> corp-pc -> vpn -> historian -> hmi -> plc | user click, none, none, none, none
    email -> corp-pc -> historian -> hmi -> plc | user click, password, none, none
D2 VPN + jump host: 5 paths; smallest chokepoint set ['corp-pc', 'jump']; paths with no barrier after the first hop: 0
    internet -> vpn -> jump -> hmi -> plc | MFA, password, password, none
    internet -> vpn -> jump -> eng-ws -> plc | MFA, password, password, none
    email -> corp-pc -> jump -> hmi -> plc | user click, password, password, none
    email -> corp-pc -> jump -> eng-ws -> plc | user click, password, password, none
    email -> corp-pc -> historian-dmz -> historian -> hmi -> plc | user click, password, none, none, none
D3 brokered access + one-way historian: 2 paths; smallest chokepoint set ['broker']; paths with no barrier after the first hop: 0
    internet -> broker -> eng-ws -> plc | MFA + per-session approval, recorded session, time-boxed, PLC key switch in RUN blocks writes
    email -> corp-pc -> broker -> eng-ws -> plc | user click, MFA + per-session approval, recorded session, time-boxed, PLC key switch in RUN blocks writes

Interpretación. D1 tiene siete rutas; en seis de ellas nada se interpone entre el primer punto de apoyo y el controlador. Su conjunto mínimo de puntos de estrangulamiento es de dos nodos. D2 elimina todas las rutas sin barreras y añade MFA, pero el grafo revela un defecto que el documento de diseño no mencionaba: la ruta corp-pc → historian-dmz → historian → hmi → plc. Trasladar el historiador a una DMZ dejando una conexión desde la DMZ hacia el historiador de la zona de control recrea una ruta que rodea el servidor de salto. Es exactamente el tipo de arista de conveniencia contra el que advertía el §5.3; el EX021 lo corrige. D3 tiene dos rutas, ambas a través de un único punto de estrangulamiento (el intermediario), y cada una cruza varias barreras fuertes. Por motivos de seguridad, D3 es claramente la mejor.

Por motivos de operabilidad, el único punto de estrangulamiento de D3 es también su debilidad. Si el intermediario o su proveedor de identidad fallan durante una emergencia, no existe ninguna ruta remota; por tanto, el diseño necesita una ruta de acceso de emergencia probada, que es a su vez una arista nueva que hay que modelar y proteger. La barrera del interruptor de llave solo es real si los procedimientos operativos mantienen los interruptores en RUN y si una visita al emplazamiento es aceptable para los cambios de programa. Una recomendación completa añadiría estos elementos al coste y al grafo.

5.7 Elegir y registrar

Reúna la evidencia con los métodos del capítulo 1: una tabla de escenarios para cada diseño (incidentes evitados, costes operativos de un acceso más lento, escenarios de caída del intermediario) y la comprobación distributiva del capítulo 4 (¿hace un diseño más difícil dar soporte a los emplazamientos remotos?). Después, redacte un registro de decisión de arquitectura (ADR): el contexto, la consecuencia que se aborda, las alternativas consideradas con sus grafos, la decisión, las consecuencias (incluidos los riesgos nuevos, como la dependencia del intermediario), el diseño del acceso de emergencia, la evidencia que mostrará que el diseño funciona (capítulo 6) y un desencadenante de revisión. Un ADR es un registro de decisión (§1.8) especializado en diseños; su valor está en que el próximo ingeniero que quiera añadir una arista cómoda pueda ver por qué no estaba ahí.

5.8 Errores comunes y límites

Partir de un producto o de un eslogan en lugar de la consecuencia.
Omitir las mitigaciones no digitales que acotan directamente la consecuencia.
Dibujar el diseño previsto y pasar por alto las rutas añadidas después.
Contar controles en lugar de examinar las barreras a lo largo de cada ruta.
Celebrar un único punto de estrangulamiento sin diseñar para su fallo.
Ignorar quién operará el diseño y cómo se gestionarán las excepciones.
No redactar ningún registro de decisión, de modo que el siguiente cambio deshace el diseño sin que nadie lo note.

Los grafos solo son tan completos como el inventario que los sustenta, y las etiquetas de las barreras son juicios sobre su fuerza, no mediciones. Úselos para comparar diseños y exponer supuestos, y después pruebe el diseño elegido (capítulo 6).

Ejercicios — capítulo 5

EX021 — Corrija D2. Objetivo: eliminar una ruta no prevista y volver a evaluar. Entradas: el Lab 5. Restricciones: cambie solo los enlaces del historiador en D2, de modo que los datos fluyan en un solo sentido desde el historiador de la zona de control hacia la copia de la DMZ, como en D3. Pasos: (1) edítelo y vuelva a ejecutarlo; (2) informe de las rutas y del conjunto mínimo de puntos de estrangulamiento de D2; (3) compare D2 corregida con D3 en dos frases. Evidencia esperada: edición, salida y comparación. Rúbrica: 3 = edición correcta, D2 tiene ahora cuatro rutas con el punto de estrangulamiento jump, la comparación señala los saltos de D2 que siguen dependiendo solo de contraseñas frente a la aprobación por sesión y la grabación de D3; 2 = números correctos, comparación pobre; 1 = no ejecutado; 0 = nada.

EX022 — Una arista nueva. Objetivo: evaluar una propuesta de conveniencia. Entradas: D3; Corvane propone un agente de monitorización en la nube en la estación de trabajo de ingeniería que mantiene una conexión saliente con la nube de Corvane «para diagnósticos». Restricciones: modélelo como una arista internet → eng-ws con la barrera "vendor cloud account". Pasos: (1) añada la arista y vuelva a ejecutarlo; (2) informe de las rutas y de los puntos de estrangulamiento; (3) proponga una alternativa que cubra la necesidad de diagnóstico. Evidencia esperada: salida y propuesta. Rúbrica: 3 = reconoce que el conjunto de puntos de estrangulamiento cambia porque ahora una ruta elude el intermediario, propone una alternativa (por ejemplo, diagnósticos exportados a través del historiador unidireccional, o el agente en un equipo de la DMZ), indica el riesgo residual; 2 = salida correcta, alternativa débil; 1 = acepta la arista porque, al ser solo saliente, sería segura; 0 = nada.

EX023 — Diseño del acceso de emergencia. Objetivo: diseñar para el fallo del punto de estrangulamiento. Entradas: D3. Restricciones: debe funcionar cuando el intermediario y el proveedor de identidad están caídos; no debe convertirse en una ruta habitual. Pasos: (1) diseñe la ruta de acceso de emergencia; (2) añádala al grafo; (3) especifique las alarmas, los registros y la frecuencia de las pruebas. Evidencia esperada: diseño y lista de rutas actualizada. Rúbrica: 3 = ruta física o con credenciales selladas, con alarmas y revisión tras cada uso, modelada como una arista con su barrera, probada según un calendario; 2 = sin pruebas; 1 = contraseña compartida permanente; 0 = nada.

EX024 — Elija con evidencia. Objetivo: combinar la seguridad y la operabilidad. Entradas: D1, D2 corregida y D3 con acceso de emergencia; costes anuales sintéticos de 20.000 £, 70.000 £ y 110.000 £; su juicio sobre las pérdidas de cada escenario con el formato del capítulo 1. Restricciones: al menos tres escenarios, incluida una caída del intermediario durante una emergencia. Pasos: (1) construya la tabla; (2) aplique el VE y el minimax del arrepentimiento; (3) indique el umbral que cambiaría su recomendación. Evidencia esperada: tabla y recomendación. Rúbrica: 3 = escenarios plausibles que incluyen los inconvenientes operativos de D3, ambas reglas aplicadas correctamente, umbral explícito; 2 = solo una regla; 1 = solo seguridad; 0 = nada.

EX025 — Registro de decisión de arquitectura. Objetivo: dejar constancia de la elección de diseño. Entradas: su recomendación del EX024. Restricciones: una página; todos los elementos del §5.7. Pasos: redacte el ADR. Evidencia esperada: ADR. Rúbrica: 3 = contexto que parte de la consecuencia, alternativas con evidencia de los grafos, riesgos nuevos y acceso de emergencia, evidencia de verificación y desencadenante de revisión; 2 = falta un elemento; 1 = descripción de un producto; 0 = nada.

Síntesis del capítulo

Diseñe hacia atrás desde la consecuencia y ponga primero los límites no digitales. Use principios consolidados (mínimo privilegio, mediación completa, zonas y conductos, decisiones por sesión, técnicas de resiliencia) para generar alternativas que difieran en su naturaleza. Represente los diseños como grafos de rutas permitidas y compare las rutas, los puntos de estrangulamiento y las barreras, incluidas las aristas de conveniencia que acumulan los entornos reales. Evalúe cada diseño como un sistema operable y diseñe para el fallo de sus propios controles. Elija con los métodos de decisión de los capítulos anteriores y deje constancia de la elección en un ADR para que sobreviva a la próxima solicitud de cambio.