Capítulo 20 — Infraestructura crítica y seguridad sectorial: resolución de problemas
Mapa de la lección
Lección 20 publicada. Mapa, ejemplo, EX058.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["20.1 Un método"]
N2["20.2 Conserve antes de cambiar"]
N3["20.3 Cuándo una avería se convierte en incidente"]
N4["20.4 Datos que faltan: cuatro causas habituales"]
N5["20.6 Actividad práctica: discrimine las causas"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX058"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["20.1 Un método"]
N2["20.2 Conserve antes de cambiar"]
N3["20.3 Cuándo una avería se convierte en incidente"]
N4["20.4 Datos que faltan: cuatro causas habituales"]
N5["20.6 Actividad práctica: discrimine las causas"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX058"]
[Resultados de aprendizaje y conexión]
|
v
[20.1 Un método]
|
v
[20.2 Conserve antes de cambiar]
|
v
[20.3 Cuándo una avería se convierte en incidente]
|
v
[20.4 Datos que faltan: cuatro causas habituales]
|
v
[20.6 Actividad práctica: discrimine las causas]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX058]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- seguir un método disciplinado de resolución de problemas que funcione tanto si una avería resulta ser técnica como humana o maliciosa;
- conservar la evidencia antes de cambiar nada, y saber cuándo una avería debe convertirse en un incidente;
- distinguir las causas habituales de los «datos que faltan» (pérdida, retraso, error de reloj, filtrado) usando los propios datos;
- redactar un breve registro del problema que la siguiente persona pueda usar.
La mayor parte de la vida laboral de un implementador se dedica a las averías. En los servicios críticos, algunas averías son ataques y algunos ataques parecen averías; el método debe funcionar para ambos sin frenar las reparaciones ordinarias.
20.1 Un método
- Defina el síntoma con precisión: qué falla, desde cuándo, para quién y medido cómo. «PS-07 y PS-09 muestran huecos en el panel desde aproximadamente las 22:50», no «la telemetría no funciona».
- Compruebe primero el impacto y la seguridad física: ¿alguien tiene que actuar ahora sobre el proceso físico? Diga a operaciones de Agua en qué pueden confiar y en qué no.
- Conserve antes de cambiar: copie los registros, configuraciones y salidas pertinentes, con sus horas, antes de reiniciar o reconfigurar nada (véase «Conserve antes de cambiar», más abajo).
- Enumere hipótesis, incluida al menos una explicación no maliciosa y otra maliciosa, y qué evidencia las distinguiría.
- Pruebe primero la hipótesis discriminante más barata, con lecturas antes que escrituras.
- Cambie una sola cosa cada vez, con el tipo de cambio adecuado (capítulo 14), registrando cada cambio.
- Verifique la corrección frente al síntoma original y vigile si se repite.
- Registre la causa, la evidencia, las acciones y los elementos abiertos.
20.2 Conserve antes de cambiar
Reiniciar un servicio borra su memoria, rota los registros y puede destruir la única evidencia de lo ocurrido. Las recomendaciones del NIST sobre respuesta a incidentes insisten en conservar la evidencia y en coordinar la respuesta con la gestión de riesgos de la organización (NIST SP 800-61 Rev. 3). Para un implementador, conservar suele ser rápido: copie los registros y la configuración del servicio, exporte los registros de flujos y de alertas pertinentes, anote los procesos en ejecución y las conexiones de red, calcule los hashes de lo copiado y anote la hora. Si la avería afecta al proceso físico, restablecer el servicio puede ir legítimamente primero, pero dígalo y registre lo que se perdió.
20.3 Cuándo una avería se convierte en incidente
Escale al proceso de incidentes cuando se cumpla cualquiera de estas condiciones: hay evidencia de un acceso o un cambio no autorizados (una diferencia de configuración no aprobada, el uso de la cuenta de alguien que se ha marchado, capítulo 7); un control de seguridad ha fallado de una forma que podría explotarse; los datos pueden haber ido adonde no deberían (capítulo 12); o no se encuentra la causa y una causa maliciosa es plausible. Escalar no es una acusación. Incorpora a personas con otra autoridad y otras obligaciones, incluidas las obligaciones de notificación del operador (capítulo 10).
El inicio de sesión de c.mendes el 14 de septiembre es el desencadenante más claro de Fallowmere.
20.4 Datos que faltan: cuatro causas habituales
La telemetría que falta es el síntoma más común de LANTERN. Los propios datos suelen discriminar entre las causas:
- Pérdida: los números de secuencia tienen huecos (capítulo 15); los mensajes nunca se recibieron.
- Retraso: la secuencia está completa, pero la hora de recepción va muy por detrás de la hora de la estación, a menudo tras un problema del operador.
- Error de reloj: la secuencia está completa y la llegada es puntual, pero las marcas de tiempo de la estación están desplazadas una cantidad constante; los datos se archivan en la ventana temporal equivocada, así que un panel que consulta por la hora de la estación muestra un hueco.
- Filtrado: los mensajes se reciben, pero se rechazan o se ponen en cuarentena (recuentos de rechazos crecientes en el registro del retransmisor).
20.5 Ejemplo resuelto: dos huecos, dos causas (sintético)
Los operadores informan de huecos en el panel para PS-07 y PS-09. El Lab 20 examina doce números de secuencia de cada estación. A PS-07 le faltan los números de secuencia 5–8, con llegada puntual del resto: los datos se perdieron. PS-09 tiene todos los números de secuencia y llega puntualmente según el reloj del retransmisor, pero las marcas de tiempo de la estación van unos 422 segundos por detrás: su reloj está mal, y la ventana del panel no recoge ninguno de sus puntos. Los dos síntomas parecían idénticos en el panel; las causas y las correcciones son completamente distintas.
Para PS-09, la siguiente pregunta es por qué está mal el reloj: ¿ha perdido la estación su ruta NTP hacia el retransmisor (¿un cambio en el conducto?, capítulo 2), o alguien ha cambiado la configuración horaria de la estación? Lo primero es una avería; lo segundo puede ser un evento de seguridad. Un desfase constante de unos siete minutos en todos los mensajes es inusual para una deriva, que es gradual. Conserve los registros NTP del retransmisor y la configuración del conducto antes de que nadie reajuste el reloj.
Para PS-07, el hueco de cuatro mensajes consecutivos podría deberse a una caída del operador, a un reinicio de la estación o a rechazos del retransmisor. Revise el registro de rechazos del retransmisor para esas horas antes de llamar a BayTel: si en ese momento hubo fallos de MAC en PS-07, la causa está en la gestión de claves (capítulo 18), no en el operador.
20.6 Actividad práctica: discrimine las causas
Lab 20 (guárdelo como lab20.py y ejecútelo con python3 lab20.py):
# Lab 20 - troubleshooting "missing telemetry": sequence gaps versus clock skew (offline, standard library only)
# Synthetic historian extract: station, sequence number, station timestamp (s), relay receive time (s).
rows = {
"PS-04": [(s, 1000 + 10*s, 1000 + 10*s + 1) for s in range(1, 13)],
"PS-07": [(s, 1000 + 10*s, 1000 + 10*s + 1) for s in range(1, 13) if s not in (5, 6, 7, 8)],
"PS-09": [(s, 1000 + 10*s - 420, 1000 + 10*s + 2) for s in range(1, 13)],
}
for st, rs in rows.items():
seqs = [r[0] for r in rs]
missing = sorted(set(range(seqs[0], seqs[-1] + 1)) - set(seqs))
offsets = [recv - ts for _, ts, recv in rs]
avg = sum(offsets) / len(offsets)
dx = "data lost in transit or at source" if missing else ("clock skew: station clock behind by ~%d s; data present but filed in the wrong window" % round(avg) if abs(avg) > 60 else "healthy")
print(f"{st}: received {len(rs)}/{seqs[-1]-seqs[0]+1}, missing seq {missing or '-'}, mean recv-ts offset {avg:+.0f} s -> {dx}")
# A dashboard that queries by station timestamp for window [1050, 1130) would show:
for st, rs in rows.items():
print(st, "points in dashboard window:", sum(1 for _, ts, _ in rs if 1050 <= ts < 1130))
Salida esperada (Python 3.13.5):
PS-04: received 12/12, missing seq -, mean recv-ts offset +1 s -> healthy
PS-07: received 8/12, missing seq [5, 6, 7, 8], mean recv-ts offset +1 s -> data lost in transit or at source
PS-09: received 12/12, missing seq -, mean recv-ts offset +422 s -> clock skew: station clock behind by ~422 s; data present but filed in the wrong window
PS-04 points in dashboard window: 8
PS-07 points in dashboard window: 4
PS-09 points in dashboard window: 0
Mire las columnas de las dos estaciones una junto a otra. Los números de secuencia de PS-07 saltan de 4 a 9, así que cuatro mensajes nunca llegaron. Los números de secuencia de PS-09 están completos, pero sus marcas de tiempo de estación van unos 422 segundos por detrás de las horas de llegada al retransmisor en todos los mensajes. Lo primero es pérdida; lo segundo, hora. Después redacte la siguiente comprobación para cada una: el registro de rechazos del retransmisor y el estado de BayTel para el hueco de PS-07, y la ruta NTP y la configuración horaria de PS-09, conservadas antes de que nadie reajuste el reloj.
20.7 Errores frecuentes y límites
- Reiniciar primero e investigar después.
- Una sola hipótesis, normalmente la más conocida.
- Varios cambios a la vez, de modo que nadie sabe cuál lo arregló, o cuál estropeó otra cosa.
- Tratar todas las averías como ataques, o ninguna.
- «Arreglar» un reloj o una configuración antes de registrar cómo estaba.
- Cerrar la incidencia sin un registro de la causa y la evidencia.
Reajustar primero el reloj de PS-09 habría destruido la evidencia para la pregunta de los 422 segundos.
Llamar a BayTel por el hueco de PS-07 antes de revisar el registro de rechazos del retransmisor sería el segundo error: una sola hipótesis, la más conocida, probada en primer lugar y quizá en exclusiva.
Ejercicios — capítulo 20
EX058 — Hipótesis y discriminantes. Objetivo: razonar antes de actuar. Entradas: síntoma: «el recuento de rechazos del retransmisor para PS-04 subió de 0 a 300 por hora a las 09:00; desde entonces el panel no muestra datos de PS-04». Restricciones: cuatro hipótesis, al menos una maliciosa. Pasos: para cada una, indique la evidencia que la apoyaría o la descartaría y la comprobación más barata. Evidencia esperada: tabla. Rúbrica: 3 = por ejemplo, clave rotada en la estación pero no en el retransmisor (fallos de MAC en los motivos de rechazo, calendario de cambios), salto del reloj de la estación (rechazos por ventana), estado de reproducción envenenado (rechazos por reproducción tras una secuencia alta, capítulo 29), tráfico falsificado (fallos de MAC desde una dirección de origen inesperada); las comprobaciones son lecturas; 2 = tres; 1 = una; 0 = nada.
EX059 — Lista de conservación. Objetivo: conservar la evidencia con rapidez. Entradas: el caso del desfase del reloj de PS-09. Restricciones: diez minutos como máximo; ningún cambio en los sistemas. Pasos: enumere lo que copiaría o registraría, en orden, y cómo demostraría después que las copias no se alteraron. Evidencia esperada: lista. Rúbrica: 3 = registros NTP y del retransmisor, configuración del conducto o del cortafuegos y registro de cambios reciente, extracto del historiador, salida de un análisis al estilo del Lab 20, hora de la recogida, hashes anotados en la incidencia y copias guardadas fuera del equipo; 2 = faltan los hashes o las horas; 1 = «hacer una captura de pantalla»; 0 = nada.
EX060 — Registro del problema. Objetivo: redactar un registro útil. Entradas: el capítulo 20 («Ejemplo resuelto: dos huecos, dos causas») y suponga que la causa de PS-09 fue un cambio en el cortafuegos que bloqueó udp/123 del retransmisor a la estación dos días antes. Restricciones: como máximo 250 palabras; etiquetas observado / inferido / hecho / abierto. Pasos: redacte el registro. Evidencia esperada: el registro. Rúbrica: 3 = síntoma preciso, evidencia (desfase de ~422 s, secuencia completa), causa con el cambio identificado, corrección con control de cambios, verificación y elementos abiertos (por qué el cambio eliminó NTP; por qué no saltó ninguna alerta por el desfase del reloj: añadir una); 2 = falta un elemento; 1 = solo narración; 0 = nada.
Síntesis del capítulo
Resuelva los problemas con un método: síntoma preciso, seguridad física e impacto primero, conservar antes de cambiar, varias hipótesis incluida una maliciosa, la comprobación discriminante más barata primero, un cambio cada vez, verificar y registrar. Escale a incidente cuando la evidencia sugiera actividad no autorizada o exposición. Para los datos que faltan, los propios datos (secuencia, llegada, marcas de tiempo, recuentos de rechazos) suelen distinguir la pérdida, el retraso, el error de reloj y el filtrado.
Siga estudiando — capítulo 20 de 30
← Capítulo 19 · Índice de capítulos del curso · Capítulo 21 →
Continúe con la siguiente lección escrita.