OpenCyber Academy
Ingeniería · Capítulo 20 · Español
Código del curso: OCA-138Capítulo 20: OCA-138-C020

Capítulo 20 — Infraestructura crítica y seguridad sectorial: contexto de ingeniería

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 20 publicada. Mapa, ejemplo, EX039.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["20.1 Qué hace «crítica» a una infraestructura"]
  N2["20.2 Los sectores como sistemas de ingeniería"]
  N3["20.3 Interdependencia"]
  N4["20.4 Aprender de los incidentes documentados"]
  N5["20.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX039"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["20.1 Qué hace «crítica» a una infraestructura"]
  N2["20.2 Los sectores como sistemas de ingeniería"]
  N3["20.3 Interdependencia"]
  N4["20.4 Aprender de los incidentes documentados"]
  N5["20.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX039"]
[Resultados de aprendizaje y conexión]
    |
    v
[20.1 Qué hace «crítica» a una infraestructura]
    |
    v
[20.2 Los sectores como sistemas de ingeniería]
    |
    v
[20.3 Interdependencia]
    |
    v
[20.4 Aprender de los incidentes documentados]
    |
    v
[20.6 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX039]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted podrá (1) describir cómo se define la infraestructura crítica y cómo se organiza en sectores, así como el panorama regulatorio en el que trabajan los ingenieros; (2) caracterizar los sectores por sus procesos físicos, sus unidades de consecuencia y su tecnología; (3) describir las interdependencias entre sectores; y (4) aprender de los incidentes documentados al nivel que sus fuentes públicas permiten. Es el puente entre los fundamentos (capítulos 1–19) y los capítulos del campo (21–50).

20.1 Qué hace «crítica» a una infraestructura

Los gobiernos designan como críticos los activos, sistemas y redes cuya incapacidad dañaría gravemente la seguridad, la economía, la salud pública o la seguridad de las personas. Estados Unidos identifica dieciséis sectores de infraestructura crítica y, más recientemente, un conjunto de funciones críticas nacionales que atraviesan las organizaciones. La Directiva NIS2 (2022/2555) de la Unión Europea fija obligaciones de ciberseguridad para las entidades esenciales e importantes, y la Directiva CER (2022/2557) aborda de forma más amplia la resiliencia de las entidades críticas. Las normas sectoriales añaden detalle: las normas NERC CIP para los sistemas eléctricos mayoristas de Norteamérica, los requisitos de evaluación de riesgos de la America's Water Infrastructure Act de 2018 para los sistemas comunitarios de agua de Estados Unidos, DORA (2022/2554) para las finanzas de la UE y los HHS Healthcare and Public Health Cybersecurity Performance Goals. Todo esto cambia; cite versión y fecha, y vuelva a verificar.

20.2 Los sectores como sistemas de ingeniería

Cada sector tiene un proceso físico o de servicio, una unidad de consecuencia y una tecnología característica.

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

Sector Proceso Unidad de consecuencia Tecnología típica
Agua Tratar y distribuir agua Personas sin agua segura × horas PLC/RTU, SCADA, dosificación, telemetría
Electricidad Generar, transmitir, distribuir MW o clientes interrumpidos × horas Relés de protección, EMS/DMS, automatización de subestaciones
Salud Diagnosticar y tratar Atención retrasada, derivaciones, daño Historia clínica electrónica, dispositivos médicos, sistemas del edificio
Transporte Mover personas y mercancías Viajes interrumpidos, incidentes de seguridad Señalización, control de tráfico, venta de billetes
Finanzas Compensar y liquidar Transacciones fallidas o retrasadas Sistemas de pago, infraestructuras de mercado
Comunicaciones Transportar voz y datos Abonados afectados × horas Redes troncales, acceso radio, sincronización

La tabla es una simplificación para orientarse en ingeniería; cada fila es una carrera profesional.

20.3 Interdependencia

Rinaldi, Peerenboom y Kelly (2001) clasifican las interdependencias en físicas, cibernéticas, geográficas y lógicas. El agua necesita electricidad para el bombeo; el restablecimiento eléctrico necesita comunicaciones; los hospitales necesitan agua, energía y comunicaciones; casi todo necesita una hora exacta. La interdependencia convierte las fallas locales en regionales y los proveedores compartidos en causas comunes. La actualización defectuosa de CrowdStrike de julio de 2024, que según la estimación de Microsoft afectó a unos 8,5 millones de dispositivos Windows (Microsoft, 2024), no fue un ataque, pero perturbó a la vez aerolíneas, hospitales y otros servicios a través de una dependencia de software compartida.

20.4 Aprender de los incidentes documentados

Los informes públicos de incidentes son valiosos y parciales. Úselos al nivel de sus fuentes. El incidente de Colonial Pipeline de 2021 implicó ransomware en la TI de gestión; la empresa detuvo las operaciones del oleoducto como precaución, lo que recuerda que la dependencia de las operaciones respecto de los sistemas de TI (facturación, programación) puede detener el servicio físico sin ningún compromiso de la TO. El ataque a la red eléctrica ucraniana de 2015 usó acceso remoto para operar interruptores y dañó las capacidades de recuperación. El brote de WannaCry de 2017 perturbó los servicios del NHS en Inglaterra. Cada uno tiene detalles documentados y preguntas abiertas; cuando los primeros relatos se revisaron, como en Oldsmar, cite ambos.

20.5 Ejemplo resuelto: situar a LRWA en su contexto (sintético)

LRWA es una empresa de agua con un hospital entre sus clientes críticos. Su unidad de consecuencia son las personas-hora sin agua segura, ponderadas para los usuarios vulnerables; el almacenamiento propio de St Brenna's da unas cuatro horas de reserva. Sus interdependencias: electricidad (bombeo, tratamiento), comunicaciones (telemetría LTE), suministro químico (cloro) y tiempo (correlación de registros). Se supone que su contexto regulatorio incluye una obligación de evaluación de riesgos y resiliencia similar a la de la AWIA. El alcance del TMRP queda definido por todo esto: el programa no consiste en «proteger el SCADA», sino en «mantener el agua segura llegando a las personas en condiciones adversas creíbles, incluido un ataque».

20.6 Actividad práctica

Elija un sector distinto del agua. Solo con fuentes públicas, construya con más detalle su fila de §20.2: tres unidades de consecuencia, tres tecnologías típicas, dos regulaciones clave con versión y fecha, y un incidente documentado con su fuente. Mantenga el perfil al nivel de sus fuentes. Para cada regulación, dé la versión, la fecha en que la consultó y las entidades que abarca. Para el incidente, indique solo lo que dice el informe citado y anote cualquier revisión posterior, como en Oldsmar. Después compare la unidad de consecuencia de su sector con las personas-hora sin agua segura de LRWA, y anote una interdependencia que su sector comparta con el agua, como la electricidad, las comunicaciones o el tiempo.

20.7 Errores comunes y límites

El propio contexto de LRWA muestra por qué esto importa. Su condición de crítica procede de St Brenna's y de sus demás clientes, no de la tecnología que opera. Sus operaciones dependen de la electricidad, de LTE, del suministro de cloro y de una hora exacta, de modo que analizar el agua de forma aislada pasaría por alto la dependencia oculta del alimentador encontrada antes. Cualquier obligación regulatoria en la que se apoye debe citarse con versión y fecha.

Ejercicios — capítulo 20

EX039 — Perfil de un sector. Objetivo: elaborar el perfil de un sector a partir de fuentes públicas. Entradas: §20.6. Pasos: elabore el perfil con citas. Evidencia esperada: una página. Rúbrica: 3 = exacto, citado, con unidades de consecuencia medibles y el incidente descrito dentro de sus fuentes; 2 = una afirmación sin citar; 1 = genérico; 0 = nada.

EX040 — Dependencia compartida. Objetivo: razonar sobre las causas comunes entre sectores. Entradas: la caída de CrowdStrike de julio de 2024 tal como la describe Microsoft. Pasos: explique en 200 palabras por qué una actualización de software no maliciosa provocó una perturbación intersectorial, qué propiedad de ingeniería revela y una práctica de diseño que limite estos eventos. Evidencia esperada: texto. Rúbrica: 3 = dependencia compartida o causa común, componente privilegiado con actualización automática, despliegue por etapas o diversidad como práctica, afirmaciones dentro de las fuentes; 2 = práctica genérica; 1 = lo llama ataque; 0 = nada.

Síntesis del capítulo

La infraestructura crítica se define por las consecuencias. Los sectores difieren en procesos, unidades de consecuencia y tecnología, pero comparten la interdependencia respecto de la energía, las comunicaciones, el tiempo y los proveedores comunes. Trabaje dentro de las regulaciones según versión y fecha, aprenda de los incidentes solo hasta donde llegan sus fuentes y defina cada programa de seguridad por el servicio y las personas que protege.

Respuestas desarrolladas

EX039. Se evalúa con la rúbrica; por ejemplo, distribución eléctrica: unidades de consecuencia: clientes interrumpidos × horas, MW no suministrados, clientes críticos afectados; tecnologías: relés de protección, sistemas de gestión de la distribución, RTU de subestaciones; regulaciones: normas NERC CIP (cite versión y fecha) y NIS2 (2022/2555) para los operadores de la UE; incidente: Ucrania 2015, descrito a partir de CISA IR-ALERT-H-16-056-01.

EX040. Modelo: un único producto de seguridad con acceso privilegiado al núcleo estaba instalado en muchas organizaciones de distintos sectores y se actualizaba automáticamente; una actualización de contenido defectuosa hizo fallar a la vez los equipos Windows, y Microsoft estimó que resultaron afectados unos 8,5 millones de dispositivos. La propiedad es una causa común a través de una dependencia compartida, privilegiada y actualizada automáticamente. Práctica: despliegues por etapas (canario) de las actualizaciones, por parte de los proveedores y, cuando sea posible, controlados por los clientes en los sistemas críticos, más procedimientos de recuperación que no dependan de los equipos afectados. No fue un ataque.