Capítulo 13 — Infraestructura crítica y seguridad sectorial: diagnóstico de averías
Mapa de la lección
Lección 13 publicada. Mapa, ejemplo, EX049.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["13.1 El método"]
N2["13.2 De la avería al incidente"]
N3["13.4 Segundo caso: el puesto corporativo en KW-04"]
N4["13.5 El registro de diagnóstico"]
N5["13.6 Actividad práctica"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX049"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["13.1 El método"]
N2["13.2 De la avería al incidente"]
N3["13.4 Segundo caso: el puesto corporativo en KW-04"]
N4["13.5 El registro de diagnóstico"]
N5["13.6 Actividad práctica"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX049"]
[Resultados de aprendizaje y conexión]
|
v
[13.1 El método]
|
v
[13.2 De la avería al incidente]
|
v
[13.4 Segundo caso: el puesto corporativo en KW-04]
|
v
[13.5 El registro de diagnóstico]
|
v
[13.6 Actividad práctica]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX049]
Resultados de aprendizaje y conexión
Al terminar este capítulo debería ser capaz de:
- aplicar un método estructurado de diagnóstico de averías: definir el síntoma, recoger observaciones de solo lectura, enumerar hipótesis, contrastar predicciones, conservar y, después, cambiar;
- descartar hipótesis comparando lo que predice cada una con lo que usted observó, de un modo que otros puedan comprobar;
- reconocer cuándo la investigación de una avería se convierte en un incidente de seguridad y qué conservar en ese momento;
- llevar un registro de diagnóstico que sea también evidencia.
El capítulo 8 describió los síntomas; los capítulos 7, 9 y 11 le dieron observaciones. Este capítulo las reúne bajo presión de tiempo, cuando una estación ha enmudecido y los operadores quieren recuperarla.
13.1 El método
- Defina el síntoma con precisión: qué etiqueta, desde cuándo (UTC), cómo se detectó, qué sigue funcionando.
- Recoja observaciones de solo lectura por orden de coste: el estado de las demás estaciones; los contadores del enlace y del router; los registros del cortafuegos; una prueba de conexión TCP desde el origen de sondeo habitual; una lectura del protocolo; los registros de configuración del dispositivo.
- Enumere hipótesis (al menos una corriente y otra relevante para la seguridad) antes de contrastar ninguna.
- Escriba las predicciones de cada hipótesis: ¿qué observaría si fuera cierta?
- Compare las predicciones con las observaciones. Una hipótesis contradicha por una observación fiable queda refutada; la que es coherente con todas se mantiene.
- Conserve todo lo que pueda ser evidencia antes de cambiarlo (capítulo 5).
- Cambie una sola cosa, con un registro de cambio, y verifique (capítulo 11).
- Registre la causa, la evidencia y lo que la habría detectado antes.
La disciplina de escribir las predicciones antes de comparar es lo que impide que el primer relato verosímil se convierta en la conclusión.
13.2 De la avería al incidente
Un ejercicio de diagnóstico se convierte en un posible incidente cuando una observación no se explica por ninguna actividad aprobada: una sesión de configuración no aprobada, un origen desconocido, un archivo modificado sin registro de cambio. En ese momento deje de cambiar cosas, conserve (configuración, registros, registros de sesiones) y traspase el asunto a través del proceso de incidentes. Las recomendaciones del NIST sobre respuesta a incidentes sitúan esta decisión dentro de la gestión de riesgos más amplia de la organización (SP 800-61 Rev. 3). La tarea del técnico no es decidir que hubo un ataque; es advertir que falta la explicación y mantener intacta la evidencia.
13.3 Ejemplo resuelto: KW-09 enmudece (sintético)
A las 07:05Z del 12 de octubre dejan de llegar las lecturas de KW-09; todas las demás estaciones funcionan. Usted recoge observaciones de solo lectura durante quince minutos y enumera cinco hipótesis. Lab 13 (guárdelo como lab13.py y ejecútelo con python3 lab13.py):
# Lab 13 - eliminate hypotheses for "KW-09 readings missing" (offline, standard library only)
# Synthetic observations collected read-only between 07:05 and 07:20Z on 2026-10-12.
observed = {
"rtu_ping": True, # RTU answers ICMP from the SCADA server
"tcp502_handshake": True, # TCP connect to 10.10.9.2:502 succeeds from SCADA server
"modbus_reply": "exception 2", # read of registers 0..3 returns illegal data address
"fw_denies": False, # no fw-01 denies for 10.10.9.2 in the window
"radio_errors": False, # cellular router CRC/error counters flat
"rtu_config_changed": True, # rtu-kw09 config session at 06:41Z (clock-corrected) by user eng
"change_ticket": False, # no approved change ticket for KW-09 today
"other_stations_ok": True,
}
hypotheses = { # what each hypothesis predicts we would observe
"H1 radio/link failure": {"rtu_ping": False, "tcp502_handshake": False, "radio_errors": True},
"H2 firewall change blocks polls": {"tcp502_handshake": False, "fw_denies": True},
"H3 SCADA server fault": {"other_stations_ok": False},
"H4 RTU register map changed": {"rtu_ping": True, "tcp502_handshake": True, "modbus_reply": "exception 2",
"rtu_config_changed": True},
"H5 RTU powered off": {"rtu_ping": False},
}
for h, pred in hypotheses.items():
clash = [k for k, v in pred.items() if observed[k] != v]
print(f"{h:<32} {'REFUTED by ' + ', '.join(clash) if clash else 'CONSISTENT with all observations'}")
print("unapproved RTU configuration session -> preserve RTU config and session logs, then treat as possible incident"
if observed["rtu_config_changed"] and not observed["change_ticket"] else "change was approved")
Salida esperada (Python 3.13.5):
H1 radio/link failure REFUTED by rtu_ping, tcp502_handshake, radio_errors
H2 firewall change blocks polls REFUTED by tcp502_handshake, fw_denies
H3 SCADA server fault REFUTED by other_stations_ok
H4 RTU register map changed CONSISTENT with all observations
H5 RTU powered off REFUTED by rtu_ping
unapproved RTU configuration session -> preserve RTU config and session logs, then treat as possible incident
Cuatro hipótesis quedan refutadas por observaciones concretas: el enlace está activo (ping, establecimiento de la conexión, contadores de errores planos); el cortafuegos no está denegando; el servidor SCADA sondea con éxito las demás estaciones; la RTU tiene alimentación. Una sigue siendo coherente: el mapa de registros de la RTU cambió, de modo que las lecturas del servidor SCADA apuntan ahora a direcciones que el dispositivo ya no tiene (excepción 02, exactamente como en el laboratorio del capítulo 12). Y la RTU registró una sesión de configuración a las 06:41Z (reloj corregido) sin incidencia de cambio.
Esta última observación convierte una avería en un posible incidente. Los pasos siguientes correctos son: conservar la exportación de la configuración actual de la RTU y su registro de sesiones, y los registros del servidor de salto y de la estación de ingeniería de 06:30–06:50Z; informar al jefe de turno de Kestrel Water de que los valores de KW-09 no están disponibles (quizá necesiten una visita a la instalación para tomar lecturas manuales); abrir un registro de incidente. Restaurar la configuración anterior es la corrección, pero solo después de la conservación y con el acuerdo del responsable del incidente.
13.4 Segundo caso: el puesto corporativo en KW-04
El capítulo 10 dejó un elemento abierto: fw-01 deniega el tráfico de los puestos corporativos hacia las estaciones y, sin embargo, una captura en KW-04 mostró escrituras desde 10.30.3.7. Hipótesis: (a) algún dispositivo tradujo la dirección de origen de la captura; (b) existe otra ruta hacia KW-04 que elude fw-01. Comprobaciones de solo lectura: la exportación de la configuración del router celular de KW-04 muestra una redirección del puerto tcp/502 desde su dirección privada del lado del operador de telecomunicaciones, y la red privada de ese operador también es alcanzable desde la VPN corporativa de acceso remoto. La hipótesis (b) es coherente; la ruta se instaló durante una puesta en servicio de 2024 y nunca se retiró. La lección es de arquitectura (capítulo 15): cada router de estación es un límite potencial, y el modelo del capítulo 6 debe incluirlo.
13.5 El registro de diagnóstico
Escriba sobre la marcha, en UTC, con las cuatro etiquetas: observado, inferido, hecho, abierto. Un buen registro permite que un colega que toma el relevo en el cambio de turno continúe sin preguntarle nada, y permite que un investigador reconstruya después qué se cambió y cuándo. El capítulo 16 ofrece una plantilla; el capítulo 18 lo sella como evidencia del proyecto. Incluya referencias a la evidencia de cada observación, como el hash de la exportación de configuración de la RTU y el intervalo del registro del servidor de salto. En el Lab 18, el registro se convierte en 05-troubleshooting-log.md, y el hash de su manifiesto se verifica como OK cuando se comprueba el paquete.
13.6 Actividad práctica
Añada al Lab 13 la hipótesis H6 «el firmware de la RTU falló y pasó a un modo degradado», con las predicciones que crea que hace, y observe si las observaciones existentes la refutan. Si no lo hacen, nombre la única observación adicional de solo lectura que lo haría. Si las observaciones existentes no refutan H6, nombre una comprobación adicional de solo lectura, como un diagnóstico del fabricante que informe del estado del firmware, que sí lo haría. Escriba las predicciones antes de inventar la comprobación, para que la nueva observación tenga algo que contradecir. Mantenga H6 en la lista hasta que quede refutada o se haga cargo el proceso de incidentes.
13.7 Errores comunes y límites
- Tratar una hipótesis coherente como demostrada; solo está aún sin refutar.
-
El Lab 13 compara valores predichos exactos; las observaciones reales tienen incertidumbre, y una sola observación poco fiable no debería refutar por sí sola una hipótesis.
-
Reiniciar primero y destruir la evidencia volátil.
- Detenerse en la primera hipótesis que encaja en lugar de contrastar las predicciones con todas las observaciones.
- Declarar H4, el mapa de registros de la RTU cambiado, como la causa antes de que una exportación de la configuración lo confirme; el Lab 13 solo muestra que es coherente.
- Cambiar varias cosas a la vez, de modo que la corrección no puede atribuirse.
Ejercicios — capítulo 13
EX049 — Primero, las predicciones. Objetivo: practicar el método. Entradas: la laguna de siete minutos de KW-05 del capítulo 8. Pasos: enumere tres hipótesis con sus predicciones para el ping, el establecimiento de la conexión TCP, la respuesta Modbus, los contadores de radio y las demás estaciones. Evidencia esperada: una tabla. Rúbrica: 3 = al menos una hipótesis de enlace, una de sondeo/SCADA y una relevante para la seguridad, con predicciones distintas para que las observaciones puedan separarlas; 2 = predicciones solapadas; 1 = solo hipótesis; 0 = nada.
EX050 — Añada H6. Objetivo: ampliar el laboratorio. Entradas: la actividad 13.6. Pasos: impleméntela y ejecútela. Evidencia esperada: código, salida y la observación adicional. Rúbrica: 3 = predicciones verosímiles (por ejemplo, ping verdadero, conexión verdadera, respuesta con tiempo de espera agotado o excepción 04); reconoce que, si H6 predice la excepción 02, no queda refutada, y propone una comprobación de solo lectura como la página de diagnóstico o el contador de tiempo en funcionamiento de la RTU; 2 = se ejecuta sin razonamiento; 1 = intentado; 0 = nada.
EX051 — El momento del escalado. Objetivo: reconocer cuándo parar y conservar. Entradas: el caso de KW-09. Pasos: redacte el mensaje de escalado al responsable del incidente y la lista de elementos conservados, con sus horas. Evidencia esperada: mensaje y lista. Rúbrica: 3 = el mensaje expone los hechos observados y la sesión sin explicar, separa la inferencia, pide una decisión sobre la restauración; los elementos conservados incluyen la exportación de la configuración y el registro de sesiones de la RTU, los registros de jump-01 y eng-ws-15 de la ventana, el propio registro de diagnóstico, cada uno con hash; 2 = bueno pero sin hashes; 1 = «nos han hackeado»; 0 = nada.
EX052 — Cierre la ruta de KW-04. Objetivo: corregir el desvío encontrado en 13.4. Entradas: la redirección de puerto del router y la alcanzabilidad desde la VPN. Pasos: proponga el cambio, su paso de conservación, sus pruebas y su responsable. Evidencia esperada: plan de cambio. Rúbrica: 3 = conservar primero la configuración del router; eliminar la redirección de puerto; restringir el acceso a la red privada del operador desde la VPN corporativa; prueba negativa desde un cliente VPN señalado y prueba positiva del sondeo del SCADA; comprobar el mismo patrón en todos los demás routers de estación; responsable nombrado; 2 = corrección sin comprobación amplia; 1 = solo eliminar; 0 = nada.
Síntesis del capítulo
El diagnóstico de averías en un servicio crítico es un método, no una corazonada: definir el síntoma, observar en solo lectura, escribir hipótesis con predicciones, descartar con evidencia, conservar y, después, cambiar una sola cosa y verificar. Cuando una observación no se explica por una actividad aprobada, la avería se ha convertido en un posible incidente: deténgase, conserve y escale. El registro que lleva es a la vez el traspaso de turno y la evidencia.
Siga estudiando — capítulo 13 de 18
← Capítulo 12 · Índice de capítulos del curso · Capítulo 14 →
Continúe con la siguiente lección escrita.