Panorama#

El capítulo anterior situó a GOVERN como el techo del marco: la función que no es una capacidad técnica sino un conjunto de decisiones, y que fija las condiciones dentro de las cuales operan las otras cinco. Este capítulo entra en esa función y muestra cómo se ejerce, porque «gobernar el riesgo» suena a abstracción de consultoría hasta que se desglosa en las cosas concretas que alguien tiene que decidir, escribir y firmar.

La tesis es directa: GOVERN traduce el apetito de riesgo de la dirección en autoridad, política y presupuesto. Ese es todo su trabajo, y es un trabajo de traducción porque el apetito de riesgo empieza como una postura difusa —cuánta pérdida está dispuesta a tolerar la organización a cambio de cuánta agilidad— y tiene que terminar como instrucciones ejecutables: esta política, este rol con esta autoridad, esta partida de presupuesto. Sin esa capa, las decisiones que las funciones operativas toman a diario —qué vulnerabilidad se parchea primero, cuál se acepta, si se desconecta un sistema de producción a las tres de la mañana— se toman sin mandato. Y una decisión sin mandato es frágil de una forma específica: se sostiene mientras nadie la cuestione, y se derrumba en cuanto hay que defenderla ante un auditor, un regulador o un consejo que pregunta quién autorizó eso. La diferencia que GOVERN introduce es la que separa «el analista decidió» de «la organización decidió», y esa diferencia no es de matiz: es la que determina si la decisión resiste el escrutinio posterior a un incidente.

El CSF organiza GOVERN en seis categorías, y conviene recorrerlas no como una lista sino como una cascada: el contexto define para qué existe la organización, la estrategia de riesgo fija cuánto está dispuesta a arriesgar, los roles reparten quién decide, la política escribe las reglas, la supervisión comprueba que se cumplan, y la gestión de la cadena de suministro extiende todo lo anterior a lo que la organización no controla directamente.

flowchart TB
  OC["GV.OC — contexto y misión\n¿para qué existe la organización?"]
  RM["GV.RM — estrategia de riesgo\napetito y tolerancia"]
  RR["GV.RR — roles y autoridades\n¿quién decide? ¿quién acepta? ¿quién desconecta?"]
  PO["GV.PO — política\nlas reglas escritas y aplicadas"]
  OC --> RM
  RM --> RR
  RM --> PO
  RR --> OPS["las cinco funciones operativas\nIDENTIFY · PROTECT · DETECT · RESPOND · RECOVER"]
  PO --> OPS
  OV["GV.OV — supervisión\n¿se está cumpliendo la estrategia?"]
  OPS -.métricas honestas.-> OV
  OV -.ajusta.-> RM
  SC["GV.SC — cadena de suministro\nla superficie que no se controla directamente"]
  RM --> SC

GV.OC — el contexto es el punto de partida, no un preámbulo#

La primera categoría, contexto organizacional (GV.OC), parece la más prescindible —el apartado de misión y visión que nadie lee— y es en realidad la que evita el error más común de un programa de seguridad: proteger todo por igual. Comprender el contexto significa saber para qué existe la organización, qué la haría fracasar, a qué regulaciones está sujeta y qué esperan de ella sus clientes y sus reguladores. Ese entendimiento es lo que convierte una lista plana de activos en una jerarquía de importancia. Un hospital y un banco pueden tener la misma infraestructura técnica y apetitos de riesgo opuestos: para el banco el peor resultado es la fuga de datos financieros, para el hospital es la interrupción de un sistema del que depende una vida. Sin ese contexto, las cinco funciones operativas trabajan a ciegas —protegen, detectan y responden sin saber qué es lo que de verdad no puede fallar—, y un programa que no distingue lo crítico de lo accesorio termina gastando lo mismo en ambos, que es otra forma de no proteger lo crítico.

El contexto es también lo que ancla la seguridad en la gestión de riesgo empresarial que abrió 7.1. El riesgo cibernético no se evalúa en su propia escala aislada, sino en la misma en la que la organización mide el riesgo financiero, legal y operativo, porque compite con ellos por el mismo presupuesto y se decide con los mismos criterios. GV.OC es la categoría que fuerza esa integración: obliga a expresar el riesgo cibernético en términos de impacto sobre la misión, que es el único lenguaje en el que el consejo de administración puede compararlo con todo lo demás que le disputa recursos.

GV.RM — apetito y tolerancia de riesgo: la decisión que ordena todo lo demás#

La categoría de estrategia de gestión de riesgo (GV.RM) es donde la gobernanza toma su decisión más consecuente: cuánto riesgo acepta la organización. Conviene distinguir dos términos que suelen usarse como sinónimos y no lo son. El apetito de riesgo (risk appetite) es la cantidad de riesgo que la organización está dispuesta a asumir en general, en la búsqueda de sus objetivos —una postura estratégica, cualitativa, fijada por la dirección—. La tolerancia de riesgo (risk tolerance) es la desviación aceptable respecto de ese apetito en un contexto concreto y medible —cuántas horas de indisponibilidad de tal servicio se toleran, cuántos registros expuestos disparan la notificación obligatoria—. El apetito es la orientación; la tolerancia es el umbral operativo que se deriva de ella. Un programa que fija apetito pero no lo aterriza en tolerancias medibles deja a los equipos operativos sin criterio: saben que la organización «es conservadora con los datos de clientes» pero no saben si mil registros expuestos son un incidente menor o una crisis.

Esta es la categoría que conecta la gobernanza con la validación de la Parte anterior de la forma más directa. El capítulo 6.1 estableció que ante cualquier riesgo identificado hay cuatro salidas posibles —prevenir (implementar un control que lo elimine o reduzca), detectar (aceptar que puede ocurrir pero garantizar que se verá), cazar (buscar proactivamente su materialización) y aceptar con dueño (asumirlo de forma consciente y documentada)—. Lo que 6.1 no decía, porque es materia de gobernanza, es quién decide cuál de las cuatro se aplica a cada riesgo. Esa decisión es exactamente el aterrizaje del apetito: una organización con apetito bajo previene donde otra aceptaría, y la cuarta salida —aceptar— solo es legítima cuando la toma quien tiene autoridad para comprometer a la organización, no cuando un equipo se queda sin presupuesto y la acepta por omisión. El apetito de riesgo es lo que hace que la elección entre las cuatro salidas sea una política y no una improvisación.

La aceptación de riesgo sin dueño no es aceptación, es negligencia. La diferencia entre aceptar un riesgo y simplemente no tratarlo es enteramente de gobernanza: aceptar es una decisión registrada, con un responsable nombrado, una justificación y una fecha de revisión; no tratar es lo que ocurre cuando nadie decidió nada y el riesgo quedó vivo por defecto. Ante un incidente, la primera resiste la pregunta «¿quién sabía de esto y qué hizo?» —había un dueño, una evaluación y una decisión consciente— y la segunda no tiene respuesta. Por eso la gestión de exposición insiste en que cada riesgo aceptado tenga nombre y fecha: un registro de aceptaciones sin dueños es una lista de huecos que nadie eligió dejar abiertos.

GV.RR — roles y autoridades: quién decide, quién acepta, quién desconecta#

La categoría de roles, responsabilidades y autoridades (GV.RR) responde a las preguntas que un incidente formula sin piedad: ¿quién puede aceptar este riesgo?, ¿quién tiene autoridad para desconectar producción?, ¿quién rinde cuentas ante el consejo cuando algo falla? Son preguntas que parecen burocráticas hasta que hay que contestarlas en caliente y no hay respuesta escrita. El ejercicio de crisis de 6.4 mostró que el punto de quiebre más frecuente no es técnico sino de autoridad: el equipo sabe lo que hay que hacer pero no sabe si tiene permiso para hacerlo, y mientras se busca a quien pueda autorizarlo el atacante sigue trabajando. GV.RR es la categoría que previene ese quiebre asignando las autoridades antes de que la crisis las reclame.

Una herramienta útil para hacerlo explícito es la matriz RACI, que para cada actividad o decisión nombra a quien es Responsable de ejecutarla (Responsible), a quien rinde cuentas por ella y tiene la autoridad final (Accountable), a quien debe ser Consultado (Consulted) y a quien debe ser Informado (Informed). Su valor no está en la sigla sino en una regla que impone: para cada decisión hay exactamente un Accountable, una sola persona que responde. La ambigüedad que mata a los programas es la que reparte la responsabilidad entre varios —«seguridad y sistemas son responsables de los parches»—, porque una responsabilidad compartida entre dos es una responsabilidad de nadie: cada uno supone que el otro se encargó. Nombrar un único Accountable por decisión no es un formalismo; es lo que garantiza que, cuando haya que aceptar un riesgo o desconectar un sistema, exista una persona con la autoridad para hacerlo y la obligación de responder por ello. La autoridad para aceptar un riesgo crítico y la autoridad para tomar una decisión disruptiva en plena crisis son precisamente las que hay que asignar por adelantado, porque son las que no se pueden improvisar sin que la improvisación misma se convierta en el problema.

GV.PO — la política es el instrumento, y una política que no se aplica es teatro#

La categoría de política (GV.PO) es donde las decisiones de riesgo se vuelven reglas escritas: la política de control de acceso, la de clasificación de datos, la de uso aceptable, la de gestión de vulnerabilidades. La política es el instrumento por el que la organización comunica su apetito de riesgo hacia adentro y lo hace exigible: sin ella, cada equipo interpreta por su cuenta cuánto rigor aplicar, y el resultado es una postura desigual donde los controles dependen de quién los implementó y no de lo que la organización decidió.

Pero la política tiene un modo de fallo característico, y es el mismo que 6.1 diagnosticó para los controles técnicos, trasladado al plano documental: la política que existe en el papel pero que nadie hace cumplir no gobierna nada. Una organización puede tener un manual de políticas impecable y una realidad operativa que lo contradice en cada punto, y la brecha entre ambos es exactamente el «control no probado» de 6.1 a escala organizacional: un control que se supone que está y que nadie verificó que funcione. Peor todavía, una política que se aplica de forma inconsistente —estricta para unos, laxa para otros— es activamente dañina en un sentido que va más allá de la seguridad: en un caso de amenaza interna, como se verá en 7.3, una política aplicada de forma desigual es prueba en contra de la organización, porque convierte una sanción legítima en una discriminación demostrable. La política solo gobierna si se aplica, se aplica igual para todos, y alguien verifica que así sea. Escribirla es la parte fácil; hacerla cumplir es la que la vuelve gobernanza.

GV.OV — supervisión y métricas: el peligro del indicador que solo sabe subir#

La categoría de supervisión (GV.OV) cierra el lazo: comprueba que la estrategia de riesgo se esté cumpliendo y alimenta los ajustes. En la práctica, la supervisión se ejerce con métricas que suben hacia la dirección, y aquí acecha el modo de fallo político que 6.1 ya señaló y que conviene repetir porque en el plano de gobernanza es donde más daño hace: la métrica elegida para tranquilizar en lugar de para informar.

Un panel que reporta «el 98 % de los endpoints tiene el agente instalado» o «el cumplimiento de parches subió al 95 %» produce la sensación de progreso, y esa es precisamente su trampa: son indicadores que casi siempre pueden subir y que casi nunca miden lo que importa. El 98 % de cobertura no dice nada sobre si el 2 % restante es justamente el segmento de servidores críticos; el 95 % de parches no dice si el 5 % pendiente incluye la vulnerabilidad que se está explotando en el mundo real ahora mismo. Una supervisión honesta reporta hacia la dirección no los indicadores que suben sino los que responden a la pregunta que la dirección debería hacerse: ¿estamos reduciendo el riesgo sobre lo que de verdad importa? Eso exige métricas atadas a los activos críticos que definió GV.OC y a las tolerancias que fijó GV.RM, no promedios agregados que diluyen lo crítico en el volumen. La función de la supervisión no es demostrar que el programa trabaja, sino detectar dónde no está funcionando; una supervisión que solo produce buenas noticias no está supervisando, está tranquilizando, y tranquilizar a la dirección con datos que no miden el riesgo real es el modo más silencioso en que un programa de gobernanza fracasa.

GV.SC — la cadena de suministro: gobernar lo que no se controla#

La última categoría, gestión del riesgo de la cadena de suministro (GV.SC, o Cybersecurity Supply Chain Risk Management, C-SCRM), es la que extiende la gobernanza al terreno más incómodo: el que la organización no controla directamente. Cada proveedor de software, cada servicio en la nube, cada componente de terceros incorporado a un producto es una superficie de ataque que la organización ha delegado sin dejar de ser responsable de ella. El riesgo no desaparece por estar tercerizado; solo se vuelve invisible, que es peor. Y a diferencia de un activo propio, sobre el proveedor no se puede correr un escáner, ni desplegar un agente, ni exigir un parche: la única palanca de control es contractual y de relación.

C-SCRM es, por eso, gobernanza casi pura —no hay un control técnico que la resuelva—. Se ejerce integrando los requisitos de seguridad directamente en los contratos (el derecho a auditar, la obligación de notificar incidentes en un plazo, los estándares que el proveedor debe cumplir), evaluando el riesgo del proveedor antes de incorporarlo y monitoreándolo a lo largo de todo el ciclo de vida del servicio, no solo en la selección inicial. Un proveedor que era seguro cuando se lo contrató puede degradarse, ser adquirido, sufrir su propia brecha; la gestión del riesgo de terceros que se hace una vez, al firmar, no es gestión sino un trámite. Este es también el puente con la dependencia que 6.4 ejercitó en crisis: el escenario del proveedor caído no es hipotético, y la organización que no gobernó ese riesgo por adelantado lo descubre cuando ya no puede hacer nada más que esperar a que el tercero se recupere.

El ataque de cadena de suministro convierte la confianza en un vector. La técnica que C-SCRM gobierna tiene nombre en el marco de MITRE ATT&CK —Supply Chain Compromise, T1195— y su caso testigo es SolarWinds: el compromiso de la infraestructura de compilación de un proveedor de software de gestión insertó una puerta trasera en una actualización firmada y legítima, que miles de organizaciones instalaron confiando en la firma del fabricante. Ningún control perimetral de las víctimas podía detenerlo, porque el vector era una actualización autorizada de un producto autorizado: el atacante no rompió la puerta, entró por la que la organización mantenía abierta a su proveedor de confianza. La lección de gobernanza es que la confianza en un tercero es en sí misma una superficie de ataque, y que el panorama de amenazas la ubica hoy entre las de crecimiento más rápido precisamente porque escala: comprometer un proveedor es comprometer a todos sus clientes de una vez. C-SCRM es la disciplina que trata esa confianza como lo que es —un riesgo a evaluar y monitorear— y no como un supuesto.

Cierre#

GOVERN, vista de cerca, no es un ideal abstracto sino una secuencia de decisiones concretas que alguien tiene que tomar y firmar: entender para qué existe la organización, fijar cuánto riesgo tolera, repartir quién decide, escribir las reglas, verificar que se cumplan y extender todo eso a los terceros de los que se depende. Cada una de esas decisiones es lo que da mandato a las funciones operativas que las Partes anteriores construyeron; sin ellas, la operación funciona por inercia y buena voluntad, que es exactamente lo que no resiste ni un recorte de presupuesto ni la investigación posterior a una brecha.

Lo que queda de la Parte lleva esta capa directiva a su prueba más exigente. Los capítulos 7.3 y 7.4 toman la amenaza interna —el caso donde el adversario ya tiene acceso legítimo, ningún control técnico basta por sí solo, y todo depende de que exista un programa gobernado que coordine a IT, recursos humanos, legal y seguridad física—, porque es el terreno que mejor demuestra que, en el límite, la seguridad es un problema de organización antes que de tecnología.

Referencias#

  • blue-dfir/nist-csf-2/cap-01 — NIST Cybersecurity Framework (CSF) 2.0: la función GOVERN y sus categorías —contexto organizacional (GV.OC), estrategia de gestión de riesgo (GV.RM), roles, responsabilidades y autoridades (GV.RR), política (GV.PO), supervisión (GV.OV) y gestión del riesgo de la cadena de suministro (GV.SC / C-SCRM)—, y la definición de C-SCRM como el proceso sistemático de identificar, evaluar y mitigar la exposición introducida por proveedores y productos de terceros, integrando requisitos en los contratos y monitoreando el riesgo a lo largo del ciclo de vida del servicio.
  • La distinción entre apetito y tolerancia de riesgo, el uso de la matriz RACI para asignar un único responsable por decisión, el aterrizaje del apetito en las cuatro salidas de la validación de 6.1, el modo de fallo de las métricas que solo saben subir y el encuadre de C-SCRM como gobernanza de lo que no se controla directamente son enriquecimiento propio. El caso SolarWinds (MITRE ATT&CK T1195, Supply Chain Compromise) se usa como ilustración del riesgo que C-SCRM gobierna; el crecimiento del vector se apoya en el panorama de amenazas de 1.6, la exigencia de aplicación consistente de la política se retoma en 7.3, y los huecos de autoridad y de dependencia de terceros se apoyan en el ejercicio de crisis de 6.4 y en la gestión de exposición de 6.5.