Capítulo 39 — Seguridad de TO, IoT y sistemas ciberfísicos: mantenibilidad

Mapa de la lección

Lección 39 publicada. Mapa, ejemplo, EX115.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["39.1 Cambios constantes"]
  N2["39.2 Adaptadores delgados"]
  N3["39.3 Responsabilidad"]
  N4["Nota práctica"]
  N5["39.1b Planes de obsolescencia y borrado"]
  N6["Nota de campo: bloqueo por vacaciones"]
  N7["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX115"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["39.1 Cambios constantes"]
  N2["39.2 Adaptadores delgados"]
  N3["39.3 Responsabilidad"]
  N4["Nota práctica"]
  N5["39.1b Planes de obsolescencia y borrado"]
  N6["Nota de campo: bloqueo por vacaciones"]
  N7["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]

[Resultados de aprendizaje]
    |
    v
[39.1 Cambios constantes]
    |
    v
[39.2 Adaptadores delgados]
    |
    v
[39.3 Responsabilidad]
    |
    v
[Nota práctica]
    |
    v
[39.1b Planes de obsolescencia y borrado]
    |
    v
[Nota de campo: bloqueo por vacaciones]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX115]

Resultados de aprendizaje

Usted podrá (1) presupuestar las actualizaciones de políticas y dependencias; (2) mantener delgados los adaptadores; (3) documentar la responsabilidad, incluida la cobertura durante las vacaciones.

39.1 Cambios constantes

Las técnicas de ATT&CK for ICS, los firmwares de los PLC y las matrices de soporte de los HMI de los proveedores cambian. Reserve tiempo de calendario para las actualizaciones; fije las versiones y vigile los avisos de seguridad. En ABP, Lena mantiene una página de dependencias que enumera la versión de ATT&CK for ICS que usa el asignador, las revisiones de firmware del PLC-A y del SIS-B y las versiones admitidas por el proveedor del HMI. Una suscripción a los avisos de los proveedores alimenta una revisión semanal, y cada versión fijada tiene una fecha de revisión. Cuando cambia la lista de técnicas, el plan de cobertura se reconstruye a partir de la nueva versión antes de la siguiente evaluación, para que las 44 técnicas planificadas nunca remitan en silencio a un catálogo desactualizado.

39.2 Adaptadores delgados

Aísle los SDK de terceros detrás de interfaces para que las actualizaciones no reescriban el núcleo del almacén de hallazgos. El equipo de Lena lo aprendió del adaptador de alarmas basado en extracción de pantalla, que se rompía con cada actualización del HMI y tocaba código mucho más allá de su propósito. El CNHP coloca ahora cada biblioteca de proveedor detrás de una pequeña interfaz propiedad del equipo, con pruebas de contrato que usan salidas grabadas del proveedor. Cuando un proveedor cambia su biblioteca, solo cambian el adaptador y sus pruebas; la función de permiso, el almacén de hallazgos y el código del expediente quedan intactos, y las notas de versión pueden decir exactamente qué parte se movió.

39.3 Responsabilidad

Cada servicio tiene un equipo responsable nombrado y un respaldo. CODEOWNERS impone la revisión. La falta de cobertura durante las vacaciones bloquea la publicación de una versión.

Caso sintético — Ashford Batch Plant. El asignador de ATT&CK for ICS es un adaptador; actualizar la lista de técnicas es una solicitud de incorporación de cambios de datos, no una reescritura.

En ABP, la página de cada servicio del CNHP nombra a un responsable y a un respaldo con nombre y apellido, no con un alias de equipo. Antes de una versión, las páginas se contrastan con el calendario de permisos, y una versión sin cobertura durante la siguiente ventana se retiene hasta que se forme a alguien.

39.4 Errores y límites

Las herramientas huérfanas se pudren hasta convertirse en museos de fallo abierto. El adaptador de alarmas basado en extracción de pantalla de ABP es el ejemplo que usa Lena: solo un ingeniero lo entendía, necesitó once correcciones en un año y fallaba en silencio cada vez que cambiaba el HMI. Una herramienta sin responsable deja de recibir parches, y cuando se rompe nadie se da cuenta de si falla de forma cerrada o abierta. La regla de Lena es que una herramienta sin responsable y sin respaldo la adopta una persona nombrada en el plazo de un mes o se retira con una fecha de borrado publicada.

Nota práctica

Escriba una nota sobre el factor autobús: quién puede publicar versiones, quién entiende permit(), quién puede restaurar el almacén sellado. Si la respuesta es una sola persona, programe formación cruzada antes de la siguiente temporada.

39.1b Planes de obsolescencia y borrado

Anuncie con fechas la obsolescencia de las API; mantenga periodos de funcionamiento doble. La mantenibilidad incluye saber retirar una herramienta: exportar los expedientes, revocar las credenciales, archivar el código. El calendario del CNHP reserva un mes anual de actualización de dependencias, fuera de la parada general de la planta, para que las versiones fijadas por CVE no esperen a una emergencia. Las sesiones de formación cruzada usan los mismos datos de prueba sintéticos que el laboratorio I, de modo que un respaldo practica con las entradas con las que se juzgará la versión; tras una sesión, el respaldo formado ejecutó solo el laboratorio I y la versión retenida salió.

Lena aplica este plan a todas las herramientas del CNHP, incluido el adaptador sustituido. Su retirada se anunció con antelación.

Nota de campo: bloqueo por vacaciones

Una versión quedó bloqueada porque la única persona que entendía permit() estaba de permiso sin un respaldo formado. La formación cruzada con los datos de prueba del laboratorio I a la semana siguiente levantó el bloqueo. La mantenibilidad consiste sobre todo en que las personas puedan irse de vacaciones.

Los códigos de motivo obsoletos siguen siendo legibles para los consumidores durante una versión completa después de que los productores dejen de emitirlos.

La fecha de borrado se anuncia en la página del servicio con al menos una versión de antelación.

39.5 Ejemplo resuelto: eliminar un adaptador frágil (ABP sintética)

El CNHP tenía un adaptador a medida que analizaba la exportación de alarmas del proveedor del HMI mediante extracción de pantalla. Cada actualización del HMI lo rompía, y solo un ingeniero lo entendía. La revisión de mantenibilidad de Lena mide los cambios (11 correcciones en un año), la responsabilidad (una persona) y el radio de impacto (las estadísticas de alarmas de toda la planta). Lo sustituye por la interfaz de alarmas OPC UA admitida por el proveedor, mantiene el adaptador en solo lectura durante una versión como respaldo, publica una fecha de borrado y redacta el procedimiento para que un segundo ingeniero pueda operar la nueva vía. Menos piezas a medida significa menos fallos silenciosos en la evidencia de seguridad.

Ejercicios — capítulo 39

• EX115 — Fijar. ¿Cómo fija el monitor para una ventana y permite aun así los parches de seguridad? Rúbrica: 3 = versión fijada + minilaboratorio I para la corrección urgente; 2 = parcial; 1 = siempre la última; 0 = nada.
• EX116 — Adaptador. Un método de una interfaz StoragePort. Rúbrica: 3 = p. ej., put_evidence(hash,bytes); 2 = vago; 1 = llamada concreta a un SDK; 0 = nada.
• EX117 — Responsable. Línea de responsabilidad del monitor serie. Rúbrica: 3 = equipo + respaldo + contacto; 2 = equipo; 1 = «el equipo»; 0 = nada.

Síntesis del capítulo

Las versiones fijadas, los adaptadores y los responsables nombrados mantienen vivas las herramientas de forma segura.

Siga estudiando — capítulo 39 de 50

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