Capítulo 19 — Infraestructura crítica y seguridad sectorial: monitorización
Mapa de la lección
Lección 19 publicada. Mapa, ejemplo, EX055.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["19.1 De dónde salen las reglas"]
N2["19.2 La ausencia es una señal"]
N3["19.3 Eventos, episodios y calidad de las alertas"]
N4["19.4 Encaminamiento y primera acción"]
N5["19.5 Monitorizar la monitorización"]
N6["19.7 Actividad práctica: reglas sobre eventos"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX055"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["19.1 De dónde salen las reglas"]
N2["19.2 La ausencia es una señal"]
N3["19.3 Eventos, episodios y calidad de las alertas"]
N4["19.4 Encaminamiento y primera acción"]
N5["19.5 Monitorizar la monitorización"]
N6["19.7 Actividad práctica: reglas sobre eventos"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]
[Resultados de aprendizaje y conexión]
|
v
[19.1 De dónde salen las reglas]
|
v
[19.2 La ausencia es una señal]
|
v
[19.3 Eventos, episodios y calidad de las alertas]
|
v
[19.4 Encaminamiento y primera acción]
|
v
[19.5 Monitorizar la monitorización]
|
v
[19.7 Actividad práctica: reglas sobre eventos]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX055]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- redactar reglas de detección a partir de escenarios y de la arquitectura declarada;
- detectar la ausencia (latidos que faltan, fuentes en silencio) además de la presencia;
- ajustar las reglas para que alerten una vez por episodio en lugar de una vez por evento, sin perder información;
- monitorizar la monitorización: saber cuándo una regla, una fuente o un reenviador ha dejado de funcionar.
El capítulo 17 produjo registros normalizados. Este capítulo los convierte en alertas sobre las que pueda actuar una persona de guardia. El objetivo no son muchas alertas, sino las pocas adecuadas, cada una de las cuales apunta a un escenario y a una primera acción.
19.1 De dónde salen las reglas
Tres fuentes producen las reglas de LANTERN. Los escenarios (capítulo 13): cada paso de un camino que deja rastro es una regla candidata, como un inicio de sesión del proveedor fuera de una ventana aprobada o el cloro fuera de su banda. La arquitectura (capítulos 2 y 8): cualquier flujo que incumpla un conducto declarado (de la red corporativa a una estación por un puerto industrial) es una regla que no necesita inteligencia de amenazas, porque la define su propio diseño. Los comportamientos conocidos: conviene saber de los inicios de sesión fallidos repetidos desde un mismo origen. La matriz ATT&CK for ICS de MITRE cataloga los comportamientos de adversarios observados contra sistemas industriales y ayuda a comprobar si las reglas cubren las técnicas más relevantes para sus escenarios (MITRE ATT&CK for ICS).
19.2 La ausencia es una señal
En los servicios críticos, muchas de las alertas más importantes tratan de cosas que dejan de ocurrir: una estación que deja de informar, un retransmisor que deja de reenviar, una fuente de registros que queda en silencio, una copia de seguridad que no se ejecuta. Las reglas de ausencia necesitan un ritmo esperado (un latido cada cinco minutos) y una tolerancia (alertar tras 15 minutos de silencio). Detectan interrupciones, dispositivos averiados, cables cortados, errores de configuración y atacantes que deshabilitan el registro. La regla C marcó a las 23:00 el silencio de 40 minutos de PS-09, 15 minutos después de su último latido; esa tolerancia de 15 minutos es la decisión de diseño.
19.3 Eventos, episodios y calidad de las alertas
Una regla que salta con cada evento coincidente inunda al tecnólogo de guardia: 14 inicios de sesión fallidos se convierten en 14 alertas. Las reglas mejores alertan una vez por episodio (el primer evento de una ventana, con un recuento del resto) y adjuntan contexto: zona de origen, criticidad del activo y eventos recientes relacionados. Haga un seguimiento de la tasa de falsas alarmas y del tiempo de respuesta de cada regla. Una regla que ha saltado cien veces sin ningún verdadero positivo está enseñando a la gente a ignorarla; ajústela, cambie su umbral o envíela a un informe diario en lugar de a un aviso al busca.
19.4 Encaminamiento y primera acción
Toda alerta necesita un responsable y una primera acción escrita en la regla: «Modbus de la red corporativa a una estación: comprobar si hay en curso una sesión de ingeniería aprobada (calendario de cambios); si no, llamar a la sala de control de Agua y, después, conservar los registros de flujos». Las alertas que afectan al proceso físico van a operaciones de Agua además de a FSTS. Redacte las primeras acciones antes de activar una regla. La primera acción de la regla B cumplió su función en la noche resuelta: primero el calendario de cambios y después la sala de control de Agua.
La primera acción de la regla C, tras el estudio del capítulo 24, es «llamar a la sala de control de Agua y, después, comprobar el estado del operador».
19.5 Monitorizar la monitorización
Las reglas, las fuentes y los reenviadores fallan en silencio. Monitorice: la tasa de eventos de cada fuente (una regla de ausencia para los registros); el recuento de líneas no analizadas del normalizador (capítulo 17); la hora de la última evaluación de cada regla; y eventos de prueba periódicos que deberían producir alertas conocidas (capítulo 23). La guía del NIST sobre la monitorización continua de la seguridad de la información insiste en saber de forma permanente si los controles siguen siendo eficaces (NIST SP 800-137).
Los fallos de la regla B en el Lab 23, flujos de un conmutador de estación que nunca se exportaban al SIEM, muestran el coste de no monitorizar las fuentes: la regla era correcta, faltaba su entrada.
19.6 Ejemplo resuelto: una noche, tres reglas (sintético)
El Lab 19 aplica tres reglas a una noche de eventos y latidos. La regla A (≥10 inicios de sesión fallidos desde un origen en 5 minutos) salta una vez para 192.0.2.44. La regla B (Modbus de la red corporativa a una estación) salta dos veces para la misma estación de trabajo, a las 22:16 y a las 22:31: dos avisos para un episodio; debería ajustarse para alertar una vez y actualizar un recuento. La regla C (latido ausente durante > 15 minutos) salta a las 23:00 para PS-09, que estuvo en silencio 40 minutos. Observe lo que no salta: un único inicio de sesión fallido de e.strand desde una dirección interna, por debajo del umbral de la regla A; con razón, ya que una contraseña mal tecleada no es un episodio.
Junto con la cronología del capítulo 17, la regla B es la alerta que más importa: la estación de trabajo que inició sesión como administrador a las 22:14 habló después Modbus con un PLC. Primera acción: comprobar el calendario de cambios; si no se aprobó ninguna sesión de ingeniería, llamar a la sala de control de Agua.
19.7 Actividad práctica: reglas sobre eventos
Lab 19 (guárdelo como lab19.py y ejecútelo con python3 lab19.py):
# Lab 19 - three monitoring rules over normalized events, including "absence" (offline, standard library only)
# Synthetic events for one night at Fallowmere (times are minutes after 22:00 UTC).
events = [ # minute, host, type, fields
(14, "rly-01", "auth_ok", {"src": "10.40.3.7", "user": "b.lind"}),
*[(15 + i // 4, "rly-01", "auth_fail", {"src": "192.0.2.44", "user": "root"}) for i in range(14)],
(16, "fw-hub", "flow", {"src": "10.40.3.7", "dst": "10.20.0.11", "dport": 502}),
(31, "fw-hub", "flow", {"src": "10.40.3.7", "dst": "10.20.0.11", "dport": 502}),
(44, "rly-01", "auth_fail", {"src": "10.40.9.9", "user": "e.strand"}),
]
heartbeats = {"PS-04": list(range(0, 120, 5)), "PS-07": list(range(0, 120, 5)),
"PS-09": [m for m in range(0, 120, 5) if not 50 <= m < 85]}
alerts = []
# Rule A: >=10 failed logins from one source within 5 minutes
fails = [(m, f["src"]) for m, h, t, f in events if t == "auth_fail"]
for src in {s for _, s in fails}:
times = sorted(m for m, s in fails if s == src)
for i in range(len(times)):
if sum(1 for t in times if times[i] <= t < times[i] + 5) >= 10:
alerts.append((times[i], "A brute-force", src)); break
# Rule B: any flow from corp to a station on an industrial port (not a declared conduit)
for m, h, t, f in events:
if t == "flow" and f["src"].startswith("10.40.") and f["dst"].startswith("10.20.") and f["dport"] == 502:
alerts.append((m, "B corp->station Modbus", f"{f['src']}->{f['dst']}"))
# Rule C: heartbeat missing for > 15 minutes (silence is a signal)
for st, beats in heartbeats.items():
for a, b in zip(beats, beats[1:]):
if b - a > 15:
alerts.append((a + 15, "C station silent", f"{st} gap {b - a} min"))
for m, rule, detail in sorted(alerts):
print(f"22:{m:02d}+ {rule:<24} {detail}" if m < 60 else f"23:{m-60:02d}+ {rule:<24} {detail}")
print("alerts:", len(alerts), "| rule B fired per event, not per episode:", sum(1 for a in alerts if a[1].startswith("B")))
Salida esperada (Python 3.13.5):
22:15+ A brute-force 192.0.2.44
22:16+ B corp->station Modbus 10.40.3.7->10.20.0.11
22:31+ B corp->station Modbus 10.40.3.7->10.20.0.11
23:00+ C station silent PS-09 gap 40 min
alerts: 4 | rule B fired per event, not per episode: 2
Cuente las alertas por episodio, no por línea: las cuatro alertas de la salida son tres episodios (regla A para 192.0.2.44, regla B para la estación de trabajo 10.40.3.7, regla C para PS-09), y ajustar la regla B para que alerte una vez y actualice un recuento las deja en tres. Compruebe también lo que permanece en silencio: el único inicio de sesión fallido de e.strand desde 10.40.9.9 queda por debajo del umbral de la regla A, correctamente, porque una contraseña mal escrita una vez no es un episodio.
19.8 Errores frecuentes y límites
- Reglas sin escenario, responsable ni primera acción.
- Solo reglas de presencia; nada advierte el silencio.
- Una alerta por evento, que inunda a quienes responden.
- Umbrales que nunca se revisan.
- Suponer que una regla funciona porque se desplegó; debe probarse (capítulo 23).
- Enviar las alertas relevantes para el proceso solo a TI.
Las reglas detectan lo que se previó. El comportamiento imprevisto necesita personas que miren los datos (búsqueda proactiva de amenazas, revisiones) y reglas de ausencia, que detectan los efectos sin conocer las causas.
Los dos avisos de la regla B para un solo episodio en la noche resuelta son el tercer error.
Ejercicios — capítulo 19
EX055 — Regla por episodios. Objetivo: reducir el ruido de las alertas sin perder información. Entradas: el Lab 19. Restricciones: solo la biblioteca estándar. Pasos: (1) cambie la regla B para que genere una alerta por par origen–destino cada 60 minutos, registrando el recuento de eventos coincidentes; (2) ejecútela y muestre la salida; (3) explique qué información se conserva. Evidencia esperada: código, salida y explicación. Rúbrica: 3 = una alerta de la regla B con recuento 2 y horas primera y última; explicación de que los recuentos y las horas se conservan para la investigación mientras el aviso salta una sola vez; 2 = funciona, falta el recuento; 1 = no ejecutado; 0 = nada.
EX056 — Primeras acciones. Objetivo: redactar alertas accionables. Entradas: las reglas A, B y C. Restricciones: como máximo tres pasos cada una; deben incluir a quién llamar. Pasos: redacte la primera acción de cada una. Evidencia esperada: tres procedimientos breves. Rúbrica: 3 = A: confirmar la exposición de SSH, comprobar si hubo algún éxito desde ese origen, bloquear en el perímetro mediante un cambio estándar; B: comprobar el calendario de cambios, llamar a la sala de control de Agua si no está aprobado, conservar los flujos; C: llamar a la sala de control de Agua para confirmar el estado de la estación, comprobar el estado del operador, revisar los registros del retransmisor en busca de fallos de MAC; 2 = una débil; 1 = genéricas; 0 = nada.
EX057 — Monitorice el monitor. Objetivo: diseñar la automonitorización. Entradas: la cadena de monitorización de LANTERN: fuentes → reenviador → normalizador → reglas → avisos. Restricciones: una comprobación por etapa. Pasos: enumere la comprobación, su umbral y a quién se alerta. Evidencia esperada: tabla. Rúbrica: 3 = ausencia en la tasa de eventos de las fuentes, cola o acumulación del reenviador, tasa de líneas no analizadas del normalizador, hora de la última ejecución de las reglas, prueba de avisos (aviso sintético programado y confirmado); umbrales y destinatarios razonables; 2 = cuatro etapas; 1 = genérica; 0 = nada.
Síntesis del capítulo
Derive las reglas de los escenarios, de su propia arquitectura y de los comportamientos conocidos; asigne a cada una un responsable y una primera acción. Detecte la ausencia además de la presencia. Alerte por episodio con recuentos y contexto, haga un seguimiento de las falsas alarmas y de los tiempos de respuesta, y envíe a operaciones las alertas relevantes para el proceso. Monitorice la monitorización, porque cada una de sus etapas puede fallar en silencio.
Siga estudiando — capítulo 19 de 30
← Capítulo 18 · Índice de capítulos del curso · Capítulo 20 →
Continúe con la siguiente lección escrita.