Capítulo 11 — Infraestructura crítica y seguridad sectorial: verificación
Mapa de la lección
Lección 11 publicada. Mapa, ejemplo, EX041.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["11.1 Requisitos que se pueden probar"]
N2["11.2 Pruebas positivas y negativas"]
N3["11.3 Reglas de evidencia"]
N4["11.5 Verificación segura en redes de control"]
N5["11.6 Actividad práctica"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX041"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["11.1 Requisitos que se pueden probar"]
N2["11.2 Pruebas positivas y negativas"]
N3["11.3 Reglas de evidencia"]
N4["11.5 Verificación segura en redes de control"]
N5["11.6 Actividad práctica"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX041"]
[Resultados de aprendizaje y conexión]
|
v
[11.1 Requisitos que se pueden probar]
|
v
[11.2 Pruebas positivas y negativas]
|
v
[11.3 Reglas de evidencia]
|
v
[11.5 Verificación segura en redes de control]
|
v
[11.6 Actividad práctica]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX041]
Resultados de aprendizaje y conexión
Al terminar este capítulo debería ser capaz de:
- redactar los requisitos como enunciados comprobables y vincular cada uno con al menos una prueba (trazabilidad);
- diseñar pruebas positivas (la función necesaria sigue funcionando) y negativas (la acción prohibida falla) para cada cambio de un control;
- negarse a contar una prueba sin evidencia, e informar de los requisitos como verificados, fallidos o sin probar;
- verificar sin dañar el proceso: pruebas pequeñas y delimitadas en ventanas acordadas.
El capítulo 10 cambió la configuración. Un cambio no termina cuando se aplica; termina cuando se demuestra que sus requisitos se cumplen. Este capítulo hace sistemática esa demostración.
11.1 Requisitos que se pueden probar
«El historiador está bastionado» no puede probarse. «SSH en hist-02 escucha solo en 10.90.0.21» sí. Redacte cada requisito de modo que una prueba nombrada, ejecutada por otra persona, pudiera hacerlo fallar. Divida los requisitos compuestos: «solo el servidor SCADA y la estación de ingeniería alcanzan tcp/502 en las estaciones» necesita una prueba positiva (el SCADA sigue sondeando) y una negativa (otro equipo del centro de control es rechazado). El REQ-1 del Lab 11 supera esta comprobación: que SSH escuche solo en 10.90.0.21 es algo que las pruebas T1 y T2 podrían haber hecho fallar. El REQ-4 muestra la división en la práctica: T5 y T6 cubren sus mitades negativa y positiva, y el requisito falla si falla cualquiera de ellas. Ponga los identificadores de los requisitos en el registro de cambio antes de empezar el trabajo.
11.2 Pruebas positivas y negativas
Las pruebas negativas muestran que un control bloquea lo que debe; las pruebas positivas muestran que no bloquea lo que operaciones necesita. Un cambio de cortafuegos que supera todas sus pruebas negativas pero detiene la recogida del historiador ha fallado. En los entornos de control, las pruebas positivas importan tanto como las negativas: la disponibilidad suele ser la primera prioridad. La guía de pruebas del NIST trata la planificación y la ejecución de pruebas técnicas (SP 800-115); las orientaciones sobre supervisión continua insisten en que la eficacia de los controles debe demostrarse de nuevo con el tiempo, no suponerse (SP 800-137).
11.3 Reglas de evidencia
Una prueba solo cuenta si tiene: un identificador, el requisito que verifica, el método, la hora, la persona, el resultado y un archivo de evidencia (capítulo 5). Una «solo revisión de la configuración» sin salida registrada es una actividad útil, pero no un resultado de prueba. Un requisito sin ninguna prueba contada está sin probar: ni verificado ni fallido. Informar de lo no probado como verificado es la forma más común en que la verificación induce a error. El Lab 11 aplica la regla a T8, una revisión de la configuración del REQ-2 sin archivo de evidencia, que el script ignora. El REQ-6 del Lab 11 sigue sin probar hasta que alguien produzca una línea de denegación desde el colector; informar de él como verificado porque la regla existe ocultaría la laguna. Guarde los archivos de evidencia junto a los identificadores de las pruebas en el registro de verificación.
11.4 Ejemplo resuelto: verificación de CHG-2207 (sintético)
CHG-2207 bastionó SSH en hist-02 y debía cerrar el acceso corporativo al centro de control en fw-01. El registro de verificación:
Lab 11 (guárdelo como lab11.py y ejecútelo con python3 lab11.py):
# Lab 11 - requirement-to-test traceability after a hardening change (offline, stdlib)
# Synthetic verification record for change CHG-2207 on HIST-02 and fw-01, 2026-10-12.
requirements = {
"REQ-1": "SSH listens only on management address 10.90.0.21",
"REQ-2": "Root cannot log in over SSH",
"REQ-3": "Corporate desks cannot reach control-centre RDP",
"REQ-4": "Only SCADA server and engineering workstation reach station tcp/502",
"REQ-5": "Historian still receives KW-01..KW-12 readings after change",
"REQ-6": "Firewall denies are logged to the collector",
}
tests = [ # test id, requirement, method, positive/negative, result, evidence
("T1", "REQ-1", "listening-socket listing on host", "neg", "pass", "ss-output-0612.txt"),
("T2", "REQ-1", "connect to 10.20.0.21:22 from jump host", "neg", "pass", "conn-0614.txt"),
("T3", "REQ-2", "root login attempt from jump host", "neg", "pass", "auth-0615.log"),
("T4", "REQ-3", "RDP connect from 10.30.3.7", "neg", "fail", "conn-0618.txt"),
("T5", "REQ-4", "Modbus read from 10.20.0.12", "neg", "fail", "conn-0620.txt"),
("T6", "REQ-4", "Modbus read from SCADA 10.20.0.10", "pos", "pass", "poll-0621.txt"),
("T7", "REQ-5", "count stations reporting 06:30-06:40Z", "pos", "pass", "hist-count.csv"),
("T8", "REQ-2", "config review only", "neg", "pass", ""),
]
status = {}
for tid, req, method, kind, res, ev in tests:
if not ev: print(f"{tid} {req} ignored: no evidence file recorded ({method})"); continue
status.setdefault(req, []).append((tid, kind, res))
for req, text in requirements.items():
rs = status.get(req, [])
if not rs: verdict = "UNTESTED"
elif any(r == "fail" for _, _, r in rs): verdict = "FAILED"
else: verdict = "verified"
kinds = "+".join(sorted({k for _, k, _ in rs})) or "-"
print(f"{req} {verdict:<9} tests={','.join(t for t, _, _ in rs) or '-':<6} kinds={kinds:<7} {text}")
v = sum(1 for r in requirements if status.get(r) and all(x[2] == "pass" for x in status[r]))
print(f"verified {v}/{len(requirements)}; the change is not complete until every requirement is verified")
Salida esperada (Python 3.13.5):
T8 REQ-2 ignored: no evidence file recorded (config review only)
REQ-1 verified tests=T1,T2 kinds=neg SSH listens only on management address 10.90.0.21
REQ-2 verified tests=T3 kinds=neg Root cannot log in over SSH
REQ-3 FAILED tests=T4 kinds=neg Corporate desks cannot reach control-centre RDP
REQ-4 FAILED tests=T5,T6 kinds=neg+pos Only SCADA server and engineering workstation reach station tcp/502
REQ-5 verified tests=T7 kinds=pos Historian still receives KW-01..KW-12 readings after change
REQ-6 UNTESTED tests=- kinds=- Firewall denies are logged to the collector
verified 3/6; the change is not complete until every requirement is verified
Tres requisitos verificados, dos fallidos, uno sin probar. El REQ-3 falló porque R4 se dejó en su sitio: la incidencia decía «corregir la regla de RDP», y el ingeniero corrigió R5 en lugar de la regla que la sombreaba, un patrón habitual cuando un cambio se redacta como la edición de una línea en lugar de como un requisito. El REQ-4 falló su prueba negativa (10.20.0.12 todavía puede leer las estaciones, a través de R6) mientras superaba la positiva: exactamente por eso hacen falta ambos tipos. El REQ-6 no tiene ninguna prueba; nadie comprobó que las denegaciones llegan al colector, de modo que las detecciones del capítulo 17 estarían ciegas ante los intentos denegados. T8 se ignoró porque no tiene archivo de evidencia. El cambio vuelve a «en curso» con tres elementos abiertos, cada uno con un responsable.
11.5 Verificación segura en redes de control
- Prefiera leer resultados que el sistema ya registra (registros del cortafuegos, recuentos del historiador) antes que generar tráfico.
- Cuando genere tráfico, use un origen de prueba señalado (por ejemplo, 10.30.99.9), la acción más pequeña posible (una conexión TCP sin carga útil) y una ventana acordada con operaciones informada.
- No verifique nunca un bloqueo de escritura intentando escribir en un controlador en servicio; verifíquelo con una prueba de conexión y el registro del cortafuegos, o frente a un dispositivo de repuesto en un laboratorio (capítulo 12).
- Deténgase ante el primer comportamiento inesperado.
Operaciones debe saber antes de la primera conexión que 10.30.99.9 es el origen de prueba, para que su tráfico no se confunda con un intruso.
11.6 Actividad práctica
Escriba una prueba para el REQ-6 que no toque ninguna estación: un intento de conexión desde el puesto de pruebas señalado a un puerto del centro de control que debería denegarse y, después, una consulta en el colector de la línea de denegación correspondiente en un plazo de 60 s. Añádala al Lab 11 como T9 con un nombre de archivo de evidencia y vuelva a ejecutar. Use el puesto de pruebas señalado y consulte después en el colector la denegación correspondiente en un plazo de sesenta segundos. Añada la prueba como T9 con un nombre de archivo de evidencia y vuelva a ejecutar el Lab 11 para que el REQ-6 pase de sin probar a verificado o fallido. Guarde el texto de la consulta al colector en el archivo de evidencia para que la prueba pueda repetirse.
11.7 Errores comunes y límites
- Ejecutar solo pruebas negativas y no advertir que se detuvo la recogida del historiador.
- Contar una prueba sin evidencia.
- Informar de «5 de 6 pruebas superadas» en lugar del estado de cada requisito.
- Verificar una vez y suponerlo para siempre; vuelva a verificar después de los cambios relacionados.
-
El Lab 11 trata cualquier prueba fallida como un requisito fallido; un requisito también puede estar verificado en parte si una prueba solo cubre parte de su alcance; dígalo con palabras.
-
Dejar el REQ-6 sin probar porque producir una línea de denegación en el colector parecía más difícil que leer la regla del cortafuegos.
Ejercicios — capítulo 11
EX041 — Hágalo comprobable. Objetivo: reescribir requisitos. Entradas: «El acceso remoto es seguro», «La hora está sincronizada», «Los registros se conservan». Pasos: reescriba cada uno como uno o más requisitos comprobables para el KVROC. Evidencia esperada: requisitos reescritos con una idea de prueba para cada uno. Rúbrica: 3 = enunciados específicos como «el acceso del proveedor a SS-3 solo es posible a través de jump-01 con MFA durante una ventana activada», «todos los equipos de Z2 a menos de 1 s de ntp-ops», «los eventos de permiso y denegación de fw-01 llegan al colector en 60 s y se conservan 12 meses»; cada uno con una prueba; 2 = uno vago; 1 = repetidos tal cual; 0 = nada.
EX042 — Añada la prueba que falta. Objetivo: cerrar un requisito sin probar. Entradas: el Lab 11 y la actividad de 11.6. Pasos: añada T9 para el REQ-6 con resultado superado y archivo de evidencia collector-0630.txt; ejecute. Evidencia esperada: salida. Rúbrica: 3 = REQ-6 verificado mediante T9, total «verified 4/6»; explica que REQ-3 y REQ-4 siguen impidiendo cerrar el cambio; 2 = solo la salida; 1 = intentado; 0 = nada.
EX043 — Pruebas positivas para un cambio de cortafuegos. Objetivo: proteger la disponibilidad. Entradas: la corrección de fw-01 de EX038. Pasos: enumere las pruebas positivas necesarias antes de cerrar el cambio. Evidencia esperada: lista con método y evidencia. Rúbrica: 3 = el SCADA sondea las doce estaciones (recuento del historiador), la estación de ingeniería puede conectarse a una estación en una ventana aprobada, el SSH de jump-01 a Z2 funciona, la exportación diaria de hist-02 sigue llegando; cada una con su fuente de evidencia; 2 = algunas; 1 = ninguna positiva; 0 = nada.
EX044 — Sin probar no es verificado. Objetivo: informar con honestidad. Entradas: el resumen de un directivo: «CHG-2207: 7 de 8 pruebas superadas, terminado». Pasos: redacte el estado corregido en un párrafo. Evidencia esperada: párrafo. Rúbrica: 3 = indica el estado por requisito (3 verificados, 2 fallidos, 1 sin probar), nombra los elementos abiertos y sus responsables, dice que el cambio no está terminado; 2 = correcto pero sin responsables; 1 = retoque menor; 0 = nada.
Síntesis del capítulo
La verificación convierte un cambio de configuración en un resultado demostrado. Redacte requisitos que puedan fallar, pruebe cada uno con pruebas positivas y negativas, cuente solo las pruebas con evidencia e informe de cada requisito como verificado, fallido o sin probar. En las redes de control, verifique con las acciones delimitadas más pequeñas, y nunca experimentando con el proceso en servicio.
Siga estudiando — capítulo 11 de 18
← Capítulo 10 · Índice de capítulos del curso · Capítulo 12 →
Continúe con la siguiente lección escrita.