Capítulo 22 — Infraestructura crítica y seguridad sectorial: modelos de sistema y de datos

Mapa de la lección

Lección 22 publicada. Mapa, ejemplo, EX043.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["22.1 Primero, el inventario"]
  N2["22.2 Tres vistas de un sistema"]
  N3["22.3 Estados degradados"]
  N4["22.4 El modelo como información sensible"]
  N5["22.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX043"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["22.1 Primero, el inventario"]
  N2["22.2 Tres vistas de un sistema"]
  N3["22.3 Estados degradados"]
  N4["22.4 El modelo como información sensible"]
  N5["22.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX043"]

[Resultados de aprendizaje y conexión]
    |
    v
[22.1 Primero, el inventario]
    |
    v
[22.2 Tres vistas de un sistema]
    |
    v
[22.3 Estados degradados]
    |
    v
[22.4 El modelo como información sensible]
    |
    v
[22.6 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX043]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted podrá (1) construir un inventario de activos y un modelo del sistema que sirvan para el análisis de seguridad; (2) modelar las dependencias funcionales, los flujos de datos y las fronteras de confianza; (3) representar los estados degradados, no solo «funciona / no funciona»; y (4) mantener el modelo actualizado y protegido como información sensible. Se apoya en los capítulos 2, 13 y 21 y prepara el capítulo 23 (análisis de amenazas y fallas).

22.1 Primero, el inventario

No se puede proteger lo que no se conoce. Un inventario de activos de TO registra, para cada dispositivo: identidad, ubicación, función, zona, direcciones de red, versiones de hardware y de firmware, relaciones de comunicación, responsable, criticidad y estado del soporte. Constrúyalo a partir de varias fuentes y concílielas: documentos de diseño, monitoreo pasivo de la red, exportaciones de configuración y recorridos por los sitios. Cada fuente omite cosas: los documentos derivan, el monitoreo pasivo no ve los dispositivos silenciosos y los recorridos no ven los virtuales.

En LRWA, el inventario cubre las 42 estaciones de campo, el par SCADA y las pasarelas, y se construyó con los documentos de diseño, el monitoreo pasivo en el conmutador de control y en la cabecera LTE, y visitas a los sitios.

22.2 Tres vistas de un sistema

• Vista funcional: lo que hace el sistema (funciones como «mantener el nivel del depósito», «desinfectar», «dar visibilidad al operador») y qué funciones dependen de cuáles (el grafo del Lab 2).
• Vista física y de red: dónde están los activos y cómo se conectan: zonas, conductos, enlaces.
• Vista de flujos de datos: qué datos se mueven, hacia dónde, en qué dirección, con qué protección y a través de qué fronteras de confianza. Los diagramas de flujo de datos con fronteras de confianza son la entrada del modelado de amenazas (capítulo 23).

Mantenga las vistas enlazadas: cada función corresponde a los activos que la implementan; cada flujo corresponde a un conducto.

22.3 Estados degradados

Los grafos de «funciona / no funciona» son útiles (capítulo 2), pero insuficientes. Una estación de bombeo puede estar en automático remoto, automático local, manual local, degradada (una bomba de dos) o fuera de servicio; el depósito puede estar normal, bajo o por debajo del piso. Un modelo de estados para cada función crítica, con transiciones causadas por fallas, ataques y acciones de los operadores, permite preguntar: desde la operación normal, ¿qué secuencia de eventos lleva a un estado inaceptable y qué control la interrumpe?

PS4 es el primer candidato evidente en LRWA, porque abastece directamente al hospital.

22.4 El modelo como información sensible

Un modelo preciso del sistema es un mapa para un adversario. Guárdelo con control de acceso, versiónelo y publique solo abstracciones. Trate las exportaciones a proveedores y consultores mediante acuerdos. Mantenga un registro de cambios del modelo vinculado a la gestión de la configuración (capítulo 16) para que el modelo siga actualizado; un modelo con un año de retraso es un pasivo presentado como activo. El modelo de LRWA, incluidos el grafo de dependencias y las listas de permitidos de las zonas, se guarda con control de acceso y se versiona con cada cambio de configuración.

22.5 Ejemplo resuelto: modelo funcional de Hollin Hill (sintético)

La función F1, «abastecer a St Brenna's», se cumple si está disponible el camino A (PS4 directo) o el camino B (depósito de Hollin Hill alimentado por PS3), y el tanque propio del hospital cubre el hueco durante la conmutación. El camino A necesita PS4, su energía (alimentador F2 o generador) y su control (basta el automático local). El camino B necesita el depósito por encima del piso y PS3 con energía del alimentador F1. La telemetría no es necesaria para el suministro (el control automático local mantiene las bombas en marcha), pero sí para la visibilidad (F3) y la intervención remota. Esta idea cambia las prioridades: la propiedad de seguridad más importante para F1 es que nadie pueda ordenar a distancia a las bombas que entren en un estado inseguro, mientras que la pérdida de telemetría es un problema de visibilidad con una reserva de 72 h en automático local (R-local). El árbol de fallas del capítulo 23 formaliza exactamente esta estructura Y/O.

22.6 Actividad práctica

Amplíe el Lab 2 para que cada nodo tenga un tipo de dependencia Y u O, e implemente una función de disponibilidad que evalúe si hospital_supply funciona dado un conjunto de nodos fallidos. Pruebe con las fallas {grid_f1}, {ps4} y {ps4, grid_f1}. Modele el suministro del hospital como un O de sus dos caminos, con la energía de PS4 como un O del alimentador F2 y el generador. Deje la telemetría fuera de la función de suministro, como argumenta el ejemplo resuelto, pero manténgala en una función de visibilidad separada para que su pérdida siga apareciendo. Después contraste sus tres resultados con el EX043: el suministro debe sobrevivir a la pérdida del alimentador F1 o a la de PS4, y fallar solo cuando se pierden ambos.

22.7 Errores comunes y límites

• Inventario a partir de una sola fuente.
• Diagramas sin fronteras de confianza ni dirección de los datos.
• Modelos de «funciona / no funciona» cuando los modos degradados deciden el resultado.
• Modelos que nunca se actualizan o que se comparten libremente.
• Tratar la pérdida de telemetría y el uso indebido del control como la misma consecuencia.

El modelo de Hollin Hill muestra claramente el último error: tratar la pérdida de telemetría como pérdida de suministro enviaría el presupuesto del TMRP a la redundancia de comunicaciones, cuando la propiedad que realmente protege al hospital es que no se pueda ordenar a distancia a las bombas que entren en un estado inseguro.

Ejercicios — capítulo 22

EX043 — Evaluación Y/O. Objetivo: implementar y usar un modelo de dependencias mixto. Entradas: §22.6. Pasos: impleméntelo, ejecute las tres pruebas e informe los resultados. Evidencia esperada: código y salida. Rúbrica: 3 = semántica correcta; {grid_f1} → el suministro sobrevive gracias a PS4 si PS4 funciona en automático local (sin necesidad de LTE); {ps4} → sobrevive gracias al depósito; {ps4, grid_f1} → falla; 2 = se exige erróneamente la telemetría para el suministro; 1 = no ejecutado; 0 = nada.

EX044 — Modelo de estados. Objetivo: modelar los estados degradados. Entradas: los modos de PS4 de §22.3. Pasos: dibuje un modelo de estados con al menos cinco estados y los eventos (falla, ataque, acción del operador) entre ellos; identifique un camino desde automático remoto hasta fuera de servicio que un atacante remoto podría provocar, y el control que lo rompe. Evidencia esperada: tabla de estados y análisis. Rúbrica: 3 = estados y eventos coherentes, camino de ataque realista, el control lo rompe (p. ej., el rearme tras un disparo exige una acción local); 2 = solo estados; 1 = solo «funciona / no funciona»; 0 = nada.

Síntesis del capítulo

Construya el inventario a partir de varias fuentes conciliadas, modele el sistema en vistas funcional, física y de flujos de datos con fronteras de confianza, represente explícitamente los modos degradados y mantenga el modelo actualizado y protegido. Los buenos modelos separan la visibilidad del control y muestran qué propiedad protege realmente el servicio.