Capítulo 37 — Infraestructura crítica y seguridad sectorial: operaciones

Mapa de la lección

Lección 37 publicada. Mapa, ejemplo, EX074.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["37.1 Operaciones de seguridad en la TO"]
  N2["37.2 Guías de actuación"]
  N3["37.3 Gestión de cambios, accesos y vulnerabilidades"]
  N4["37.4 Aprender sin culpabilizar"]
  N5["37.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX074"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["37.1 Operaciones de seguridad en la TO"]
  N2["37.2 Guías de actuación"]
  N3["37.3 Gestión de cambios, accesos y vulnerabilidades"]
  N4["37.4 Aprender sin culpabilizar"]
  N5["37.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX074"]

[Resultados de aprendizaje y conexión]
    |
    v
[37.1 Operaciones de seguridad en la TO]
    |
    v
[37.2 Guías de actuación]
    |
    v
[37.3 Gestión de cambios, accesos y vulnerabilidades]
    |
    v
[37.4 Aprender sin culpabilizar]
    |
    v
[37.6 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX074]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted podrá (1) diseñar operaciones de seguridad para la TO: supervisión, clasificación, escalado y coordinación con las operaciones del proceso; (2) redactar procedimientos operativos y guías de actuación que los operadores puedan ejecutar bajo presión; (3) gestionar los cambios, los accesos y las vulnerabilidades en las operaciones diarias; y (4) aprender de los incidentes y de los cuasiincidentes sin culpabilizar. Se apoya en los capítulos 18, 29 y 34 y prepara los capítulos 38 y 47.

37.1 Operaciones de seguridad en la TO

La supervisión de seguridad de la TO vigila el tráfico de red, los registros y los datos del proceso en busca de indicios de uso indebido. La clasificación en la TO difiere de la de TI: la primera pregunta no es «¿es esto malicioso?», sino «¿está seguro el proceso?». Por eso, las vías de escalado llegan a la sala de control y al jefe de operaciones de turno, además de al personal de seguridad. Muchas empresas de servicios no tienen un equipo de seguridad 24/7; la sala de control sí está atendida 24/7 y debe poder actuar ante las alarmas de seguridad con guías de actuación claras, escalando a especialistas de seguridad de guardia.

37.2 Guías de actuación

Una guía de actuación es un procedimiento breve y probado para una situación concreta: desencadenante, acciones de seguridad inmediatas, información que recopilar, decisiones y quién las toma, comunicaciones y vuelta a la normalidad. Escriba para un operador cansado a las 03:00: pasos numerados, puntos de decisión claros, números de teléfono, sin jerga. Pruebe cada guía en ejercicios y actualícela después de cada uso. Las orientaciones sobre gestión de incidentes como NIST SP 800-61 Rev. 3 ofrecen una estructura general; las guías de TO añaden pasos de seguridad del proceso.

La guía de actuación de la LRWA ante un cambio inesperado de consigna está redactada conforme a este criterio.

37.3 Gestión de cambios, accesos y vulnerabilidades

Las operaciones diarias mantienen el sistema en su estado de diseño: gestión de cambios (ningún cambio de configuración sin aprobación y registro); gestión de accesos (altas, cambios de puesto y bajas; sesiones de fabricantes aprobadas para cada uso); gestión de vulnerabilidades (seguir avisos como los avisos ICS de la CISA, evaluar su aplicabilidad, planificar la corrección, capítulo 12). La deriva —la acumulación de cambios no documentados— es la forma más común en que un sistema bien diseñado se vuelve inseguro.

En la LRWA, el script olvidado de informes corporativos que apareció en la revisión de flujos es un ejemplo de deriva, y el control de cambios en cada conducto es la forma en que el TMRP impide que esas vías reaparezcan.

37.4 Aprender sin culpabilizar

Los incidentes y los cuasiincidentes son evidencia sobre el sistema. Reason (2000) contrastó el enfoque centrado en la persona (culpar a los individuos) con el enfoque sistémico (defensas, barreras y condiciones latentes), y sostuvo que este último es más eficaz. Las revisiones posteriores a la acción preguntan qué ocurrió, por qué tenía sentido para las personas implicadas en aquel momento, qué defensas funcionaron o fallaron y qué va a cambiar. La culpa reprime la notificación, y los cuasiincidentes no notificados son lecciones perdidas.

En la LRWA, el técnico que conectó un portátil a la red de PS3 en el EX074 recibe este trato: la revisión pregunta por qué el servidor de salto le parecía demasiado lento y qué hizo posible el atajo.

37.5 Ejemplo resuelto: guía de actuación «cambio inesperado de consigna» (sintético)

Desencadenante: el SCADA muestra un cambio de consigna en cualquier estación que no coincide con una acción del operador en los últimos 5 minutos, o una pasarela registra fallos de MAC repetidos. Acciones de seguridad inmediatas: (1) contraste los valores del proceso de la estación con mediciones independientes; (2) si están fuera del rango normal, restablezca localmente la consigna anterior o pase a manual local a través del técnico de turno; (3) no desactive la telemetría remota. Recopilar: estación, hora, valores anterior y nuevo, extracto del registro de la pasarela, registro del operador. Decidir: el jefe de turno decide si desactiva las escrituras remotas en toda la flota (conmutador de configuración de las pasarelas). Comunicar: al responsable de seguridad de guardia en 30 minutos; al enlace con el hospital si PS3 o PS4 están afectadas. Vuelta a la normalidad: las escrituras remotas se reactivan solo cuando el responsable de seguridad de guardia está de acuerdo.

37.6 Actividad práctica

Ejecute la guía de actuación en un ejercicio de mesa con una secuencia guionizada de inyecciones (primero un único cambio de consigna, luego fallos de MAC en una segunda estación y, por último, una llamada del hospital por presión baja). Registre los tiempos de decisión y las ambigüedades, y revise la guía. Ejecute las inyecciones en orden y anote la hora de cada decisión. Observe en particular si el equipo mantiene en funcionamiento la telemetría remota, como exige la guía, y si el jefe de turno decide desactivar las escrituras remotas en toda la flota antes de que llegue la llamada del hospital. Registre cada punto en el que alguien preguntó qué quería decir la guía. Después del ejercicio de mesa, reescriba esos pasos y programe una segunda ejecución para comprobar las revisiones.

37.7 Errores comunes y límites

• Alarmas de seguridad dirigidas a un equipo que no está de servicio cuando saltan.
• Guías de actuación escritas para expertos y nunca probadas.
• Gestión de cambios eludida «temporalmente».
• Revisiones posteriores a la acción que terminan en «error del operador».

El diseño de la guía de la LRWA responde a estos errores: las alarmas de seguridad llegan a la sala de control, que está atendida a todas horas, y se llama al responsable de seguridad de guardia en 30 minutos. La guía se prueba en ejercicios de mesa, y el control de cambios no admite excepciones temporales. Las revisiones posteriores a la acción de la LRWA buscan condiciones latentes, como un servidor de salto lento, en lugar de terminar en un error del operador.

Ejercicios — capítulo 37

EX073 — Revisión de la guía de actuación. Objetivo: mejorar una guía de actuación. Entradas: §37.5. Pasos: identifique tres debilidades (p. ej., umbrales ambiguos, contactos que faltan, un valor por defecto inseguro) y reescriba los pasos afectados. Evidencia esperada: pasos revisados. Rúbrica: 3 = debilidades sustanciales corregidas con pasos ejecutables; 2 = cambios cosméticos; 1 = solo crítica; 0 = nada.

EX074 — Revisión de un cuasiincidente. Objetivo: realizar una revisión sin culpabilizar. Entradas: un técnico conectó un portátil a la red de control de PS3 para descargar registros, eludiendo el servidor de salto; el portátil no se había analizado. No hubo incidente posterior. Pasos: redacte una revisión de una página: qué ocurrió, por qué tenía sentido, qué defensas fallaron y qué cambios del sistema se proponen. Evidencia esperada: revisión. Rúbrica: 3 = explica la racionalidad local (servidor de salto lento, plazo), identifica las condiciones latentes (sin seguridad de puertos, sin una vía sencilla para los registros) y propone cambios del sistema; 2 = algo de culpa; 1 = «volver a formar al técnico»; 0 = nada.

Síntesis del capítulo

Las operaciones de seguridad de la TO empiezan por la seguridad del proceso y encauzan el escalado a través de la sala de control. Las guías de actuación deben ser breves, estar probadas y poder ejecutarse bajo presión. La gestión diaria de cambios, accesos y vulnerabilidades mantiene el sistema tal como se diseñó, y el aprendizaje sin culpabilizar a partir de incidentes y cuasiincidentes mejora las defensas.