Capítulo 16 — Ingeniería de sistemas
Mapa de la lección
Lección 16 publicada. Mapa, ejemplo, EX031.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["16.1 El ciclo de vida y la V"]
N2["16.2 Necesidades, requisitos, trazabilidad"]
N3["16.3 Interfaces y configuración"]
N4["16.4 La seguridad como disciplina de la ingeniería d"]
N5["16.6 Actividad práctica"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX031"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["16.1 El ciclo de vida y la V"]
N2["16.2 Necesidades, requisitos, trazabilidad"]
N3["16.3 Interfaces y configuración"]
N4["16.4 La seguridad como disciplina de la ingeniería d"]
N5["16.6 Actividad práctica"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]
[Resultados de aprendizaje y conexión]
|
v
[16.1 El ciclo de vida y la V]
|
v
[16.2 Necesidades, requisitos, trazabilidad]
|
v
[16.3 Interfaces y configuración]
|
v
[16.4 La seguridad como disciplina de la ingeniería d]
|
v
[16.6 Actividad práctica]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX031]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted podrá (1) aplicar a un programa de seguridad el ciclo de vida de la ingeniería de sistemas: concepto, requisitos, arquitectura, diseño, integración, verificación, validación, operación y retirada; (2) descomponer las necesidades de las partes interesadas en requisitos de sistema y de subsistema con trazabilidad; (3) gestionar las interfaces y la configuración; y (4) integrar la ingeniería de seguridad en la ingeniería de sistemas en lugar de añadirla a posteriori. Se apoya en los capítulos 5 y 14 y enmarca toda la segunda mitad del libro.
16.1 El ciclo de vida y la V
La ingeniería de sistemas gestiona la complejidad pasando de las necesidades a los requisitos, a la arquitectura y a los componentes, y luego subiendo de nuevo a través de la integración y la verificación. El modelo en V empareja cada nivel de descomposición de la izquierda con un nivel de verificación de la derecha: las necesidades de las partes interesadas con la validación, los requisitos del sistema con la verificación del sistema, el diseño de subsistemas con las pruebas de integración, los componentes con las pruebas unitarias. El NASA Systems Engineering Handbook describe este ciclo de vida y sus revisiones técnicas. El desarrollo iterativo no abole la V; recorre V más pequeñas con más frecuencia.
16.2 Necesidades, requisitos, trazabilidad
Las necesidades de las partes interesadas son lo que las personas necesitan que el sistema logre, en su propio lenguaje: «el hospital no debe quedarse sin agua más de cuatro horas». Los requisitos del sistema traducen las necesidades en enunciados verificables sobre el sistema (capítulo 5). La trazabilidad vincula cada requisito hacia arriba con una necesidad y hacia abajo con los elementos de diseño y la verificación. Un requisito sin padre es un exceso innecesario o una necesidad oculta; una necesidad sin requisito es una brecha; un requisito sin verificación es una afirmación sin respaldo (capítulo 38 y Lab 14).
16.3 Interfaces y configuración
La mayoría de las fallas de los sistemas ocurren en las interfaces: entre subsistemas, organizaciones o personas. Un documento de control de interfaces especifica los datos, la temporización, los protocolos, la energía, las conexiones físicas y las responsabilidades de cada lado. La gestión de la configuración identifica cada elemento (hardware, versiones de firmware, ajustes, documentos), controla los cambios mediante revisión y conserva registros, de modo que se conozca el sistema tal como se construyó. En seguridad, una configuración desconocida es una superficie de ataque desconocida.
Los tres documentos de control de interfaces del TMRP cubren RTU–pasarela, pasarela–SCADA y SCADA–DMZ. Cada uno nombra un responsable a ambos lados.
16.4 La seguridad como disciplina de la ingeniería de sistemas
NIST SP 800-160 Vol. 1 Rev. 1 plantea la ingeniería de seguridad de sistemas como un conjunto de actividades de seguridad integradas en los procesos técnicos de la ingeniería de sistemas: necesidades de protección de las partes interesadas, requisitos de seguridad, diseño arquitectónico para la seguridad, verificación de las afirmaciones de seguridad, y operación y eliminación seguras. Su volumen complementario, SP 800-160 Vol. 2 Rev. 1, trata la ciberresiliencia: anticipar condiciones adversas, incluido el ataque, resistirlas, recuperarse de ellas y adaptarse.
El TMRP sigue este enfoque: N2 es una necesidad de protección descompuesta en R1 y R2, y cada uno tiene una verificación planificada.
16.5 Ejemplo resuelto: el TMRP como sistema (sintético)
Las necesidades de nivel superior del TMRP: N1, mantener abastecido el hospital (interrupción ≤ 4 h en los escenarios creíbles); N2, detectar y contener el uso indebido del control remoto; N3, recuperar la operación remota en un día hábil; N4, conservar la visibilidad del operador durante los cortes de la red eléctrica. Estas se descomponen en los requisitos R1–R9 presentados hasta ahora (telemetría autenticada, rechazo de repeticiones, límites de consigna, modo manual local, 24 h de autonomía del gabinete, restauración en 8 h, alarmas en menos de 60 s, integridad de los registros, alarma de dosificación independiente). El equipo redacta documentos de control de interfaces para RTU–pasarela, pasarela–SCADA y SCADA–DMZ, y pone bajo control de cambios todas las versiones de firmware y los archivos de configuración de las RTU. Cada requisito tiene ahora una necesidad padre y un método de verificación planificado.
16.6 Actividad práctica
Dibuje una matriz de trazabilidad N1–N4 × R1–R9 y marque el padre o los padres de cada requisito. Identifique cualquier necesidad con una cobertura débil. Use una cuadrícula simple con las necesidades como columnas y los requisitos como filas, y marque el padre o los padres de cada requisito. Algunos requisitos sirven a más de una necesidad: R5 apoya la visibilidad durante los cortes de la red eléctrica, y R1 apoya tanto la contención como el suministro al hospital. Cuando termine, cuente los requisitos de cada necesidad. Una necesidad respaldada por un solo requisito merece una segunda mirada, porque una sola prueba fallida la dejaría sin respaldo en el expediente.
16.7 Errores comunes y límites
- Requisitos redactados después del diseño para justificarlo.
- Interfaces sin responsable.
- Configuración conocida solo por el ingeniero de puesta en marcha.
- Requisitos de seguridad en un documento aparte, nunca trazados ni verificados.
- Tratar el modelo en V como una excusa de cascada para aplazar las pruebas.
En el TMRP cada uno de estos errores tiene una contramedida: los requisitos se trazan hasta N1–N4, cada interfaz tiene un responsable y el firmware y la configuración de las RTU están bajo control de cambios. La verificación se planifica para cada requisito antes de que empiece el diseño, de modo que la V no se usa como razón para aplazar las pruebas.
Ejercicios — capítulo 16
EX031 — Trace y encuentre brechas. Objetivo: construir y analizar una matriz de trazabilidad. Entradas: §16.5. Pasos: asigne cada uno de R1–R9 a su necesidad o necesidades padre; identifique qué necesidad depende de menos requisitos y proponga un requisito adicional. Evidencia esperada: matriz y propuesta. Rúbrica: 3 = mapeo defendible, necesidad más débil identificada con un nuevo requisito verificable; 2 = errores de mapeo; 1 = sin propuesta; 0 = nada.
EX032 — Control de interfaces. Objetivo: especificar una interfaz por completo. Entradas: la interfaz pasarela–SCADA. Pasos: enumere al menos ocho atributos de la interfaz con valores de ejemplo (elementos de datos, codificación, frecuencia, latencia, autenticación, manejo de errores, fuente de tiempo, responsabilidad, proceso de cambio). Evidencia esperada: tabla. Rúbrica: 3 = completa y coherente con los Labs 8 y 13; 2 = faltan atributos de seguridad o de responsabilidad; 1 = solo datos; 0 = nada.
Síntesis del capítulo
La ingeniería de sistemas pasa de las necesidades a sistemas verificados y validados mediante requisitos trazables, interfaces gestionadas y configuración controlada. La seguridad pertenece a esos procesos: las necesidades de protección se convierten en requisitos, los requisitos en arquitectura y diseño, y cada afirmación de seguridad necesita evidencia de verificación.
Siga estudiando — capítulo 16 de 50
← Capítulo 15 · Índice de capítulos del curso · Capítulo 17 →
Continúe con la siguiente lección escrita.