Capítulo 27 — Seguridad de TO, IoT y sistemas ciberfísicos: verificación
Mapa de la lección
Lección 27 publicada. Mapa, ejemplo, EX079.
flowchart TD
N0["Resultados de aprendizaje"]
N1["27.1 Las políticas necesitan pruebas"]
N2["27.2 Diseñar los vectores"]
N3["27.3 Leer el resultado"]
N4["27.4 Del laboratorio a la planta"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX079"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["27.1 Las políticas necesitan pruebas"]
N2["27.2 Diseñar los vectores"]
N3["27.3 Leer el resultado"]
N4["27.4 Del laboratorio a la planta"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX079"]
[Resultados de aprendizaje]
|
v
[27.1 Las políticas necesitan pruebas]
|
v
[27.2 Diseñar los vectores]
|
v
[27.3 Leer el resultado]
|
v
[27.4 Del laboratorio a la planta]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX079]
Resultados de aprendizaje
Usted podrá (1) escribir vectores de prueba para una política de lista de permitidos; (2) incluir casos límite, negativos y de origen desconocido; (3) ejecutar pruebas de conformidad sin conexión antes de cualquier despliegue; y (4) explicar por qué la evidencia de verificación forma parte del ciclo de vida de IEC 62443.
27.1 Las políticas necesitan pruebas
Un cortafuegos o una lista de permitidos que entiende el protocolo es código, aunque esté escrito como reglas. Verificar significa mostrar, con evidencia registrada, que la política permite lo que necesitan las operaciones y bloquea lo que debe. IEC 62443-4-1 (ciclo de vida de desarrollo seguro de productos) y las actividades de puesta en marcha del integrador de sistemas esperan ambas pruebas documentadas. La política de LDHP para PLC-H es lo bastante pequeña como para enunciarla en una línea: HMI-1 puede leer con el código de función 3 y escribir los registros 100–119 con el código de función 6, HIST-1 puede leer con los códigos de función 3 y 4, y cualquier otro origen y función queda bloqueado. El laboratorio convierte esa línea en seis vectores con resultados esperados. Una política que nunca se ha ejecutado contra vectores como estos es una conjetura sobre lo que hace el cortafuegos.
27.2 Diseñar los vectores
Unos buenos vectores incluyen: cada par permitido (origen, función); cada límite de un rango de registros (primero, último, uno después del último); un origen permitido que usa una función prohibida; un origen desconocido; y una función de escritura que la planta nunca usa (16, escritura múltiple). Los resultados esperados se escriben antes de ejecutar la prueba.
"""Lab 27: conformance test of a Modbus allow-list against a test vector table."""
ALLOW = {("HMI-1", 3), ("HMI-1", 6), ("HIST-1", 3), ("HIST-1", 4)}
WRITE_RANGE = range(100, 120)
def permit(src, fc, reg):
if (src, fc) not in ALLOW: return "BLOCK"
if fc == 6 and reg not in WRITE_RANGE: return "BLOCK"
return "PASS"
vectors = [("HMI-1", 3, 100, "PASS"), ("HMI-1", 6, 119, "PASS"), ("HMI-1", 6, 120, "BLOCK"),
("HIST-1", 6, 105, "BLOCK"), ("ENG-WS", 16, 100, "BLOCK"), ("HIST-1", 4, 10, "PASS")]
fails = 0
for src, fc, reg, want in vectors:
got = permit(src, fc, reg); fails += got != want
print(f"{src:6} fc={fc:2} reg={reg:3} want={want:5} got={got:5} {'ok' if got == want else 'FAIL'}")
print("failures:", fails, "of", len(vectors))
Ejecútelo con python3 lab_allow.py. Salida verificada:
HMI-1 fc= 3 reg=100 want=PASS got=PASS ok
HMI-1 fc= 6 reg=119 want=PASS got=PASS ok
HMI-1 fc= 6 reg=120 want=BLOCK got=BLOCK ok
HIST-1 fc= 6 reg=105 want=BLOCK got=BLOCK ok
ENG-WS fc=16 reg=100 want=BLOCK got=BLOCK ok
HIST-1 fc= 4 reg= 10 want=PASS got=PASS ok
failures: 0 of 6
En el laboratorio, los seis vectores son: HMI-1 leyendo el registro 100; HMI-1 escribiendo el 119, el último registro permitido; HMI-1 escribiendo el 120, uno después del final; HIST-1 escribiendo el 105; ENG-WS usando la función 16; e HIST-1 leyendo con la función 4.
27.3 Leer el resultado
Los seis vectores coinciden. Observe el vector 3: el registro 120 está uno después del final de range(100, 120), así que debe bloquearse: el clásico error de límite por uno. El vector 4 confirma que el historiador no puede escribir ni siquiera dentro del rango escribible. Una ejecución limpia es evidencia solo para estos seis casos; no dice nada del código de función 23 (lectura/escritura múltiple) salvo que usted lo añada. La solicitud de cambio de un colega de Maya muestra cómo se mantienen los vectores: ampliar el rango escribible de HMI-1 para incluir el registro 120, destinado a un nuevo punto de consigna de velocidad de bomba, supuso cambiar a PASS el resultado esperado del vector 3, añadir un vector nuevo (HMI-1, 6, 121, BLOCK) y solo entonces editar WRITE_RANGE.
27.4 Del laboratorio a la planta
Antes de desplegar una política en el cortafuegos de la zona de control de LDHP, los mismos vectores se reproducen en un entorno de banco con el dispositivo real, primero en modo de supervisión, y el resultado se adjunta a la incidencia de cambio. El modo de supervisión significa que el cortafuegos registra lo que habría bloqueado sin bloquearlo. En LDHP, ese periodo debería cubrir al menos una semana completa, incluida la ejecución del informe semanal y una ventana de mantenimiento, porque un origen legítimo que solo escribe ocasionalmente, como EWS-1 durante un cambio de lógica, aparecería de otro modo por primera vez como una escritura bloqueada en mitad del turno de un operador. La incidencia de cambio lleva entonces los resultados de los vectores en banco, el registro del modo de supervisión y el acuerdo del jefe de turno para aplicar la política.
Ejemplo resuelto (LDHP sintética)
Un colega propone ampliar el rango escribible de HMI-1 para incluir el registro 120 (un nuevo punto de consigna de velocidad de bomba). Maya cambia primero a PASS el resultado esperado del vector 3, añade el vector (HMI-1, 6, 121, BLOCK), después edita WRITE_RANGE a range(100, 121) y vuelve a ejecutar. El cambio de las pruebas se revisa junto con el cambio de la política.
Caso sintético — Lakeside District Heating Plant. Los números de registro son inventados.
Errores y límites
Las pruebas escritas después del código tienden a confirmar lo que hace el código, no lo que necesita la planta. La conformidad sin conexión no demuestra el rendimiento del dispositivo bajo carga.
Ejercicios — capítulo 27
- EX079 — Un código de función que falta. Añada un vector para (HMI-1, 23, 105). ¿Qué debería esperar y qué devuelve el laboratorio? Rúbrica: 3 = esperar BLOCK; el laboratorio devuelve BLOCK porque (HMI-1, 23) no está en ALLOW; 2 = uno; 1 = PASS; 0 = nada.
- EX080 — Límites tras el cambio de rango. Tras
WRITE_RANGE = range(100, 121), enumere los dos vectores de límite que conservaría. Rúbrica: 3 = reg 120 PASS y reg 121 BLOCK; 2 = uno; 1 = solo 119; 0 = nada. - EX081 — Escribir antes las expectativas. ¿Por qué escribir los resultados esperados antes de ejecutar? Rúbrica: 3 = evita confirmar el comportamiento del código; vincula las pruebas al requisito operativo; 2 = parcial; 1 = «buena práctica»; 0 = nada.
Síntesis del capítulo
La verificación es una lista escrita de decisiones esperadas, que incluye límites y desconocidos, ejecutada antes del despliegue y conservada como evidencia.
Siga estudiando — capítulo 27 de 40
← Capítulo 26 (borrador) · Índice de capítulos del curso · Capítulo 28 (borrador) →