Capítulo 35 — Taller de diseño II | 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 35 publicada. Mapa, ejemplo, EX069.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["35.1 Del concepto al diseño de detalle"]
  N2["35.2 Argumentos de aseguramiento"]
  N3["35.3 Encargo del Taller II sintético"]
  N4["35.5 Actividad práctica"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX069"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["35.1 Del concepto al diseño de detalle"]
  N2["35.2 Argumentos de aseguramiento"]
  N3["35.3 Encargo del Taller II sintético"]
  N4["35.5 Actividad práctica"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX069"]

[Resultados de aprendizaje y conexión]
    |
    v
[35.1 Del concepto al diseño de detalle]
    |
    v
[35.2 Argumentos de aseguramiento]
    |
    v
[35.3 Encargo del Taller II sintético]
    |
    v
[35.5 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX069]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted podrá (1) llevar un diseño desde el concepto hasta el diseño de detalle con una justificación cuantitativa; (2) integrar los análisis de confiabilidad, seguridad funcional, seguridad, desempeño y coste en un único argumento; (3) construir un argumento de aseguramiento estructurado que vincule las afirmaciones con la evidencia; y (4) defender las decisiones del diseño de detalle ante una revisión. Integra los capítulos 26–34 y prepara los capítulos 36–40.

35.1 Del concepto al diseño de detalle

El Taller I seleccionó un concepto. El Taller II lo detalla: componentes concretos, configuraciones, interfaces, procedimientos y verificación. Vuelven todas las cifras de los capítulos anteriores: tiempos de autonomía (capítulos 1 y 6), dimensionamiento de baterías (capítulo 3), tasas base (capítulo 7), latencia (capítulo 11), árbol de fallos (capítulo 23), métricas de detección (capítulo 29), disponibilidad (capítulo 32) y colas (avance del capítulo 36). Un diseño de detalle es coherente cuando estas cifras concuerdan entre sí y con los requisitos. En el TMRP, el dimensionamiento de las baterías, las 72 horas de operación automática local, la reserva de cuatro horas del hospital y el tiempo de recuperación deben contar la misma historia; el EX069 muestra qué ocurre cuando una de ellas no lo hace.

35.2 Argumentos de aseguramiento

Un caso de aseguramiento es un argumento estructurado de que un sistema cumple una afirmación, respaldado por evidencia. Tiene una afirmación principal («el TMRP mantiene abastecido al hospital en escenarios creíbles, incluida la falsificación de órdenes remotas»), subafirmaciones (cada requisito se cumple; los riesgos residuales son aceptables), argumentos (por qué las subafirmaciones respaldan la afirmación) y evidencia (resultados de pruebas, análisis, revisiones). El modelo de argumentación de Toulmin —afirmación, datos, garantía, respaldo, cualificador, refutación (Toulmin, 1958/2003)— es una lente útil: qué evidencia respalda la afirmación, por qué es pertinente y qué la derrotaría. Los derrotadores explícitos («salvo que el centro SCADA esté comprometido») mantienen honesto el argumento.

35.3 Encargo del Taller II (sintético)

Elabore el diseño de detalle de la fase 1 del TMRP (PS2, PS3, PS4 y Hollin Hill): lista de componentes con sus funciones de seguridad; listas de permitidos de zonas y conductos; procedimiento de gestión de claves; procedimientos de manual local y de conmutación por error; racionalización de las nuevas alarmas de seguridad; plan de verificación; y un caso de aseguramiento para la afirmación principal con al menos cuatro subafirmaciones y derrotadores identificados. El encargo abarca los cuatro activos que más importan para St Brenna's: PS2 como piloto probado, PS3 y Hollin Hill como la vía del depósito y PS4 como alimentación directa. Las estaciones restantes y la planta de Fenwick vienen en fases posteriores, de modo que el caso de aseguramiento de la fase 1 debe decir con claridad que todavía no las cubre.

35.4 Ejemplo resuelto: una rama del caso de aseguramiento (sintético)

Subafirmación C2: las órdenes remotas falsificadas no pueden causar la pérdida del suministro al hospital. Argumento: las órdenes requieren un MAC válido por estación (R1) y un contador reciente (R2); incluso las órdenes aceptadas no pueden llevar el proceso más allá de los límites locales (R3); la pérdida de ambas vías de suministro exige además que falle el depósito del hospital (árbol de fallos). Evidencia: T1 y T2 aprobadas (banco y aceptación en el emplazamiento en PS2); T3 aprobada en v2; análisis de condicionamiento del Lab 9; revisión independiente de la gestión de claves. Derrotadores: (D1) servidores SCADA comprometidos: las órdenes son auténticas; se mitiga con los límites locales y la aprobación por dos personas de los cambios masivos, con el riesgo residual aceptado por el director de operaciones; (D2) clave de estación extraída de una RTU robada: limitada a una estación, detección mediante la alarma de manipulación, procedimiento de rotación. Cualificador: la afirmación se sostiene para los escenarios del registro de riesgos v1.2; no para un ataque físico contra ambas estaciones de bombeo.

35.5 Actividad práctica

Redacte el caso de aseguramiento completo para el encargo del Taller II y preséntelo a un panel al que se le haya pedido encontrar derrotadores. Entregue al panel el encargo, su lista de componentes y el caso de aseguramiento, y pídale que encuentre qué derrotaría cada subafirmación. Registre cada derrotador que encuentre, lo hubiera enumerado usted o no, y redacte una respuesta: evidencia que lo aborde, un cambio de diseño o una aceptación explícita con un responsable. Se esperan derrotadores como un centro SCADA comprometido o una clave de RTU robada; la tarea del panel es encontrar los que usted pasó por alto, como el mal uso del modo manual local.

35.6 Errores comunes y límites

Cifras incoherentes entre análisis.
Casos de aseguramiento con afirmaciones sin evidencia, o con evidencia sin argumento.
Derrotadores omitidos para que el caso parezca más sólido.
Diseño de detalle que modifica los requisitos en silencio.

El EX069 es un ejemplo del primer error dentro del propio TMRP: R6 pide ocho horas, pero el ensayo de recuperación midió doce. Un caso que afirmara R6 citando el ensayo sería incoherente, de modo que el caso registra R6 como no cumplido y explica por qué la afirmación sobre el hospital puede seguir sosteniéndose gracias a la operación automática local.

Ejercicios — capítulo 35

EX069 — Comprobación de coherencia. Objetivo: encontrar incoherencias entre análisis. Entradas: autonomía de las baterías de PS4 de 24 h (R5); reserva del hospital de 4 h; R6, restablecer la operación remota en 8 h; el ensayo del capítulo 47 muestra 12 h. Pasos: identifique qué afirmaciones entran en conflicto y qué significa el conflicto para el caso de aseguramiento. Evidencia esperada: análisis. Rúbrica: 3 = identifica que R6 no se cumple (12 > 8), que el suministro no depende de la operación remota (automático local), de modo que la afirmación sobre el hospital puede seguir sosteniéndose, y que el caso debe registrar R6 como fallido con un plan; 2 = parcial; 1 = no advierte lo de R6; 0 = nada.

EX070 — Encuentre un derrotador. Objetivo: cuestionar un argumento. Entradas: la subafirmación C2 del §35.4. Pasos: proponga otros dos derrotadores no enumerados y la evidencia o el cambio de diseño que respondería a cada uno. Evidencia esperada: dos derrotadores con sus respuestas. Rúbrica: 3 = derrotadores creíbles (p. ej., mal uso del modo manual local por un interno; compromiso del camino de actualización del firmware de la pasarela; fallo en la persistencia del contador) con respuestas específicas; 2 = uno débil; 1 = repite los ya enumerados; 0 = nada.

Síntesis del capítulo

El diseño de detalle hace que todas las cifras anteriores encajen. Un caso de aseguramiento conecta la afirmación principal con la evidencia mediante argumentos explícitos, con los cualificadores y los derrotadores enunciados abiertamente. La coherencia entre análisis y la honestidad sobre los derrotadores son lo que hace defendible un diseño de detalle.