7.1 · El marco de gobernanza: NIST CSF 2.0 y la función GOVERN

10 min de lectura · gobernanza / nist-csf / gestion-de-riesgo / frameworks / madurez / blue-team / estrategia · ⎙ PDF

Panorama#

Las seis Partes anteriores construyeron capacidades: inteligencia sobre el adversario, técnicas ofensivas y su contracara defensiva, detección superficie por superficie, validación empírica de que todo eso funciona. Lo que ninguna respondió es una pregunta que no es técnica y sin la cual las demás quedan sin ancla: ¿quién decide qué proteger, con qué presupuesto, bajo qué política, y quién rinde cuentas cuando falla? Esa es la materia de la gobernanza, y es lo que esta Parte agrega.

El instrumento de referencia para ordenarla es el Cybersecurity Framework (CSF) 2.0 del NIST, y conviene entender primero qué tipo de documento es, porque su naturaleza determina cómo se usa. El CSF es un marco de resultados: no prescribe herramientas ni configuraciones, sino que describe qué debe lograr una organización en materia de ciberseguridad y deja el cómo a cada quien. Es voluntario, agnóstico de sector, país y tecnología, y está pensado para servir a una empresa multinacional tanto como a un municipio pequeño. Su valor no está en decir algo que un técnico no sepa, sino en ofrecer un lenguaje común con el que el técnico, el director financiero y el consejo de administración pueden hablar de lo mismo sin traducirse mal.

La tesis que abre la Parte se apoya en ese carácter: la ciberseguridad no es un dominio técnico aislado, sino un componente de la gestión de riesgo empresarial (Enterprise Risk Management). El riesgo cibernético compite por recursos con el riesgo financiero, el legal y el operativo, se decide con los mismos criterios y se reporta a las mismas instancias. Un programa que se piensa a sí mismo como una función técnica separada —el equipo de seguridad contra el resto de la empresa— es un programa sin mandato, y un programa sin mandato no sobrevive al primer recorte de presupuesto ni al primer incidente que exponga que nadie era responsable.

El manual ya era una implementación del CSF, sin el techo#

Hay un modo de leer el CSF que lo vuelve inmediatamente útil para este manual, y es notar que su estructura describe exactamente el recorrido hecho hasta aquí. El Core del CSF organiza los resultados en seis Funciones, y cinco de ellas son operativas y ya están construidas en las Partes anteriores:

IDENTIFY (comprender activos, riesgos y contexto) es lo que hicieron el programa de inteligencia de la Parte 1 y el inventario y la gestión de exposición de 6.5.
PROTECT (salvaguardas preventivas: control de acceso, cifrado, resiliencia) es la contracara defensiva que cada capítulo ofensivo de las Partes 3 y 4 desarrolló —el hardening, el least privilege, la segmentación—.
DETECT (monitoreo y descubrimiento de eventos adversos) es la Parte 5 entera, de la telemetría a la caza.
RESPOND (contención y mitigación) y RECOVER (restauración de capacidades) son las dos mitades de 5.4, el ciclo de respuesta y la recuperación con continuidad de negocio.

La sexta función es la que no tiene un capítulo previo, y no por olvido: es la que faltaba. GOVERN —la gobernanza del riesgo: estrategia, política, roles, supervisión, gestión del riesgo de la cadena de suministro— es la novedad estructural de la versión 2.0 del marco, que antes daba por supuesta la dirección y ahora la hace explícita. Y su posición no es la de una sexta función al lado de las otras cinco, sino la de una capa por encima: GOVERN establece el contexto, el apetito de riesgo y las autoridades dentro de los cuales las otras cinco operan. El manual llega a la Parte 7 habiendo construido una implementación del CSF a la que le faltaba el techo; esta Parte lo pone.

flowchart TB
  GV["GOVERN — estrategia, política, roles, riesgo, C-SCRM\n(la capa que decide y rinde · Parte 7, lo que faltaba)"]
  GV --> ID["IDENTIFY\nactivos, riesgo, contexto\n→ P1 + 6.5"]
  GV --> PR["PROTECT\nsalvaguardas preventivas\n→ hardening de P3/P4"]
  GV --> DE["DETECT\nmonitoreo y descubrimiento\n→ P5 entera"]
  GV --> RS["RESPOND\ncontención y mitigación\n→ 5.4"]
  GV --> RC["RECOVER\nrestauración y continuidad\n→ 5.4"]

La estructura del Core: resultados, no controles#

El Core del CSF tiene tres niveles de granularidad, y entenderlos evita el error de tratarlo como una lista de tareas. Las seis Funciones se subdividen en Categorías —grupos de resultados relacionados— y estas en Subcategorías, que son resultados concretos y verificables. Cada elemento tiene un código legible: GV.OC es la categoría de contexto organizacional dentro de GOVERN, ID.AM es la gestión de activos dentro de IDENTIFY, DE.CM es el monitoreo continuo dentro de DETECT, y así. Ese código es lo que permite decir «tenemos un hueco en DE.CM» y que un auditor, un proveedor y un directivo entiendan lo mismo.

La decisión de diseño que importa es que las Subcategorías se expresan como resultados, no como controles. El marco dice «las anomalías y los eventos se detectan y se analiza su impacto potencial», no «instale un SIEM de tal fabricante». Esa abstracción es deliberada y tiene una consecuencia práctica: el marco no envejece con la tecnología. Un control concreto —una herramienta, un producto— queda obsoleto; el resultado que se busca con él permanece. Por eso el CSF puede mapear sus Subcategorías a estándares y regulaciones externas mediante referencias informativas —enlaces que dicen «este resultado se corresponde con tal control de la ISO 27001 o de los CIS Controls»— sin atarse a ninguno. El técnico implementa controles; el marco ordena los resultados que esos controles deben producir.

GOVERN: por qué es el techo y no una función más#

La función GOVERN merece su capítulo propio —es el objeto de 7.2— pero su papel estructural se entiende aquí. GOVERN agrupa los resultados que fijan las condiciones de todo lo demás: comprender el contexto y la misión de la organización (GV.OC), establecer una estrategia de gestión de riesgo con un apetito definido (GV.RM), asignar roles, responsabilidades y autoridades (GV.RR), fijar la política (GV.PO), supervisar que la estrategia se cumpla (GV.OV) y gestionar el riesgo de la cadena de suministro (GV.SC).

Lo que estos resultados tienen en común, y lo que los pone por encima de las otras cinco funciones, es que ninguno es una capacidad técnica: todos son decisiones. Cuánto riesgo se acepta, quién tiene autoridad para aceptarlo, qué se prioriza cuando el presupuesto no alcanza para todo, quién responde ante el consejo cuando algo falla. Sin esas decisiones tomadas y documentadas, las funciones operativas trabajan en el vacío: el equipo de detección no sabe qué priorizar porque nadie definió qué activos importan más, y el analista de guardia no sabe si puede desconectar un sistema de producción porque nadie le dio —ni le negó— esa autoridad. Es el mismo hueco que 6.4 encontró en la crisis: lo que falla no es el sensor, es la decisión sin dueño. GOVERN es la función que le pone dueño a las decisiones antes de que la crisis las exija.

Perfiles organizacionales: del diagnóstico al plan#

El CSF no se usa marcando Subcategorías como una lista de verificación, sino construyendo perfiles organizacionales (Organizational Profiles). Un perfil describe el estado de la postura de ciberseguridad en términos de los resultados del Core, y se construye por pares: un Current Profile documenta qué resultados se logran hoy, y un Target Profile documenta cuáles se quieren lograr, priorizados según los objetivos y el apetito de riesgo de la organización. La diferencia entre ambos es un análisis de brechas (gap analysis), y esa brecha —no la lista completa de Subcategorías— es lo que se convierte en un plan de acción con prioridades, plazos y presupuesto. Es el instrumento que traduce «estamos inseguros», que no es accionable, en «nos falta cobertura de monitoreo en el segmento industrial y el objetivo es cerrarla en noventa días», que sí lo es.

El Current Profile honesto sale de medir, no de suponer. Un perfil actual construido preguntándole a cada responsable si cumple su parte produce el mismo resultado que 6.1 desarmó al abrir la Parte anterior: una foto de lo que la organización cree que tiene, no de lo que tiene. El perfil solo sirve como base de decisión si el Current se deriva de la evidencia —la validación de controles de 6.1, la medición de exposición de 6.5— y no de la autoevaluación. Un análisis de brechas sobre un Current inventado prioriza inversiones sobre datos falsos, que es peor que no priorizar: gasta con la confianza de estar cerrando huecos que quizá ni existen mientras deja abiertos los reales. La gobernanza consume la validación; sin ella, el marco se vuelve un ejercicio de documentación.

Los Tiers: madurez como decisión, no como escalera#

El último instrumento del marco son los Tiers, cuatro niveles que caracterizan el rigor con que una organización gestiona el riesgo cibernético: Partial (Tier 1: gestión ad hoc y reactiva), Risk Informed (Tier 2: hay conciencia del riesgo pero los procesos no están formalizados), Repeatable (Tier 3: prácticas formalizadas y consistentes) y Adaptive (Tier 4: la organización ajusta su postura de forma proactiva, alimentándose de inteligencia de amenazas). Avanzar de Tier implica institucionalizar procesos —pasar de que alguien lo haga a que la organización lo haga con independencia de quién esté—.

La tentación es leer los Tiers como una escalera donde el objetivo es siempre llegar al cuarto, y es una lectura equivocada. El Tier objetivo es una decisión de apetito de riesgo, no una meta universal. Subir de nivel cuesta —dinero, personal, fricción operativa— y no toda organización necesita ser Adaptive en todo: una función de bajo riesgo puede gestionarse razonablemente en Tier 2, y forzarla al Tier 4 malgasta recursos que rendirían más en el activo crítico. La decisión de qué Tier se busca, para qué parte de la organización, es en sí misma un acto de gobernanza —un resultado de GOVERN—, y ese carácter, el de una decisión deliberada sobre cuánto rigor comprar y dónde, es lo que separa un programa maduro de uno que colecciona certificaciones.

Cierre#

El CSF da a esta Parte su columna vertebral: un vocabulario de resultados, un instrumento para medir la brecha entre lo que se tiene y lo que se quiere, y un modelo para decidir cuánto rigor buscar. Y da al manual entero su lugar: lo que las Partes 1 a 6 construyeron son las cinco funciones operativas del marco, y lo que faltaba —la función que las decide y las rinde— es lo que esta Parte desarrolla.

El resto de la Parte baja del marco a su ejercicio. El capítulo 7.2 entra en la función GOVERN en detalle —apetito de riesgo, política, roles y la cadena de suministro—; los capítulos 7.3 y 7.4 toman un caso donde la gobernanza no es opcional y ningún control técnico basta por sí solo —la amenaza interna—, porque es el terreno que mejor muestra que la seguridad, en el límite, 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: el marco de resultados y su carácter voluntario y agnóstico, las seis Funciones con la incorporación de GOVERN como novedad de la versión 2.0, la jerarquía Function–Category–Subcategory con sus códigos, las referencias informativas hacia estándares externos, los perfiles organizacionales (Current y Target) con el análisis de brechas, los cuatro Tiers de madurez y la relación del CSF con la gestión de riesgo empresarial y con la gestión del riesgo de la cadena de suministro (C-SCRM).
El mapeo explícito de las cinco funciones operativas a las Partes del manual que las construyeron —IDENTIFY, PROTECT en el hardening de las Partes 3 y 4, DETECT, RESPOND y RECOVER y la gestión de exposición— y la lectura de los Tiers como decisión de apetito de riesgo son enriquecimiento propio. La exigencia de que el Current Profile se derive de la validación empírica y no de la autoevaluación se apoya en 6.1, y el hueco de la decisión sin dueño, en 6.4.

Mencionado en

0.5 · Arquitectura de seguridad: modelar la amenaza y confiar con criterioEl capítulo que compone los tres sustratos anteriores —la red, el sistema operativo y la criptografía— en un sistema que se puede defender. La seguridad no se agrega al final como una capa de pintura: se diseña, y diseñarla empieza por una pregunta que casi nadie hace a tiempo, ¿contra qué, exactamente, estamos defendiéndonos? El modelado de amenazas (con STRIDE como marco de referencia) es la disciplina de hacerse esa pregunta de forma estructurada, sobre un dibujo del sistema, antes de que el atacante la haga por uno. De ahí salen los dos conceptos que organizan todo el capítulo: la superficie de ataque, que hay que ver para poder reducir, y la frontera de confianza, que deja de ser un accidente para convertirse en un artefacto de diseño explícito —la línea, dibujada a propósito, donde algo confiable recibe algo que no lo es y por lo tanto hay que validar—. El capítulo muestra cómo el modelo de perímetro tradicional —duro por fuera, blando por dentro— fracasó, y cómo el zero trust lo reemplaza aplicando a toda la red el principio de mediación completa: nunca confiar por ubicación, verificar en cada acceso, con la identidad convertida en el nuevo perímetro. Cierra con el diseño seguro por defecto como la forma de no repetir el error. No rehace la gobernanza de la Parte 7 ni el detalle operativo del zero trust: da el marco de diseño que la gobernanza dirige.
0.6 · Síntesis: el manual en una ideaEl capítulo que cierra la Parte 0 y, con ella, el manual entero. Después de recorrer diez Partes —la explotación, el Active Directory, el reconocimiento, la defensa azul, la inteligencia de amenazas, la validación púrpura, la gobernanza, el factor humano, la inteligencia artificial y estos fundamentos— la pregunta que queda es la más difícil y la más importante: ¿cuál es el hilo único que atraviesa todo? Este capítulo lo responde destilando las diez Partes en una sola idea. Muestra que las técnicas cambian —cambia el intérprete que se inyecta, cambia el protocolo que se abusa, cambia la superficie que aparece con cada tecnología nueva— pero los principios no: separar los datos del código, otorgar el mínimo privilegio, apilar la defensa en profundidad, reconocer que el humano es una superficie y que la máquina cambia la escala pero no los fundamentos, todo bajo una gobernanza que lo ejerce y una inteligencia que lo orienta. Recapitula la travesía como un solo movimiento y llega a la tesis que corona el libro: la seguridad no es un producto que se compra ni una técnica que se domina, sino una propiedad que se cultiva —un puñado de invariantes aplicados con disciplina a cada capa, sostenidos en el tiempo—. Y cierra volviendo al principio: esta Parte se lee primera porque es el cimiento, pero se escribió última porque solo desde el edificio terminado se ve sobre qué se paró cada piso.
7.2 · Riesgo, política y cadena de suministro (C-SCRM)El capítulo que baja de la taxonomía del marco a la función GOVERN en detalle. Sostiene que la gobernanza traduce el apetito de riesgo de la dirección en autoridad, política y presupuesto, y que sin esa capa las decisiones operativas —qué se parchea, qué se acepta, quién desconecta— se toman sin mandato y no se sostienen: es la diferencia entre «el analista decidió» y «la organización decidió». Recorre las seis categorías de GOVERN —contexto organizacional, estrategia de riesgo, roles y autoridades, política, supervisión y gestión del riesgo de la cadena de suministro—, aterriza el apetito de riesgo en las cuatro salidas de la validación de la Parte 6, señala el modo de fallo político de las métricas que solo saben subir, y cierra con C-SCRM como la superficie que no se controla directamente y que solo se gobierna por contrato y monitoreo del ciclo de vida del proveedor.
7.3 · El programa de amenaza interna (IRMP)El capítulo que aplica la gobernanza a su caso más incómodo: el adversario que ya está adentro con acceso legítimo. Sostiene que la amenaza interna no se elimina sino que se gestiona con un programa estructurado, multidisciplinario y basado en evidencia —un Insider Risk Management Program, IRMP—, y que a diferencia del atacante externo el insider no se frena en el perímetro sino con least privilege y con la correlación de señales entre dominios que ninguna área ve completa sola: IT, recursos humanos, legal y seguridad física. Presenta los seis arquetipos de incidente y el ciclo de vida del empleado como eje temporal —con el despido y la renuncia como los desencadenantes empíricos más frecuentes—, distingue gestión de riesgo de vigilancia, y recorre las tres primeras prácticas del CERT: inventariar los activos críticos, formalizar el programa con patrocinio de la dirección, y aplicar los controles administrativos con una consistencia que es a la vez control preventivo y prueba jurídica. Enlaza la detección técnica a la Parte 5 y la crisis a la Parte 6 sin rehacerlas.
7.4 · Controles de amenaza interna: administrativos, humanos y de ciclo de vidaEl capítulo que cierra la Parte 7 bajando el programa de amenaza interna a las veintidós prácticas del CERT, y sostiene que no son veintidós herramientas sino tres planos que tienen que operar integrados —humano, técnico y de ciclo de vida—. El plano que más rinde y que el resto del manual no había cubierto es el humano, porque actúa aguas arriba de todo lo demás, en la motivación y no en el comportamiento ya desviado: conducta preocupante desde la contratación, gestión del estrés, concientización, y sobre todo justicia organizacional e incentivos positivos, la contramedida más barata y menos usada. El plano técnico se referencia a las Partes que ya lo construyeron —control de cuentas privilegiadas, UEBA y correlación, separación de funciones y least privilege— porque el aporte de la gobernanza es la política que los ordena, no la técnica. El plano de ciclo de vida cierra el eje temporal abierto en 7.3 con el control de cambios contra las bombas lógicas, el respaldo protegido del propio administrador y el deprovisionamiento en la terminación, el momento de máximo riesgo empírico. Y la última práctica —aprender de los incidentes— es el lazo de mejora que devuelve la Parte entera a la validación. Cierre: la gobernanza no se compra, se ejerce.
9.2 · IA defensiva: ML en el SOC y respuesta autónomaEl capítulo azul de la Parte 9: la inteligencia artificial como herramienta del defensor. Recorre el aprendizaje automático en el corazón del centro de operaciones —el modelo supervisado que clasifica lo conocido, el no supervisado que detecta la anomalía que nunca vio— y la arquitectura que lo sostiene: el pipeline de ingesta, feature y modelo sobre un data lake, y las plataformas que lo materializan (NGAV, EDR, XDR, NDR, UEBA, SOAR). Su eje es el espectro delicado de la respuesta autónoma —de la sugerencia a la aprobación al bloqueo automático— y la supervisión humana como el freno que ninguna madurez elimina, porque la automatización a escala puede convertirse en una denegación de servicio autoinfligida. Cierra con los límites honestos que separan la IA defensiva real del ruido de mercado: los falsos positivos y la fatiga de alertas, la degradación del modelo por data drift, el problema de la explicabilidad, y la incómoda verdad de que el propio modelo defensivo es una superficie de ataque nueva. La tesis: la IA no reemplaza al analista ni a la detección que la Parte 5 construyó; le pone una capa encima, y esa capa hay que gobernarla.
9.4 · Seguridad de la IA: adversarial ML y el modelo como superficieEl tercer eje de la Parte 9 y el cierre del bloque substantivo del manual: no la IA para defender ni para atacar, sino la seguridad del propio sistema de inteligencia artificial. Al desplegar un modelo, la organización crea una superficie de ataque nueva —el modelo mismo—, con vulnerabilidades que no son las del software clásico. El capítulo recorre el aprendizaje automático adversario (la evasión que engaña al clasificador en tiempo de inferencia, el envenenamiento que corrompe el entrenamiento, la inversión que extrae los datos confidenciales del modelo) y luego la superficie propia de los modelos de lenguaje, cuyo corazón es una vieja conocida: la inyección de instrucciones (prompt injection) es la misma clase de vulnerabilidad que la inyección de la Parte 3 —un intérprete que no puede distinguir los datos de las órdenes—, un nivel más arriba. Cierra con la defensa arquitectónica que el problema exige (tratar toda salida del modelo como no confiable, privilegio mínimo para los agentes de IA, los marcos OWASP LLM y MITRE ATLAS) y con la síntesis que corona la Parte y el manual: una tecnología nueva no deroga los fundamentos, reubica la frontera de confianza, y la vulnerabilidad vive en la frontera que se dejó de validar.