Capítulo 13 — Infraestructura crítica y seguridad sectorial: escenarios de riesgo
Mapa de la lección
Lección 13 publicada. Mapa, ejemplo, EX037.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["13.1 Escenarios, no categorías"]
N2["13.2 Primero la consecuencia"]
N3["13.3 Controles existentes y riesgo residual"]
N4["13.4 De los escenarios al trabajo"]
N5["13.6 Actividad práctica: ordenación de escenarios"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX037"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["13.1 Escenarios, no categorías"]
N2["13.2 Primero la consecuencia"]
N3["13.3 Controles existentes y riesgo residual"]
N4["13.4 De los escenarios al trabajo"]
N5["13.6 Actividad práctica: ordenación de escenarios"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX037"]
[Resultados de aprendizaje y conexión]
|
v
[13.1 Escenarios, no categorías]
|
v
[13.2 Primero la consecuencia]
|
v
[13.3 Controles existentes y riesgo residual]
|
v
[13.4 De los escenarios al trabajo]
|
v
[13.6 Actividad práctica: ordenación de escenarios]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX037]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- redactar un escenario de riesgo como una historia concreta: causa, camino, activo afectado, consecuencia para las personas y controles existentes;
- asignar franjas de consecuencia y de probabilidad con motivos explícitos, midiendo la consecuencia en personas y tiempo;
- ordenar los escenarios primero por consecuencia cuando interviene la seguridad física, y explicar por qué el producto probabilidad × consecuencia puede inducir a error;
- convertir los escenarios principales en trabajo de implementación con responsables.
La evaluación de riesgos puede hacerse con muchos niveles de profundidad; la guía del NIST describe un proceso completo para las organizaciones (NIST SP 800-30 Rev. 1). Este capítulo enseña la versión del implementador: redactar escenarios lo bastante precisos para que un tecnólogo pueda construir, probar y monitorizar los controles que implican.
13.1 Escenarios, no categorías
«Ransomware» es una categoría. Un escenario es: «Un ransomware entregado mediante un correo de phishing cifra HIST-01; los datos de las estaciones siguen llegando al retransmisor, que los almacena; los operadores pierden las pantallas de tendencias y los informes semanales de cumplimiento hasta que se restaura el historiador». Un buen escenario nombra la causa, el camino, el activo afectado, la consecuencia para las personas y el servicio, y los controles existentes. Así puede probarse («¿de verdad almacena el retransmisor? ¿durante cuánto tiempo?») y monitorizarse. R2 supera la prueba: credencial de proveedor robada, acceso remoto del proveedor, el punto de consigna de dosificación de PS-07, un cambio de cloro en el agua que bebe la gente.
13.2 Primero la consecuencia
La consecuencia describe lo que les ocurre a las personas: cuántas, durante cuánto tiempo y si alguien podría sufrir daños. Una clasificación por franjas sencilla usa personas × horas de interrupción, y cualquier efecto creíble sobre la seguridad física se sitúa en la franja más alta sean cuales sean las cifras. La probabilidad es una franja de juicio (de 1 a 5) basada en la exposición, las amenazas conocidas y el historial. Escriba el motivo de cada franja; una franja sin motivo no puede rebatirse.
Muchos registros ordenan por el producto probabilidad × consecuencia. El producto es cómodo y peligroso: trata como iguales una molestia frecuente y una catástrofe rara si los productos coinciden, y deja que un problema visto a menudo pero recuperable supere a un escenario de seguridad física. Cuando la seguridad física está en juego, ordene primero por consecuencia y después por probabilidad dentro de la franja; use el producto, si acaso, solo dentro de una misma franja de consecuencia. Los métodos basados en la consecuencia desarrollados para la infraestructura crítica adoptan la misma perspectiva: partir de los resultados que no deben ocurrir (INL CCE).
13.3 Controles existentes y riesgo residual
Para cada escenario, registre los controles que ya lo reducen y si se han probado (capítulo 23). Un control sin probar es una esperanza, y no debería rebajar mucho la franja. El riesgo residual (lo que queda después de los controles) necesita un responsable que lo haya aceptado, identificado por su función, con una fecha de revisión. Para R1, el ransomware en el historiador, el control clave es que el retransmisor almacene los datos de las estaciones mientras HIST-01 está caído. Mientras ese almacenamiento no se haya probado deteniendo el historiador a propósito y comprobando cuántas horas aguanta el retransmisor, es una esperanza, y la franja baja de R1 descansa en ella. El responsable del riesgo residual de R1 sería Operaciones de Agua, porque los informes de cumplimiento son suyos.
13.4 De los escenarios al trabajo
El valor del registro es el trabajo que produce. Para cada uno de los escenarios principales, enumere las tareas de implementación que reducirían la consecuencia o la probabilidad, y la monitorización que lo detectaría mientras ocurre. Un registro que no produce tareas es un documento; uno que produce tareas con responsables es un plan. Para R3, el llenado del disco del retransmisor, el trabajo es concreto: averiguar qué conserva los datos de RLY-01 más allá de 30 días, configurar una alerta de disco antes de la alarma del 85 % y probar el comportamiento del búfer cuando el disco está lleno. Para R2, son los controles de la cuenta del proveedor y la alerta de cloro fuera de banda que aparecen como fichas de control en el capítulo 18.
13.5 Ejemplo resuelto: seis escenarios de Fallowmere (sintético)
El Lab 13 ordena seis escenarios. Dos llevan la marca de seguridad física (una credencial de proveedor robada que se usa para cambiar el punto de consigna de dosificación de PS-07, R2, y una caída de la pasarela clínica que impide actualizar la biblioteca de fármacos de las bombas de infusión, R4) y pasan a la franja de consecuencia 5. Ordenados primero por consecuencia, R2 y R4 van en cabeza, seguidos del llenado del disco del retransmisor (R3) y del corte del operador de telecomunicaciones (R6). Ordenados por el producto, R3 (16) y R6 (12) superan a ambos escenarios de seguridad física (10 cada uno). La ordenación por producto enviaría el esfuerzo del próximo trimestre a la capacidad de disco: útil, pero no donde es posible el daño a las personas.
Fíjese también en R1, el ransomware en el historiador, al final con consecuencia 1. Eso refleja el diseño: la telemetría y el control continúan sin el historiador. No es un motivo para ignorar R1 (los informes de cumplimiento y las investigaciones dependen del historiador), sino un motivo para confiar en la propiedad de diseño del capítulo 8, siempre que se haya probado el almacenamiento del retransmisor.
R2 merece una nota. LANTERN no transporta órdenes, así que el camino de R2 no pasa por LANTERN. Pasa por el acceso remoto del proveedor al sistema de control. El registro de riesgos de un tecnólogo debería incluir escenarios que el servicio no causa, pero que debe detectar o apoyar: la telemetría de LANTERN es la forma en que los operadores advertirían un cambio inesperado de dosificación.
13.6 Actividad práctica: ordenación de escenarios
Lab 13 (guárdelo como lab13.py y ejecútelo con python3 lab13.py):
# Lab 13 - a small risk-scenario register ranked by consequence first (offline, standard library only)
# Synthetic: Fallowmere scenarios. Likelihood band 1-5 (judgement), consequence in service units.
scenarios = [ # id, scenario, likelihood band, people affected, hours of disruption, safety flag
("R1", "Ransomware encrypts historian; station data still reaches relay", 3, 0, 0, False),
("R2", "Stolen vendor credential used to change PS-07 dosing setpoint", 2, 41000, 24, True),
("R3", "Relay disk fills; telemetry dropped for remote stations", 4, 41000, 6, False),
("R4", "Clinical gateway outage stops infusion-pump library updates", 2, 300, 72, True),
("R5", "Depot kiosk defaced", 4, 0, 2, False),
("R6", "Upstream carrier outage isolates 6 stations", 3, 18000, 8, False),
]
def consequence_band(people, hours, safety):
ph = people * hours
band = 1 if ph == 0 else 2 if ph < 10_000 else 3 if ph < 100_000 else 4 if ph < 1_000_000 else 5
return 5 if safety else band # any credible safety effect goes to the top band
rows = []
for sid, text, lik, people, hours, safety in scenarios:
c = consequence_band(people, hours, safety)
rows.append((c, lik, sid, text, c * lik))
print("ranked by consequence, then likelihood:")
for c, lik, sid, text, prod in sorted(rows, key=lambda r: (-r[0], -r[1])):
print(f" {sid} C{c} L{lik} CxL={prod:>2} {text}")
print("ranked by CxL product only:")
print(" " + " ".join(sid for c, lik, sid, text, prod in sorted(rows, key=lambda r: -r[4])))
Salida esperada (Python 3.13.5):
ranked by consequence, then likelihood:
R2 C5 L2 CxL=10 Stolen vendor credential used to change PS-07 dosing setpoint
R4 C5 L2 CxL=10 Clinical gateway outage stops infusion-pump library updates
R3 C4 L4 CxL=16 Relay disk fills; telemetry dropped for remote stations
R6 C4 L3 CxL=12 Upstream carrier outage isolates 6 stations
R5 C1 L4 CxL= 4 Depot kiosk defaced
R1 C1 L3 CxL= 3 Ransomware encrypts historian; station data still reaches relay
ranked by CxL product only:
R3 R6 R2 R4 R5 R1
Ejecútelo y compare las dos ordenaciones. Ordenados primero por consecuencia, R2 y R4 van en cabeza porque ambos llevan la marca de seguridad física en la franja 5. Ordenados por producto, R3 con 16 y R6 con 12 los adelantan, y R1 queda al final en ambos casos. Después cambie un dato de entrada que considere incierto, como la probabilidad de R2, y vea si desplaza a R2 por debajo de R3. Si la ordenación por consecuencia resiste su cambio y la ordenación por producto no, ese es el argumento que debe presentar a quienes asignan el trabajo del próximo trimestre.
13.7 Errores frecuentes y límites
- Redactar categorías en lugar de escenarios.
- Franjas sin motivos.
- Ordenar por producto cuando interviene la seguridad física.
- Rebajar la probabilidad por controles que nunca se han probado.
- Riesgo residual sin responsable.
- Dejar fuera escenarios ajenos a su sistema que su sistema debe detectar.
Las franjas son juicios. Su valor está en que hacen el razonamiento explícito y comparable, no en que midan el riesgo con precisión. El Lab 13 muestra el tercer error: ordenar por producto pone la capacidad de disco por encima de la dosificación de cloro.
Dejar fuera R2 porque LANTERN no transporta órdenes sería el sexto error: la telemetría de LANTERN es la forma en que los operadores advierten un cambio inesperado de dosificación.
Ejercicios — capítulo 13
EX037 — Redacte dos escenarios. Objetivo: redactar escenarios que puedan probarse. Entradas: el diseño de LANTERN de los capítulos 2 y 8. Restricciones: cada uno debe nombrar causa, camino, activo, consecuencia (personas y tiempo) y controles existentes. Pasos: redacte un escenario sobre el operador BayTel y otro sobre el servidor de salto de FSTS. Evidencia esperada: dos escenarios de 80 a 120 palabras. Rúbrica: 3 = concretos, comprobables, con consecuencias en personas y tiempo y controles nombrados con su estado de prueba; 2 = un elemento vago; 1 = categorías; 0 = nada.
EX038 — Producto frente a consecuencia. Objetivo: explicar a un directivo una decisión de ordenación. Entradas: la salida del Lab 13. Restricciones: 150 palabras; sin jerga. Pasos: explique por qué R2 y R4 deberían abordarse antes que R3 aunque R3 puntúe más por producto, y qué sigue necesitando R3. Evidencia esperada: párrafo. Rúbrica: 3 = argumento claro sobre el posible daño a las personas, la irrecuperabilidad y el defecto del producto de dar el mismo peso a todo; reconoce que R3 sigue necesitando una acción de capacidad (capítulo 1) y que es barato de corregir; 2 = argumento parcial; 1 = solo «primero la seguridad»; 0 = nada.
EX039 — Del escenario al trabajo. Objetivo: producir tareas de implementación. Entradas: R2 (credencial de proveedor usada para cambiar un punto de consigna de dosificación). Restricciones: tareas que FSTS o Agua puedan ejecutar; cada una con responsable y evidencia de que se completó. Pasos: enumere tres tareas de prevención o reducción y dos de detección. Evidencia esperada: tabla. Rúbrica: 3 = por ejemplo, acceso de proveedor limitado en el tiempo con MFA (capítulo 7), registro de sesiones, límites de los puntos de consigna del PLC diseñados por Agua, alerta de telemetría ante un cambio de cloro o de dosificación fuera de una ventana aprobada y comparación de los valores de los puntos de consigna con una línea base aprobada; responsables y evidencia nombrados; 2 = tareas genéricas; 1 = menos de tres; 0 = nada.
Síntesis del capítulo
Redacte los riesgos como escenarios concretos (causa, camino, activo, consecuencia y controles) para que puedan probarse y monitorizarse. Mida la consecuencia en personas y tiempo, sitúe arriba los efectos creíbles sobre la seguridad física y ordene primero por consecuencia; el producto probabilidad × consecuencia puede hacer que las molestias superen al daño. Asigne un responsable al riesgo residual, incluya los escenarios que su servicio debe detectar y convierta el registro en tareas.
Siga estudiando — capítulo 13 de 30
← Capítulo 12 · Índice de capítulos del curso · Capítulo 14 →
Continúe con la siguiente lección escrita.