Capítulo 30 — Laboratorio II | Grado Seguridad de OT, IoT y sistemas ciberfísicos

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 30 publicada. Mapa, ejemplo, EX088.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["30.1 La base de referencia"]
  N2["30.2 Leer el resultado de la flota"]
  N3["30.3 Priorizar"]
  N4["30.5 Reproducir y ampliar el laboratorio"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX088"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["30.1 La base de referencia"]
  N2["30.2 Leer el resultado de la flota"]
  N3["30.3 Priorizar"]
  N4["30.5 Reproducir y ampliar el laboratorio"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX088"]

[Resultados de aprendizaje]
    |
    v
[30.1 La base de referencia]
    |
    v
[30.2 Leer el resultado de la flota]
    |
    v
[30.3 Priorizar]
    |
    v
[30.5 Reproducir y ampliar el laboratorio]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX088]

Resultados de aprendizaje

Usted podrá (1) evaluar una flota IoT sintética frente a disposiciones seleccionadas de ETSI EN 303 645; (2) comunicar las carencias por dispositivo y de toda la flota; (3) relacionar las disposiciones con las actividades de los fabricantes de NIST IR 8259; y (4) priorizar la remediación.

30.1 La base de referencia

ETSI EN 303 645 V2.1.1 establece 13 disposiciones de ciberseguridad para el IoT de consumo, más disposiciones de protección de datos. Este laboratorio comprueba cuatro: 5.1 (sin contraseñas por defecto universales), 5.2 (implantar un medio para gestionar los informes de vulnerabilidades), 5.3 (mantener el software actualizado) y 5.5 (comunicar de forma segura). NIST IR 8259 cubre un terreno similar desde el lado del proceso del fabricante, por ejemplo, la planificación de las actualizaciones y la comunicación con los clientes.

"""Lab 30: score a synthetic IoT meter fleet against selected ETSI EN 303 645 provisions."""
fleet = {"MTR-A": {"unique_pw": True, "vuln_policy": True, "update": True, "tls": True},
         "MTR-B": {"unique_pw": False, "vuln_policy": True, "update": True, "tls": True},
         "MTR-C": {"unique_pw": True, "vuln_policy": False, "update": False, "tls": False}}
PROV = {"unique_pw": "5.1 no universal default passwords", "vuln_policy": "5.2 vulnerability disclosure",
        "update": "5.3 software updatable", "tls": "5.5 secure communication"}
for dev, f in fleet.items():
    miss = [PROV[k] for k, v in f.items() if not v]
    print(f"{dev}: {4-len(miss)}/4 met; missing: {miss or 'none'}")
print("fleet-wide gaps:", sorted({k for f in fleet.values() for k, v in f.items() if not v}))

Ejecútelo con python3 lab_fleet.py. Salida verificada:

MTR-A: 4/4 met; missing: none
MTR-B: 3/4 met; missing: ['5.1 no universal default passwords']
MTR-C: 1/4 met; missing: ['5.2 vulnerability disclosure', '5.3 software updatable', '5.5 secure communication']
fleet-wide gaps: ['tls', 'unique_pw', 'update', 'vuln_policy']

Los tres modelos de contador del laboratorio responden a un breve cuestionario sobre esas cuatro disposiciones; el script informa de cuáles cumple cada uno y de lo que le falta a la flota.

30.2 Leer el resultado de la flota

MTR-A cumple las cuatro. MTR-B solo incumple la 5.1, lo que se corrige forzando credenciales únicas en la instalación. MTR-C incumple tres disposiciones: no tiene política de divulgación, ni mecanismo de actualización, ni comunicación segura. La lista de carencias de toda la flota contiene las cuatro disposiciones, lo que parece alarmante pero se debe solo a dos modelos; comunique ambas vistas. La vista por dispositivo le dice a Maya qué corregir en cada modelo de contador, mientras que la vista de la flota le dice al director de LDHP qué disposiciones faltan en algún punto del parque. Leer solo la lista de la flota sugeriría cuatro problemas distintos en todos los contadores, cuando MTR-A está limpio y tres de las cuatro carencias recaen solo en MTR-C.

30.3 Priorizar

La gravedad depende de la consecuencia y de la facilidad de corrección. La falta de capacidad de actualización de MTR-C es estructural —no se puede parchear—, así que la planificación de su sustitución empieza ya. La contraseña por defecto de MTR-B es el vector clásico de Mirai (capítulo 20) y es urgente, pero barata. La tabla de remediación de Maya sigue ese orden. MTR-B se corrige en dos semanas, en la siguiente visita de lectura de contadores. MTR-C recibe de inmediato controles compensatorios —aislamiento detrás de la pasarela, con TLS terminado allí— y una sustitución programada en 12 meses, porque ningún cambio de configuración puede cumplir la 5.3. MTR-A no necesita nada por ahora, pero se vuelve a comprobar cada vez que cambia su firmware, ya que un resultado favorable describe una sola versión.

30.4 Límites de la evaluación por lista de comprobación

«Cumple la 5.3» es en este laboratorio un booleano procedente de un cuestionario. Una evaluación real comprueba la evidencia: ¿verifica firmas el mecanismo de actualización, y se publican realmente actualizaciones? Para los contadores de LDHP, eso significa pedir a cada fabricante evidencia en lugar de respuestas. Para el «cumple la 5.3» de MTR-A, significa un paquete de actualización firmado y la fecha de la última actualización publicada. Para la 5.1, un restablecimiento de fábrica que siga dando una contraseña única. Para la 5.5, la versión de TLS y la gestión de certificados observadas en el banco. Solo las afirmaciones de MTR-A tendrían que comprobarse así en primer lugar, porque sus cuatro «sí» son los que ahora mismo sustentan una decisión de no actuar.

Ejemplo resuelto (LDHP sintética)

Tabla de remediación de Maya: MTR-B: restablecer contraseñas únicas durante la siguiente visita de lectura de contadores, 2 semanas. MTR-C: aislar detrás de la pasarela con terminación TLS como control compensatorio para la 5.5, solicitar el contacto de divulgación del fabricante, programar la sustitución en 12 meses porque no puede cumplirse la 5.3. MTR-A: ninguna acción; volver a comprobar cuando cambie el firmware.

Caso sintético — Lakeside District Heating Plant. Los modelos de dispositivo y las respuestas son inventados.

30.5 Reproducir y ampliar el laboratorio

Cambie el diccionario de un solo dispositivo cada vez y vuelva a ejecutar, registrando la salida junto a la modificación. Si dos estudiantes obtienen resultados distintos con los mismos diccionarios, compare las versiones de Python y el archivo exacto; el script es determinista y nunca debería diferir. Una primera modificación útil es poner a true el unique_pw de MTR-B y confirmar que su línea pasa a 4/4, mientras la lista de carencias de la flota pierde unique_pw y conserva las tres carencias de MTR-C; una segunda es dar a MTR-C una política de divulgación y comprobar que solo desaparece la 5.2 de su lista de incumplimientos. Si la lista de la flota no cambia como usted predijo, lea la agregación del script antes de fiarse de su modificación.

Errores y límites

ETSI EN 303 645 se dirige a dispositivos de consumo; los contadores de un distrito pueden estar sujetos a otros regímenes. Las cuatro disposiciones comprobadas son un subconjunto.

Ejercicios — capítulo 30

EX088 — Añadir una disposición. Añada "secure_storage" asignada a la 5.4 con MTR-A True, MTR-B True, MTR-C False. ¿Qué imprime ahora MTR-C?
Mostrar criterios de evaluación
Rúbrica: 3 = detecta el 4 fijo en el código (imprime 0/4), lo corrige y obtiene 1/5 con cuatro disposiciones incumplidas; 2 = una de las dos cosas; 1 = dice 1/4; 0 = nada.
EX089 — Por qué engañan las carencias de toda la flota. Explique por qué «carencias de toda la flota: las cuatro» podría engañar a un directivo.
Mostrar criterios de evaluación
Rúbrica: 3 = lo causan dos modelos; la vista por dispositivo muestra la mayoría de los problemas en MTR-C; 2 = parcial; 1 = vago; 0 = nada.
EX090 — Evidencia para la 5.3. ¿Qué evidencia pediría a un fabricante para aceptar «software actualizable»?
Mostrar criterios de evaluación
Rúbrica: 3 = mecanismo de actualización firmado, historial de actualizaciones publicado/periodo de soporte, prueba de actualización en banco; 2 = dos; 1 = el fabricante dice que sí; 0 = nada.

Síntesis del capítulo

Las evaluaciones frente a una base de referencia son útiles cuando se comunican por dispositivo y por flota, se respaldan con evidencia y se convierten en un plan de remediación con fechas.

Siga estudiando — capítulo 30 de 40

← Capítulo 29 (borrador) · Índice de capítulos del curso · Capítulo 31 (borrador) →