Mapa de la lección
Lección 07 publicada. Mapa, ejemplo, EX031.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["7.1 Modelos operativos"]
N2["7.2 Titularidad: RACI y segregación de funciones"]
N3["7.3 Proveedores y concentración"]
N4["7.4 Integración con la gestión de emergencias"]
N5["7.5 Intercambio de información"]
N6["7.7 Actividad práctica: comprobaciones de concentrac"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX031"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["7.1 Modelos operativos"]
N2["7.2 Titularidad: RACI y segregación de funciones"]
N3["7.3 Proveedores y concentración"]
N4["7.4 Integración con la gestión de emergencias"]
N5["7.5 Intercambio de información"]
N6["7.7 Actividad práctica: comprobaciones de concentrac"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Resultados de aprendizaje y conexión]
|
v
[7.1 Modelos operativos]
|
v
[7.2 Titularidad: RACI y segregación de funciones]
|
v
[7.3 Proveedores y concentración]
|
v
[7.4 Integración con la gestión de emergencias]
|
v
[7.5 Intercambio de información]
|
v
[7.7 Actividad práctica: comprobaciones de concentrac]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX031]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- Comparar modelos operativos para la seguridad de la TO y de la TI en una organización de servicios esenciales y elegir uno de forma razonada.
- Asignar la titularidad de modo que cada actividad de seguridad crítica tenga exactamente un rol que rinda cuentas y que los conflictos de funciones sean visibles.
- Medir la concentración de proveedores dentro de una organización y en una región, y planificar para un fallo de modo común de un proveedor.
- Integrar la respuesta a ciberincidentes con la gestión de emergencias, la continuidad del negocio y los mecanismos regionales de resiliencia.
- Diseñar un intercambio de información entre operadores que sea útil, lícito y de confianza.
Los capítulos 1 a 6 dotaron al especialista de herramientas para decidir, aportar evidencia y evaluar. Este capítulo sitúa ese trabajo dentro de una organización y de una región, porque la mayoría de los fallos en los servicios esenciales son fallos de integración: entre la TI y las operaciones, entre un operador y sus proveedores, entre un equipo de ciberincidentes y las personas que dirigen la respuesta a emergencias. El capítulo 8 pone a prueba la integración en los casos más difíciles; el capítulo 9 la dirige y la asegura.
7.1 Modelos operativos
Tres modelos habituales para la seguridad en una organización que gestiona tanto TI como TO:
Tabla de la lección; desplázate para ver todas las columnas →
| Modelo | Descripción | Fortalezas | Debilidades |
|---|---|---|---|
| Central | El equipo del CISO es titular de la seguridad de la TI y de la TO | Un solo estándar, una sola visión del riesgo, herramientas eficientes | Distancia respecto de la planta; controles diseñados para la TI; las operaciones pueden sortearlos |
| Federado | Operaciones es titular de la seguridad de la TO con sus propios especialistas; el CISO fija la política y la asegura | Cerca del proceso; cultura de seguridad funcional; creíble para los operadores | Estándares incoherentes; herramientas duplicadas; lagunas en la frontera entre TI y TO |
| Integrado | Una función conjunta de seguridad de la TO que depende de operaciones con una línea formal hacia el CISO, estándares compartidos y un proceso de incidentes compartido | Combina el conocimiento del proceso con la profundidad en seguridad | Necesita una titularidad explícita y una resolución de conflictos; depende de las personas |
No existe un modelo correcto universal. La NIST SP 800-82 recomienda formar un equipo multifuncional que incluya a ingenieros de control, operadores, personal de seguridad de la TI y de seguridad funcional (NIST, 2023); el NIST CSF 2.0 sitúa los roles, las responsabilidades y las autoridades dentro de la gobernanza (NIST, 2024). La elección del modelo integrado por parte de Merrow Water (un especialista principal de seguridad que depende del director de operaciones con una línea de puntos hacia el CISO) se deriva de su tamaño y del peso que da a la confianza de los operadores. Después, el modelo debe hacerse realidad mediante la titularidad, el presupuesto y el proceso de incidentes; un organigrama por sí solo no integra nada.
7.2 Titularidad: RACI y segregación de funciones
Para cada actividad crítica, un rol rinde cuentas (Accountable: es titular del resultado y lo aprueba), uno o más son responsables (Responsible: hacen el trabajo) y otros son consultados (Consulted) o informados (Informed). Dos reglas detectan la mayoría de los fallos de titularidad: cada actividad crítica tiene exactamente un rol que rinde cuentas; y, cuando un mismo rol ejecuta y aprueba una actividad con consecuencias de seguridad (un cambio de emergencia en un cortafuegos, un pago, la concesión de un acceso a un proveedor), el conflicto se elimina o se cubre con un control compensatorio, como una revisión a posteriori de cada caso. La segregación de funciones es un principio de control de larga tradición en el catálogo del NIST (NIST SP 800-53 Rev. 5). Dos roles que rinden cuentas de «declarar un ciberincidente» suena a seguridad adicional; en la práctica, crea una laguna a las 3 de la madrugada, cuando cada uno supone que el otro ya ha decidido.
7.3 Proveedores y concentración
Los servicios esenciales dependen de proveedores para el soporte de los sistemas de control, la detección gestionada, las telecomunicaciones y el alojamiento en la nube. La concentración tiene dos niveles:
- Dentro de un operador. Si un proveedor presta toda una función crítica, su fallo (técnico, comercial o por compromiso) es el fallo del operador. Una medida estándar de la concentración es el índice de Herfindahl-Hirschman (HHI): la suma de los cuadrados de las cuotas porcentuales, desde casi 0 (muchos proveedores pequeños) hasta 10.000 (un solo proveedor) (U.S. Department of Justice, HHI). Es una señal tosca pero útil.
- En una región. Si un proveedor es una dependencia mayoritaria de varios operadores, un único evento se convierte en un evento regional. La caída mundial de julio de 2024 causada por una actualización defectuosa de un software de seguridad, que afectó a unos 8,5 millones de dispositivos Windows según Microsoft (Microsoft, 2024), mostró cómo un proveedor de confianza puede convertirse en un fallo de modo común entre sectores. La regulación financiera es la que más ha avanzado en esto: DORA exige registros de los acuerdos con terceros proveedores de TIC y establece la supervisión de los terceros proveedores críticos de servicios TIC (Regulation (EU) 2022/2554).
La concentración no es automáticamente mala: un proveedor bien gestionado puede ser más seguro que tres mal gestionados. La tarea del especialista es hacerla visible, decidir qué concentraciones son aceptables y preparar planes de salida y de continuidad: ¿qué haríamos si este proveedor no estuviera disponible durante una semana, o estuviera comprometido? Los contratos deben otorgar derechos de acceso a los registros, la notificación de incidentes, requisitos de seguridad y soporte durante los incidentes del propio proveedor. Las prácticas de la cadena de suministro de software (listas de materiales de software, SBOM (CISA, SBOM); desarrollo seguro (NIST SP 800-218); y compromisos de seguridad desde el diseño (CISA, Secure by Design)) ayudan en la vertiente del producto.
7.4 Integración con la gestión de emergencias
Un ciberincidente grave en un servicio esencial es también una emergencia: avisos de hervir el agua, desvíos hospitalarios, cierres portuarios. Por eso, el equipo de ciberincidentes debe encajar en el mando de emergencias y de continuidad del negocio de la organización en lugar de funcionar en paralelo. Puntos prácticos de integración:
- Una clasificación de incidentes compartida que relacione la gravedad cibernética con el impacto en el servicio, para que el responsable de guardia pueda escalar sin que haya un especialista en seguridad presente.
- Representación cibernética en la estructura de mando de emergencias y representación de la gestión de emergencias en los ciberejercicios.
- Planes de operación manual y de continuidad cuya titularidad sea de operaciones y que se prueben con escenarios de seguridad (capítulo 6).
- Mecanismos regionales acordados previamente: quién informa a los operadores vecinos, a los servicios de salud y a las autoridades locales; cómo funciona la ayuda mutua; cómo se coordinan los mensajes públicos. La Directiva CER de la UE enmarca la resiliencia de las entidades críticas como multirriesgo e intersectorial (Directive (EU) 2022/2557); de forma similar, la política estadounidense sobre seguridad y resiliencia de las infraestructuras críticas hace hincapié en la coordinación sectorial (NSM-22 overview, CISA).
7.5 Intercambio de información
Los operadores aprenden más rápido juntos, pero compartir conlleva riesgos jurídicos, comerciales y de seguridad. El intercambio útil es específico (indicadores, técnicas, versiones de productos afectadas, mitigaciones que funcionaron), oportuno, protegido (reglas de tratamiento acordadas, como las etiquetas del semáforo) y recíproco. Un acuerdo de intercambio para un foro regional debe cubrir: qué se comparte y en qué formato; las reglas de tratamiento y de difusión posterior; los datos personales (minimizarlos; comprobar la base jurídica, GDPR); la cautela en materia de defensa de la competencia con la información comercialmente sensible; la responsabilidad; y cómo puede llegar la información compartida a los reguladores. Nota para el lector hispanohablante: en España, el RGPD se complementa con la Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales; en América Latina rige la ley de cada país, por ejemplo la Ley 25.326 en Argentina o la Ley 1581 de 2012 en Colombia. La confianza se construye sobre todo con el comportamiento: compartir primero, proteger lo que comparten los demás y reconocer el mérito ajeno.
7.6 Ejemplo resuelto: las dependencias de Merrow Bay y un borrador de RACI (sintético)
El foro de resiliencia preguntó a cada operador qué proveedores prestan servicio a sus funciones esenciales y qué cuota aportan. Al mismo tiempo, el especialista de Merrow Water redactó un RACI para cinco actividades de seguridad críticas, que debía acordarse con operaciones y con el CISO. El Lab 7 analiza ambas cosas. Las preguntas eran deliberadamente sencillas: qué proveedor presta servicio a cada función esencial y, aproximadamente, con qué cuota. Los operadores respondieron a partir de los contratos y de los registros de activos, no de memoria, y el foro acordó de antemano que las respuestas solo se usarían para el análisis regional. El borrador de RACI cubre la aprobación y la ejecución de cambios de emergencia en los cortafuegos de la TO, la concesión de sesiones remotas a proveedores, la declaración de un ciberincidente y la restauración desde copias de seguridad fuera de línea, cada una elegida porque un error de titularidad en ella retrasaría la respuesta o debilitaría el control.
7.7 Actividad práctica: comprobaciones de concentración y de titularidad
# Lab 7 - concentration and ownership checks for an integrated security function (offline, stdlib only)
# Synthetic: which suppliers Merrow Bay operators depend on for essential functions, and a draft RACI.
from collections import defaultdict
DEPENDS = [ # (operator, function, supplier, share of that operator's function served by the supplier)
("Merrow Water", "SCADA support", "Corvane Systems", 1.0),
("Merrow Water", "managed detection", "Lumen Watch", 1.0),
("Merrow Water", "telemetry links", "BayTel", 0.7), ("Merrow Water", "telemetry links", "radio (own)", 0.3),
("Merrow Health", "EPR hosting", "Halden Cloud", 1.0),
("Merrow Health", "managed detection", "Lumen Watch", 1.0),
("Merrow Health", "pathology LIMS", "Corvane Systems", 1.0),
("Merrow Energy", "SCADA support", "Corvane Systems", 0.6), ("Merrow Energy", "SCADA support", "in-house", 0.4),
("Merrow Energy", "telemetry links", "BayTel", 0.5), ("Merrow Energy", "telemetry links", "private fibre", 0.5),
("Port of Merrow", "terminal OS hosting", "Halden Cloud", 1.0),
("Port of Merrow", "managed detection", "Lumen Watch", 1.0),
]
by_op_fn = defaultdict(list)
for op, fn, sup, share in DEPENDS: by_op_fn[(op, fn)].append((sup, share))
print("Herfindahl-Hirschman index per operator function (10000 = single supplier):")
for (op, fn), lst in by_op_fn.items():
hhi = sum((100 * s) ** 2 for _, s in lst)
print(f" {op:15s} {fn:20s} HHI {hhi:6.0f}")
reach = defaultdict(set)
for op, fn, sup, share in DEPENDS:
if sup not in ("in-house", "radio (own)", "private fibre") and share >= 0.5: reach[sup].add(op)
print("Suppliers that are a majority dependency for 2+ operators (regional common mode):")
for sup, ops in sorted(reach.items(), key=lambda x: -len(x[1])):
if len(ops) >= 2: print(f" {sup:16s} {len(ops)} operators: {', '.join(sorted(ops))}")
RACI = { # activity -> {role: letters}
"approve OT firewall change": {"OT engineer": "R", "OT manager": "A", "CISO": "C"},
"emergency OT firewall change": {"OT engineer": "RA", "OT manager": "I"},
"grant vendor remote session": {"OT engineer": "R", "Service desk": "R"},
"declare cyber incident": {"CISO": "A", "Duty manager": "A", "OT manager": "C"},
"restore from offline backup": {"OT engineer": "R", "OT manager": "A", "IT ops": "R"},
}
print("RACI findings:")
for act, roles in RACI.items():
a = [r for r, l in roles.items() if "A" in l]
if len(a) != 1: print(f" {act}: {len(a)} accountable roles {a}")
for r, l in roles.items():
if "R" in l and "A" in l: print(f" {act}: {r} both does and approves (needs compensating control or record)")
Salida esperada:
Herfindahl-Hirschman index per operator function (10000 = single supplier):
Merrow Water SCADA support HHI 10000
Merrow Water managed detection HHI 10000
Merrow Water telemetry links HHI 5800
Merrow Health EPR hosting HHI 10000
Merrow Health managed detection HHI 10000
Merrow Health pathology LIMS HHI 10000
Merrow Energy SCADA support HHI 5200
Merrow Energy telemetry links HHI 5000
Port of Merrow terminal OS hosting HHI 10000
Port of Merrow managed detection HHI 10000
Suppliers that are a majority dependency for 2+ operators (regional common mode):
Corvane Systems 3 operators: Merrow Energy, Merrow Health, Merrow Water
Lumen Watch 3 operators: Merrow Health, Merrow Water, Port of Merrow
BayTel 2 operators: Merrow Energy, Merrow Water
Halden Cloud 2 operators: Merrow Health, Port of Merrow
RACI findings:
emergency OT firewall change: OT engineer both does and approves (needs compensating control or record)
grant vendor remote session: 0 accountable roles []
declare cyber incident: 2 accountable roles ['CISO', 'Duty manager']
Interpretación. Dentro de los operadores, siete de los diez pares función-operador tienen un HHI de 10.000 (un único proveedor), algo habitual y no alarmante en sí mismo. La visión regional es más importante: Corvane Systems es una dependencia mayoritaria de tres operadores (soporte del SCADA en el agua y la energía, sistemas de anatomía patológica en la salud), Lumen Watch presta detección gestionada a tres, y BayTel y Halden Cloud, a dos cada uno. Un compromiso de Lumen Watch dejaría ciega a la vez la detección de tres operadores; un compromiso del soporte remoto de Corvane podría alcanzar los sistemas operativos de tres sectores. Son riesgos del nivel del foro que no mostrará el registro de ningún operador aislado. La comprobación del RACI encuentra tres problemas: en el cambio de emergencia del cortafuegos, el ingeniero de TO ejecuta y aprueba a la vez, lo que puede ser aceptable de noche si cada caso se revisa el siguiente día laborable; la concesión de sesiones remotas a proveedores no tiene ningún rol que rinda cuentas, el hallazgo más peligroso dado el suceso de Hollin del capítulo 3; y la declaración de un ciberincidente tiene dos roles que rinden cuentas, que deberían quedar en uno (el responsable de guardia, que siempre está disponible), con el CISO como consultado.
7.8 Errores comunes y límites
- Elegir un modelo operativo copiando a otra organización en lugar de atender al tamaño, el riesgo y la cultura.
- Dibujar un organigrama y llamarlo integración.
- Dejar actividades críticas sin ningún titular que rinda cuentas, o con dos.
- Evaluar el riesgo de los proveedores contrato a contrato y pasar por alto la concentración regional.
- Tratar la certificación de un proveedor como evidencia de resiliencia durante el propio incidente del proveedor.
- Llevar la respuesta a ciberincidentes en paralelo al mando de emergencias.
- Compartir información sin reglas de tratamiento, o no compartirla nunca porque las reglas no están claras.
El límite del análisis estructural es que la integración depende, en última instancia, de las relaciones y de la práctica. Las tablas RACI y los valores del HHI indican dónde mirar; los ejercicios y los incidentes reales muestran si la integración funciona.
Ejercicios — capítulo 7
EX031 — Repare el RACI. Objetivo: corregir los defectos de titularidad y verificarlo. Entradas: el Lab 7. Restricciones: cada actividad, exactamente una A; cualquier conflicto R+A se elimina o se documenta con un control compensatorio. Pasos: (1) edite el RACI; (2) vuelva a ejecutarlo y muestre que no quedan hallazgos sin tratar; (3) redacte el control compensatorio de cualquier conflicto que mantenga. Evidencia esperada: tabla editada, salida, texto del control. Rúbrica: 3 = la concesión de sesiones a proveedores tiene un rol que rinde cuentas (el responsable de TO) con el centro de servicios y el ingeniero de TO como responsables, la declaración de incidentes tiene un único rol que rinde cuentas, el conflicto del cambio de emergencia se elimina o se mantiene con una revisión al día siguiente de cada caso; 2 = salida limpia pero falta el control; 1 = no se vuelve a ejecutar; 0 = nada.
EX032 — Modo común regional. Objetivo: planificar para un proveedor concentrado. Entradas: Lumen Watch presta servicio a tres operadores. Restricciones: el foro no tiene autoridad sobre los contratos; los operadores mantienen sus propias elecciones. Pasos: (1) describa dos escenarios de fallo (caída; compromiso del proveedor); (2) proponga acciones para cada operador y para el foro; (3) defina las cláusulas contractuales que se pedirán en la renovación. Evidencia esperada: plan. Rúbrica: 3 = escenarios distintos (ceguera frente al proveedor como vía de ataque), las acciones incluyen una detección o un registro mínimos locales conservados por cada operador, un ejercicio conjunto, cláusulas de notificación, acceso a los registros y un plan de salida; 2 = un escenario; 1 = «cambiar de proveedor»; 0 = nada.
EX033 — Elija un modelo operativo. Objetivo: justificar un modelo para otra organización. Entradas: Port of Merrow: 600 empleados, un equipo de seguridad de la TI de dos personas, la TO de la terminal gestionada por un contratista y un centro de operaciones del capitán de puerto. Restricciones: use el §7.1. Pasos: compare los modelos; elija uno; indique las tres condiciones que harían fracasar su elección. Evidencia esperada: recomendación de una página. Rúbrica: 3 = elección argumentada a partir del tamaño, la dependencia del contratista y la cultura de operaciones, condiciones de fracaso concretas; 2 = ventajas e inconvenientes genéricos; 1 = sin elección; 0 = nada.
EX034 — Lo cibernético dentro del mando de emergencias. Objetivo: integrar las estructuras de respuesta. Entradas: el plan de emergencias vigente de Merrow Water (hervir el agua, pérdida de suministro) y su procedimiento de ciberincidentes, que actualmente no se mencionan entre sí. Restricciones: una sola clasificación compartida; ningún mando duplicado. Pasos: (1) redacte una tabla de clasificación combinada a partir del impacto en el servicio; (2) defina el lugar del responsable cibernético en el mando de emergencias; (3) enumere las notificaciones regionales y quién las hace. Evidencia esperada: tabla y descripción de un diagrama. Rúbrica: 3 = clasificación por impacto en el servicio utilizable por un responsable de guardia, el responsable cibernético asesora al director del incidente en lugar de dirigir una estructura paralela, notificaciones regionales asignadas; 2 = se mantienen estructuras paralelas; 1 = gravedad solo cibernética; 0 = nada.
EX035 — Aritmética y juicio sobre la concentración. Objetivo: calcular e interpretar el HHI. Entradas: los servicios de telemetría y de red de Merrow Health se reparten un 40 % / 40 % / 20 % entre tres operadores de telecomunicaciones, dos de los cuales comparten la misma canalización a lo largo de la carretera del puerto. Restricciones: muestre el cálculo. Pasos: (1) calcule el HHI; (2) explique por qué la cifra subestima la concentración real; (3) proponga cómo representar las rutas físicas compartidas. Evidencia esperada: cálculo y un párrafo. Rúbrica: 3 = HHI de 3.600, se reconoce que el 80 % del servicio comparte una ruta física, de modo que la concentración efectiva es muy superior, se propone calcular la concentración por rutas físicas o dominios de fallo; 2 = solo la cifra; 1 = aritmética errónea; 0 = nada.
Síntesis del capítulo
La integración es donde suele fallar la seguridad de los servicios esenciales. Elija un modelo operativo adecuado a su tamaño, su riesgo y su cultura, y hágalo realidad con la titularidad: exactamente un rol que rinda cuentas por cada actividad crítica y un tratamiento visible de los conflictos de funciones. Mida la concentración de proveedores dentro de la organización y en la región, y prepare planes de salida y de continuidad para un fallo de modo común de un proveedor. Sitúe la respuesta cibernética dentro del mando de emergencias y de continuidad, con una clasificación compartida basada en el servicio. Comparta información de forma específica, con reglas de tratamiento acordadas, y construya la confianza con el comportamiento.