Del valor al riesgo: una cadena que debe poder explicarse
Un informe enumera «ransomware, vulnerabilidades con identificador CVE (Common Vulnerabilities and Exposures), fuga de datos y riesgo reputacional» en una misma columna. Cada término pertenece a una parte distinta del problema. Ransomware puede nombrar una clase de herramienta, campaña o evento; una CVE identifica una vulnerabilidad publicada en el catálogo del programa, cuyo alcance depende de sus reglas de asignación (CVE Program); la fuga es un efecto o una pérdida de confidencialidad; y la reputación describe una posible consecuencia para un stakeholder. Mezclarlos impide razonar sobre qué causa qué.
El análisis profesional de riesgo no comienza asignando colores. Comienza construyendo un escenario que pueda recorrerse: alguien depende de un activo; ciertas propiedades preservan su valor; una fuente origina un evento; el evento encuentra condiciones que lo hacen posible; los controles alteran esa trayectoria; y el resultado puede producir consecuencias inciertas.
Este capítulo fija el vocabulario de esa cadena. No pretende imponer una taxonomía universal: distintas normas usan los términos con variaciones. El objetivo es conservar las relaciones causales y declarar qué definición se emplea, de modo que dos personas puedan discutir evidencia y no sólo etiquetas.
El activo es aquello de lo que alguien depende
Un activo no tiene que ser un archivo ni una máquina. Puede ser información, una función, autoridad para tomar decisiones, continuidad operacional, seguridad humana, confianza pública, propiedad intelectual o una relación con terceros. Lo convierte en activo el valor o dependencia que representa para una persona, organización o sociedad.
Inventariar servidores sin relacionarlos con funciones produce una lista técnica, no un modelo de riesgo. Una base de datos de recetas importa porque sostiene decisiones clínicas, disponibilidad del tratamiento, privacidad y autoridad de prescripción. El mismo motor de base de datos en un entorno de demostración posee consecuencias diferentes.
El valor tampoco es siempre monetario. Puede expresarse como daño humano, tiempo de interrupción, incumplimiento de una obligación, pérdida irreversible de información o concentración de autoridad. Traducir todo inmediatamente a dinero puede facilitar comparaciones, pero también ocultar distribuciones: una pérdida pequeña para la organización puede ser catastrófica para un individuo.
Una propiedad dice qué debe seguir siendo verdadero
Un activo adquiere valor bajo propiedades concretas. Confidencialidad pregunta quién puede conocer información. Integridad incluye exactitud, completitud y modificaciones autorizadas. Disponibilidad exige acceso oportuno para sujetos autorizados. Según el sistema también importan autenticidad, procedencia, accountability, privacidad, control de uso, safety o resiliencia.
No basta escribir «integridad de la base de datos». Conviene especificar: «una receta aceptada corresponde al paciente, prescriptor, medicamento, dosis y momento autorizados, y toda modificación conserva procedencia». Esta forma permite buscar eventos que violan la propiedad y controles que la sostienen.
Las propiedades pueden entrar en tensión sin ser enemigas absolutas. Bloquear una cuenta después de intentos fallidos puede proteger autenticación y perjudicar disponibilidad si un adversario provoca bloqueos masivos. Registrar más contexto puede mejorar accountability y aumentar exposición de datos personales. El análisis debe hacer visible el trade-off y la misión, no declarar que una propiedad siempre domina.
Threat source y threat event son objetos distintos
NIST define threat como una circunstancia o evento con potencial de afectar adversamente operaciones, activos o personas. En una evaluación detallada conviene separar la threat source, capaz de originar daño, del threat event, la acción o circunstancia concreta que ocurre. NIST SP 800-30 Rev. 1
Una fuente adversarial puede ser un operador interno, un grupo criminal o un servicio comprometido. Una fuente accidental puede ser un administrador que comete un error. También existen fuentes estructurales o ambientales: incendio, dependencia regional, fallo eléctrico o defecto de fabricación. Seguridad no trata únicamente de intenciones hostiles.
El evento debe describirse con suficiente precisión para analizarlo: una identidad modifica una regla de acceso; un despliegue elimina una réplica; una inundación interrumpe alimentación; un proveedor revoca una interfaz de programación de aplicaciones (API). «Atacante compromete el sistema» es demasiado circular: no identifica la acción, precondiciones ni punto donde un control podría cambiar el resultado.
Vulnerabilidad: una debilidad, no el daño completo
Una vulnerabilidad es una debilidad que una fuente puede explotar o activar para producir un efecto adverso. Puede residir en software, arquitectura, configuración, procedimiento, control interno o interacción humana. NIST, glosario de Vulnerability
Una CVE es una forma de identificar públicamente determinadas vulnerabilidades, no el universo completo. Credenciales compartidas, una autoridad excesivamente concentrada, recuperación sin verificación suficiente o dependencia de una sola región pueden ser debilidades importantes sin tener CVE.
También conviene distinguir vulnerabilidad de condición predisponente. La ubicación de un sistema, su arquitectura o entorno pueden aumentar la probabilidad de que eventos produzcan daño sin constituir un defecto explotable aislado. NIST SP 800-30 usa esta separación para evitar forzar toda explicación dentro de «hay un bug».
La exposición responde otra pregunta: ¿existe un camino por el que la fuente o evento relevante alcance la debilidad? Un servicio vulnerable no accesible desde Internet puede seguir expuesto a identidades internas, administración, supply chain o movimiento lateral. «No está público» reduce ciertos escenarios; no elimina automáticamente la vulnerabilidad ni todo riesgo.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Los controles cambian la trayectoria
Un control puede reducir la probabilidad del evento, impedir que alcance la debilidad, limitar el efecto, detectar la progresión o facilitar recuperación. La autenticación resistente puede reducir uso de credenciales robadas; segmentación puede limitar alcance; validaciones de integridad pueden impedir cambios; alertas pueden acortar permanencia; backups probados pueden reducir consecuencias.
Describir sólo «control presente» es insuficiente. Interesan cobertura, eficacia, independencia, dependencia y modo de fallo. Un segundo factor no ayuda a cuentas excluidas. Dos réplicas en la misma región comparten una causa de fallo. Un backup conectado con las mismas credenciales puede quedar dentro del radio de compromiso.
Los controles también introducen coste y nuevas superficies. Un agente de administración centralizada mejora visibilidad y parcheo, pero concentra autoridad. El análisis debe reconocer tanto el riesgo reducido como el creado, sin caer en la conclusión de que todo control es perjudicial.
Efecto técnico, pérdida e impacto
Ejecución de código, lectura de una tabla, escalada de privilegios o indisponibilidad son efectos técnicos. Para estimar impacto hay que conectarlos con activos, misión y stakeholders.
En el servicio de recetas, modificar una fila puede causar una prescripción incorrecta, retrasar tratamiento, originar fraude, obligar a reconciliar historiales y erosionar confianza. El impacto depende de cuántos pacientes, durante cuánto tiempo, con qué capacidad de detección y qué alternativa operacional.
La misma vulnerabilidad puede producir efectos distintos según privilegios, datos y arquitectura. El mismo efecto puede causar impactos distintos según contexto. Leer registros de un catálogo público no equivale a leer expedientes clínicos; interrumpir un entorno de pruebas no equivale a interrumpir urgencias, aunque el error de software sea idéntico.
El impacto tampoco se agota en la organización propietaria. Puede recaer en clientes, pacientes, empleados, proveedores, otras organizaciones o infraestructura pública. Una valoración que sólo cuenta coste interno puede externalizar las consecuencias más graves.
Riesgo: incertidumbre sobre escenarios y consecuencias
NIST describe riesgo como una medida de hasta qué punto una entidad está amenazada por una circunstancia o evento, típicamente en función del impacto adverso y su likelihood. NIST, glosario de Risk
Esta relación suele escribirse como riesgo = likelihood × impacto. La expresión puede recordar que ambas dimensiones importan, pero no autoriza por sí sola una multiplicación significativa. Si «bajo, medio, alto» se convierte en 1, 2 y 3, no sabemos que la distancia de bajo a medio sea igual que de medio a alto ni que alto represente tres veces bajo. Multiplicar ordinales produce un número con apariencia de precisión, no necesariamente una medida.
Likelihood tampoco es siempre frecuencia histórica. En escenarios adversariales, el actor adapta conducta; la ausencia histórica puede reflejar falta de interés, de observabilidad o de oportunidad. Una estimación puede integrar probabilidad de inicio, capacidad, exposición, éxito dadas las condiciones y eficacia de controles. Debe explicar horizonte temporal y evidencia.
El resultado más útil puede ser un rango, orden parcial o distribución, acompañado de sensibilidad: «la prioridad cambia si la restauración supera ocho horas» o «el escenario domina mientras una sola identidad conserve esta autoridad». La incertidumbre no invalida la decisión; ocultarla sí puede hacerlo.
Las escalas permiten operaciones diferentes
Una categoría ordinal permite ordenar casos bajo criterios acordados, pero no calcular distancias. Un intervalo numérico permite hablar de diferencias si la escala está calibrada. Una razón con cero significativo permite proporciones. Una distribución expresa múltiples resultados y probabilidades o grados de creencia.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Las matrices pueden facilitar conversación y consistencia si sus categorías poseen criterios observables. Fallan cuando colores sustituyen escenarios, cuando equipos interpretan términos de forma distinta o cuando la aritmética impone prioridades que los datos no sostienen.
Una matriz 5×5 tampoco vuelve comparables automáticamente daños humanos, interrupción y pérdida financiera. Puede requerirse una evaluación multicriterio que mantenga dimensiones separadas hasta el nivel de decisión apropiado.
El registro debe conservar quién eligió la escala, qué horizonte representa y qué decisión pretende informar. Si una categoría cambia de significado entre equipos, la tabla no es una medición común aunque use los mismos colores. Una revisión puede comparar órdenes («este escenario requiere atención antes que aquel») sin inventar proporciones («es dos veces peor»). Cuando se necesita una cifra, se documenta la unidad, el método de calibración y el margen de incertidumbre; si no existe, se mantiene una comparación cualitativa y se identifica qué dato permitiría mejorarla.
Severidad técnica no equivale a riesgo contextual
Una puntuación técnica ayuda a caracterizar propiedades de una vulnerabilidad: requisitos de acceso, complejidad, privilegios, interacción y efectos posibles bajo un modelo. El riesgo organizacional añade exposición real, activos, controles, amenaza, consecuencias y tiempo.
Una vulnerabilidad de alta severidad en un componente inaccesible y próximo a retiro puede representar menor prioridad que una configuración sin CVE que expone autoridad administrativa cotidiana. Inversamente, «no es crítica en el Common Vulnerability Scoring System (CVSS)» no significa que sea aceptable dentro de una composición específica; CVSS comunica características y severidad técnica, no la decisión contextual (CVSS v4.0, §1).
Desliza horizontalmente para leer el diagrama a tamaño completo.
El modelo necesita fronteras y supuestos
La cadena causal es una herramienta de reconstrucción, no una tubería física ni un algoritmo que produzca una cifra por sí solo. Antes de recorrerla hay que fijar el sistema de interés, el horizonte temporal y los stakeholders incluidos. Una amenaza que parece remota para el servicio puede ser inmediata para un paciente; una interrupción tolerable para el propietario puede ser inaceptable para una farmacia que no dispone de alternativa.
El stakeholder es una persona, grupo u organización que tiene una necesidad, una obligación o una consecuencia relevante respecto del sistema. El activo es aquello de valor de lo que ese stakeholder depende; la propiedad es la condición que debe conservarse para que el activo mantenga el valor considerado. Así, «API» no es todavía un activo ni «confidencialidad» un impacto: son, respectivamente, una posible superficie y una propiedad que debe vincularse con datos y personas.
La frontera también decide qué se observa. Un análisis del servicio de recetas puede incluir el proveedor cloud, el proveedor de identidad (IdP), farmacias y procedimiento manual, o excluirlos temporalmente. Excluirlos no elimina su influencia: convierte sus estados en supuestos o incertidumbres que deben registrarse. La ausencia de una entidad en el diagrama no es evidencia de ausencia de dependencia.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Medir no reemplaza adjudicar
Una evaluación puede ser cualitativa, semicuantitativa o cuantitativa. En una valoración cualitativa, «alto» significa que el criterio definido para esa organización se cumple; no significa una probabilidad universal. En una semicuantitativa, los rangos pueden ordenar escenarios o apoyar una decisión, pero sus intervalos deben estar anclados en ejemplos y no confundirse con unidades físicas. En una cuantitativa, una probabilidad o pérdida monetaria sólo es defendible si el modelo, los datos y el horizonte hacen explícita su interpretación.
La cifra nunca es el primer objeto. Primero se adjudica el escenario: qué evento se supone, qué precondiciones existen, qué control actúa, qué efecto se espera, quién recibe la consecuencia y con qué evidencia. Después se puede comparar. Si dos equipos asignan «alto» a la misma palabra pero uno piensa en una hora de interrupción y otro en siete días, la escala no ha producido consistencia; ha ocultado una discrepancia.
La incertidumbre tiene varias fuentes. Puede faltar observabilidad, ser incompleta la historia, cambiar la conducta adversarial, depender el efecto de una cadena de terceros o no existir una medición directa del impacto. Conviene registrar si una afirmación es observada, inferida, modelada o sólo hipotética. «No encontramos eventos» es una observación sobre el registro disponible, no una prueba de que el evento sea imposible o improbable.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Caso evolutivo: una misma receta, cuatro decisiones
En la primera versión del servicio, una farmacia recibe una receta firmada por el sistema. El stakeholder principal necesita saber que el paciente y la dosis corresponden al prescriptor autorizado. El activo no es sólo la fila de base de datos: incluye la autoridad de prescripción y la continuidad del tratamiento. La propiedad de integridad exige que los campos no sean alterados sin autorización; autenticidad exige poder vincular la orden con su emisor; disponibilidad exige que pueda ser consultada cuando se dispensa.
En la segunda versión aparece una recuperación de cuenta basada en datos públicos. La condición es una debilidad del proceso, aunque no exista un identificador de vulnerabilidad de software. Una fuente adversarial obtiene acceso a la recuperación y origina el evento de emisión fraudulenta. El efecto técnico es una solicitud aceptada por la API; el impacto posible incluye medicación incorrecta, fraude y trabajo de reconciliación. Un límite de emisión puede reducir alcance, una aprobación humana puede detectar el patrón y una reconciliación posterior puede recuperar integridad parcial. Ningún control convierte el escenario en imposible por el solo hecho de estar instalado.
En la tercera versión, el equipo despliega una réplica en otra región, pero ambas regiones dependen de la misma autoridad de identidad y de la misma canalización de despliegue. La disponibilidad mejora frente a un fallo regional aislado, pero no frente a una causa común. Si se dibujan dos cajas como «redundancia» sin modelar la dependencia compartida, el diagrama sugiere una garantía que el diseño no ofrece. La condición predisponente es la concentración; el evento puede ser un fallo de proveedor o un cambio defectuoso; el efecto es indisponibilidad o datos divergentes, según el modo de fallo.
En la cuarta versión se usa una matriz 5×5. El equipo etiqueta probabilidad y impacto como 1–5 y multiplica. Esa operación puede ser una convención interna, pero sólo tiene interpretación si las categorías, el método de combinación y la decisión que soporta están definidos. Si «4» y «2» son rangos ordinales, el producto «8» no permite afirmar que un escenario sea el doble de otro; la propia especificación CVSS presenta sus puntuaciones como comunicación de severidad técnica y no como riesgo local (FIRST CVSS v4.0). La revisión debe conservar la comparación ordenada, describir la sensibilidad y pedir evidencia adicional, no maquillar la incertidumbre con decimales.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Transferir el modelo a un escenario distinto
Ahora considérese un sistema de nómina de un proveedor externo. El activo puede incluir la capacidad de pagar a tiempo y la privacidad de empleados; la propiedad de integridad no se reduce a «la base no cambia», porque también importa que la cuenta bancaria corresponda a la persona autorizada y que exista procedencia. Una amenaza ambiental o una indisponibilidad del proveedor no requiere una vulnerabilidad de software. Un control contractual puede repartir obligaciones, pero no transfiere automáticamente el perjuicio de una persona ni elimina la necesidad de comprobar recuperación.
La transferencia correcta conserva la forma de razonar y cambia las entidades: stakeholder → activo y propiedad → fuente y evento → condición/vulnerabilidad y exposición → control → efecto → impacto → riesgo e incertidumbre. No conserva las conclusiones del caso de recetas. «Hay autenticación» no prueba autorización; «hay seguro» no prueba continuidad; «el proveedor tiene certificación» no demuestra que una ruta concreta, una dependencia o un procedimiento funcionen en este horizonte.
La respuesta al riesgo tampoco es sinónimo de mitigación. Una organización puede evitar una actividad, reducir likelihood o impacto mediante controles, compartir ciertas pérdidas bajo un acuerdo, aceptar dentro de límites con autoridad informada o transferir una parte de la exposición. Cada opción deja obligaciones residuales y requiere monitorización. Si el contrato distribuye coste financiero pero el sistema sigue siendo el único canal de pago, la dependencia operacional permanece.
Síntesis operativa
Un análisis defendible empieza por quién depende de qué y por qué. Define la propiedad antes de nombrar el incumplimiento. Separa la fuente que puede originar un evento del evento mismo; identifica las debilidades y condiciones que permiten que alcance una superficie; describe el control por su mecanismo, cobertura y modo de fallo; distingue efecto técnico de consecuencia para cada stakeholder; y conserva horizonte, evidencia e incertidumbre al comparar escenarios.
El modelo no promete una fórmula universal. Permite preguntar dónde se rompe una explicación: ¿el activo está identificado?, ¿la propiedad es verificable?, ¿el evento es concreto?, ¿la exposición es plausible?, ¿el control actúa antes o después del efecto?, ¿qué impacto se observa y para quién?, ¿qué supuesto hace incierta la likelihood?, ¿qué decisión tiene autoridad y fecha de revisión? Cuando una respuesta es desconocida, el resultado correcto es una incertidumbre registrada y una próxima medición, no una etiqueta de confianza inventada.
Una práctica útil es escribir primero una afirmación de propiedad con criterio de observación. «La receta conserva integridad» es demasiado amplia; «el receptor rechaza una firma cuyo contenido fue modificado y registra la decisión sin exponer datos clínicos» permite diseñar una prueba. Después se anota qué parte depende de la clave, del canal, del servicio de identidad, del reloj y del procedimiento de recuperación. Esta descomposición evita atribuir al control una cobertura que en realidad pertenece a otra frontera.
La transferencia profesional exige además declarar qué se mantiene constante y qué cambia. Si se compara el mismo defecto en laboratorio y producción, el defecto debe permanecer igual mientras cambian exposición, datos, privilegios, controles y capacidad de recuperación. Si se cambia también el defecto, ya no se está explicando contexto: se están comparando dos problemas. El lector debe poder señalar la variable que explica la diferencia, no inferirla de una etiqueta «alto» o «bajo».
La priorización madura conserva ambas vistas. La severidad permite compartir información técnica; el riesgo decide tratamiento en un entorno. Alterar una puntuación técnica para introducir contexto local confunde los niveles. Es preferible registrar por separado severidad, exposición, valor del activo, controles y decisión.
Caso completo: servicio regional de recetas
Consideremos un servicio que recibe prescripciones, valida autoridad profesional y las entrega a farmacias.
Activos y propiedades. La continuidad del tratamiento necesita disponibilidad. La dosis, paciente y prescriptor requieren integridad y autenticidad. Los datos clínicos requieren confidencialidad. Las decisiones administrativas necesitan trazabilidad.
Fuentes y eventos. Un criminal puede usar una sesión robada para emitir recetas. Un despliegue defectuoso puede eliminar capacidad regional. Un operador puede conceder permisos excesivos. El proveedor cloud puede sufrir una interrupción.
Debilidades y condiciones. Recuperación de cuenta basada en información pública, privilegios amplios, falta de reconciliación, dependencia de una sola región y ausencia de modo degradado hacen posibles o agravan los eventos.
Controles. Autenticación resistente al phishing, aprobación para cambios de autoridad, registros verificables, límites de emisión, réplica independiente y procedimiento manual pueden actuar en puntos distintos.
Consecuencias. No todas se expresan como «datos perdidos». Puede haber tratamiento incorrecto, retraso, fraude, exposición de salud, sobrecarga de personal y pérdida de confianza.
Un registro útil formularía escenarios separados. «Una identidad de prescriptor comprometida emite recetas fraudulentas antes de que límites y revisión detecten el patrón» no es el mismo riesgo que «un fallo regional impide entregar recetas durante seis horas». Comparten el servicio, pero requieren evidencias y respuestas distintas.
Riesgo inherente, actual y residual
Algunas organizaciones llaman inherente al riesgo antes de considerar controles; actual al que existe con controles presentes; y residual al que queda después de una respuesta. Los términos deben definirse porque se usan de formas diferentes.
El contrafactual «sin controles» puede ser artificial: la arquitectura quizá no existiría sin autenticación, aislamiento o procesos básicos. Sirve para comunicar dependencia, pero no siempre es una medición observable. El riesgo residual tampoco es una cantidad que simplemente se resta. Los controles cambian rutas, actores, impactos y evidencias; pueden introducir nuevos escenarios.
Aceptar riesgo significa que una autoridad informada decide tolerarlo dentro de límites, horizonte y responsabilidades. No significa que el riesgo desaparezca. Transferir mediante contrato o seguro puede redistribuir pérdidas financieras, pero rara vez transfiere safety, continuidad o reputación por completo. Evitar elimina la actividad que origina el escenario. Reducir modifica likelihood o impacto. Cada respuesta necesita dueño y monitorización.
El riesgo cambia con el sistema
NIST SP 800-39 organiza la gestión como enmarcar, evaluar, responder y monitorizar a través de niveles de organización, misión/proceso y sistema (NIST SP 800-39, §§3.1–3.4). Enmarcar fija contexto, supuestos y alcance antes de evaluar; esta perspectiva evita tratar el assessment como documento anual aislado.
Cambian versiones, exposición, identidades, dependencias, amenazas, valor y capacidad de recuperación. Una adquisición puede concentrar datos; una integración puede abrir una ruta; una migración puede retirar otra; un control degradado puede aumentar riesgo sin modificar el código.
Monitorizar riesgo no consiste sólo en contar vulnerabilidades. Requiere indicadores de los supuestos: cobertura de controles, tiempo de recuperación probado, productores de telemetría activos, privilegios, concentración, accesibilidad, incidentes, cambios del entorno y decisiones pendientes.
Agregar sin contar dos veces
Un registro separa escenarios para analizarlos, pero la decisión debe considerar dependencias y causas comunes. Sumar pérdidas máximas de cada fila supone implícitamente que pueden ocurrir juntas y que no comparten consecuencias. Promediarlas puede ocultar un escenario extremo. Elegir sólo la puntuación más alta ignora acumulación y cascadas.
Dos aplicaciones pueden depender del mismo proveedor de identidad, región o equipo de operación. Sus interrupciones no son independientes. Un único compromiso administrativo puede materializar varios escenarios; una misma pérdida regulatoria puede aparecer como consecuencia en varias filas. La agregación exige modelar qué eventos se excluyen, cuáles se correlacionan y dónde una consecuencia ya fue contabilizada.
También importa la secuencia. Una interrupción puede forzar procedimientos manuales que reducen controles de integridad; un incidente puede agotar personal y elevar likelihood de errores posteriores; una restauración puede reintroducir una configuración vulnerable. El riesgo sistémico no se obtiene simplemente sumando riesgos de componentes.
Un registro de agregación debe identificar la unidad que se cuenta y la unidad que decide. Puede agrupar escenarios para localizar una dependencia común sin presentar el grupo como un único evento. También debe conservar escenarios pequeños que sirven como señales tempranas: su pérdida individual quizá sea limitada, pero su coincidencia puede indicar que una causa compartida está cambiando el entorno. La forma de comunicar depende de la decisión, no de la comodidad de una cifra única.
Cuando la evidencia no permite una distribución conjunta, es preferible presentar escenarios, concentraciones y sensibilidades que fabricar un total exacto. La pregunta de decisión puede ser «¿qué dependencia domina varias funciones críticas?» o «¿qué combinación supera nuestra capacidad de recuperación?». Estas formulaciones conservan incertidumbre y señalan dónde obtener nueva evidencia.
Errores de modelo frecuentes
«La amenaza es la vulnerabilidad». La fuente o evento y la debilidad ocupan lugares distintos; pueden combinarse de varias maneras.
«Tiene CVE, por tanto es el mayor riesgo». La identificación técnica no determina exposición, activos ni consecuencias locales.
«No está en Internet, así que no hay riesgo». Reduce ciertas rutas, pero quedan identidades internas, administración, dependencias, supply chain y fallos no adversariales.
«Alto por alto es 25». Sólo es válido si las escalas y operación poseen semántica justificada; colores ordinales no crean una razón numérica.
«Mitigado significa resuelto». Debe comprobarse la eficacia del control y describirse el riesgo restante y el creado.
«El impacto es la ejecución de código». Eso es un efecto técnico; el impacto depende de lo que ese efecto permite dañar.
«No ocurrió antes, por tanto es improbable». La observación histórica depende de exposición, motivación, detección y cambio.
Cómo redactar un escenario evaluable
Una estructura útil es:
Debido a condiciones y debilidades, la fuente S puede originar el evento E, que viola la propiedad P del activo A y produce consecuencias I para stakeholders, bajo el horizonte H. Los controles C modifican la progresión de estas maneras; la evidencia Q y la incertidumbre U sostienen la estimación.
Después se separan hechos, estimaciones y decisiones. Un inventario confirma versiones; un test demuestra una ruta; inteligencia informa capacidad e interés; métricas estiman restauración; responsables determinan tolerancia. Ninguna fuente debe presentarse como si demostrara las demás.
Síntesis
Activos son aquello de lo que alguien depende; propiedades expresan qué debe preservarse. Las threat sources pueden originar eventos adversos. Vulnerabilidades y condiciones predisponentes hacen posible o agravan su progresión. Los controles alteran la cadena. Los efectos técnicos se convierten en impacto al relacionarse con misión y stakeholders. El riesgo expresa incertidumbre sobre likelihood y magnitud de consecuencias.
Una puntuación de vulnerabilidad no reemplaza este escenario. Una matriz puede organizar conversación, pero sus escalas limitan las operaciones legítimas. La estimación profesional conserva contexto, horizonte e incertidumbre y se actualiza cuando cambian sistema, entorno o evidencia.
Comprobación de comprensión
- ¿Por qué un servidor no constituye por sí solo una descripción suficiente del activo?
- Distingue threat source, threat event y vulnerabilidad mediante un ejemplo.
- ¿Qué diferencia hay entre exposición y vulnerabilidad?
- ¿Por qué ejecución de código no describe todavía el impacto organizacional?
- ¿Qué información falta para convertir severidad técnica en una decisión de riesgo?
- ¿Por qué no deberían multiplicarse categorías ordinales sin más justificación?
- ¿Qué puede cambiar entre riesgo inherente y residual además de una puntuación?
- ¿Qué supuestos monitorizarías en el caso de recetas?
Problema de transferencia
Dos organizaciones usan la misma versión vulnerable de un servidor de archivos. En A contiene material público, está aislado y se reconstruye automáticamente. En B conserva diseños aún no publicados, acepta autenticación desde una red de proveedores y su restauración nunca fue probada. Construye escenarios separados: identifica activos, propiedades, fuentes, eventos, exposición, controles, efectos e impactos. Explica qué evidencia necesitas antes de comparar riesgo y qué parte de la severidad técnica permanece igual.
Fuentes principales
- NIST. SP 800-30 Rev. 1: Guide for Conducting Risk Assessments.
- NIST. SP 800-39: Managing Information Security Risk.
- Ron Ross, Mark Winstead y Michael McEvilley. NIST SP 800-160 Vol. 1 Rev. 1.
- NIST CSRC Glossary: Threat, Vulnerability y Risk.
- CVE Program. CNA Rules: scope definitions.
- FIRST. CVSS v4.0 Specification Document.
Esta separación permite que ingeniería, operaciones, cumplimiento y dirección cuestionen supuestos distintos sin convertir su vocabulario local en una ley general.