Capítulo 14 — Infraestructura crítica y seguridad sectorial: métodos I
Mapa de la lección
Lección 14 publicada. Mapa, ejemplo, EX040.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["14.1 Líneas base de configuración"]
N2["14.2 Un control de cambios que la gente use"]
N3["14.3 Planificar un cambio en un entorno operativo"]
N4["14.4 Evidencia del cambio"]
N5["14.6 Actividad práctica: redacte un plan de cambio n"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX040"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["14.1 Líneas base de configuración"]
N2["14.2 Un control de cambios que la gente use"]
N3["14.3 Planificar un cambio en un entorno operativo"]
N4["14.4 Evidencia del cambio"]
N5["14.6 Actividad práctica: redacte un plan de cambio n"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX040"]
[Resultados de aprendizaje y conexión]
|
v
[14.1 Líneas base de configuración]
|
v
[14.2 Un control de cambios que la gente use]
|
v
[14.3 Planificar un cambio en un entorno operativo]
|
v
[14.4 Evidencia del cambio]
|
v
[14.6 Actividad práctica: redacte un plan de cambio n]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX040]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- redactar una línea base de configuración para una clase de equipo y mantenerla bajo control de versiones;
- aplicar un control de cambios proporcionado: cambios estándar, normales y de emergencia;
- planificar un cambio en un entorno operativo con comprobaciones previas, una ventana, una reversión y un paso de verificación;
- vincular cada cambio con evidencia de que se hizo tal como se aprobó.
Los capítulos 1 a 13 describieron sistemas, datos y riesgos. Este capítulo y el capítulo 16 tratan de métodos: las rutinas que un tecnólogo ejecuta cada semana. Métodos I cubre las líneas base y los cambios, porque casi todos los demás controles dependen de saber cómo debería ser un sistema y de controlar cómo cambia.
14.1 Líneas base de configuración
Una línea base es la configuración aprobada para una clase de sistema: paquetes instalados y sus versiones, servicios habilitados y sus direcciones de escucha, cuentas y grupos, permisos de archivos, ajustes de registro y de hora, y parámetros de seguridad. La guía del NIST sobre la gestión de la configuración orientada a la seguridad describe cómo establecer líneas base, controlar sus cambios y vigilar las desviaciones (NIST SP 800-128). Escriba la línea base como un archivo bajo control de versiones, no como un documento en la carpeta de alguien: el capítulo 22 la usa para detectar la deriva automáticamente.
14.2 Un control de cambios que la gente use
El control de cambios existe para impedir que cambios sin revisar causen interrupciones o debiliten la seguridad. Los procesos demasiado pesados se eluden; así aparecen los servicios de depuración a la escucha y los scripts auxiliares sin explicación (capítulo 6). Un esquema proporcionado tiene tres tipos de cambio:
- Cambios estándar: preaprobados, de bajo riesgo y repetibles (añadir una estación a la lista de permitidos a partir de una solicitud aprobada). Siguen un procedimiento escrito y se registran.
- Cambios normales: se revisan y aprueban antes de implantarse, con un plan y una reversión.
- Cambios de emergencia: se hacen con rapidez para restablecer el servicio o contener un incidente, los aprueba una autoridad de guardia designada y se revisan después.
En TO, la aprobación de cualquier cambio que pueda afectar al proceso físico incluye al responsable de operaciones, no solo a TI.
14.3 Planificar un cambio en un entorno operativo
Un plan de cambio para LANTERN indica: qué cambiará y por qué; los sistemas y clientes afectados; las comprobaciones previas (copias de seguridad hechas, reversión preparada, operaciones informadas); la ventana (acordada con operaciones: no durante el pico de demanda de la mañana ni durante la ejecución programada de un informe); la implantación paso a paso; la verificación (cómo sabrá que funcionó: comprobaciones concretas, no «probar el servicio»); los criterios y pasos de reversión; y a quién llamar. El capítulo 27 amplía esto a los despliegues con canarios.
Mover el servicio SSH a la escucha de RLY-02 es un caso típico: la reversión no debe depender de SSH.
14.4 Evidencia del cambio
Después de un cambio, tres cosas deberían coincidir: el registro del cambio (lo que se aprobó), la línea base bajo control de versiones (lo que ahora debería ser cierto) y el propio sistema (lo que es cierto, verificado con la comprobación de integridad del capítulo 6 y la comprobación de deriva del capítulo 22). Cuando no coinciden, o el cambio no se hizo tal como se aprobó o el registro es erróneo. Ambas cosas son hallazgos. Después de CHG-118, las tres coincidían para allow.list y no coincidían para el servicio de depuración a la escucha.
Para el servicio de depuración no existía ningún registro de cambio, así que la propia discrepancia era el hallazgo, y condujo a la investigación del capítulo 6.
14.5 Ejemplo resuelto: añadir PS-11 (sintético)
Operaciones de Agua pone en servicio una estación nueva, PS-11. Añadirla a LANTERN es un cambio estándar con un procedimiento escrito: (1) recibir la solicitud de puesta en servicio con el ID de la estación, su dirección y su responsable; (2) confirmar que el conducto ya cubre la subred de la estación; (3) añadir PS-11 a la lista de permitidos bajo control de versiones, con la revisión de un segundo tecnólogo; (4) desplegar la lista de permitidos en los retransmisores; (5) verificar: los primeros mensajes de PS-11 aparecen como accept en el registro del retransmisor; la comprobación de integridad muestra que allow.list cambió con CHG-118 y nada más; (6) actualizar el inventario y el registro de flujos de datos. En el laboratorio del capítulo 6, esta fue la única diferencia aprobada. Las otras tres diferencias no tenían registro de cambio, y así fue como el método las reveló.
14.6 Actividad práctica: redacte un plan de cambio normal
Redacte un plan de cambio completo para: «Mover el servicio SSH a la escucha de RLY-02 de todas las interfaces solo a la interfaz de gestión». Incluya todos los elementos del capítulo 14 («Planificar un cambio en un entorno operativo»). Preste atención al riesgo de quedarse fuera: ¿cómo llegará al equipo si el cambio falla? Para el cambio de RLY-02, un plan seguro mantiene una segunda vía de entrada: el acceso de consola a través del hipervisor, o una sesión abierta en la interfaz de gestión, probada antes de mover el servicio. La verificación es concreta: SSH responde en la dirección de gestión, no responde en la dirección orientada a las estaciones, y la comprobación de deriva muestra que solo cambió la línea prevista. Elija la ventana con operaciones de Agua, evitando el pico de demanda de la mañana y las ejecuciones semanales del informe los días 6 y 7.
14.7 Errores frecuentes y límites
- Líneas base guardadas como documentos que nadie compara con los sistemas.
- Procesos de cambio tan pesados que la gente los elude.
- Ventanas de cambio elegidas por comodidad de TI y no de operaciones.
- «Verificar que el servicio funciona» como paso de verificación.
- Planes de reversión que nunca se probaron.
- Cambios de emergencia que nunca se revisan después y acaban siendo permanentes.
El control de cambios controla los cambios autorizados. No detecta los cambios no autorizados; esa es la tarea de las comprobaciones de integridad y de deriva.
La fusión de NTP del capítulo 25 es el cuarto error en la práctica: su criterio de aceptación decía solo «actualizar los servidores NTP».
Ejercicios — capítulo 14
EX040 — Clasifique cambios. Objetivo: aplicar un control de cambios proporcionado. Entradas: (a) añadir una estación a la lista de permitidos; (b) actualizar el software del retransmisor a una nueva versión menor; (c) deshabilitar a las 02:00 una cuenta de proveedor comprometida; (d) cambiar la conservación del historiador de 730 a 365 días; (e) rotar la clave HMAC del retransmisor. Restricciones: estándar, normal o de emergencia para cada uno, con un motivo. Pasos: clasifique e indique quién aprueba. Evidencia esperada: tabla. Rúbrica: 3 = (a) estándar, (b) normal, (c) de emergencia con aprobación de guardia y revisión, (d) normal con aprobación del responsable de los datos porque afecta a los registros y a las obligaciones, (e) normal (o estándar una vez que exista un procedimiento probado) coordinado con las estaciones; aprobadores razonables; 2 = uno mal clasificado; 1 = todos normales; 0 = nada.
EX041 — Pasos de verificación. Objetivo: redactar una verificación concreta. Entradas: el cambio «el retransmisor reenvía a HIST-01 sobre TLS 1.3 en lugar de TLS 1.2». Restricciones: al menos cuatro comprobaciones; cada una observable. Pasos: enumere las comprobaciones y la evidencia que produce cada una. Evidencia esperada: lista. Rúbrica: 3 = por ejemplo, el registro de conexiones muestra TLS 1.3 negociado, el historiador recibe lecturas de todas las estaciones con la latencia normal, no aumentan los errores ni los rechazos del retransmisor, la validación de certificados sigue aplicándose y la comprobación de integridad muestra que solo cambió el archivo aprobado; 2 = tres; 1 = «probarlo»; 0 = nada.
EX042 — Revise un cambio de emergencia. Objetivo: cerrar el ciclo del cambio de emergencia. Entradas: durante una interrupción a las 03:00, un ingeniero abrió tcp/22 desde la zona corporativa directamente a todos los retransmisores «temporalmente». Restricciones: revisión posterior al cambio en un día laborable. Pasos: (1) enumere las preguntas que plantea la revisión; (2) decida qué ocurre con la regla; (3) indique qué cambio de proceso evita que se repita. Evidencia esperada: nota de revisión. Rúbrica: 3 = pregunta por qué falló la ruta del servidor de salto, quién aprobó y a qué se accedió durante la ventana (registros), elimina o restringe la regla con un registro de cambio y corrige la resiliencia del servidor de salto o el diseño del acceso de emergencia; 2 = regla eliminada pero sin causa raíz; 1 = regla mantenida; 0 = nada.
Síntesis del capítulo
Escriba las configuraciones aprobadas como líneas base bajo control de versiones. Aplique el control de cambios de forma proporcionada (estándar, normal y de emergencia), con operaciones aprobando los cambios que puedan afectar al proceso físico. Planifique los cambios con comprobaciones previas, una ventana acordada, una verificación concreta y una reversión probada. Después de cada cambio, el registro, la línea base y el sistema deberían coincidir; cuando no coinciden, tiene usted un hallazgo.
Siga estudiando — capítulo 14 de 30
← Capítulo 13 · Índice de capítulos del curso · Capítulo 15 →
Continúe con la siguiente lección escrita.