OpenCyber AcademyMapa de la lección
Lección 14 publicada. Mapa, ejemplo, EX027.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["14.1 Por qué importa el proceso"]
N2["14.2 Un ciclo de vida de desarrollo seguro"]
N3["14.3 Revisiones e inspecciones"]
N4["14.4 Dependencias y cadena de suministro"]
N5["14.5 Versiones para sistemas de larga vida"]
N6["14.7 Actividad práctica"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX027"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["14.1 Por qué importa el proceso"]
N2["14.2 Un ciclo de vida de desarrollo seguro"]
N3["14.3 Revisiones e inspecciones"]
N4["14.4 Dependencias y cadena de suministro"]
N5["14.5 Versiones para sistemas de larga vida"]
N6["14.7 Actividad práctica"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX027"]
[Resultados de aprendizaje y conexión]
|
v
[14.1 Por qué importa el proceso]
|
v
[14.2 Un ciclo de vida de desarrollo seguro]
|
v
[14.3 Revisiones e inspecciones]
|
v
[14.4 Dependencias y cadena de suministro]
|
v
[14.5 Versiones para sistemas de larga vida]
|
v
[14.7 Actividad práctica]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX027]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted podrá (1) aplicar un ciclo de vida de desarrollo seguro al software de infraestructura; (2) gestionar requisitos, revisiones de diseño, revisiones de código e inspecciones; (3) gestionar las dependencias y la cadena de suministro de software con SBOM y procedencia; y (4) planificar versiones y actualizaciones para software embebido y de TO de larga vida. Se apoya en los capítulos 5 y 9 y prepara los capítulos 28, 31 y 39.
14.1 Por qué importa el proceso
Brooks (1987) sostuvo que las dificultades esenciales del software (complejidad, conformidad, mutabilidad, invisibilidad) no admiten un único avance decisivo. El proceso no las elimina; hace visibles los errores pronto, cuando corregirlos es barato, y deja evidencia de que el trabajo se hizo. En la infraestructura crítica, la evidencia forma parte del producto: los reguladores, las aseguradoras y los propietarios de los activos la pedirán. Para la pasarela del TMRP, esa evidencia incluye la revisión del modelo de amenazas, los resultados de las pruebas y la compilación firmada, que van todos al expediente.
14.2 Un ciclo de vida de desarrollo seguro
El NIST Secure Software Development Framework (SP 800-218) agrupa las prácticas en preparar a la organización, proteger el software, producir software bien protegido y responder a las vulnerabilidades. En concreto: requisitos de seguridad y modelos de amenazas con cada funcionalidad; normas de codificación segura; revisión por pares; análisis estático automatizado y pruebas en la integración continua; sistemas de compilación protegidos; recepción y divulgación de vulnerabilidades; y parches con avisos claros. Los principios Secure by Design de CISA añaden que los fabricantes deben asumir la responsabilidad de los resultados de seguridad de sus clientes: valores predeterminados seguros, sin contraseñas predeterminadas, lenguajes con seguridad de memoria cuando sea factible.
14.3 Revisiones e inspecciones
Fagan (1976) describió inspecciones formales de diseño y de código con roles y listas de comprobación definidos, e informó de que encontraban defectos antes y con menor costo que las pruebas. La revisión de código moderna es más ligera, pero conserva los principios: una segunda persona competente lee cada cambio, con una lista de comprobación que incluye la validación de entradas, la autenticación, el manejo de errores y el registro. Las métricas de complejidad, como la complejidad ciclomática de McCabe (McCabe, 1976), señalan las funciones difíciles de probar.
En LRWA, cada cambio en el código de la pasarela lo lee un segundo ingeniero con una lista de comprobación.
14.4 Dependencias y cadena de suministro
La mayor parte del software se ensambla a partir de componentes de terceros. Una lista de materiales de software (SBOM) los enumera para que, cuando se anuncie una vulnerabilidad, pueda saber si le afecta (recursos sobre SBOM de CISA). La procedencia, evidencia verificable de cómo y a partir de qué se construyó un artefacto, protege contra compilaciones manipuladas; el marco SLSA define niveles de integridad de la compilación, y las compilaciones reproducibles permiten a terceros independientes confirmar que un binario corresponde a su código fuente.
14.5 Versiones para sistemas de larga vida
El software de TO puede mantenerse durante veinte años. Planifique: actualizaciones firmadas; reversión; despliegue por etapas (banco de pruebas, un sitio, flota); ventanas de compatibilidad; fechas de fin de soporte publicadas con antelación; y un proceso de actualización que funcione cuando un sitio solo es alcanzable de forma intermitente. Un mecanismo de actualización es en sí mismo una superficie de ataque y debe estar autenticado. Para el TMRP, el plan es concreto: la pasarela pasa del banco a PS2 y luego a PS1, se conserva una imagen de reversión en cada etapa, y las actualizaciones deben llegar a estaciones que solo son alcanzables de forma intermitente por LTE. Como las pasarelas están registradas como deuda técnica con un horizonte de tres años, la fecha de fin de soporte se publica desde el principio.
14.6 Ejemplo resuelto: el proyecto de la pasarela de telemetría (sintético)
El TMRP debe construir una pequeña pasarela que añada autenticación HMAC para las RTU heredadas de PS1 y PS2. El plan: los requisitos R1, R2 y R7, trazados hasta las pruebas; un modelo de amenazas revisado por un segundo ingeniero; solo la biblioteca estándar de Python, evitando dependencias de terceros; análisis estático y pruebas unitarias en la integración continua; compilaciones en un ejecutor dedicado, con artefactos firmados y una SBOM (trivialmente corta en este caso); despliegue en un banco, luego en PS2 y luego en PS1; y una imagen de reversión conservada. Cada paso deja un registro en el expediente de evidencia (capítulo 48).
14.7 Actividad práctica
Escriba un plan de una página, mapeado al SSDF, para una pequeña herramienta que haya escrito: para cada uno de los cuatro grupos de prácticas, enumere dos prácticas concretas y la evidencia que produce cada una. Elija algo real que haya escrito, como su analizador del Lab 3, para que las prácticas sean concretas. Para cada práctica, nombre la evidencia que deja: un registro de revisión, un informe de pruebas, una compilación firmada o una plantilla de aviso. Si una práctica no dejara ninguna evidencia, cámbiela o admita que es solo una intención. Compare su plan con el plan de la pasarela del TMRP y anote una práctica que añadiría.
14.8 Errores comunes y límites
- Documentos de proceso sin las prácticas que describen.
- Revisión de código sin lista de comprobación o sin autoridad para bloquear.
- Dependencias descargadas en tiempo de compilación sin fijar versiones ni procedencia.
- Mecanismos de actualización sin autenticación ni reversión.
- Ninguna fecha de fin de soporte publicada.
El plan de la pasarela del TMRP se redactó para evitar cada uno de estos errores. Usa solo la biblioteca estándar, así que no hay dependencias sin fijar; las revisiones siguen una lista de comprobación; las compilaciones se firman con una SBOM; el despliegue conserva una imagen de reversión; y las pasarelas tienen un horizonte publicado de tres años.
Ejercicios — capítulo 14
EX027 — Lista de comprobación de revisión. Objetivo: crear una lista de comprobación de revisión para el código de infraestructura. Entradas: el código del Lab 3 y del Lab 8. Pasos: escriba una lista de diez puntos y aplíquela a ambos laboratorios, registrando un hallazgo para cada uno. Evidencia esperada: lista y dos hallazgos. Rúbrica: 3 = lista específica (validación de entradas, comparación en tiempo constante, manejo de claves, caminos de error, registro, límites) y hallazgos reales; 2 = lista genérica; 1 = sin hallazgos; 0 = nada.
EX028 — Simulacro de respuesta con SBOM. Objetivo: usar una SBOM en la respuesta a una vulnerabilidad. Entradas: una SBOM sintética que enumera libmodbus 3.1.6, openssl 3.0.8 y zlib 1.2.13 para el firmware de RTU-B, y un aviso sobre uno de ellos. Pasos: describa los pasos de triaje desde el aviso hasta la decisión, incluido cómo determina la explotabilidad en su despliegue. Evidencia esperada: procedimiento. Rúbrica: 3 = coincidencia, análisis de alcanzabilidad, contacto con el proveedor, control compensatorio, comunicación; 2 = sin alcanzabilidad; 1 = «actualizar todo»; 0 = nada.
Síntesis del capítulo
El proceso hace visibles los errores pronto y deja evidencia. Use un marco de desarrollo seguro reconocido, revise con listas de comprobación, mida la complejidad y trate las dependencias y las compilaciones como parte de su superficie de ataque, con SBOM y procedencia. Diseñe las versiones y las actualizaciones para décadas, con autenticación, despliegue por etapas y reversión.