Capítulo 31 — Infraestructura crítica y seguridad sectorial: casos avanzados

Mapa de la lección

Lección 31 publicada. Mapa, ejemplo, EX061.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["31.1 Más allá del titular"]
  N2["31.2 Cadenas de suministro"]
  N3["31.3 Un marco de comparación"]
  N4["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX061"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["31.1 Más allá del titular"]
  N2["31.2 Cadenas de suministro"]
  N3["31.3 Un marco de comparación"]
  N4["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[Resultados de aprendizaje y conexión]
    |
    v
[31.1 Más allá del titular]
    |
    v
[31.2 Cadenas de suministro]
    |
    v
[31.3 Un marco de comparación]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX061]

Resultados de aprendizaje y conexión

Después de este capítulo usted podrá (1) analizar casos en los que el daño llegó a través del proceso físico, los sistemas de seguridad o los proveedores compartidos, y no mediante el robo de datos; (2) comparar casos sistemáticamente según la causa, la ruta, la consecuencia, la detección y la recuperación; (3) razonar sobre el riesgo de la cadena de suministro y de concentración entre sectores; y (4) extraer lecciones defendibles y acotadas para un operador. Se apoya en el capítulo 20 y en los capítulos 21–30, y prepara el proyecto comparativo (capítulo 34).

31.1 Más allá del titular

El análisis avanzado de casos no pregunta «¿qué ocurrió?», sino «¿qué supuesto falló y está presente aquí ese supuesto?». Tres familias de casos ilustran supuestos en los que se apoyan los servicios críticos. Manipulación del proceso diseñada para pasar inadvertida. El análisis de Langner sobre Stuxnet describe un malware que manipulaba controladores industriales que accionaban centrifugadoras mientras mostraba a los operadores valores de apariencia normal (Langner, 2011). Supuesto fallido: lo que ve el operador es lo que hace el proceso. Lección trasladable: rutas de medición independientes para las variables críticas y límites físicos que no dependan del controlador.

Ataques a la capa de seguridad funcional. El análisis de TRITON/HatMan describe un malware dirigido contra un controlador de un sistema instrumentado de seguridad (CISA MAR-17-352-01). Supuesto fallido: el sistema de seguridad funcional es independiente de las redes a las que puede llegar un atacante. Lección: imponer físicamente los modos de programación del SIS (interruptores de llave), separar las redes del SIS y tratar las estaciones de ingeniería del SIS como los activos más sensibles.

Falla de una dependencia compartida. La actualización de seguridad defectuosa de julio de 2024, que bloqueó unos 8,5 millones de dispositivos Windows (Microsoft, 2024), y la parada de precaución de 2021 tras un ransomware en la red de TI de una empresa de oleoductos (CISA AA21-131A) muestran daños que llegan a través de las dependencias y no del sistema de control. Supuesto fallido: nuestro riesgo está acotado por nuestros propios sistemas. Lección: cartografiar la concentración (muchos servicios que dependen de un mismo producto, proveedor o región de la nube), escalonar las actualizaciones y planificar una operación degradada que no necesite la TI de negocio.

31.2 Cadenas de suministro

Todo operador ejecuta software y hardware construidos por otros, a menudo a través de largas cadenas de componentes. Entre las medidas públicas figuran las listas de materiales de software (SBOM), que enumeran los componentes (CISA SBOM), los marcos para la integridad de la compilación como SLSA (SLSA), las prácticas de desarrollo seguro para los proveedores (NIST SSDF, SP 800-218) y las expectativas de «seguridad desde el diseño» para los fabricantes (CISA Secure by Design). En el nivel de grado, las palancas del operador son principalmente contractuales y arquitectónicas: exigir SBOM y divulgación de vulnerabilidades, probar las actualizaciones antes de desplegarlas, escalonar los despliegues, conservar la capacidad de revertirlos y evitar que la falla de un solo proveedor detenga a la vez varias funciones críticas.

31.3 Un marco de comparación

Tabla de la lección; desplázate para ver todas las columnas →

Lea primero la fila «Supuesto fallido»; es la parte trasladable. Cada control genérico aborda ese supuesto y no la técnica concreta.

31.4 Ejemplo resuelto: concentración en Calder (sintético)

Este caso es sintético. La CRP encuesta a sus miembros: el CVH, el CEDC y Calder Mutual usan el mismo producto de seguridad de endpoint, configurado con actualizaciones automáticas; el CEDC y CT usan la misma región de la nube para el CAD y la programación; CW y CPN usan el mismo integrador de TO, con acceso remoto a ambos. Eventos únicos que podrían afectar a la vez a varios sectores: una actualización defectuosa del endpoint (hospital, despacho y banco simultáneamente); una caída de la región de la nube (despacho y transporte); un compromiso del integrador (agua y electricidad). Recomendaciones: escalonar las actualizaciones del endpoint (primero un pequeño grupo canario, las consolas críticas de despacho al final); confirmar que el respaldo de papel y radio del CEDC no necesita la nube; exigir aprobación por sesión y credenciales separadas para el integrador en cada operador, e incluirlo en el ejercicio conjunto. La cuestión no es que estos proveedores sean malos; es que el riesgo del condado es compartido y debe analizarse de forma conjunta.

31.5 Errores comunes y límites

• Extraer lecciones de detalles llamativos pero sin fuentes.
• Tratar las operaciones estatales dirigidas como la amenaza típica para todo operador.
• Ignorar las fallas accidentales de dependencias compartidas porque no interviene ningún adversario.
• Enseñar técnicas en lugar de supuestos fallidos.

El ejemplo de concentración de Calder los evita: no usa ningún detalle técnico, trata una actualización accidental del endpoint con la misma seriedad que un compromiso del integrador y no presupone un actor estatal. Repetir afirmaciones sin fuentes sobre el origen de Stuxnet sería el primer error. El cuarto error convertiría una lección de TRITON en una descripción de cómo llegar a un controlador de seguridad.

Ejercicios — capítulo 31

EX061 — Encuentre el supuesto. Objetivo: abstraer un caso. Entradas: el caso de Ucrania 2015 (capítulo 20). Pasos: indique dos supuestos que fallaron y uno que se mantuvo y ayudó a la recuperación, con respaldo de las fuentes. Evidencia esperada: tres supuestos. Rúbrica: 3 = p. ej., el acceso remoto y las estaciones de los operadores eran de confianza (falló), los centros de atención telefónica seguirían accesibles (falló), la operación manual era posible (se mantuvo), cada uno vinculado a la alerta de CISA; 2 = dos; 1 = uno; 0 = nada.

EX062 — Mapa de concentración. Objetivo: identificar las dependencias compartidas. Entradas: la encuesta de concentración de Calder del ejemplo resuelto de este capítulo. Pasos: dibuje un mapa bipartito (proveedores ↔ operadores), marque el proveedor con mayor alcance y proponga una medida por proveedor. Evidencia esperada: mapa y medidas. Rúbrica: 3 = el producto de endpoint alcanza a tres operadores de tres sectores (el mayor), medidas específicas (actualizaciones escalonadas, independencia de los respaldos, controles sobre el integrador); 2 = mapa sin medidas; 1 = lista; 0 = nada.

Síntesis del capítulo

Los casos avanzados enseñan a través de los supuestos fallidos: lo que ven los operadores es real, los sistemas de seguridad son independientes, el riesgo está acotado por nuestros propios sistemas. Compare los casos según la causa, la ruta, la consecuencia y el supuesto; gestione el riesgo de la cadena de suministro y de concentración de forma conjunta entre operadores; y convierta las lecciones en controles genéricos y no en conocimiento de técnicas.