Capítulo 28 — Infraestructura crítica y seguridad sectorial: implementación I | Ingeniería Seguridad de infraestructuras críticas y sectores

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 28 publicada. Mapa, ejemplo, EX055.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["28.1 De la especificación al código"]
  N2["28.2 Codificación segura para los caminos de control"]
  N3["28.3 El banco de pruebas"]
  N4["28.4 Evidencia"]
  N5["28.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX055"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["28.1 De la especificación al código"]
  N2["28.2 Codificación segura para los caminos de control"]
  N3["28.3 El banco de pruebas"]
  N4["28.4 Evidencia"]
  N5["28.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX055"]

[Resultados de aprendizaje y conexión]
    |
    v
[28.1 De la especificación al código]
    |
    v
[28.2 Codificación segura para los caminos de control]
    |
    v
[28.3 El banco de pruebas]
    |
    v
[28.4 Evidencia]
    |
    v
[28.6 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX055]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted podrá (1) implementar un control de seguridad como código funcional con pruebas, a partir de su especificación; (2) aplicar prácticas de codificación segura para el manejo de entradas, la criptografía y el manejo de errores; (3) construir un banco de pruebas que ejercite el control sin conexión; y (4) registrar una evidencia de implementación que remita a los requisitos. Implementa las especificaciones del capítulo 27 y prepara el capítulo 29.

28.1 De la especificación al código

Parta de la especificación del control (capítulo 27): cada «deberá» se convierte en al menos una prueba, antes del código o a la par que él. Mantenga la implementación pequeña y, cuando sea posible, sin dependencias: la pasarela de este libro usa solo la biblioteca estándar de Python. Estructúrela como recomienda el capítulo 9: un analizador (capítulo 4), un verificador (capítulo 19), un almacén de estado (contadores contra repeticiones) y una interfaz de salida, cada uno probado por separado. La pasarela del TMRP sigue esta estructura, y por eso su error con NaN pudo encontrarse y corregirse solo en el validador.

28.2 Codificación segura para los caminos de control

Valide la entrada antes de usarla: longitud, MAC, contador, forma, rango físico (Labs 3 y 8).
Compare los secretos en tiempo constante (hmac.compare_digest).
Cargue las claves desde un almacenamiento protegido, nunca desde el código fuente ni desde archivos legibles por todos.
Trate toda excepción en el camino de verificación como un rechazo; nunca acepte por defecto.
Acote el uso de recursos: tamaño máximo de mensaje, longitud máxima de cola, límites de frecuencia por origen.
Registre los rechazos con contexto suficiente para investigar, sin registrar secretos.

Estas reglas salen directamente de los Labs 3, 8 y 11. Cada una tiene una prueba en el conjunto de pruebas de la pasarela.

28.3 El banco de pruebas

Un banco de pruebas reproduce sin conexión el entorno del control: RTU simuladas que envían mensajes válidos, malformados, falsificados, repetidos y retrasados; un SCADA simulado que recibe la salida de la pasarela; y un reloj que se puede controlar. El Lab 15 (capítulo 40) es una versión compacta. Los bancos permiten probar modos de falla que sería inseguro o imposible provocar en un sistema en servicio. El banco del TMRP incluye RTU simuladas en PS2 y PS4, un receptor SCADA simulado y un reloj controlable, de modo que los reinicios, los retardos y las repeticiones pueden producirse a demanda. El mismo arnés sostiene después la campaña de inyección de fallas con semilla, y por eso invertir pronto en él ahorra tiempo cuando empieza la verificación del proyecto final.

28.4 Evidencia

Registre para cada implementación: las versiones del requisito y de la especificación implementadas; la revisión del código fuente; los resultados de las pruebas con las versiones de las herramientas; las limitaciones conocidas; y la aprobación del revisor. Esto pasa a formar parte del expediente de evidencia (capítulo 48). Para el validador de consignas del TMRP, el registro muestra la versión de la especificación, los commits de v1 y v2, los resultados de T3 de cada uno, la limitación conocida de que v1 aceptaba NaN y el revisor que planteó la pregunta sobre NaN. Sin ese registro, el hallazgo posterior del expediente sobre el estado de T3 habría sido imposible de resolver, porque nadie podría haber mostrado qué versión había pasado. Registrar la evidencia mientras se hace el trabajo cuesta minutos; reconstruirla después cuesta días.

28.5 Ejemplo resuelto: validador de consignas v1 (sintético)

El equipo del TMRP implementa R3 a partir de la especificación de §27.5. La versión 1 comprueba new < lo, new > hi y el límite de escalón, y supera las pruebas de ejemplo: en rango, aceptado; por encima y por debajo del rango, rechazado; escalón demasiado grande, rechazado. La revisión de código pregunta: ¿y NaN? En la aritmética IEEE 754, toda comparación de orden con NaN es falsa, así que nan < lo y nan > hi son ambas falsas y abs(nan - old) > max_step es falsa: v1 acepta NaN. La versión 2 rechaza explícitamente los valores no finitos y expresa la región segura en positivo (lo <= new <= hi), lo que es falso para NaN. Las pruebas basadas en propiedades del capítulo 30 confirman la diferencia de forma sistemática (Lab 11). Esta es la falla de la prueba T3 del escenario de aprobación del capítulo 10.

28.6 Actividad práctica

Implemente una pasarela mínima que combine la salida del analizador del Lab 3 con el sellado del Lab 8, de modo que una lectura Modbus validada se convierta en una trama autenticada. Escriba pruebas para cada camino de rechazo. Mantenga las dos partes separadas tras interfaces claras: el analizador devuelve una lectura validada o un motivo de rechazo, y solo se sella una lectura validada. Pruebe cada camino de rechazo del Lab 3 y confirme que nada llega a la función de sellado. Después compruebe que la trama sellada supera el receptor del Lab 8 y que una copia manipulada se rechaza. Guarde la clave fuera del archivo fuente, incluso en este ejercicio, para que el hábito esté instalado antes de que aparezcan claves reales.

28.7 Errores comunes y límites

Código escrito antes de que la especificación esté clara.
Comportamiento de aceptar por defecto ante las excepciones.
Comprobaciones en negativo (if x > hi: reject) que pasan por alto NaN; prefiera comprobaciones en positivo de la región segura.
Claves en el código fuente.
Evidencia reconstruida a posteriori.

La primera versión del validador de consignas muestra el tercer error, y el expediente del TMRP existe para evitar el último. Su aceptación de NaN venía de las comprobaciones en negativo, y la corrección fue enunciar en positivo la región segura. Las claves del código del banco del TMRP se cargan desde un archivo protegido, nunca se escriben en el código fuente, y toda excepción en el camino de verificación termina en un rechazo que se registra.

Ejercicios — capítulo 28

EX055 — NaN y compañía. Objetivo: encontrar aceptaciones inseguras. Entradas: validate_v1 del Lab 11. Pasos: evalúe a mano v1 y v2 para new = NaN, +∞, −∞, 5.5 y 5.50001 con old = 5.2, y explique cada resultado. Evidencia esperada: tabla. Rúbrica: 3 = entre los valores especiales, v1 acepta solo NaN (∞ se rechaza por > hi, −∞ por < lo), 5.5 lo aceptan ambas (límite inclusivo), 5.50001 se rechaza; v2 rechaza todos los no finitos; explicaciones correctas; 2 = un error; 1 = sin explicaciones; 0 = nada.

EX056 — Registro de los rechazos. Objetivo: diseñar registros útiles. Entradas: la pasarela. Pasos: defina un registro para cada tipo de rechazo (etiqueta, repetición, sin datos recientes, forma, rango) con sus campos, y explique un campo que excluye deliberadamente. Evidencia esperada: esquema. Rúbrica: 3 = los campos permiten investigar (fuente de tiempo, estación, contador, motivo, ID de la pasarela, hash del mensaje), excluye el material de claves y la carga útil completa cuando es sensible; 2 = falta la fuente de tiempo o la estación; 1 = texto libre; 0 = nada.

Síntesis del capítulo

Implemente los controles a partir de las especificaciones, con pruebas para cada «deberá». Programe el camino de control de forma defensiva: valide por completo, compare en tiempo constante, proteja las claves, rechace ante cualquier error, acote los recursos y registre de forma útil. Prefiera las comprobaciones en positivo de la región segura. Pruebe en un banco capaz de producir las fallas que no puede provocar en servicio, y registre la evidencia sobre la marcha.