Capítulo 16 — Infraestructura crítica y seguridad sectorial: métodos II
Mapa de la lección
Lección 16 publicada. Mapa, ejemplo, EX046.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["16.1 Recepción de vulnerabilidades y aplicabilidad"]
N2["16.2 Priorización"]
N3["16.3 Tratamiento cuando no se puede parchear con rap"]
N4["16.4 Verificación"]
N5["16.5 Copias de seguridad y pruebas de restauración"]
N6["16.7 Actividad práctica: registro de vulnerabilidad"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX046"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["16.1 Recepción de vulnerabilidades y aplicabilidad"]
N2["16.2 Priorización"]
N3["16.3 Tratamiento cuando no se puede parchear con rap"]
N4["16.4 Verificación"]
N5["16.5 Copias de seguridad y pruebas de restauración"]
N6["16.7 Actividad práctica: registro de vulnerabilidad"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Resultados de aprendizaje y conexión]
|
v
[16.1 Recepción de vulnerabilidades y aplicabilidad]
|
v
[16.2 Priorización]
|
v
[16.3 Tratamiento cuando no se puede parchear con rap]
|
v
[16.4 Verificación]
|
v
[16.5 Copias de seguridad y pruebas de restauración]
|
v
[16.7 Actividad práctica: registro de vulnerabilidad]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX046]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- aplicar una rutina de gestión de vulnerabilidades: recepción, aplicabilidad, priorización, tratamiento y verificación;
- priorizar las correcciones a partir de la evidencia de explotación, la exposición y la consecuencia para el activo, y no solo de la puntuación de gravedad;
- planificar la aplicación de parches cuando el dispositivo no puede parchearse con rapidez, mediante controles compensatorios con fecha de fin;
- diseñar, ejecutar y registrar copias de seguridad y pruebas de restauración que demuestren la recuperación dentro de un tiempo objetivo.
Métodos I (capítulo 14) controlaba los cambios. Métodos II cubre las dos rutinas que con más frecuencia deciden lo malo que llega a ser un mal día: ocuparse de las vulnerabilidades antes de que se exploten y recuperarse cuando, aun así, algo se pierde.
16.1 Recepción de vulnerabilidades y aplicabilidad
Los avisos llegan de fabricantes, agencias nacionales y listas de correo de seguridad. La primera pregunta es la aplicabilidad: ¿usamos el producto y la versión afectados, en una configuración en la que el fallo importa? Esto depende de que el inventario (capítulo 11) sea exacto en las versiones. Registre la decisión («aplicable», «no aplicable (motivo)», «desconocido (acción para averiguarlo)») para cada aviso que afecte a un producto del inventario. «Desconocido» es habitual en TO y debe tener un responsable. Para el aviso del Arlen 300, el inventario contenía ambas versiones: PS04-PLC con la 4.2 y PS07-PLC con la 3.9.
16.2 Priorización
Una puntuación de gravedad describe el fallo en general; su prioridad depende de su situación. Tres preguntas la afinan. ¿Se está explotando? El catálogo de vulnerabilidades explotadas conocidas de la CISA enumera los fallos con evidencia de explotación activa (CISA KEV); esas entradas pasan al frente. ¿Está expuesto? Un fallo alcanzable desde internet o desde la zona corporativa es más urgente que uno alcanzable solo desde dentro de un conducto bien controlado. ¿Cuál es la consecuencia? Un fallo en un activo de criticidad 1 de la zona de estaciones importa más que uno en un quiosco de las cocheras. Las guías de gestión de parches lo tratan como una planificación basada en el riesgo, con planes de mantenimiento definidos para los distintos grupos de activos (NIST SP 800-40 Rev. 4).
16.3 Tratamiento cuando no se puede parchear con rapidez
Los controladores de las estaciones pueden necesitar firmware certificado por el fabricante, una visita a la instalación, una ventana de interrupción y una nueva prueba del proceso. El tratamiento tiene entonces dos partes: controles compensatorios ya (restringir más el conducto, deshabilitar la función vulnerable si no se usa, añadir monitorización de los intentos de explotación, intensificar la revisión de la configuración del dispositivo) y un plan con fecha para la corrección. Registre ambas cosas, y también al responsable del riesgo residual (capítulo 13). Recuerde el capítulo 9: estos elementos abiertos durante mucho tiempo deben aparecer en sus medidas de parcheo.
PS04-PLC y PS07-PLC son el caso de Fallowmere: deshabilitar la interfaz web que no se usa, cerrar la ruta corporativa→PS-04, alertar sobre el puerto web y, después, el firmware 4.3 en las próximas visitas a las instalaciones.
16.4 Verificación
Una corrección está completa cuando se verifica en el dispositivo: la versión se confirma (desde el dispositivo o su exportación de ingeniería, no desde la incidencia), el servicio funciona (las comprobaciones del capítulo 27) y los controles compensatorios que ya no hacen falta se eliminan con control de cambios; de lo contrario, las reglas temporales se acumulan. Para PS07-PLC, la versión se leyó del dispositivo en la visita a la instalación: 3.9, tal como estaba registrada, así que la corrección sigue abierta. Cuando se instale la 4.3, la evidencia será la exportación del ingeniero que muestre la 4.3, y la alerta sobre el puerto web del PLC se mantendrá o se eliminará con su propio registro de cambio.
16.5 Copias de seguridad y pruebas de restauración
Una copia de seguridad que no se ha restaurado es una esperanza. La guía del NIST sobre planificación de contingencias cubre la planificación y la prueba de las copias de seguridad y de la recuperación (NIST SP 800-34 Rev. 1), y la guía del NIST sobre la recuperación tras ciberincidentes insiste en preparar y ejercitar la recuperación de antemano (NIST SP 800-184). Para LANTERN:
- Qué se copia: la configuración del retransmisor y la lista de permitidos (ya bajo control de versiones), las claves (en la copia de seguridad propia de su almacén protegido), la base de datos del historiador, los programas y configuraciones de los controladores (a cargo de los ingenieros de Agua) y la documentación necesaria para reconstruir.
- Dónde: al menos una copia fuera de línea o inmutable, para que un ransomware o un error de un administrador no puedan borrar todas las copias.
- Objetivos: un objetivo de tiempo de recuperación (RTO: con qué rapidez debe volver el servicio) y un objetivo de punto de recuperación (RPO: cuánta pérdida de datos es tolerable). Para HIST-01 en Fallowmere: RTO de 4 horas y RPO de 24 horas.
- Pruebas de restauración: programadas, cronometradas y registradas, con el resultado comparado con los objetivos; el capítulo 9 muestra cómo informar de ellas con honestidad.
16.6 Ejemplo resuelto: un aviso para el Arlen 300 (sintético)
Un aviso informa de un fallo en la interfaz web de gestión del PLC Arlen 300, con firmware anterior a la 4.3, que ya figura como explotado en otros lugares (sintético). Aplicabilidad: PS04-PLC ejecuta la 4.2 y PS07-PLC la 3.9; ambos son aplicables. Exposición: la interfaz web solo debería ser alcanzable desde la ruta de salto de ingeniería; pero la revisión de flujos del capítulo 2 encontró una estación de trabajo corporativa comunicándose directamente con PS-04. Prioridad: alta en las tres preguntas. Tratamiento: hoy, confirmar con el ingeniero de Agua si se usa la interfaz web y, si no, deshabilitarla; cerrar la ruta corporativa→PS-04 (ya notificada); añadir una alerta ante cualquier conexión al puerto web de los PLC. Corrección: firmware 4.3 en las próximas visitas a las instalaciones, con las pruebas del proceso de Agua. Verificación: versión leída de la exportación de ingeniería; alerta y conducto probados.
16.7 Actividad práctica: registro de vulnerabilidad
Redacte el registro completo del aviso del capítulo 16 («Ejemplo resuelto: un aviso para el Arlen 300»): aplicabilidad por activo, prioridad con los motivos de cada una de las tres preguntas, controles compensatorios con evidencia, plan de corrección con fechas y responsables, pasos de verificación y responsable del riesgo residual. La prioridad de PS04-PLC descansa en tres respuestas: aplicable (la 4.2 es anterior a la 4.3), explotado en otros lugares y expuesto, porque la revisión de flujos vio una estación de trabajo corporativa comunicándose con PS-04. PS07-PLC es aplicable y explotado, pero no se ha visto ninguna ruta no declarada, así que su motivo de exposición es más débil. Designe a operaciones de Agua como responsable del riesgo residual hasta que la 4.3 esté verificada en ambos.
16.8 Errores frecuentes y límites
- Priorizar solo por la puntuación de gravedad.
- Marcar «no aplicable» sin comprobar las versiones.
- Dejar «desconocido» sin responsable.
- Controles compensatorios sin fecha de fin, que acaban siendo permanentes.
- Cerrar la incidencia cuando el parche está programado, no cuando está verificado.
- Copias de seguridad guardadas donde la misma cuenta de administrador puede borrar todas las copias.
- Medir el éxito de las copias por la finalización de los trabajos en lugar de por las pruebas de restauración.
Ambos PLC muestran el riesgo del quinto error: la incidencia se cerraría en «firmware 4.3 programado», mientras la 3.9 sigue funcionando en PS-07.
La 4.2 de PS04-PLC habría quedado marcada como no aplicable por cualquiera que leyera solo la puntuación del aviso.
Ejercicios — capítulo 16
EX046 — Priorice tres avisos. Objetivo: aplicar explotación, exposición y consecuencia. Entradas: (a) fallo de gravedad crítica en el navegador del quiosco de las cocheras, sin explotación conocida, quiosco en la red de las cocheras con acceso a internet; (b) fallo de gravedad media en el servidor SSH del retransmisor, incluido en el KEV, con SSH alcanzable solo desde el servidor de salto; (c) fallo de gravedad alta en la base de datos de HIST-01, sin explotación conocida, alcanzable desde la zona corporativa. Restricciones: ordene y justifique con una frase cada uno. Pasos: ordene y después dé una fecha objetivo para cada uno. Evidencia esperada: tabla. Rúbrica: 3 = (b) primero por la explotación activa y la criticidad, pese a la puntuación media y la exposición restringida; después, un orden defendible de (c) y (a) con motivos (consecuencia del historiador frente a exposición a internet del quiosco); fechas proporcionadas; 2 = orden defendible, motivos escasos; 1 = solo por gravedad; 0 = nada.
EX047 — Plan de controles compensatorios. Objetivo: tratar una vulnerabilidad que no puede parchearse con rapidez. Entradas: el capítulo 16 («Ejemplo resuelto: un aviso para el Arlen 300»); el firmware 4.3 solo puede instalarse en PS-07 dentro de 10 semanas. Restricciones: al menos tres controles, cada uno con evidencia y fecha de fin. Pasos: redacte el plan. Evidencia esperada: tabla. Rúbrica: 3 = deshabilitar la interfaz web si no se usa (evidencia: exportación de ingeniería), restricción del conducto verificada mediante la revisión de flujos, alerta ante conexiones al puerto web probada, comparación de la configuración intensificada; todo termina cuando la 4.3 esté verificada; 2 = sin fechas de fin; 1 = «monitorizar»; 0 = nada.
EX048 — Diseño de una prueba de restauración. Objetivo: diseñar una prueba de restauración que demuestre el RTO. Entradas: HIST-01, RTO de 4 h, RPO de 24 h. Restricciones: no debe perturbar la producción; debe ser repetible. Pasos: (1) describa el entorno de prueba; (2) los pasos y los puntos de cronometraje; (3) los criterios de superación; (4) lo que se registra. Evidencia esperada: una página. Rúbrica: 3 = destino de restauración aislado, parte de la copia fuera de línea o inmutable, cronometra desde «decisión de restaurar» hasta «los operadores pueden consultar los datos», comprueba la antigüedad de los datos frente al RPO, registra tiempos, carencias y lecciones, y se programa con regularidad; 2 = falta el cronometraje o la comprobación del RPO; 1 = «comprobar que el trabajo de copia terminó bien»; 0 = nada.
Síntesis del capítulo
Gestione las vulnerabilidades como una rutina: decida la aplicabilidad a partir del inventario, priorice por explotación, exposición y consecuencia, aplique controles compensatorios con fechas de fin cuando el parcheo sea lento y verifique las correcciones en el dispositivo. Copie lo que necesita para reconstruir, conserve una copia que no puedan borrar las mismas personas que gestionan la producción, fije el RTO y el RPO, y demuéstrelos con pruebas de restauración cronometradas.
Siga estudiando — capítulo 16 de 30
← Capítulo 15 · Índice de capítulos del curso · Capítulo 17 →
Continúe con la siguiente lección escrita.