Capítulo 21 — Infraestructura crítica y seguridad sectorial: integración del servicio
Mapa de la lección
Lección 21 publicada. Mapa, ejemplo, EX061.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["21.1 Las interfaces son acuerdos"]
N2["21.2 Matrices de responsabilidades"]
N3["21.3 Integración de los proveedores"]
N4["21.4 La gestión de incidentes se encuentra con la co"]
N5["21.6 Actividad práctica: acuerdos de interfaz"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX061"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["21.1 Las interfaces son acuerdos"]
N2["21.2 Matrices de responsabilidades"]
N3["21.3 Integración de los proveedores"]
N4["21.4 La gestión de incidentes se encuentra con la co"]
N5["21.6 Actividad práctica: acuerdos de interfaz"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX061"]
[Resultados de aprendizaje y conexión]
|
v
[21.1 Las interfaces son acuerdos]
|
v
[21.2 Matrices de responsabilidades]
|
v
[21.3 Integración de los proveedores]
|
v
[21.4 La gestión de incidentes se encuentra con la co]
|
v
[21.6 Actividad práctica: acuerdos de interfaz]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX061]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- integrar un servicio técnico con las personas y organizaciones que lo rodean: operadores, el centro de monitorización de seguridad, proveedores y planificadores de emergencias;
- definir interfaces (qué se entrega, en qué forma, con qué rapidez y a quién), no solo formatos de datos;
- redactar una matriz de responsabilidades para un servicio compartido y probarla con un escenario;
- conectar la gestión de incidentes del servicio con los planes de continuidad y de emergencia del operador.
A estas alturas, LANTERN es un servicio técnico que funciona. Un servicio está integrado cuando todos los que dependen de él, o de quienes él depende, saben qué esperar y qué hacer. La mayoría de los fallos en esta etapa no son técnicos: una alerta sin responsable, un proveedor al que nunca se avisó de un cambio, un operador que no sabía que el panel podía mostrar datos desactualizados.
21.1 Las interfaces son acuerdos
Para cada vecino, ponga por escrito la interfaz como un acuerdo:
- Operaciones de Agua: lo que proporciona LANTERN (telemetría al historiador en 60 s, mostrando la antigüedad del valor), lo que proporciona Agua (solicitudes de puesta en servicio de estaciones, exportaciones de ingeniería, aprobaciones relevantes para el proceso), cómo llegan a la sala de control las alertas que afectan al proceso y cómo notifica Agua un problema sospechado de telemetría.
- Monitorización de seguridad de FSTS (SOC): qué registros y alertas envía LANTERN, en qué formato y con qué primeras acciones; cómo escala el SOC a la guardia de LANTERN; qué puede hacer el SOC sin preguntar (por ejemplo, deshabilitar una cuenta de proveedor) y qué no debe hacer (por ejemplo, bloquear los conductos de las estaciones).
- Proveedores (Kell, Arlen, BayTel, Halden): cómo se les avisa de los cambios que les afectan, cómo notifican problemas y vulnerabilidades, cómo funciona su acceso (capítulo 7) y con qué antelación avisan de sus propios cambios.
- Planificación de emergencias: cómo se reflejan una interrupción o un compromiso de LANTERN en los planes de continuidad de Agua y del hospital.
21.2 Matrices de responsabilidades
Una matriz RACI registra para cada actividad quién es responsable de ejecutarla (R, Responsible: la hace), quién rinde cuentas (A, Accountable: es dueño del resultado; exactamente uno), a quién se consulta (C, Consulted) y a quién se informa (I, Informed). Pruébela con un escenario: recorra «retransmisor comprometido a las 02:00» y compruebe que cada paso tiene exactamente un rol que rinde cuentas, que no hace falta consultar a nadie que no pueda localizarse a las 02:00 y que las personas que deben actuar sobre el proceso físico reciben la información pronto.
Recorrer «retransmisor comprometido a las 02:00» sobre el borrador de Fallowmere puso de manifiesto el problema que describe el ejemplo resuelto: nadie rendía cuentas de decir a los operadores de Agua que desconfiaran de la telemetría.
21.3 Integración de los proveedores
Los proveedores forman parte del servicio. Su acceso remoto es un camino hacia él; sus actualizaciones de software son cambios en él; sus interrupciones son sus interrupciones. Integrarlos significa: su acceso por el camino declarado; sus avisos de cambio en su calendario de cambios; sus avisos de seguridad en su rutina de vulnerabilidades (capítulo 16); y cláusulas contractuales que exijan la notificación de los incidentes que le afecten. La iniciativa Secure by Design de la CISA anima a los fabricantes a asumir la responsabilidad de los resultados de seguridad de sus clientes (CISA Secure by Design); como cliente, pregunte a los proveedores cómo cumplen esas expectativas y registre las respuestas.
21.4 La gestión de incidentes se encuentra con la continuidad
Un incidente en LANTERN lo gestiona el proceso de incidentes de FSTS, pero sus consecuencias las gestionan los mecanismos de continuidad y de emergencia de Agua y del hospital. El punto de integración es una lista breve de desencadenantes: condiciones en las que FSTS dice a Agua «suponga que la telemetría no es fiable: pase a lecturas manuales en las estaciones» o dice al hospital «suponga que la pasarela clínica no está disponible: use el procedimiento en papel de la biblioteca de fármacos». Los desencadenantes deben acordarse y ejercitarse de antemano (capítulo 28), porque a las 02:00 nadie debería estar negociando qué significa «no fiable».
21.5 Ejemplo resuelto: una RACI que no superó su prueba (sintético)
El borrador de la RACI para «sospecha de compromiso de un retransmisor» indica: guardia de FSTS, R; responsable de seguridad de FSTS, A; operaciones de Agua, I; SOC, C; Kell, I. Recorrer el escenario revela tres problemas. Primero, la decisión de decir a los operadores de Agua que desconfíen de la telemetría no tiene ningún rol que rinda cuentas: FSTS Security no puede juzgar el impacto en el proceso, y Agua solo está informada. Corrección: el jefe de turno de Agua rinde cuentas de la respuesta operativa y el responsable de seguridad de FSTS de la respuesta técnica, con un desencadenante designado para el traspaso. Segundo, Kell solo está informada, pero si el compromiso llegó por el camino del proveedor, la cuenta de Kell debe deshabilitarse de inmediato y hay que consultar a Kell sobre su propia exposición. Tercero, el SOC figura como «consultado», pero en la práctica detecta la mayoría de los incidentes; debería ser responsable de los primeros pasos del triaje.
21.6 Actividad práctica: acuerdos de interfaz
Redacte un acuerdo de interfaz de una página entre LANTERN y operaciones de Agua que cubra: lo que proporciona cada parte, los niveles de servicio (puntualidad, visualización de la antigüedad del valor), el encaminamiento de las alertas, cómo se notifica un problema sospechado de telemetría, los desencadenantes de «telemetría no fiable» y la frecuencia de revisión. Haga que los desencadenantes sean medibles: por ejemplo, se declara «telemetría no fiable» cuando los fallos de MAC del retransmisor superan una tasa fijada en más de una estación, cuando dos o más estaciones muestran desfases de reloj como los 422 segundos de PS-09, o cuando FSTS sospecha el compromiso de un retransmisor. Indique quién lo declara (el jefe de turno de Agua, con el asesoramiento de FSTS), cómo se informa a la sala de control y que se ejercita cada año.
21.7 Errores frecuentes y límites
- Tratar la integración solo como formatos de datos e interfaces de programación (API).
- Matrices RACI con varios roles que rinden cuentas, o con ninguno.
- Proveedores fuera de los procesos de cambios y de vulnerabilidades.
- Planes de continuidad que suponen que el servicio de TI está o totalmente activo o totalmente caído, sin un estado «activo pero no fiable».
- Desencadenantes definidos pero nunca ejercitados.
El primer borrador de la RACI muestra el segundo error: ningún rol rendía cuentas de la respuesta operativa.
La exclusión de Kell de los roles consultados en el borrador de la RACI muestra el tercero: a un proveedor cuya cuenta puede ser la vía de entrada solo se le iba a informar.
Ejercicios — capítulo 21
EX061 — Repare la RACI. Objetivo: corregir una matriz de responsabilidades. Entradas: el borrador del capítulo 21 («Ejemplo resuelto: una RACI que no superó su prueba»). Restricciones: exactamente una A por actividad; divida actividades si es necesario. Pasos: redacte la matriz reparada para las actividades: detectar y hacer el triaje; contener en el retransmisor; deshabilitar el acceso del proveedor; decidir la respuesta operativa; notificar a los reguladores si es obligatorio; restablecer el servicio. Evidencia esperada: matriz. Rúbrica: 3 = una A por fila; el SOC, R en el triaje; FSTS Security, A en la contención técnica; el jefe de turno de Agua, A en la respuesta operativa; la A de la notificación regulatoria recae en el rol designado del operador, no en FSTS; Kell, C en el acceso del proveedor; 2 = una fila errónea; 1 = siguen varias A; 0 = nada.
EX062 — Defina un desencadenante. Objetivo: precisar «telemetría no fiable». Entradas: las alertas de LANTERN del capítulo 19 y los resultados de validación del capítulo 3. Restricciones: condiciones medibles; no debe activarse con averías ordinarias de una sola estación. Pasos: (1) redacte las condiciones del desencadenante; (2) indique quién lo declara y quién lo da por terminado; (3) indique qué hace Agua cuando se declara. Evidencia esperada: media página. Rúbrica: 3 = condiciones como un cambio no autorizado confirmado en un retransmisor, fallos de MAC en varias estaciones o un fallo de integridad del retransmisor; lo declara el responsable de seguridad de FSTS con el jefe de turno de Agua; Agua pasa a lecturas manuales y muestreo; la condición de fin exige un estado limpio verificado; 2 = condiciones vagas; 1 = «cuando parezca que algo va mal»; 0 = nada.
EX063 — Preguntas al proveedor. Objetivo: integrar a un proveedor. Entradas: Kell Instruments. Restricciones: seis preguntas; cada una vinculada a un proceso de LANTERN. Pasos: redacte las preguntas y el proceso al que alimenta cada una. Evidencia esperada: lista. Rúbrica: 3 = por ejemplo, cómo notifica Kell las vulnerabilidades (capítulo 16), cómo se controla y revoca el acceso de su personal (capítulo 7), su compromiso de notificar incidentes (este capítulo), cómo se firma el firmware (capítulo 27), las fechas de fin de soporte (capítulo 11) y la disponibilidad de una SBOM (CISA SBOM); 2 = cuatro o cinco; 1 = genéricas; 0 = nada.
Síntesis del capítulo
Un servicio está integrado cuando cada vecino (operadores, el SOC, proveedores, planificadores de emergencias) tiene una interfaz acordada: qué se proporciona, con qué rapidez, a quién y qué ocurre cuando falla. Pruebe las matrices de responsabilidades con escenarios hasta que cada actividad tenga un solo rol que rinda cuentas. Incorpore a los proveedores a los procesos de cambios, vulnerabilidades e incidentes. Acuerde y ejercite los desencadenantes que conectan un incidente técnico con los planes de continuidad del operador, incluido el estado «activo pero no fiable».
Siga estudiando — capítulo 21 de 30
← Capítulo 20 · Índice de capítulos del curso · Capítulo 22 →
Continúe con la siguiente lección escrita.